핵심 요약
주소창에 URL을 입력하고 엔터를 누르면 ①URL 파싱 → ②DNS로 IP 찾기 → ③TCP 연결 → ④TLS 핸드셰이크(https) → ⑤HTTP 요청/응답 → ⑥HTML 파싱과 렌더링이 순서대로 일어난다. 면접에서는 "각 단계에서 캐시가 어떻게 개입하는가"까지 말할 수 있으면 좋다.
1. URL 파싱과 캐시 확인
브라우저는 먼저 URL을 스킴(https)·호스트(youngsam.net)·경로로 분해한다. 그리고 요청을 보내기 전에 여러 캐시를 확인한다 — HSTS 목록, 브라우저 캐시, 그리고 아래 DNS 캐시들.
2. DNS 조회 — 도메인을 IP로
도메인 이름(youngsam.net)을 실제 IP 주소로 바꾸는 단계. 캐시를 순서대로 뒤진다.
| 순서 | 확인 대상 |
|---|---|
| 1 | 브라우저 DNS 캐시 |
| 2 | OS 캐시 / hosts 파일 |
| 3 | 라우터 캐시 |
| 4 | ISP의 재귀 리졸버 → 루트 → TLD(.net) → 권한 네임서버 |
어디서도 못 찾으면 리졸버가 루트부터 계층적으로 물어 최종 IP를 받아온다.
3. TCP 연결과 TLS 핸드셰이크
IP를 알았으면 3-way 핸드셰이크(SYN → SYN/ACK → ACK)로 TCP 연결을 만든다. https라면 이어서 TLS 핸드셰이크로 인증서를 검증하고 대칭키를 교환한다. 이 왕복 때문에 첫 연결이 느리고, 그래서 keep-alive·HTTP/2·TLS 세션 재사용이 중요하다.
4. HTTP 요청과 응답
GET / HTTP/1.1
Host: youngsam.net
User-Agent: ...
Accept: text/html서버(또는 앞단의 CDN·리버스 프록시)가 상태코드와 함께 HTML을 돌려준다. 301/302면 다른 주소로 다시 시작한다.
5. 렌더링 — HTML을 화면으로
- HTML 파싱 → DOM 트리, CSS 파싱 → CSSOM 트리
- 둘을 합쳐 렌더 트리 → 레이아웃(위치·크기 계산) → 페인트 → 컴포지트
- 파싱 중 만난
<script>는 기본적으로 파싱을 멈추므로async/defer가 중요
6. 함정 · 면접 팁
- "캐시가 어디어디서 개입하나"를 짚으면 깊이가 드러난다(DNS·HTTP·브라우저)
- HTTPS의 존재 이유(도청·변조 방지)와 인증서 검증 과정을 한 줄 덧붙이면 좋다
- CDN·리버스 프록시가 중간에 끼어 실제 응답을 준다는 점을 언급
자주 묻는 질문
DNS는 왜 이렇게 여러 단계로 캐시하나요?
전 세계 도메인을 매번 루트부터 조회하면 지연도 크고 루트 서버 부하도 감당이 안 됩니다. 브라우저·OS·라우터·ISP 리졸버가 각각 TTL 동안 캐싱해 대부분의 조회를 로컬에서 끝냅니다.
TCP 연결과 TLS 핸드셰이크는 매번 하나요?
아니요. keep-alive와 HTTP/2 멀티플렉싱으로 한 연결을 재사용하고, TLS도 세션 티켓으로 재개(resumption)합니다. 그래서 같은 사이트의 두 번째 요청부터는 훨씬 빠릅니다.
script 태그는 왜 렌더링을 막나요?
스크립트가 DOM을 바꿀 수 있어 브라우저가 파싱을 멈추고 실행합니다. defer는 파싱을 끝낸 뒤 순서대로, async는 받는 대로 실행해 이 블로킹을 피합니다.
댓글 0