웹페이지 요청 후 응답을 받기까지... (feat. DHCP, UDP, IP, Ethernet, DNS, ARP, BGP, TCP, HTTP)

주니어 개발자에게 추천하는 책 TOP 12

| 이 글은 많은 부분 [1]을 차용하였습니다

 

네트워크는 5 layers, OSI 7 계층 등과 같이 여러 가지 레이어로 나누어 구분되곤 합니다. 하지만 단순한 하나의 웹페이지 요청 후 응답을 받는데도 여러 레이어에 걸쳐서 배웠던 다양한 요소들이 관여하게 됩니다.

 

이 글에서는 웹페이지 요청 후 응답까지의 과정을 순서대로, 상세히 알아보며 다양한 레이어와 프로토콜들을 좀 더 짜임새 있게 복습해보고자 합니다:

 

• 시작1: DHCP, UDP, IP, Ethernet
• 시작2: DNS, ARP
• 시작3: Intra-Domain Routing to the DNS Server
• 웹 클라이언트-서버 인터랙션: TCP, HTTP

 

A Web page request flow - Image from Author inspired by [1]

 

시작1: DHCP, UDP, IP, Ethernet

위의 이미지처럼 밥이 자신의 노트북을 켜고 school의 이더넷 스위치에 연결된 이더넷 케이블에 연결한다고 가정해보겠습니다. 또한, 이더넷 스위치는 school의 라우터에 연결되어 있고, 그런 school의 라우터는 ISP인 comcast.net에 연결되어 있습니다. 

 

이 예시에서 comcast.net은 school에게 DNS 서비스도 제공합니다. 그러므로, DNS 서버는 school 네트워크가 아닌 Comcast의 네트워크에 존재합니다. 그리고, DHCP 서버는 (일반적인 상황과 유사하게) 라우터 안에서 실행되고 있다고 가정하겠습니다.

 

밥이 네트워크에 처음 노트북을 연결하면, 그는 IP 주소 없이 아무것(예로, 웹페이지 다운로드 하기 등)도 할 수 없습니다. 그렇기에, 가장 처음 밥의 노트북이 취하는 네트워크 관련 액션은 바로 local DHCP 서버로부터 IP 주소와 다른 정보를 얻기 위해 DHCP 프로토콜을 실행하는 것입니다.

 

1.

밥의 노트북에 있는 운영체제는 DHCP 메시지를 생성하고 목적지 포트 67(DHCP 서버) 및 소스(source) 포트 68(DHCP 클라이언트)인 UDP 세그먼트 안에 이 메시지를 넣습니다. 그 UDP 세그먼트는 이어서 브로드캐스트 IP 목적지 주소(255.255.255.255) 및 (밥의 노트북이 아직 IP 주소를 받지 못하였기에) 소스 주소(0.0.0.0)를 가진 IP 데이터그램 안에 위치하게 됩니다.

 

2. 

DHCP 요청을 포함한 1의 IP 데이터그램은 이후 이더넷 프레임 안에 들어갑니다. 이더넷 프레임은 목적지 맥(MAC) 주소 FF:FF:FF:FF:FF:FF를 가지며 이는 스위치에 연결된 모든 기기에 프레임이 브로드캐스트 되도록 합니다. 그 프레임 소스 맥 주소는 밥의 노트북의 맥 주소인 00:16:D3:23:68:8A 를 갖습니다.

 

3.

DHCP 요청을 포함한 브로드캐스트 이더넷 프레임은 밥의 노트북에 의해 이더넷 스위치에 보내진 첫 프레임입니다. 그 스위치는 들어오는 프레임을 라우터에 연결된 포트를 포함한 모든 외부로 나가는(outgoing) 포트에 브로드캐스트 합니다.

 

4.

DHCP 요청을 포함한 브로드캐스트 이더넷 요청을 맥 주소 00:22:6B:45:1F:1B 를 가진 인터페이스를 통해 받은 라우터는 이더넷 프레임에서 IP 데이터그램을 꺼냅니다. 그 꺼내진 데이터그램의 브로드캐스트 IP 주소는 IP 데이터그램이 이 노드에서 상위 레이어 프로토콜을 통해 처리되야 한다는 사실을 나타냅니다. 이어서 데이터그램의 payload(한 개의 UDP 세그먼트)가 UDP로 demultiplexed되어 올라가고 UDP 세그먼트에서 DHCP 요청을 꺼낼 수 있게 됩니다. 이어 그 DHCP 서버는 DHCP 요청 메시지를 전달받게 됩니다.

 

5.

그 라우터 안에서 실행되는 DHCP 서버가 CIDR 블록 68.85.2.0/24 에 속하는 IP 주소를 할당할 수 있다고 가정하겠습니다. 이 예시에서, school에서 사용되는 모든 IP 주소들은 그러므로 Comcast의 주소 블록 안에 포함됩니다. DHCP 서버가 밥의 노트북에 68.85.2.101 의 IP를 할당했다고 하겠습니다. 

 

DHCP 서버는 하나의 DHCP ACK 메시지를 생성하는데, 그 안에는 할당한 IP 주소, DNS 서버의 IP 주소(68.87.71.226), 디폴트 게이트웨이 라우터의 IP 주소(68.85.2.1), 서브넷 블록의 IP 주소(68.85.2.0/24)가 들어있습니다. 그 DHCP 메시지는 이어 UDP 세그먼트에 넣고, UDP  세그먼트는 다시 IP 데이터그램 안에, IP 데이터그램은 다시 이더넷 프레임 안에 들어갑니다. 그 이더넷 프레임은 라우터의 home 네트워크를 향한 인터페이스의 맥 주소인 소스 맥 주소와 밥의 노트북 맥 주소(00:16:D3:23:68:8A)를 목적지 맥 주소로 가집니다.

 

6.

DHCP ACK를 가진 이더넷 프레임은 라우터에 의해(unicast) 스위치로 송신됩니다. 그 스위치는 밥의 노트북으로부터 이전에 (DHCP 요청을 가진)이더넷 프레임을 받았었고 self-learning하기 때문에, 스위치는 오직 밥의 노트북으로 연결되는 외부 포트에만 보내어 00:16:D3:23:68:8A로 그 프레임을 포워딩하면 된다는 사실을 알고 있습니다.

 

7.

밥의 노트북은 DHCP ACK가 포함된 이더넷 프레임을 받고 IP 데이터그램은 이더넷 프레임에서 꺼내고, 다시 UDP 세그먼트는 IP 데이터그램에서, DHCP ACK 메시지를 그 UDP 세그먼트에서 꺼냅니다. 밥의 DHCP 클라이언트는 이어 할당받은 IP 주소와 DNS 서버의 IP 주소를 기록합니다.

 

DHCP 클라이언트는 이어 디폴트 게이트웨이의 주소를 IP 포워딩 테이블에 설치합니다. 이제 밥의 노트북은 목적지 주소가 서브넷 68.85.2.0/24를 벗어나는 모든 데이터그램은 해당 디폴트 게이트웨어로 보내게 됩니다. 이로써 밥의 노트북은 네트워킹 컴포넌트를 시작하고 웹페이지 fetch 처리를 시작할 준비가 되었습니다.

 

 

시작2: DNS, ARP

밥이 웹 브라우저 안에 www.google.com라는 URL를 타이핑하면서, 최종적으로 해당 브라우저 안에 구글의 홈페이지가 보이는 결과로 나타내기까지 필요한 기나긴 이벤트 체인을 시작하게 됩니다. 밥의 웹 브라우저는 그 프로세스를 TCP 소켓을 생성하며 시작하는데, 그 TCP 소켓은 HTTP 요청을 www.google.com로 보내는데 사용됩니다. 그 소켓을 생성하기 위해서, 밥의 노트북은 www.google.com의 IP 주소를 알고 있어야만 합니다. DNS 프로토콜은 이러한 name-to-IP-주소 번역 서비스를 제공하는데 사용됩니다.

 

8.

밥의 노트북에 있는 운영체제는 DNS 쿼리 메시지를 생성하고, 문자열 "www.google.com"을 DNS 메시지의 질문섹션에 넣습니다. 이 DNS 메시지는 이후 목적지 포트 53(DNS 서버)를 가진 UDP 세그먼트에 들어갑니다. 그 UDP 세그먼트는 이어 목적지 주소 68.87.71.226(5번에서 DHCP ACK를 통해 받은 DNS 서버의 주소)와 소스 IP 주소 68.85.2.101 를 가진 IP 데이터그램에 들어갑니다.

 

9.

이어 밥의 노트북은 DNS 쿼리 메시지를 포함하는 데이터그램을 이더넷 프레임 안에 넣습니다. 이 프레임은 밥의 school의 네트워크 안의 게이트웨이 라우터로 송신(link 레이어로 전달되어)됩니다. 그러나, 위의 5번의 DHCP ACK 메시지를 통해 school의 게이트웨이 라우터 IP 주소(68.85.2.1)를 알고 있더라도 게이트웨이 라우터의 맥 주소를 알지는 못하는 상태입니다. 게이트웨이의 맥 주소를 얻기 위해서, 밥의 노트북은 ARP 프로토콜을 사용하게 됩니다.

 

10.

밥의 노트북은 타겟 IP 주소 (디폴트 게이트웨이 주소인)68.85.2.1를 가진 ARP 쿼리 메시지를 생성하고 그 ARP 메시지를 브로드캐스트 주소 (FF:FF:FF:FF:FF:FF)를 가진 이더넷 프레임 안에 넣습니다. 이후 그 이더넷 프레임을 스위치에 보내고, 그 스위치는 그 프레임을 게이트웨이 라우터를 포함한 연결된 모든 기기에 전달합니다.

 

11.

school 네트워크를 향한 인터페이스로 ARP 쿼리 메시지를 포함한 프레임을 받은 게이트웨이 라우터는 그 인터페이스의 IP 주소에 매칭되는 타겟 IP 주소 68.85.2.1 을 ARP 메시지에서 찾아냅니다. 이후 게이트웨이 라우터는 IP 주소 68.85.2.1 에 상응하는 맥 주소 00:22:6B:45:1F:1B 를 나타내는 ARP reply를 준비합니다. 이어 그 ARP reply 메시지를 목적지 주소 00:16:D3:23:68:8A 를 가진 이더넷 프레임에 넣어 스위치로 보내고, 스위치는 이어 그 프레임을 밥의 노트북에 전달합니다.

 

12.

밥의 노트북은 ARP reply 메시지는 포함한 프레임을 받고 게이트웨이 라우터(00:22:6B:45:1F:1B)의 맥 주소를 꺼냅니다. 

 

13.

밥의 노트북은 이제 게이트웨이 라우터의 맥 주소를 향한 DNS 쿼리를 포함한 이더넷 프레임을 보낼 수 있습니다. 이 프레임 안의 IP 데이터그램은 IP 목적지 주소 68.87.71.226(DNS 서버)를 가지는 반면, 프레임의 목적지 주소는 00:22:6B:45:1F:1B(게이트웨이 라우터)를 가집니다. 밥의 노트북은 이 프레임을 스위치로 보내고, 스위치는 이어서 이 프레임을 라우터에 보냅니다.

 

시작3: Intra-Domain Routing to the DNS Server

14.

게이트웨이 라우터는 위의 프레임을 받아서 DNS 쿼리를 가진 IP 데이터그램을 꺼냅니다. 그 라우터는 이 데이터그램의 목적지 주소(68.87.71.226)를 살피고 포워딩 테이블을 참고하여 이 데이터그램이 위의 이미지에서 Comcast 네트워크 가장 왼쪽 라우터로 보내져야 한다는 것을 결정합니다. 그 IP 데이터그램은 Comcast의 가장 왼쪽 라우터와 school의 라우터를 연결하는 링크에 해당되는 링크 레이어 프레임에 놓이게 됩니다. 그리고 그 프레임은 이 링크를 통해 전송됩니다.

 

15.

Comcast 네트워크의 가장 왼쪽 라우터는 그 프레임을 받고, IP 데이터그램을 꺼내고, 데이터그램의 목적지 주소 (68.87.71.226)을 확인한 후 포워딩 테이블을 참고하여 DNS 서버로 향하는 외부 방향 인터페이스를 결정합니다. 그러한 포워딩 테이블은 Comcast의 intra-domain 프로토콜(RIP, OSPF 또는 IS-IS 등)과 Internet의 inter-domain 프로토콜인 BGP에 의해서 채워져 있습니다.

 

16.

결국 DNS 쿼리를 포함한 IP 데이터그램은 DNS 서버에 도착하게 됩니다. 그 DNS 서버는 DNS 쿼리 메시지를 꺼내고 DNS 데이터베이스에서 www.google.com을 찾습니다. 이어 www.google.com에 해당되는 IP 주소(64.233.169.105)를 가진 DNS resource record를 찾아냅니다(DNS 서버에 캐싱되어 있다고 가정). 이 캐싱된 데이터는 google.com을 위한 authoritative DNS 서버로부터 기원합니다. 

 

DNS 서버는 hostname-to-IP-주소 매핑을 포함한 DNS reply 메시지를 생성하고 UDP 세그먼트에 넣고, 그 세그먼트는 다시 밥의 노트북 주소(68.85.2.101)를 목적지 주소로 가진 IP 데이터그램에 들어갑니다. 이 데이터그램은 Comcast 네트워크를 통해 다시 school의 라우터로 포워딩되고, 거기서부터 이더넷 스위치를 통해 밥의 노트북으로 전달됩니다.

 

17.

밥의 노트북은 서버 www.google.com의 IP 주소를 DNS 메시지로부터 꺼냅니다. 마침내, 밥의 노트북은 www.google.com 서버에  접근할 준비가 완료되었습니다. 

 

 

웹 클라이언트-서버 인터랙션: TCP, HTTP

18.

이제 밥의 노트북은 www.google.com의 IP 주소를 가지고 있어서, www.google.com에 보낼 HTTP GET 메시지를 송신하는 데에 사용되는 TCP 소켓을 생성할 수 있습니다. 그 TCP 소켓을 밥이 생성했을 때, 밥의 노트북에 있는 TCP는 www.google.com에 있는  TCP와 three-way handshake를 해야만 합니다. 그렇기에 밥의 노트북은 먼저 목적지 포트 80(HTTP)를 가진 TCP SYN 세그먼트를 생성하고, 그 TCP 세그먼트를 IP 주소 64.233.169.105(www.google.com)를 가진 IP 데이터그램에 넣습니다. 그리고 그 데이터 그램을 맥 주소 00:22:6B:45:1F:1B(게이트웨이 라우터)를 가진 프레임에 넣고 스위치에 그 프레임을 보냅니다.

 

19.

school 네트워크, Comcast의 네트워크, 구글의 네트워크에 있는 라우터들은 TCP SYN을 포함한 데이터그램을 각 라우터 안에 있는 포워딩 테이블을 사용하여 www.google.com를 향해 포워딩 합니다 (위의 14 ~ 16번과 유사하게). 여기서 라우터 포워딩 테이블은 Comcast 간의 inter-domain 네트워크에서의 패킷 포워딩을 관장하고 구글 네트워크는 BGP 프로토콜을 통해 결정됩니다.

 

20.

결국 TCP SYN을 포함한 데이터그램은 www.google.com에 도착합니다. 그 TCP SYN 메시지는 데이터그램으로부터 꺼내어지고 포트 80과 연관된 welcome socket으로 demultiplexed됩니다. 구글 HTTP 서버와 밥의 노트북 간의 TCP 연결을 위해 하나의 연결 소켓이 생성됩니다. TCP SYNACK 세그먼트가 생성되고, 밥의 노트북을 향하는 데이터그램에 들어가고, www.google.com과 첫 hop에 해당되는 라우터를 연결하는 링크에 해당되는 링크 레이어 프레임에 그 데이터그램이 놓이게 됩니다.

 

21.

TCP SYNACK를 포함한 데이터그램은 구글, Comcast, school 네트워크들을 통해 포워딩되어 밥의 노트북의 이더넷 카드에 도착하게 됩니다. 그 데이터그램은 운영체제 안에서 위의 18번에서 생성된 TCP 소켓으로 demultiplexed되고, TCP 소켓은 연결 상태로 전이하게 됩니다.

 

22.

밥의 노트북에 있는 소켓은 이제 www.google.com에 바이트를 송신할 준비가 되었기에, 밥의 브라우저는 fetch할 URL을 포함한 HTTP GET 메시지를 생성합니다. 그 HTTP GET 메시지는 소켓에 TCP 세그먼트의 payload인 GET 메시지로 write됩니다. TCP 세그먼트는 데이터그램 안에 들어가고 위 18 ~ 20번 단계와 같이 www.google.com로 전달됩니다. 

 

23.

www.google.com의 HTTP 서버는 TCP 소켓으로부터 HTTP GET 메시지를 읽고, HTTP response 메시지를 생성하고, 요청된 웹 페이지 컨텐츠를 HTTP response 메시지 body에 넣고, 그 메시지를 TCP 소켓으로 보냅니다.

 

24.

HTTP reply 메시지를 포함한 데이터그램은 구글, Comcast, school 네트워크를 통해 포워딩되고 밥의 노트북에 도착합니다. 밥의 웹 브라우저 프로그램은 소켓으로부터 HTTP response를 읽어서 HTTP response body에서 웹페이지에 해당되는 html을 꺼내고, 마침내 웹페이지를 보여주게 됩니다!

 

 

 

 

이와 같은 예시는 여러 가능한 대안 프로토콜 및 상세(school 게이트웨이 라우터의 NAT, school 네트워크에 wireless 액세스, school 네트워크 접근에 대한 security 프로토콜, 웹 캐싱, DNS hierarchy 등)를 제외하였습니다. 

 

 

 

Reference

[1] Computer Networking: A Top-Down Approach

 

 

4년차 자바 백엔드 기술 질문들