종합 - 주소창에 URL을 입력하면 일어나는 일

들어가며

시리즈의 마지막 편이다. 새로운 개념은 없다. 대신 브라우저 주소창에 http://www.example.com을 입력하고 Enter를 누른 순간부터 화면에 페이지가 뜨기까지, 지금까지의 다섯 편이 어떻게 맞물려 돌아가는지를 한 흐름으로 따라간다. 이 모든 일은 보통 1초 안에 끝난다.

1. URL 해석

브라우저는 먼저 URL을 분해한다. 프로토콜은 http, 호스트는 www.example.com, 경로는 /. 통신을 시작하려면 호스트의 IP 주소가 필요하다.

2. DNS 조회 — 이름을 주소로 (5편)

브라우저와 운영체제의 DNS 캐시를 먼저 확인하고, 없으면 재귀 리졸버에게 묻는다. 리졸버는 루트 → com → example.com 네임서버를 차례로 따라가 93.184.216.34라는 답을 받아온다.

여기서 짚을 점 하나. 이 DNS 질문 자체도 네트워크를 타고 나가는 패킷이다. UDP 데이터그램(4편)이 IP 패킷(3편)에, 다시 Ethernet 프레임(2편)에 캡슐화(1편)되어 리졸버까지 갔다 온다. 시리즈의 전 계층이 이미 이 단계에서 한 번 다 동원된 셈이다.

3. TCP 연결 수립 — 3-way handshake (4편)

IP 주소를 얻은 브라우저는 운영체제에 소켓을 요청하고, 93.184.216.34:80을 향해 SYN을 보낸다. SYN → SYN+ACK → ACK 세 번의 왕복으로 양쪽의 순서 번호가 맞춰지고, 신뢰성 있는 통로가 열린다.

4. 패킷의 여정 — 게이트웨이를 지나 홉을 거듭하며 (2편, 3편)

SYN이든 이후의 HTTP 요청이든, 모든 패킷은 같은 여정을 거친다.

호스트는 목적지 93.184.216.34가 자기 서브넷 밖임을 확인하고, 패킷을 기본 게이트웨이(공유기)에게 넘기기로 한다. 게이트웨이의 MAC 주소는 ARP 캐시에서 찾고, 없으면 브로드캐스트로 묻는다(2편). 공유기는 NAT로 사설 주소를 공인 주소로 바꾸고(3편), 패킷은 통신사 라우터로 나간다.

이후 패킷은 라우터들을 거치며 홉마다 다음 길을 안내받는다. 각 라우터는 라우팅 테이블에서 가장 구체적으로 일치하는 항목을 골라 다음 홉으로 넘길 뿐, 누구도 전체 경로를 알지 못한다(3편). 그 과정에서 목적지 IP 주소는 끝까지 유지되지만, 프레임은 홉마다 벗겨지고 새로 만들어져 MAC 주소가 계속 교체된다(2편).

5. HTTP 요청과 응답 (5편)

통로가 열리면 브라우저가 요청을 보낸다.

GET / HTTP/1.1
Host: www.example.com

서버의 80번 포트에서 대기하던 웹 서버 프로세스가 요청을 받아 처리하고, 200 OK와 함께 HTML을 응답한다. 응답이 크면 여러 세그먼트로 쪼개져 도착하는데, 일부가 유실되면 TCP가 재전송으로 메우고 순서를 복원해(4편), 브라우저에게는 끊김 없는 하나의 문서로 전달된다.

6. 렌더링, 그리고 반복

브라우저는 받은 HTML을 해석해 화면을 그린다. 문서 안에서 이미지, CSS, 스크립트를 발견하면 각각에 대해 이 과정(DNS 캐시 확인부터 HTTP 요청까지)을 반복한다. 페이지 하나를 띄우는 데 수십 번의 요청이 오가는 일이 흔하다. 통신이 끝난 연결은 종료 절차를 거쳐 정리된다.

전체 흐름과 계층 매핑

시리즈를 마치며

이 시리즈의 핵심 질문은 1편에서 던진 그대로다. 거대한 통신 문제를 어떻게 나눌 것인가. 답은 계층화였다. 링크 계층은 한 홉만, IP는 호스트까지의 길만, TCP는 프로세스까지의 신뢰성만, 응용 계층은 내용만 책임진다. 각 계층은 서로의 내부를 모른 채 약속된 경계로만 만나고, 그 무지(無知) 덕분에 50년 가까이 된 설계가 오늘날의 인터넷 규모까지 확장될 수 있었다.

이 구분은 실무에서 문제를 진단할 때도 그대로 쓰인다. 인터넷이 안 될 때 ping으로 IP 계층까지를 확인하고, DNS 조회가 되는지 따로 확인하고, 그다음 HTTP 응답을 확인하는 식으로 계층을 하나씩 좁혀가는 것이다. 어느 계층의 책임인지 가려내는 것이 네트워크 디버깅의 절반이다.

인터넷은 완벽한 부품이 아니라, 책임의 경계가 명확한 부품들의 합으로 만들어졌다.