오늘의 인기 글
최근 글
최근 댓글
Today
Total
11-24 10:55
관리 메뉴

우노

[Network] www.google.com 접속 흐름 본문

Network & Security/Concept

[Network] www.google.com 접속 흐름

운호(Noah) 2022. 6. 10. 18:57

들어가기 앞서,

  • 만약, www.google.com 을 웹 브라우저에 입력하면 무슨 일이 일어날까요?
    • 구글 웹서버에 80번 포트로 HTTP Request 를 보낸다는 의미와 동일합니다.
  • 해당 포스팅에선, 웹 요청 및 응답의 흐름을 간단하게 요약하고, 자세한 내용까지 다뤄보겠습니다.

흐름 간단 요약

  • www.google.com 을 브라우저 주소창에 입력합니다.
  • 보낼 패킷의 HTTP 헤더는, HTTP Request 를 통해 채워진 상태입니다.
  • 보낼 패킷의 IP 헤더를 채우기 위해, DNS 서버를 통해 www.google.com 도메인의 IP 주소를 응답 받습니다.
  • 보낼 패킷의 TCP 헤더를 채우기 위해, 클라이언트와 구글 웹서버 간 TCP 연결을 합니다.
    • 3-Way Handshaking
  • 보낼 패킷이 완성되었으므로, www.google.com 에 패킷을 전송하고, HTML 을 응답받습니다.
  • 클라이언트는 응답 받은 HTML 을 브라우저에 띄웁니다.
  • 클라이언트와 구글 웹서버간 TCP 연결을 종료합니다.
    • 4-Way Handshaking

자세한 TCP/IP 흐름

  • 우선, 구글 웹 서버에 HTTP Request 를 보내기 위해선, 아래와 같이 각 계층에 필요한 정보들을 담은 패킷을 만들어야합니다.

    • 해당 예제에선, 각 계층 별로 HTTP, TCP, IP, Ethernet 프로토콜을 사용한다고 가정해보겠습니다.
  • 따라서, Application, Transport, Internet, Network Access Layer 순으로 어떤 데이터가 들어가는지 순서대로 살펴보겠습니다.

  • 먼저, 패킷의 Application Layer 에는 HTTP Request 헤더가 들어갑니다.

      :authority: www.google.com
      :method: GET
      :path: /
      :scheme: https
      ...
      ...
  • 이후,Transport Layer 에는 TCP 헤더가 들어갑니다.

    • TCP 헤더에서 중요하게 볼 것은 SP(출발지 포트번호)와 DP(목적지 포트번호)입니다.
    • 출발지 포트번호는 내 컴퓨터에서 만든 소켓의 포트 번호이므로, 내 컴퓨터는 알고 있으며, 목적지 포트 번호 또한 80으로 알고 있습니다.
  • 이후, Internet Layer 에는 IP 헤더가 들어갑니다.

    • IP 헤더에서 중요하게 볼 것은 SA(출발지 IP주소) 와 DA(목적지 IP주소)입니다.
    • 현재, www.google.com 이라는 도메인 정보만 알고 있기 때문에
    • 나의 시작 IP 주소는 알고 있지만, 목적지의 IP 주소는 아직 모릅니다.
    • 따라서, 도메인 정보로 목적지의 IP 주소를 알아내기 위해,
    • 도메인 서버에 DNS 쿼리를 보내고, IP 주소를 응답받습니다.
  • 이후, Network Access Layer 에는 Ethernet 헤더가 들어갑니다.

    • Ethernet 헤더에서 중요하게 볼 것은 SA(출발지 MAC 주소)와 DA(목적지 MAC 주소)입니다.
    • 여기서 목적지 MAC 주소는, 구글의 MAC 주소가 아닌,
    • 물리적으로 연결된, 패킷이 전달될 라우터(예를 들어, 공유기) 또는 게이트웨이의 MAC 주소를 의미합니다.
    • 따라서, 라우터의 MAC 주소를 알아내기 위해, ARP 프로토콜을 사용합니다.
    • 이제, ARP 프로토콜을 통해 라우터의 MAC 주소까지 알아냈습니다.
  • 이후 패킷을 전송하기 전, TCP는 연결지향형 프로토콜이기 때문에, 송신측과 수신측이 서로 연결되는 작업이 필요합니다.

    • 이러한 작업을 3 Way Handshaking 이라고 부릅니다.

    • 3 Way Handshaking 을 수행하기 위해서는, TCP 헤더에 표시한 플래그들이 사용되며, 이러한 플래그들을 컨트롤 비트라고 부릅니다.

    • 3 Way Handshaking 은 SYN(동기화) 과 ACK(승인) 로 진행됩니다.

    • 먼저, 클라이언트는 서버에게, 접속을 요청하는 SYN 패킷을 보냅니다.

    • 서버는 SYN 패킷을 받고, 클라이언트에게 요청을 수락한다는 ACK 와 SYN 플래그가 설정된 패킷을 보냅니다.

    • 클라이언트는 다시 서버에게 ACK 패킷을 보냅니다.

    • 이제 3 Way Handshaking 으로 기기 간 연결이 성립되었으니, 데이터 통신이 가능해집니다.

  • 이제 라우팅을 통해 패킷을 목적지 서버에게 전송합니다.

    • 패킷은 Network Access Layer의 MAC 주소와 Internet Layer의 IP 주소로 라우팅을 반복해 목적지 구글 서버까지 도착합니다.

    • 따라서, Transport Layer부터 설명을 진행하겠습니다.

    • 먼저, 구글 서버가 받은 패킷 내부 Transport Layer의 목적지 포트 번호에는 80번이 적혀져있습니다.

    • 따라서, Transport Layer는 80번 포트를 사용하고 있는 Application Layer에 데이터를 전송합니다.

    • 이후, Application Layer는 HTTP Request 데이터를 받아, “/” 에 매핑된 GET 요청을 처리합니다.

    • 이후, 적절한 HTML을 클라이언트에게 응답합니다.

    • 따라서, 클라이언트는 라우팅을 통해 전달 받은, “www.google.com” 에 해당하는 HTML 을 브라우저에 띄우게 됩니다.

  • 이제 HTTP 요청 및 응답 과정이 끝났으므로, 연결을 종료해야합니다.

    • 여기서도 TCP의 컨트롤 비트가 사용되며, 해당 단계에서는 ACK, FIN 플래그가 사용됩니다.

    • 클라이언트와 서버의 연결 종료 작업을 4 Way Handshaking 이라고 부르며, 총 4단계로 진행됩니다.

    • 먼저, 클라이언트는 서버에게, 연결을 종료하겠다는 의미인 FIN 패킷을 전송합니다.

    • 서버는 클라이언트에게 ACK 패킷을 보내고, 클라이언트가 보냈던 요청들에 대해 마저 응답을 보냅니다.

    • 이후, 서버의 응답이 끝나면 클라이언트에게 FIN 패킷을 전송합니다.

    • 클라이언트는 서버의 통신 종료를 확인한 뒤, 서버에게 ACK 패킷을 전송하고, 연결이 종료됩니다.

    • 하지만, 서버가 클라이언트에게 FIN 을 보내는 과정에서 한가지 문제가 발생할 수 있습니다.

    • 서버가 클라이언트에게 FIN 을 보내기 전에, 이전에 서버가 클라이언트에게 응답 했던 패킷이 FIN 보다 늦게 도착할 수도 있습니다.

    • 그렇게 되면, 클라이언트가 서버의 일부 응답을 받지 못하게 됩니다.

    • 따라서, 클라이언트는 서버로부터 FIN 패킷을 받고, ACK 패킷을 보낸 뒤에도

    • 일정 시간동안 혹시나 아직 도착하지 않은 잉여 패킷을 기다립니다.

    • 이렇게, 4 Way handshaking 이후에도 소켓을 닫지 않고 잉여패킷을 기다리는 상태를, TIME_WAIT 이라고 합니다.

참고

Comments