[Network] 웹 주소를 입력하였을 때 일어나는 일

Boundary

주소 www.google.com 으로 입력한다는 것은 구글의 웹서버 80/443 포트로 HTTP Request 메시지를 보내는 것이며, 해당 요청을 인터넷을 통해서 구글 서버로 전달하기 위해서는 패킷을 만들어야 한다.

 

대부분의 웹 통신은 TCP/IP 패킷 통신을 하고 있기에, 통신 규약을 TCP/IP 4계층을 이용한다고 가정하겠다. 또한, 패킷에는 TCP/IP 각 계층에 필요한 정보들이 담기게 되며, 우선 일반적으로 통용되는 HTTP, TCP, IP, Ethernet 프로토콜을 사용한다고 가정하자.

 

 

Part 1. 패킷 생성 (TCP/IP 규약)

사용자가 웹 브라우저의 주소 창에 URL(예: www.google.com)을 입력하는 순간, 웹 브라우징 세션이 시작되어진다. 이 URL은 웹 서버의 위치를 지정하는 데 사용되며, 브라우저는 이를 기반으로 HTTP 요청을 생성한다.

 

Application Layer

이 계층에서는 사용자의 브라우저가 HTTP(Request) 메시지를 생성한다. 이 메시지는 방문하고자 하는 웹 페이지의 정보(예: GET / HTTP/1.1)와 함께 웹 서버에 전달될 다양한 헤더 정보를 포함합니다.

 

Transport Layer

이 계층에서는 생성된 HTTP 요청을 TCP 세그먼트로 래핑(wrapping)하며, 각 세그먼트에는 소스 포트와 목적지 포트(일반적으로 웹 통신에는 80(HTTP) 또는 443(HTTPS) 포트가 사용됨) 정보가 포함된다. 이는 데이터가 올바른 어플리케이션으로 전달되도록 한다.

 

Internet Layer

이 계층에서는 소스 IP 주소(사용자의 컴퓨터나 장치의 IP 주소)와 목적지 IP 주소(웹 서버의 IP 주소)를 패킷에 추가한다.

 

그러나, 이 단계에서, 시작 IP 주소는 OS에서는 알고 있겠지만, 아직 목적지의 IP 주소는 모르는 상황이다. 여기서, www.google.com:80 이라는 정보만 알고 있다. 여기서, 사용자의 브라우저는 www.google.com 에 대한 IP주소를 알고 싶다고 요청을 하게 된다. 그렇게 되면 OS는 DNS 서버로 요청을 하게 되는데, DNS 서버의 주소는 이용하고 있는 통신사 주소이며, 이미 컴퓨터에 등록되어 있다.

 

이때, DNS 프로토콜은 53번 포트를 사용하며 Internet Layer에서의 UDP를 이용한다. HTTP 요청과 비슷하게 도메인이 담긴 쿼리를 DNS 서버로 보내게 된다.(단, 응답 크기가 크거나 더 안정적인 전송이 필요한 경우 TCP를 사용할 수도 있다.)

 

DNS는 언제 TCP를 사용하는가? (아래 더보기 클릭)

DNS 쿼리와 UDP

DNS 쿼리는 주로 UDP(User Datagram Protocol)를 사용합니다. UDP는 연결이 설정되지 않는 "비연결형" 프로토콜로, 데이터 패킷을 보낼 때 연결 상태를 확인하지 않으므로 전송 속도가 빠릅니다. 이러한 특성 때문에 DNS 쿼리와 같이 작은 정보를 빠르게 교환해야 하고, 패킷 손실이 크게 문제되지 않는 상황에서 적합합니다. 대부분의 DNS 요청은 패킷 크기가 작고(512 바이트 이하), 간단한 질의와 응답으로 이루어지기 때문에 UDP가 주로 사용됩니다.

DNS 쿼리와 TCP

그러나 모든 상황에서 UDP만으로 충분하지 않은 경우가 있습니다. 예를 들어, DNS 응답이 UDP 패킷 하나에 담기에는 너무 클 때(512바이트를 초과할 때)나, 보다 안정적인 데이터 전송이 필요한 경우 TCP(Transmission Control Protocol)가 사용됩니다. TCP는 "연결형" 프로토콜로, 데이터를 전송하기 전에 송수신 측간에 연결을 설정하고, 데이터 전송이 끝난 후에는 연결을 종료합니다. 이 과정에서 데이터의 순서, 손실, 중복 등을 관리하여 보다 안정적인 데이터 전송을 보장합니다.

언제 TCP를 사용하나?

1. 응답 크기가 클 경우: DNS 응답이 512바이트를 초과하는 경우 TCP를 사용하여 데이터 전송량에 대한 제한 없이 정보를 주고받을 수 있습니다.
2. DNSSEC(DNS Security Extensions) 사용 시: DNSSEC은 DNS 정보의 위조를 방지하기 위해 디지털 서명을 사용합니다. 이러한 서명 정보는 추가적인 데이터를 요구하므로, DNS 응답이 UDP 패킷을 초과하는 경우가 많습니다. 따라서 DNSSEC을 사용하는 쿼리에서는 종종 TCP가 사용됩니다.
3. 신뢰성 있는 전송이 요구될 때: 특정 상황에서는 DNS 쿼리와 응답의 신뢰성이 중요할 수 있습니다. TCP는 데이터의 순서, 손실, 중복을 관리하여 신뢰성 있는 통신을 보장합니다.

이처럼 DNS 쿼리는 상황에 따라 UDP 또는 TCP를 사용하여 도메인 이름을 IP 주소로 해석하는 중요한 역할을 합니다. 대부분의 경우 UDP가 사용되지만, 필요에 따라 TCP를 사용하는 유연성이 DNS의 효율성과 신뢰성을 높여줍니다.

 

 

Part 2. DNS Query를 통해 IP를 찾아오는 과정

DNS 서버는 최상위 레벨로부터 계층(역구조)적인 구조를 지니고 있으며, Root, TLD, Authoritive DNS 서버를 통해 도메인과 맵핑되는 IP주소를 얻게 된다. 

 

DNS 관련 자세한 내용은 아래 별도로 작성한 내용들로부터 확인할 수 있다.

https://anggeum.tistory.com/entry/DNS-개념잡기-1-도메인-명과-IP-주소를-구분하여-사용하는-이유
https://anggeum.tistory.com/entry/DNS-개념잡기-2-DNS-구성-요소-및-분류DNS-Resolver-DNS-서버

 

(1) OS는 DNS Resolver라는 매개체를 통해 가장 가까운 DNS 서버에 조회메시지를 보내게 된다.

 

(2) 여기서 가장 가까운 DNS는 사용하고 있는 ISP사 DNS 서버이며, ISP 서버에서 캐시데이터 유무를 확인한다. (만약, 여기서 ISP 서버에 캐시가 존재하는 경우, 브라우저는 캐시서버에 존재하는 IP 주소를 바탕으로 Host OS에 다시 전달한다.)

 

(3) 계층적 탐색 과정을 걸치게 된다.

3-1. (ISP ↔ Root) 캐시가 없는 것을 확인한 ISP 서버는 Root 서버에게 어디로 가야하는지 요청합니다. 여기서 Root 서버는 TLD 주소만 관리하기에, ***.com 의 도메인을 확인하고서 com 최상위 도메인을 관리하는 TLD 서버 주소를 ISP 서버에게 안내한다.

3-2. (ISP ↔ COM TLD) ISP 서버는 com 서버에게 어디로 가야하는지 다시 요청하며, com 서버는 OOO Authoritative DNS 서버의 주소를 ISP DNS 서버에게 안내한다.

3-3. (ISP ↔ OOO Authoritative) Authoritative Dns 서버는 구글 주소의 IP 주소를 안내하게 된다. 이와 동시에 ISP 서버는 해당 정보를 캐시서버에 기록을 한다.

 

(4) ISP 서버 주소는 DNS Resolver에게 www.google.com의 IP주소를 전달한다.

 

(5) DNS Resolver는 다시 OS(Client)에게 www.google.com의 IP주소를 반환한다. 

 

 

Part 3. 웹서버의 물리주소 획득

DNS 쿼리과정을 통해 얻은 IP 주소를 통해 구글 웹서버의 위치를 향해 패킷을 보내게 된다.

사용하는 컴퓨터는 Private IP를 사용하고 있다. Private IP는 외부 네트워크 환경에서 IP 주소를 찾지 못한다. 그렇기에 공유기를 통해 나갈 때, NAT 변환 작업을 걸치게 되며 변환된 공인 IP를 가지고 여러 라우터를 통해 구글 웹서버까지 향해가게 된다. (이를 라우팅이라 한다.)

구글 웹서버의 라우터까지 데이터 패킷이 도착하게 되면, 패킷의 IP 헤드에 기록된 구글 서버의 IP를 통해 MAC 주소를 얻게 된다. 이때 사용되는 프로토콜은 ARP(Adress Resolution Protocol) 프로토콜이다.

이제, 목적지 웹서버까지 물리주소를 데이터가 물리적으로 전달될 수 있게 된다.

다시 Part 1의 TCP/IP 계층으로 돌아와서, 데이터가 물리적으로 전달될 때, Physical Layer에서 비트를 전기 신호로 변환하는 과정을 걸치게 된다.

 

 

Part 4. 3-way handshaking

대부분의 웹통신은 데이터를 완전히 전달받는 것을 보장하는 TCP 통신을 하며, 3-way handshaking 과정을 통해 연결이 성립하게 된다.

 

Client > Google Web Server: TCP SYN

클라이언트는 다음 웹서버에 접속을 요청하는 SYN 패킷을 보낸다. 여기서, 클라이언트는 SYN을 보내며, SYN_SENT 상태로 전환, 다음 웹서버는 Wait_for_Client 상태로 전환한다.

 

Client Web Server > Client: TCP SYN, ACK

클라이언트로부터 SYN 요청을 받고 클라이언트에게 요청을 수락한다는 ACK와 SYN 플래그가 설정된 패킷을 발송하며, 다시 클라이언트가 ACK로 응답하기를 기다린다.

여기서 구글 웹서버는 SYN_RECEIVED 상태로 전환한다.

 

Client > Google Web Server: TCP ACK

구글 웹서버로 SYN 플래그를 전달받은 클라이언트는 다시 다음 웹서버에게 ACK 플래그가 설정된 패킷을 발송하게 된다. ACK 플래그를 전달받은 다음 웹서버는 Established 상태로 전환하게 되며, 두 서버간 통신이 가능하게 된다.

이제, 구글 웹 서버는 전달받은 패킷 정보를 Decapsulation 과정을 통해 내용을 확인 후 응답 패킷을 클라이언트에게 전달하게 된다. 여기서 HTML 페이지나, JSON 형태의 응답을 반환하게 된다.

 

클라이언트는 비로소 구글 웹페이지를 볼 수 있게 된다.