[HTTP] 웹브라우저의 요청 흐름

 

 

이전 글에서 프로토콜은 '규약', '규칙'을 의미한다고 이야기 했다.

그렇다면 인터넷 프로토콜 스택에는 4계층이 이루어져 있는데 이에 대해 알아보자.

 

먼저, 프롵토콜 스택이란 데이터 통신에 활용되는 프로토콜의 구조에 관한 개념으로 계층화된 구조로 모여있는 프로토콜의 집합이라 생각하면된다. 그래서 우리는 이를 (Protocol Family)라고 부르기도 한다.

이러한 프로토콜은 용도에 따라 4개의 계층으로 이루어져 있다. 

 

인터넷 프로토콜 스택 4계층

 

• 어플리케이션 계층 : 프로세스간 통신을 위해 설계된 계층. 예시) HTTP, FTP, TLS/SSL
• 전송 계층(Transport Layer) : 송신자와 수신자를 연결하는 서비스에 대한 정보를 담는 계층. 예) TCP, UDP
• 인터넷 계층 : 패킷을 목적지로 전송하기 위한 정보를  계층 예) IP
• 네트워크 인터페이스 계층 : LAN 드라이버, LAN 장비 등 물리적 전송을 위한 계층

출처: 강의 '모든 개발자를 위한 HTTP 웹 기본지식' (김영한) 인프런

실제 인터넷을 이용해 서로 통신할 때 위와 같이 하나씩 덧씌어져 서버에 보내진다고 생각하면 된다. 

자, 그러면 이제 출발지와 목적지를 담은 IP를 보완해주는 정보를 담는 TCP, UDP에 대해 알아보자. 

 

---

1. TCP / IP 패킷 정보

여기서 패킷은 'package' + 'buket'의 합성어로 한 마디로 '수하물 덩어리'라고 생각하면 된다. 

 

출처: 강의 '모든 개발자를 위한 HTTP 웹 기본지식' (김영한) 인프런

TCP는 Transmission Control Protocol의 약자로 전송 제어 프로토콜이라고 생각하면 된다. 즉, 전송을 어떻게 할지를 제어하는 규약이다. TCP를 이용하면 IP 만으로 해결이 되지 않았던 '순서', '전송' 제어 등이 가능하다. 

 

TCP의 특징은 아래와 같다. 

 

1. 연결 지향 - TCP 3 way handshake (가상연결)

  IP는 그저 상대 컴퓨터가 켜져 있는지 없는지 상관없이 그냥 보내기만 한다면, TCP는 이러한 점을 보완하여 대상 컴퓨터와 내가 연결이 되는지를 확인하고 메시지를 보낸다. 즉, 가상연결이 먼저 이루어진 다음에 실제 '전송'을 하는 것이다. 이를 TCP 3 way handshake라 하는데 이는 실제로 그 연결 단계가 3번이나 이루어지기 때문이며 이에 대한 자세한 내용은 여기서 다루지는 않겠다. 

 

2. 데이터 전달을 보증할 수 있다. 

  IP 같은 경우, 상대 컴퓨터가 꺼져 있어서 전송이 이루어지지 않아도 확인할 방법이 없었다면, TCP는 데이터를 보낸 후 상대 컴퓨터에서 확인 메시지를 받기 때문에 메시지가 누락될 경우, 이를 알 수 있다. 

 

3. 패킷의 순서가 보장된다.

  패킷의 순서가 잘못된 경우, 대상 컴퓨터는 TCP에 적힌 메시지와 비교하기 떄문에 순서가 잘못된 것을 인식하여 해당 번호부터 다시 보내라고 클라이언트에 요청하게 된다. 이것이 가능한 이유는 TCP에 전송제어 정보, 순서 정보들이 포함되어 있기 때문이다. 

 

즉, TCP는 신뢰할 수 있는 프로토콜이며 IP를 보완하기에 현재, 대부분 TCP를 사용한다.

 

---

2. UDP의 특징

UDP란 User Datagram Protocol의 약자로 사용자 데이터그램 규약이라 생각하면 된다.

 

이는 사실 '하얀 도화지'와 같다. 기능이 거의 없기 때문이다.

데이터 전달 보증이나 순서 보장이 안된다는 점에서 IP와 거의 비슷하다.

 

그러나 PORT와 '체크섬' 정보와 기능이 추가된다는 점이 특징적이다.

 

그렇다면 IP에는 없지만 UDP와 TCP에 있는 port란 무엇인가?

 

자, 여러분이 평상시에 사용하는 노트북을 생각해보자. '인터넷 동작 방식'에 대한 발제를 하기 위해 노트북을 열었다. 

그렇다면 당신은 과연 발제를 준비하기위한 keynote만 켤 것인가?

 

일단, 한국인의 필수 통신인 '카카오톡'부터 열고 시작하며, 음악도 들으면서 인터넷 검색도 하면서 동시에 가십거리 기사도 보고 있을 수 있다. 이렇듯 우리는 하나의 컴퓨터(하나의 IP)로 게임도 하고 음악도 듣고 있는 등 다양한 일을 한다. 그러면 내 컴퓨터 IP에 여러 패킷이 들어오게 되는데 각각 어떤 패킷인지 구분해 주는 정보가 바로 PORT이다. 

더불어 이 메시지에 대해 제대로 맞는지 검증해주는 것이 '체크섬'인 것이다.

 

그러면 UDP의 특징은 그저 PORT와 체크섬 정도인 것 같은데 PORT 정보는 TCP도 가지고 있는데 왜 굳이 UDP가 필요할까?

TCP는 3 way handshake 도 해야하기 때문에 은근히 시간이 좀 걸릴 수 있다. 

데이터 양이 많다면 속도도 좀 더 느려질 수 밖에 없다.

 

이럴때, 최적화 하고 싶을 때 TCP는 그대로 두고 UDP에 손을 대어 최적화를 하면 된다. 

그래서 이 UDP 프로토콜이 최근에 각광을 받고 있다. 

---

3. 웹브라우저의 요청 흐름

자, 그럼 다시 정리를 해보자.

우리가 구글 웹사이트에 접속하려 한다고 생각해보자.

그럼 그 과정은 아래와 같다.

 

1. 사용자가 url을 작성한다. (https://www.google.com:443)

 

2. www.google.com  주소의 DNS를 조회하여 IP주소를 얻는다. https의 port 443은 생략된다.

 

3. 웹브라우저에서 http 요청 메시지를 생성한다.

 

4. soket 라이브러리를 이용해 TCP/IP(3 way handshake 포함) 연결 후 대상 IP에 데이터(http 메시지)를 전달한다.

 

5. 이렇게 패킷이 인터넷 망에 딱 던져지면 수 많은 노드를 통해 대상 IP로 전달이 된다.

 

6. 대상 서버인 구글서버에 요청패킷이 도착하면 구글 서버는 TCP/IP를 까서 버리고 안에 있는 HTTP 메시지를 해석한다.

 

7. get요청이 담긴 이 메시지에 해당하는 정보를 찾은 후 '응답 메시지'를 만들어 아래와 같이 'HTTP 응답 메시지'를 클라이언트에 보낸다.

출처: 강의 '모든 개발자를 위한 HTTP 웹 기본지식' (김영한) 인프런

8. 클라이언트는 받은 응답 메시지의 내용을 화면에 보여준다.

---

출처 :

'모든 개발자를 위한 HTTP 웹 기본 지식' -김영한 (인프런강의)

(https://www.inflearn.com/course/http-%EC%9B%B9-%EB%84%A4%ED%8A%B8%EC%9B%8C%ED%81%AC/dashboard)