목차
지금까지 계층·IP·DNS·포트·TCP·UDP·NAT를 하나씩 봤다. 이제 이 조각들을 통째로 이어, 주소창에 한 줄 쳤을 때 실제로 무슨 일이 순서대로 일어나는지 따라가며 시리즈를 닫는다.
주소창에 한 줄, 그 뒤의 여정
https://example.com을 치고 엔터를 누른다. 화면이 뜨기까지 1초도 안 걸리지만, 그 안에서 밑단은 여러 단계를 순서대로 밟는다.
이 순서 하나하나가 앞 글들에서 본 것이다. 밟아 보자.
먼저 이름을 주소로
브라우저가 가장 먼저 하는 건 DNS 조회다. example.com이라는 이름으로는 패킷을 못 보내니, 진짜 IP 주소로 바꿔야 한다.
캐시에 있으면 즉시 끝나고, 없으면 리졸버가 단계로 물어 주소를 알아온다. 이 첫 관문이 막히면 그 뒤는 시작도 못 한다 - “인터넷이 안 된다”의 흔한 정체다.
주소로 기계를 찾아
주소를 손에 쥐면, 패킷은 그 IP가 가리키는 기계를 향해 라우터를 하나씩 건너 간다. 내 기계가 NAT 뒤에 있으면 공유기가 출발지 주소를 공인 IP로 바꿔치고 나간다.
각 라우터는 전체 길을 모른 채 다음 홉만 보고 넘기는데, 그게 이어져 지구 반대편 기계까지 닿는다.
그 기계의 문을 두드려
기계에 닿았으면 그 안의 어느 프로세스인지가 필요하다. HTTPS니 443번 포트다. 그 포트에서 TCP가 3-way 악수로 연결을 맺는다.
SYN, SYN-ACK, ACK - 이 왕복이 오가야 비로소 데이터를 보낼 수 있다. 연결을 재사용하는 상황이면 이 악수를 건너뛰고, 처음이면 여기서 왕복 한 번을 쓴다.
자물쇠를 채우고
TCP 연결 위에서 이번엔 TLS 핸드셰이크가 일어난다. 암호를 맞추고 서버의 신원을 인증서로 확인하는 과정이다. 이게 끝나야 계층의 마지막 봉투가 채워져, 오가는 내용이 암호화된다.
TCP 악수에 이어 TLS 핸드셰이크까지, 첫 연결은 왕복이 이중이라 그만큼 걸린다. HTTP 버전이 올라온 큰 이유가 이 준비 비용을 줄이려는 것이었다.
그제야 HTTP가 오간다
여기까지 와야 비로소 HTTP 요청이 나간다. GET / 한 줄이 TCP 조각으로 쪼개져 안전하게 건너가고, 서버는 내부에서 요청을 처리해 200 OK와 HTML로 답한다.
밑단이 다 깔린 뒤에야 HTTP가 시작된다는 점이 핵심이다. GET /이라는 한 줄 뒤엔, 이름을 찾고 기계를 찾고 문을 두드리고 자물쇠를 채운 여러 층의 준비가 이미 끝나 있다.
어디서 느려지나
여정을 알면 “왜 느린가”를 단계로 나눠 짚을 수 있다.
- DNS가 느리다 - 캐시에 없어 조회에 왕복이 들 때. 첫 접속에서 두드러진다.
- 먼 거리(홉이 많다) - 물리적으로 멀면 홉마다 시간이 쌓인다. CDN이 서버를 사용자 가까이 두는 이유가 이 왕복을 줄이려는 것이다.
- 연결 수립(악수) - TCP + TLS 악수의 왕복. 첫 연결에만 들고, 재사용하면 사라진다.
- 서버 처리 - 여기서부턴 밑단이 아니라 서버 안의 일이다.
“느리다”가 어느 단계인지 가르는 것만으로 문제의 절반이 좁혀진다.
밑단을 알면 문제를 층으로 짚는다
계층 글에서 “문제를 층으로 나눠 짚으라”고 했다. 이제 그 층이 구체적인 이름을 가진다.
“연결이 안 된다”는 막연한 증상을 이렇게 단계로 쪼개면, 어디를 봐야 할지가 정해진다. 밑단을 아는 값은 결국 이것이다 - 뭉뚱그린 문제를 층으로 갈라 짚는 힘.
정리
- 주소창 한 줄 뒤엔 DNS → IP → 포트·TCP 악수 → TLS → HTTP 라는 밑단의 여정이 순서대로 밟힌다.
- HTTP는 이 모든 준비가 끝난 맨 마지막에야 시작된다 -
GET /한 줄 뒤에 여러 층의 준비가 이미 서 있다. - “왜 느린가”는 어느 단계인지(DNS·거리·악수·서버)로 갈라 짚으면 절반이 좁혀진다.
- 밑단을 아는 값은 뭉뚱그린 문제를 층으로 갈라 짚는 힘이다.
여기까지가 이 시리즈다. 계층에서 출발해 IP·DNS·포트·TCP·UDP·NAT를 지나 이 여정까지 왔다. 이제 HTTP 시리즈가 “연결됐다”에서 시작하는 그 밑에 무엇이 있는지가 보인다 - HTTP는 잘 깔린 밑단 위에 얹힌 맨 위 한 겹이다.