웹 페이지를 열 때 일어나는 일
왕복 시간이 50 ms라면 HTTPS 페이지는 HTML 첫 바이트가 오기까지 적어도 왕복 4번, 200 ms가 걸립니다. HTTP/3은 한 번을 줄입니다.
아침 7시 40분, 사람으로 꽉 찬 지하철에서 한 학생이 모바일 데이터로 학교 급식표 링크를 누릅니다. 잠시 뒤 오늘 메뉴가 화면에 뜹니다. (지어낸 장면입니다.) 그 잠깐 사이에 휴대폰은 앞의 다섯 단원에서 본 일을 전부 했습니다. DNS 조회, TCP 연결, 암호화된 세션, 그리고 상태 코드를 달고 돌아오는 HTTP 요청입니다. 학생이 한 일은 손가락으로 한 번 누른 것뿐이지만, 휴대폰과 서버 사이에서는 메시지가 여러 번 오갔습니다. 휴대폰이 기다린 시간을 세면서 그 순서를 따라가 보겠습니다.
휴대폰은 먼저 링크를 읽습니다
링크가 https://www.example.com/index.html이라고 합시다. MDN은 URL을 여러 부분으로 나눠 설명합니다. https는 스킴입니다. 암호화된 TLS 연결 위에서 HTTP를 쓰라는 뜻이고, 포트를 따로 적지 않으면 443번을 씁니다. www.example.com은 호스트이고, DNS가 주소로 바꿀 이름입니다. /index.html은 경로로, 그 서버에 달라고 할 자원을 가리킵니다. URL에는 물음표 뒤에 쿼리가, # 뒤에 프래그먼트가 붙기도 합니다. 프래그먼트는 페이지 안의 한 위치를 가리킬 뿐이라 서버로는 보내지 않습니다. 급식표 링크를 길게 눌러 주소를 복사해 보면 이 부분들이 그대로 보입니다.
첫 바이트까지 왕복 네 번
메시지가 서버에 닿고 답이 돌아오기까지 걸리는 시간을 왕복 시간(RTT)이라고 합니다. 왕복을 세어 보면 기다림이 어디서 생기는지 보입니다. 첫째, 이름이 캐시에 없으면 리졸버에 묻는 DNS 조회에 왕복 한 번쯤이 듭니다. 둘째, TCP 핸드셰이크입니다. SYN이 가고 SYN-ACK가 옵니다. 셋째, TLS 1.3(RFC 8446)이 왕복 한 번으로 암호화 키를 정합니다. 이때 클라이언트의 마지막 핸드셰이크 메시지는 HTTP 요청과 함께 실려 갈 수 있습니다. 넷째, 요청이 가고 응답이 옵니다. RTT가 50 ms라면 서버가 바로 답하더라도 급식표의 첫 바이트까지 왕복 네 번, 200 ms가 걸립니다. RTT가 100 ms로 두 배가 되면 기다리는 시간도 400 ms로 두 배가 됩니다.
끌어서 돌리고, 휠이나 두 손가락으로 확대하세요.
HTTP/3(RFC 9114)은 TCP 대신 QUIC(RFC 9000) 위에서 돕니다. QUIC은 UDP 위에서 연결 맺기와 TLS 키 정하기를 한꺼번에 하므로, TCP 핸드셰이크에 따로 쓰던 왕복 한 번이 없어집니다. DNS 조회, 핸드셰이크 왕복 한 번, 요청까지 모두 세 번입니다. 포트 80의 평범한 HTTP도 TLS를 건너뛰니 세 번이면 되지만, 그러면 카페 와이파이를 운영하는 사람처럼 길 중간에 있는 누구나 페이지를 읽거나 고칠 수 있습니다. 주소창의 자물쇠는 그 도메인과의 연결이 암호화되어 있다는 표시입니다. 사이트 자체가 정직하다는 보증은 아닙니다. 그래도 급식표처럼 사소한 페이지까지 자물쇠가 붙어 있으면, 길 중간에서 누가 내용을 몰래 바꿔 끼울 수는 없습니다.
급식표는 숫자를 달고 도착합니다
응답 맨 앞에는 세 자리 상태 코드가 붙어 있습니다. RFC 9110은 첫 자리 숫자로 코드를 나눕니다. 1xx는 정보, 2xx는 성공, 3xx는 다른 곳으로 안내(리다이렉션), 4xx는 클라이언트 오류, 5xx는 서버 오류입니다. 자주 보게 되는 것은 200 OK, 301 Moved Permanently(페이지 주소가 바뀜), 404 Not Found, 500 Internal Server Error입니다. 학교가 급식표 페이지를 옮겼다면 휴대폰은 먼저 301을 받고 새 주소로 다시 요청합니다. 404가 떴다면 서버가 답은 했지만 그 경로에 아무것도 없었다는 뜻이니, 네트워크 자체는 멀쩡했던 겁니다. 주소창에 경로를 한 글자 잘못 쳤을 때도 404를 만납니다. 브라우저 개발자 도구의 네트워크 탭을 열면 파일마다 붙은 상태 코드를 직접 볼 수 있습니다.
페이지 하나에 파일 여러 개
HTML 하나가 페이지의 전부인 경우는 드뭅니다. HTML 안에 스타일시트 하나, 스크립트 하나, 이미지 다섯 장이 적혀 있다고 합시다. 파일마다 새 연결을 연다면 파일 하나하나가 TCP와 TLS 왕복을 또 치러야 합니다. 그래서 브라우저는 연결을 열어 둔 채 다음 요청을 그 위로 보내고, HTTP/2와 HTTP/3에서는 요청 여러 개가 한 연결에서 동시에 오갑니다. 브라우저에는 자기 캐시도 있습니다. 응답에 얼마 동안 다시 써도 된다고 적혀 있으면, 다음 방문 때는 요청을 하나도 보내지 않고 저장해 둔 파일을 바로 꺼냅니다. 파일이 다 모인 뒤에야 브라우저가 화면을 배치하고 그립니다. 같은 지하철, 같은 데이터로도 매일 아침 여는 급식표가 처음 여는 사이트보다 빨리 뜨는 까닭이 여기 있습니다. 이미지가 많은 페이지일수록 연결을 다시 쓰고 캐시를 쓰는 덕을 크게 봅니다.
| RTT | 왕복 시간: 갔다가 돌아오는 시간 |
| 200 | 성공(OK) |
| 301 | 주소가 영구히 바뀜 |
| 404 | 찾을 수 없음 |
| 500 | 서버 내부 오류 |
| HTTP/3 | UDP 위의 QUIC에서 도는 HTTP |
- RTT가 50 ms입니다. DNS 조회를 포함해 HTTPS 페이지(TCP + TLS 1.3)의 첫 바이트까지 얼마나 걸립니까?
- 같은 50 ms RTT에서 HTTP/3이라면 얼마나 걸립니까?
- RTT가 80 ms이고 이름은 이미 캐시에 있습니다. TCP 위의 HTTPS 페이지는 얼마나 걸립니까?
- HTTPS 페이지를 불러오는 순서대로 놓으세요.
- 404는 무슨 뜻입니까?
- 찾을 수 없음
- 성공
- 주소가 영구히 바뀜
- 서버 오류
- 리다이렉션을 뜻하는 상태 코드 무리는 어느 것입니까?
- 3xx
- 2xx
- 4xx
- 5xx
- https://에 포트를 적지 않으면 몇 번 포트를 씁니까?
- https://www.example.com/index.html에서 /index.html은 무엇입니까?
- 경로
- 스킴
- 호스트
- 포트
- HTTP/3은 어떤 전송 방식 위에서 돕니까?
- UDP 위의 QUIC
- TCP
- DNS
- ICMP
- 주소창의 자물쇠는 무엇을 알려 줍니까?
- 그 도메인과의 연결이 암호화되었다
- 사이트가 안전하고 정직하다
- 사이트에 광고가 없다
- 페이지를 HTTP/3으로 불러왔다
- 「자물쇠가 있으면 안전한 사이트다.」 자물쇠는 그 도메인과의 연결이 TLS로 암호화되었다는 표시일 뿐입니다. 사기 사이트에도 자물쇠는 붙습니다. 주소창의 도메인이 내가 가려던 곳이 맞는지 따로 확인해야 합니다. 피싱 문자 속 링크도 자물쇠가 붙은 채 열릴 수 있습니다.
- 「시크릿 모드로 보면 통신사도 학교도 내가 뭘 봤는지 모른다.」 시크릿 모드는 창을 닫은 뒤 방문 기록과 사이트 데이터를 내 기기에 남기지 않는 기능입니다. 구글 크롬 고객센터도 방문한 사이트와, 학교나 직장, 인터넷 서비스 제공자처럼 네트워크를 관리하는 곳은 시크릿 모드에서도 활동을 볼 수 있다고 안내합니다. 패킷이 지나가는 라우터는 어느 모드에서나 같습니다. 공용 컴퓨터에서 내 기록을 남기지 않을 때 쓰는 기능이라고 생각하면 정확합니다.
- 「404가 뜨면 인터넷이 끊긴 것이다.」 404는 서버가 보낸 답입니다. 서버까지는 닿았는데 그 경로에 아무것도 없다는 뜻입니다. 네트워크가 정말 끊기면 상태 코드 자체가 오지 않습니다. 404는 주소를 잘못 쳤거나 페이지가 지워졌을 때 흔히 나옵니다.
- 「링크의 # 뒷부분도 서버로 간다.」 프래그먼트는 브라우저에 남아 페이지 안의 위치만 고릅니다. 서버로는 보내지 않습니다. 그래서 같은 페이지 주소 뒤에 #lunch를 붙이든 #notice를 붙이든, 서버가 받는 요청은 똑같습니다.
- URL은 스킴(https), 호스트(DNS 이름), 경로로 이루어집니다.
- TCP 위의 HTTPS: DNS + TCP + TLS 1.3 + 요청 = 첫 바이트까지 왕복 4번.
- QUIC 위의 HTTP/3은 핸드셰이크를 합쳐 왕복 3번입니다.
- 상태 코드: 2xx 성공, 3xx 리다이렉션, 4xx 클라이언트 오류, 5xx 서버 오류.
이 과정의 출처 (28)
- (checked 2026-10-17; reordered 2026-10-19: standards first, then official documentation, then operators and papers, history sources last)
- IETF RFCs (rfc-editor.org): RFC 768 UDP (1980, 8-byte header)
- RFC 791 IPv4 (1981, 32-bit addresses, "does not provide a reliable communication facility", TTL field "measured in units of seconds" but every module must decrease it by at least one, so it is only an upper bound)
- RFC 792 ICMP (Time Exceeded)
- RFC 801 NCP/TCP transition plan (1 January 1983)
- RFC 894 Ethernet (1500-byte payload)
- RFC 1034 and RFC 1035 DNS (1987, HOSTS.TXT kept by SRI-NIC, labels up to 63 octets and names up to 255, TTL in seconds)
- RFC 1122 (127.0.0.0/8 loopback)
- RFC 1918 private addresses (10/8, 172.16/12, 192.168/16)
- RFC 2131 DHCP, RFC 3022 NAT, RFC 3596 AAAA records, RFC 3849 and RFC 5737 documentation addresses, RFC 4271 BGP-4, RFC 4291 IPv6 text form, RFC 6298 TCP retransmission timer (initial RTO 1 second)
- RFC 6335 port ranges (0-1023, 1024-49151, 49152-65535)
- RFC 7766 DNS over TCP, RFC 8200 IPv6 (128-bit addresses, Hop Limit)
- RFC 8446 TLS 1.3 (one round-trip handshake)
- RFC 9000 QUIC and RFC 9114 HTTP/3, RFC 9110 HTTP semantics (status code classes)
- RFC 9293 TCP (three-way handshake, sequence numbers)
- IANA: ip-parameters registry (recommended default TTL 64)
- IPv4 free pool depleted 3 February 2011 (NRO and ARIN announcements)
- Official documentation: MDN Web Docs "How does the Internet work?" (45 cables for 10 computers, switches, routers, MAC and IP addresses, internet and web)
- "What is a URL?", "HTTP response status codes" (developer.mozilla.org)
- Cloudflare Learning Center: "What is DNS?" (four kinds of DNS server, 8 steps of an uncached lookup, browser and OS caches, TTL)
- "What is HTTP/3?" (cloudflare.com/learning)
- Google Chrome Help, "Browse in Incognito mode" (support.google.com/chrome/answer/95464, checked 2026-10-19: Incognito limits what is saved to the device; websites and organisations that manage your network, like your school, employer or internet service provider, may be able to observe your activity)
- Operators and papers: root-servers.org (13 root name servers run by 12 organisations, 2047 instances on 2026-10-17)
- Jacobson and Karels 1988, Congestion Avoidance and Control (loss mostly congestion)
- History blocks only: UCLA Samueli School of Engineering, Internet50 (first ARPANET message "LO", UCLA to SRI, 29 October 1969, 22:30)
- historyofinformation.com and Wikipedia ARPANET (Kline)
- Spiceworks/SRI history (HOSTS.TXT kept by SRI-NIC)
- Numbers (2^32, 2^96, 45 and 6 cables, packet counts, round-trip times)
확인한 날: 2026-10-17