TIL29, HTTP / 네트워크 기초

HTTP와 네트워크의 기초를 배워보자.

백엔드가 뭘까? 프론트엔드 개발자와 백엔드 개발자는 뭘 하지? 라는 생각이 여러번 들었었다.

대충.. 이러저러한게 백엔드다! 라고 생각은 했지만 너무나도 막연한 개념이었다.

오늘, 네트워크, 서버에 대해 배우며 그 막연한 개념을 조금이나마 채운것 같다.

물론 아직도 막연한건 사실이다..🐳

그럼 지금 상태에서 프론트엔드 개발자와 백엔드 개발자가 무엇인지 알아 보자.

프론트엔드 개발자는 주로 사용자가 직접 사용하고, 눈으로 보고, 상호작용할 수 있는 앱을 개발하며,

백엔드 개발자는 사용자가 직접 볼 수는 없지만, 상품 정보를 API로 노출 시키거나, 로그인/로그아웃, 권한 관리등의 사용자 인증을 주로 다룬다. 데이터 베이스 등의 시스템 설계까지 맡는 경우도 많다.

클라이언트 - 서버 아키텍처

우리의 로켓배송 Cupang을 예로 들어보자.

상품정보, 이미지 등과 같은 ‘리소스’가 존재하는 곳과, 그 ‘리소스’를 사용하는 ‘앱’을 분리시킨 것을

2티어 아키텍처 또는 클라이언트 - 서버 아키텍처 라고 부른다.

리소스를 사용하는 ‘앱’이 클라이언트, ‘리소스’가 제공하는 곳은 서버이다.

클라이언트는 말 그대로 고객, 사용자라고 생각하고, 서버 역시 말 그대로 serve(제공) + er (자) 제공하는 자, 서비스를 제공하는자(점원)라고 생각하자.

클라이언트가 서버에게 요청을 하는것이 선행되고, 서버가 클라이언트에게 응답을 한다.

→ 고객이 점원에게 주문을 하고 (클라이언트가 서버에 요청),

점원이 고객에게 받은 주문에 따라 물건을 내준다 (서버가 클라이언트에게 응답을 한다)

클라이언트의 요청이 있어야만 응답을 하며, 서버의 마음대로 클라이언트에 리소스를 전달하지 않는다.

(영화 극한직업에서는 치킨집 사장님(서버)이 마음대로 마약반 형사들(클라이언트)에게 치킨을 서비스로 주지만,

우리가 배우는 이곳에서 그런건 없다 ㅎ)

일반적으로 서버는 리소스를 전달해주는 역할만 담당하며,

그 리소스를 저장하는 데이터 베이스를 갖고있기도 한다.

→ 점원은 고객에게 요청을 하지 않고, 전달해주기만 한다. 때로는 가게에 창고가 있어,그 창고에 물건을 잔뜩 저장해 놓고 주문받은 물건을 창고에서 꺼내오기도 한다. (데이터 베이스)

이렇게 기존 2티어 아키텍처에 데이터 베이스가 추가된 형태를 3티어 아키텍처라고 부른다.

각 플랫폼별 클라이언트

브라우저를 통한 웹 플랫폼

→ 웹 사이트, 웹 앱 (웹 애플리케이션)

IOS, Android 등

→ 앱 (애플리케이션)

프로토콜

→ 클라이언트와 서버의 의사소통을 위한 통신 규약.

HTTP라는 프로토콜을 이용해 서로 대화를 나눈다. (HTTP에 대해서는 밑에서 더 알아보도록 하자)

이렇게 나눈 대화를 HTTP message라고 부른다.

프로토콜은 다양하게 존재한다.

치킨을 주문(서버에 요청)하는 방법은

배달앱을 통해 주문하거나, 매장에 방문해 직접 주문하거나, 매장 내의 키오스크를 통해 주문하는 등

주문 방법(프로토콜)은 다양하다.

주요 프로토콜

프로토콜에는 OSI 7 Layers라는 7개의 계층이 존재한다.

(이 OSI 7 Laters는 간혹 면접에서 질문이 들어올수도 있다)

1. 물리
2. 데이터 링크
3. 네트워크 계층
4. 전송 계층
5. 세션 계층
6. 표현 계층
7. 응용 계층

이 중에서 응용 계층과 전송 계층에 대해서 알아보자.

응용 계층

• HTTP (Hyper Text Transfer Protocol)

  → 웹에서 HTML, JSON등의 정보를 주고받는 프로토콜.

• HTTPS

  → HTTP에서 보안이 강화된 프로토콜 (HTTP + Secure)

• FTP (File Transfer Protocol)

  → 파일 전송 프로토콜

• SMTP (Simple Mail Trnasfer Protocol)

  → 메일 전송 프로토콜

• SSH (Secure SHell)

  → CLI 환경의 원격 컴퓨터에 접속하기 위한 프로토콜

• RDP (Remote Desktop Protocol)

  → Windows 계열의 원격 컴퓨터에 접속하기 위한 프로토콜

• WebSocket

  → 실시간 통신, Push 등을 지원하는 프로토콜

전송 계층

• TCP

  → HTTP, FTP 통신의 근간이 되는 인터넷 프로토콜.

• UDP

  (양방향인 TCP와는 다르게) 단방향으로 작동하여 훨씬 더 단순하고 빠르지만, 신뢰성이 낮은 인터넷 프로토콜.

API (Application Programming Interface)

클라이언트가 리소스를 잘 활용할 수 있도록 인터페이스를 제공해야 하는데, 이것을 API라고 한다.

→ 차를 보기위해 BMW 전시장에 갔다.

전시장에 방문한 고객(클라이언트)을 위해 딜러(서버)가 차량 정보(리소스)가 담긴 카탈로그(API, 인터페이스)를 제공하여 차량 정보(리소스)를 잘 활용할 수 있도록 한다.

당연하게도 리소스 전달을 위해선 API를 구축해 놓아야 클라이언트가 활용할 수 있다.

이때 ‘주소’를 통해 API에 접근한다.

아래와 같이 BMW API 서버가 제공하는 URL 예시를 보자.

HTTP API 디자인을 잘 하는 방법

HTTP API 디자인을 잘 하는 방법은.. HTTP method를 기억하는것이다 ^^

( C R U D )

• 추가 (Create) → POST
• 조회 (Read) → GET
• 갱신 (Update) → PUT 또는 PATCH
• 삭제 (Delete) →> DELETE

URL과 URI

URL (Uniform Resource Locator)은 서버가 제공되는 환경에 존재하는 파일의 위치를 나타낸다.

CLI환경에서 폴더와 파일의 위치를 찾아 이동하듯이, / 을 이용해 서버의 폴더에 진입하거나, 파일을 요청할 수 있다.

scheme, hosts, url-path로 구분할 수 있다.

schem → 가장 먼저 작성하며, 통신 방식 (Protocol)을 결정한다. 일반적인 웹 브라우저에서는 https(s)를 사용한다.

hosts → 웹 서버의 이름이나 도메인, IP를 사용하며, 주소를 나타낸다.

url-path → 웹 서버에서 지정한 루트 디렉토리부터 시작하여 웹 페이지, 동영상, 이미지 등이 위치한 경로와 파일명을 나타낸다.

URI (Uniform Resource Identifier) 는 URL의 기본 요소에 query, bookmark를 포함한다.

query → 웹 서버에 보내는 추가적인 질문.

URI는 URL을 포함하는 상위 개념이다.

위의 그림과 같이, URI에는 query가 포함되지만, URL은 포함되지 않는다.

그 외에도 작성상의 차이점이 존재한다.

IP와 포트

IP

네트워크에 연결된 특정 PC의 주소를 IP address (Internet Protocol address, IP주소) 라고 한다.

지구상에 있는 인터넷에 연결된 모~든 PC는 IP 주소 체계를 따라 IP를 부여 받고, 네덩이의 숫자로 구분된다.

(예 : 192.168.32.1)

위 예와 같이 4개의 덩어리로 구분된 IP를 IPv4 (Internet Protocol version 4)라고 한다. (4번째 버전)

각 덩어리마다 0부터 255까지 나타낼 수 있다.

이 중에서 몇 가지 IP 주소는 ‘이미’ 용도가 정해져있는데, 아래 주소는 반드시 기억하자.

• localhost, 127.0.0.1 → 현재 사용중인 로컬 PC를 지칭한다.
• 0.0.0.0, 255.255.255.255 → broadcast address, 로컬 네트워크에 접속된 모든 장치와 소통하는 주소. 서버에서 접근 가능 IP 주소를 broadcast address로 지정하면 모든 기기에서 서버에 접근할 수 있다.

IPv4는 약 2^(32)개, 즉 약 43억개의 IP주소를 만들 수 있는데, 오늘날 전세계에 PC가 보급됨에 따라 누구나 인터넷에 접속하고, 각종 웹사이트와 서비스들이 우후죽순 생겨나며 서버를 생산하는 바람에, IPv4로 감당할 수 있는 범위를 벗어나 버렸고, 이로인해 IPv6 (IP version 6) 가 나왔다.

이 6번째 버전은 2^(128)개의 IP 주소를 할당할 수 있게 됐다.

(웹서버의 IP주소 확인하는 방법 → 터미널에 'nslookup <웹페이지 주소>'를 입력한다)

PORT

리액트를 배울때, 주소창에 localhost:3000이라는 주소를 많이 봤을것이다.

이는 로컬 PC의 IP에 접근해서 3000번의 통로를 통해 실행중인 리액트를 확인하는 것이다.

이 통로를 PORT라고 부르고, 사용중은 PORT는 중복해서 사용할 수 없다.

이미 3000번 포트를 사용중이라면, 3001번 포트가 배정된다.

포트 번호는 0번부터 65,535번까지 사용할 수 있으며, 이중에 0부터 1,024번 까지의 포트는 규약에 의해서 이미 정해져있다. 아래의 포트는 반드시 알아두도록 하자..

• 22 : SSH
• 80 : HTTP
• 443 : HTTPS

domain과 DNS

domain

특정 사이트의 IP주소를 대신해서 사용하는 주소를 domain이라고 부른다.

IP주소는 어떤 치킨집의 주소이고, Domain은 그 주소의 치킨집 상호명이다.

예를 들어보자.

로스엔젤레스의 중앙도서관을 지칭할때,

위도와 경도를 이용해 34.05038132480491, -118.25551500344291라고 표현하면

이곳이 도대체 어디인지, 무엇을 하는 곳인지 전혀 알 수가 없다.

하지만 로스엔젤레스 중앙도서관 이라고 얘기하면 이곳이 어디인지, 무엇을 하는 곳인지 쉽게 알아차릴 수 있다.

이때 위도와 경도가 마치 IP, 로스엔젤레스 중앙도서관 을 domain이라고 생각하면 된다.

DNS (Domain Name System)

IP주소가 domain 이름을 가질 수 있도록 해준다.

이 domain 이름은 일정 기간동안 대여해서 사용하는 것이다.

이 때, IP 주소와 도메인 이름이 일치하는지 확인하는 작업이 필수인데, 이를 위한 서버가 별도로 존재한다.

그것이 바로 DNS이다.

만약, 주소창에 naver.com을 입력하면, DNS에서 naver.com의 IP주소 (223.130.195.95)를 찾은 뒤, 이 IP주소의 웹서버로 요청을 전달해 클라이언트와 서버가 통신할 수 있도록 해준다.

HTTP

프로토콜에서 언급했던 HTTP에 대해서 조금 더 자세히 알아보도록 하자.

HTTP는 Hyper Text Transfer Protocol의 줄임말이다.

HTML과 같은 문서를 전송하기 위한 Application Layer 프로토콜이며, 웹 브라우저와 웹 서버의 소통을 위해서 디자인 됐다.

HTTP는 Stateless (무상태성)이라는 특징을 가지는데, 이거 중요하다.

HTTP는 클라이언트나 서버의 상태를 확인하지 않는다.

만약, 어떤 웹 사이트의 로그인 창에서 로그인 버튼을 눌렀을 때, 로그인 정보를 저장해둬야 하지만, HTTP는 단지 통신 규약 일 뿐이므로 상태를 저장하지 않는다.

필요에 따라서 쿠키-세션, API등을 이용해 상태를 확인할 수 있다.

SSR과 CSR

SSR (Server Side Rendering)

→ 웹 페이지를 브라우저에서 렌더링하는 대신에, 서버에서 렌더링 한다.

브라우저가 서버의 URI로 ‘GET’ 요청을 보내면, 서버는 정해진 웹 페이지 파일을 브라우저로 전송하고,

서버의 웹 페이지가 브라우저에 도착하면 완전히 렌더링된다.

서버에서 브라우저로 보내기 전에 서버에서 완전히 렌더링 됐기 때문에 Server Side Rendering이라고 부르는 것이다.

그럼 이 SSR은 언제 사용할까?

• SEO (Search Engine Optimization)이 우선인 경우
• 웹 페이지의 첫 화면 렌더링이 빠르게 필요한 경우 ( SSR은 단일 파일의 용량이 작기 때문에 최초 렌더링이 빠르게 적용된다.)
• 웹 페이지가 사용자와의 상호작용이 적은 경우.

CSR (Client Side Rendering)

→ SSR의 반대 개념.

서버에서 렌더링을 하는것이 아니라, 클라이언트에서 페이지를 렌더링 한다.

브라우저의 요청을 서버로 보내면, 서버는 웹 페이지를 렌더링하는게 아니라, 웹 페이지의 골격이 될 단일 페이지를 클라이언트에 보낸다.

이때, 서버는 웹 페이지와 함께 JavaScript 파일을 보낸다.

클라이언트가 웹 페이지를 받으면, 웹 페이지와 함께 전달된 JavaScript 파일은 브라우저에서 웹 페이지를 완전히 렌더링 된 페이지로 바꾼다.

이녀석은 언제 사용할까?? SSR과 반대로 생각하면 된다!

• SEO (Search Engine Optimization)이 우선이 아닌 경우
• 사이트에 풍부한 상호 작용이 있는 경우. 빠른 라우팅으로 강력한 UX를 제공한다.
• 웹 애플리케이션을 제작하는 경우.