총정리: 웹페이지 요청에 대한 처리

서정범·2023년 5월 22일
1

네트워크

목록 보기
25/26
post-thumbnail

상황

여기서는 사용자가 웹페이지를 요청할 때 일어나는 일련의 사건들을 나열하면서 정리 해볼 것입니다.

애플리케이션 계층부터 트랜스포트 계층, 네트워크 계층, 링크 계층까지의 동작들에 대해서 다뤄볼 것이며, 앞서 정리했던 내용들을 총정리하는 방향으로 적어나갈 것입니다.

기본적인 상황은 아래 그림과 같습니다.

그림 6.32는 학생 봅(Bob)이 학교의 이더넷 스위치에 랩톱을 연결하고 웹페이지(www.google.com)을 다운로드 하는 것을 보여줍니다.

시작하기: DHCP, UDP, IP 그리고 이더넷

여기서 필요한 상황을 가정할 것입니다.

학교 라우터는 ISP comcast.net에 연결되어 있고, comcast.net은 이 학교에 DNS 서비스를 제공하며, DNS 서버는 학교 네트워크가 아닌 콤케스트(Comcast) 네트워크에 있다. DHCP 서버는 라우터에서 실행되고 있다고 가정해 봅시다.

처음에 봅이 네트워크에 랩톱을 연결하면 IP 주소 없이는 아무것도 할 수 없습니다.

따라서, DHCP 서버로부터 IP 주소를 획득하기 위해서 DHCP 프로토콜을 실행합니다.

  1. 봅의 랩톱의 운영체제는 DHCP 요청 메시지를 만들어서 이 메시지를 목적지 67(DHCP 서버)과 출발지 포트 68(DHCP 클라이언트)을 갖는 UDP 세그먼트에 넣습니다. UDP 세그먼트에는 브로드캐스트 IP 목적지 주소(255.255.255.255)와 출발지 IP 주소 0.0.0.0(봅의 랩톱이 아직 IP주소가 없기 때문)을 갖는 IP 데이터그램에 들어갑니다.
  2. 데이터그램은 이더넷 프레임에 들어가고 스위치에 연결된 모든 장치(DHCP 서버도 포함)에 이 프레임이 브로드캐스트 될 수 있도록 이더넷 프레임의 목적지 MAC 주소는 FF:FF:FF:FF:FF:FF로 설정. 출발지 MAC 주소는 봅 랩톱의 MAC 주소인 00:16:D3:23:68:8A가 됩니다.
  3. 스위치는 프레임을 자신의 모든 출력 포트(라우터로 연결된 포트도 포함)로 브로드캐스트 합니다.
  4. 라우터는 MAC 주소 00:22:6B:45:1F:1B인 인터페이스로 DHCP 요청 메시지가 포함된 브로드캐스트 이더넷 프레임을 수신하고, 이더넷 프레임으로부터 IP 데이터그램을 추출합니다. 데이터그램의 브로드캐스트 IP주 목적지 주소는 이 IP 데이터그램이 노드의 상위 계층 프로토콜에 의해서 처리되어야 함을 의미합니다. 이렇게 함으로써 데이터그램의 페이로드가 UDP로 역다중화되고 UDP 세그먼트로부터 DHCP 요청 메시지가 추출될 수 있습니다. 이제 DHCP 서버는 DHCP 요청 메시지를 갖게 됩니다.
  5. 라우터에서 실행되고 있는 DHCP 서버가 CIDR 블록 68.85.2.0/24에 있는 IP 주소들을 할당할 수 있다고 가정해 봅시다. 이 예제의 경우, 학교에서 사용되는 모든 IP 주소는 콤캐스트의 주소 블록 내에 있는 것들입니다. DHCP 서버가 봅의 랩톱에게 68.85.2.101을 할당했다고 가정합시다. DHCP 서버는 이 IP 주소와 DHCP 서버의 IP 주소, 디폴트 게이트웨이 라우터의 IP주소, 서브넷 블록을 포함하는 DHCP ACK 메시지를 만듭니다. 아까와 동일한 방법으로 이더넷 프레임으로 만든 후 출발지 MAC 주소로 라우터 인터페이스의 MAC 주소(00:22:6B:45:1F:1B)를, 목적지 MAC 주소로 봅 랩톱의 MAC 주소(00:16:D3:23:68:8A)를 갖습니다.
  6. DHCP ACK 메시지를 포함하는 이더넷 프레임은 유니캐스트를 통해서 스위치로 전송되고, 스위치는 이전에 자가학습을 하며 이더넷 프레임을 수신했기 때문에 봅의 랩톱으로 가는 출력 포트로만 전달되어야 한다는 것을 압니다.
  7. 봅의 랩톱은 DHCP ACK를 포함하는 이더넷 프레임을 수신한 후 IP 데이터그램을 추출하고, UDP 세그먼트를 추출하며, DHCP ACK 메시지를 추출합니다. 봅의 DHCP 클라이언트는 자신의 IP 주소와 DNS 서버의 IP 주소를 기록합니다. 또한 IP 포워딩 테이블에 디폴트 게이트웨이 주소를 저장합니다. 봅의 랩톱은 자신이 속한 서브넷 68.85.2.0/24의 외부를 목적지 주소로 하는 모든 데이터그램을 디폴트 게이트웨이로 보내게 됩니다. 이 시점에서 봅의 랩톱은 자신의 네트워킹 구성요소들을 초기화하고 웹 페이지 가져오기(fetch)를 처리할 준비를 합니다.

여전히 시작하기: DNS와 ARP

봅이 웹 브라우저에 URL로 www.google.com을 입력하면 웹 브라우저에 구글 홈페이지가 출력되도록 하는 긴 이벤트들이 시작됩니다. HTTP 요청 메시지를 보내기 위해 TCP 소켓을 생성하는 절차를 시작합니다. 소켓을 생성하기 위해서 봅의 랩톱은 www.google.com의 IP 주소를 알아야 합니다. DNS 프로토콜 시작합니다.

  1. 봅 랩톱의 운영체제는 DNS 질의 메시지를 생성하며, DNS 질의 메시지의 질문 부분에 "www.google.com"을 넣습니다. DNS 질의 메시지에는 목적지 포트가 53(DNS 서버)인 UDP 세그먼트에 들어가고 DNS 서버의 IP 주소를 목적지 IP 주소로 넣어주고, 본인의 IP 주소를 출발지 IP 주소로 넣어줍니다.
  2. 이더넷 프레임에 넣어주고 학교 네트워크에 있는 게이트웨이 라우터로 보내집니다. 봅의 랩톱이 학교 게이트웨이의 라우터의 IP주소를 단계 5의 DHCP ACK 메시지를 통해 알게 되기는 하지만 게이트웨이 라우터의 MAC 주소는 알 수 없습니다. 게이트웨이 라우터의 MAC 주소를 얻기 위해서 봅의 랩톱은 ARP 프로토콜을 사용하게 됩니다.
  3. 봅의 랩톱은 목표 IP 주소 68.85.2.1(디폴트 게이트웨이)을 포함한 ARP 질의 메시지를 생성하며, ARP 메시지는 브로드캐스트 목적지 주소(FF:FF:FF:FF:FF:FF)를 갖는 이더넷 프레임에 포함되어 스위치로 전송됩니다. 스위치는 게이트웨이를 포함한 모든 연결된 장치로 프레임을 전달합니다.
  4. 게이트웨이 라우터는 학교 네트워크로의 인터페이스를 통해 프레임을 수신하고, 목표 IP 주소와 자신의 인터페이스 IP 주소와 일치함을 확인합니다. 따라서 게이트웨이 라우터는 IP 주소 68.85.2.1에 대응하는 MAC 주소 00:22:6B:45:1F:1B를 포함한 ARP 응답 메시지를 만듭니다. 이것을 스위치로 보내며, 스위치는 봅의 랩톱에게 전달합니다.
  5. 봅의 랩톱은 게이트웨이 라우터의 MAC 주소를 추출합니다.
  6. 이제 봅의 랩톱은 게이트웨이 라우터의 MAC 주소로 DNS 질의 메시지가 포함된 이더넷 프렝미을 보낼 수 있습니다. 프레임의 목적지 주소가 00:22:6B:45:1F:1B인 반면, 프레임에 포함된 IP 데이터그램의 IP 목적지 주소는 68.87.71.226(DNS 서버)인 점을 주목해야 합니다. 봅의 랩톱은 프레임을 스위치로 보내고, 스위치는 프레임을 게이트웨이 라우터로 전달합니다.

DHCP는 클라이언트에게 IP 주소를 자동으로 할당해주면서 DNS 서버의 IP 주소, 기본 게이트웨이, 네트워크의 서브넷 마스크와 같은 추가적인 네트워크 설정 정보도 제공합니다.

여전히 시작하기: DNS 서버로의 인트라-도메인(Intra-Domain) 라우팅

  1. 게이트웨이 라우터는 프레임을 받아서 DNS 질의가 포함된 IP 데이터그램을 추출합니다. 라우터는 데이터그램의 목적지 주소를 포워딩 테이블에서 찾아서 콤캐스트의 좌측 상단 라우터로 보내야 함을 알게됩니다. 학교 라우터를 좌측 상단의 콤캐스트 라우터로 연결해 주는 링크에 적합한 링크 계층 프레임에 IP 데이터그램을 넣은 후, 프레임을 해당 링크로 전송합니다.
  2. 콤캐스트 네트워크의 좌측 상단 라우터는 프레임을 수신한 후, IP 데이터그램을 추출해서 데이터그램의 목적지 주소(68.87.71.226)와 포워딩 테이블[인터넷의 인터도메인(interdomain) 라우팅 프로토콜BGPRIP, OSPF 또는 IS-IS와 같은 콤캐스트의 인트라-도메인 라우팅 프로토콜에 의해서 결정됨]로부터 데이터그램을 DNS 서버로 전달할 출력 인터페이스를 결정합니다.
  3. DNS 질의가 포함된 IP 데이터그램이 DNS 서버로 도착합니다. DNS 서버는 DNS 질의 메시지를 추출한 후 DNS 데이터베이스에서 이름 www.google.com에 해당하는 IP주소를 포함하는 DNS 자원 레코드(resource record)를 찾습니다. (DNS 서버에 이 DNS 자원 레코드가 현재 캐싱되어 있다고 가정) 캐싱된 데이터는 구글콤(googlecom)에 대해 권위 DNS 서버가 준 것 입니다. DNS 서버는 호스트 이름에 대한 IP 주소 정보를 포함하는 DNS 응답 메시지를 만들어서 UDP 세그먼트에 넣은 후, UDP 세그먼트를 봅의 랩톱으로 보냅니다.
  4. 봅의 랩톱은 DNS 서버로부터 서버 www.google.com의 IP 주소를 추출합니다.

DHCP가 추가적인 네트워크 정보를 제공하면서 왜 기본 게이트웨이의 MAC주소는 할당해주지 않는 것일까?

DHCP는 주로 네트워크 레이어(IP 레벨)에서 작동하는 프로토콜이며, 이는 IP 주소와 같은 네트워크 계층의 정보를 할당하는데 사용됩니다. 반면, MAC(Media Access Control) 주소는 데이터 링크 레이어에서 사용되는 물리적인(하드웨어) 주소이며, 일반적으로 네트워크 인터페이스 컨트롤러(NIC)에 고유하게 할당됩니다. 따라서, DHCP는 MAC 주소를 할당하지 않습니다.

웹 클라이언트-서버 상호작용: TCP와 HTTP

  1. 봅의 랩톱은 받은 IP 주소를 토대로 HTTP GET 메시지를 보내기 위해서 TCP 소켓을 생성합니다. www.google.com에 있는 TCP와 3-방향-핸드셰이크를 먼저 수행해야 합니다. TCP SYN 세그먼트를 생성하고, TCP 세그먼트를 목적지 IP 주소가 64.233.169.105(www.google.com)인 IP 데이터그램에 넣은 후, 데이터 그램을 목적지 MAC 주소가 00:22:6B:45:1F:1B(게이트웨이 라우터)인 프레임에 넣어서 스위치로 전송합니다.
  2. 단계 14 ~ 16에서처럼 각 라우터의 포워딩 테이블을 사용해서 패킷을 전달합니다. 이때 사용되는 라우터의 포웓이 테이블 엔트리는 BGP 프로토콜에 의해서 결정됩니다.
  3. TCP SYN 세그먼트를 포함하는 데이터그램을 받은 www.google.com 서버는 TCP SYN 메시지를 추출하여 포트 80과 연관된 환영(welcome) 소켓으로 역다중화 됩니다. 연결(connection) 소켓은 구글 HTTP 서버와 봅 랩톱 사이의 TCP 연결의 위해서 생성됩니다. TCP SYNACK 세그먼트를 생성해서 봅 랩톱으로 데이터그램을 프레임에 담아서 전송합니다.
  4. TCP SYNACK 세그먼트가 포함된 데이터그램은 구글, 콤캐스트, 학교 네트워크를 통해 봅 랩톱의 이더넷 카드에 도착합니다. 데이터그램은 단계 18에서 생성된 TCP 소켓으로 운영체제에서 역다중화 됩니다.
  5. 이제 봅 랩톱의 소켓은 바이트를 www.google.com로 보낼 준비가 됐으며, 봅의 브라우저는 가져올(fetched) URL이 포함된 HTTP GET 메시지를 생성합니다. HTTP GET 메시지를 소켓으로 보내며, 이 HTTP GET 메시지는 TCP 세그먼트의 페이로드가 됩니다. TCP 세그먼트를 데이터그램에 넣어서 보내면 단계 18 ~ 20에서 처럼 www.google.com에 전달됩니다.
  6. www.google.com에 있는 HTTP 서버는 TCP 소켓으로부터 HTTP GET 메시지를 읽고, HTTP 응답 메시지를 생성하고 요청된 웹 페이지의 콘텐츠를 HTTP 응답 메시지의 보디(body)에 포함시켜서 TCP 소켓으로 보냅니다.
  7. HTTP 응답 메시지를 포함하고 있는 데이터그램은 구글, 콤캐스트, 학교 네트워크를 통해 봅의 랩톱에 도착합니다. 봅의 웹 브라우저 프로그램은 소켓에서 HTTP 응답 메시지를 읽어서, HTTP 응답 메시지의 바디로부터 웹 페이지에 대한 html을 추출한 후 마침내 웹 페이치를 추출합니다.

정리

위의 내용들은 자세하게 적기 위해서 되도록이면 서적에 있는 내용을 최대한 생략하지 않고 적었습니다.

결국, 웹 페이지를 받기 위해서 다음과 같은 동작들이 순서대로 이루어 졌습니다.

  1. DHCP
  2. ARP
  3. DNS
  4. TCP Connection
  5. HTTP GET

이 과정들이 위와 같은 내용들로 이루어 진 것을 확인할 수 있었습니다.

profile
개발정리블로그

0개의 댓글