웹 페이지가 열리기까지
주소창에 주소를 치고 Enter를 누르면 1초도 안 되어 페이지가 뜬다. 그 짧은 순간에 브라우저는 서버의 위치를 묻고, 연결을 맺고, 비밀 대화 통로를 만들고, 페이지를 요청하고, 받은 글자를 그림으로 바꾼다. 이 장에서는 이 과정을 슬로 모션으로 재생해 본다. 앞 장들에서 배운 거의 모든 것이 여기서 함께 등장한다.
- URL을 구성 요소(프로토콜, 도메인, 경로, 쿼리)로 나눠 읽는다.
- 웹 페이지 로딩의 전체 단계와 각 단계가 걸리는 시간을 폭포 그래프로 이해한다.
- DNS가 도메인 이름을 IP 주소로 바꾸는 계층적 조회 과정을 따라간다.
- HTTPS가 도청자로부터 대화를 지키는 방법과 자물쇠 아이콘의 의미를 안다.
- HTTP 요청과 응답의 모양, 상태 코드의 의미를 안다.
- 브라우저가 HTML을 DOM 트리로 만들고 화면에 그리는 과정을 체험한다.
URL 읽기: 인터넷의 주소 형식
웹 주소, 즉 URL(Uniform Resource Locator)은 몇 개의 부분으로 나뉜다. 아래에 아무 주소나 넣어 보자.
URL 해부기
전체 그림: 0.5초의 폭포
웹 페이지 하나가 열리는 과정은 대략 다음 순서로 진행된다. 각 단계는 앞 단계가 끝나야 시작할 수 있어서 계단식 폭포처럼 보인다. 개발자 도구(F12)의 “네트워크” 탭에서 실제 사이트의 폭포 그래프를 볼 수 있다.
페이지 로딩 폭포 그래프
DNS: 인터넷의 전화번호부
컴퓨터는 www.example.com 같은 이름으로는 연결할 수 없다. 10장에서 본 IP 주소가 필요하다. 이름을 IP 주소로 바꿔 주는 시스템이 DNS(Domain Name System)다. 사람 이름으로 전화번호를 찾는 전화번호부와 같다.
전 세계 수억 개의 도메인을 한 곳에서 관리할 수는 없으므로 DNS는 계층으로 나뉜다. 주소를 오른쪽부터 읽는다. .com을 아는 서버, example.com을 아는 서버를 차례로 물어 찾아간다. 한 번 찾은 결과는 여러 곳에 캐시해 두어 다음에는 바로 답한다.
DNS 조회 따라가기
연결 맺기: 세 번의 악수
IP 주소를 알았으니 이제 서버와 TCP 연결(10장)을 맺는다. 전화를 걸어 “여보세요?” “네, 들려요.” “네, 저도 들려요.”라고 확인하듯, 세 번 신호를 주고받는다. 이를 3방향 핸드셰이크(3-way handshake)라 한다.
HTTPS: 엿듣지 못하게
10장에서 패킷이 수십 대의 라우터와 공유기를 거친다고 했다. 그 중 하나라도 나쁜 마음을 먹으면(예: 카페의 가짜 Wi-Fi) 내용을 몽땅 엿볼 수 있다. 비밀번호와 카드 번호가 그대로 보인다. 그래서 요즘 웹은 거의 모두 HTTPS를 쓴다. 마지막 S는 Secure(안전한)다. 내용을 암호화해서 브라우저와 서버만 읽을 수 있게 한다.
카페 Wi-Fi의 도청자 시점
내가 보낸 것
👀 도청자가 본 것
처음 만난 두 사람이 비밀 열쇠를 어떻게 안전하게 나눠 가질까? 서버가 열린 자물쇠(공개 키)를 누구나 가져갈 수 있게 뿌린다. 브라우저는 새로 만든 비밀 열쇠를 상자에 넣고 그 자물쇠로 “찰칵” 잠가 보낸다. 잠근 자물쇠는 서버만 가진 진짜 열쇠(개인 키)로만 열린다. 도청자는 자물쇠도, 잠긴 상자도 보지만 열 수 없다. 이렇게 나눈 비밀 열쇠로 그 뒤의 대화를 빠르게 암호화한다. 이 원리를 공개 키 암호라 한다.
그런데 도청자가 “내가 그 서버야”라며 가짜 자물쇠를 보내면 어떡할까? 그래서 서버는 믿을 수 있는 기관(인증 기관)이 “이 자물쇠는 진짜 example.com의 것”이라고 서명한 인증서를 함께 보낸다. 브라우저 주소창의 자물쇠 아이콘은 “암호화되어 있고, 인증서가 유효하다”는 뜻이다. 사이트가 착한 곳이라는 보증은 아니다. 피싱 사이트도 자물쇠를 달 수 있으니 주소를 꼭 확인하자.
HTTP: 요청하고 응답받기
연결과 암호화가 준비되면 드디어 페이지를 요청한다. 웹의 대화 규칙이 HTTP(HyperText Transfer Protocol)다. 놀랍게도 그 내용은 사람이 읽을 수 있는 글자다.
첫 줄의 GET은 “가져와 달라”는 뜻이다. 로그인 정보나 글을 보낼 때는 POST를 쓴다. 응답 첫 줄의 숫자는 상태 코드다.
| 코드 | 뜻 | 언제 보나 |
|---|---|---|
| 200 OK | 성공 | 거의 모든 정상 응답 |
| 301 / 302 | 다른 곳으로 이사 갔음 | http를 https로, 옛 주소를 새 주소로 보낼 때 |
| 304 | 바뀐 것 없음, 캐시를 써라 | 다시 방문했을 때 |
| 403 | 권한 없음 | 로그인하지 않고 비공개 페이지에 접근할 때 |
| 404 | 그런 페이지 없음 | 주소를 잘못 쳤거나 삭제된 글 |
| 500 / 503 | 서버 내부 문제 / 과부하 | 서버 프로그램 오류, 접속 폭주 |
HTML을 받은 브라우저는 그 안에 적힌 그림, 글꼴, 스타일(CSS), 프로그램(자바스크립트) 파일을 다시 요청한다. 요즘 뉴스 사이트 하나를 열면 이런 요청이 100개를 넘기도 한다. 그래서 하나의 연결로 여러 요청을 동시에 처리하는 HTTP/2, HTTP/3가 나왔다.
HTTP는 원래 매 요청이 독립적이라 서버는 방금 로그인한 사람이 누구인지 기억하지 못한다. 그래서 서버는 응답에 작은 이름표(쿠키)를 실어 보내고, 브라우저는 다음 요청마다 그 이름표를 함께 보낸다. 위 요청의 Cookie: session=… 줄이 그것이다. 로그인이 유지되는 원리이자, 광고 추적에 쓰이는 원리이기도 하다.
글자에서 그림으로: 브라우저의 렌더링
서버가 보낸 HTML은 그냥 글자다. 브라우저는 이것을 다음 순서로 화면에 그린다.
- 파싱: HTML 글자를 읽어
<body>안에<h1>과<p>가 있는 식의 나무 구조, 즉 DOM 트리를 만든다. - 스타일 계산: CSS 규칙을 읽어 각 요소의 색, 글꼴, 크기를 정한다.
- 레이아웃: 화면 폭에 맞춰 각 상자의 위치와 크기를 계산한다. 글자가 몇 줄로 꺾일지도 여기서 정한다.
- 페인트·합성: 픽셀을 칠하고 여러 층을 합친다. 이 단계의 많은 부분을 GPU가 맡는다(12장).
왼쪽 HTML을 고쳐 보자. 오른쪽 화면과 아래 DOM 트리가 바로 바뀐다.
미니 브라우저: HTML → DOM → 화면
HTML (서버가 보낸 글자)
화면 (브라우저가 그린 결과)
<li>를 하나 더 추가하거나, style의 색을 바꿔 보자. 태그를 닫지 않아도 브라우저는 최대한 너그럽게 해석해 DOM을 만든다.핵심 정리
- URL은 프로토콜 · 도메인 · (포트) · 경로 · 쿼리 · 조각으로 이루어진다.
- 페이지 로딩은 DNS → TCP 연결 → TLS(암호화) → HTTP 요청 → 응답 → 렌더링의 순서로 진행된다. 왕복 지연이 전체 시간을 크게 좌우한다.
- DNS는 루트 → 최상위 도메인 → 해당 도메인 서버 순으로 물어 이름을 IP 주소로 바꾸고, 결과를 캐시한다.
- HTTPS는 공개 키 암호로 비밀 열쇠를 나눠 대화를 암호화하고, 인증서로 서버가 진짜인지 확인한다.
- HTTP는 사람이 읽을 수 있는 요청/응답 형식이며, 상태 코드로 결과를 알린다.
- 브라우저는 HTML을 DOM 트리로 만들고 스타일 계산, 레이아웃, 페인트를 거쳐 화면을 그린다.
확인 퀴즈
DNS가 하는 일은?
주소창의 자물쇠 아이콘이 보장하는 것은?
존재하지 않는 페이지를 요청했을 때 서버가 보내는 상태 코드는?
미국에 있는 서버의 페이지가 대역폭을 올려도 처음 뜨는 시간이 잘 줄지 않는 이유는?