사용자가 처음 웹사이트에 접근할 때 벌어지는 일들
0) 한눈에 보는 전체 흐름
URL 해석 → 스키마(https), 호스트(www.google.com), 포트(기본 443), 경로(/) 분해
HTTPS 업그레이드 → HSTS/브라우저 정책으로 초반부터 https 선호
DNS 질의 → 브라우저/OS/로컬/ISP 캐시 확인 → 재귀 리졸버 → 권한 서버에서 A/AAAA 등 조회
서버 선택/라우팅 → Anycast/CDN/DNS 로드밸런싱으로 가장 가까운 엣지 선택
연결 수립
HTTP/3: QUIC(UDP/443) 1-RTT 핸드셰이크(재방문시 0-RTT 가능)
HTTP/2: TCP(443) 3-way + TLS 1.3 1-RTT
암호화/프로토콜 협상 → SNI, ALPN(h2/h3)
요청 전송 →
GET / HTTP/1.1또는 HTTP/2 프레임, HTTP/3 프레임응답 수신 → 200/301 등 상태, 헤더·바디(HTML/CSS/JS/이미지)
렌더링 파이프라인 → DOM/CSSOM → Render Tree → Layout → Paint → Composite
후속 요청 → preload/prefetch, 캐시/압축/조건부 요청, 쿠키/세션
연결 유지/종료 → keep-alive, 재사용/멀티플렉싱, 종료 시(TCP는 4-way, QUIC은 자체 종료)
1) URL과 HTTPS 우선 시대
http://가 아니라https://가 기본이다. 주요 사이트(예: Google)는 HSTS(HTTP Strict Transport Security) 프리로드 목록에 올라 있어 브라우저가 처음부터 HTTPS로만 접속하려고 시도한다.포트는 보통 443(HTTPS), HTTP/1.1 시절의 80은 주로 HTTPS로 리다이렉트하는 용도로만 쓰이는 경우가 많다다.
2) DNS: 이름을 IP로, 그리고 그 이상의 일
어느 계층?
- DNS는 흔히 애플리케이션 계층(OSI L7)에서 동작한다. 전송은 전통적으로 UDP/53, 크거나 복잡한 응답(DNSSEC 등)은 TCP/53. 최근에는 DoT(853/TCP)·DoH(443/HTTPS) 로 암호화된 DNS도 널리 사용된다.
질의 흐름
캐시 레이어: 브라우저 → OS(리졸버) → 로컬 라우터 → ISP 리졸버 순서로 캐시를 먼저 확인
없으면 재귀 리졸버가 루트 → TLD(.com) → 권한 네임서버로 반복 질의(Iterative)
결과로 A(IPv4), AAAA(IPv6), 필요 시 CNAME 체인을 따라가 최종 IP를 얻는다.
TTL에 따라 캐시되고 서비스 사업자는 TTL·DNS 응답을 이용해 지리·부하 분산을 수행한다(Anycast + CDN).
첫 접속에서도 Google과 같은 대규모 서비스는 Anycast로 가까운 엣지 PoP로 트래픽을 유도한다.
3) 로컬 네트워크에서의 첫 걸음: ARP/ND
클라이언트가 얻은 목적지 IP로 바로 이더넷 프레임을 보낼 수는 없다. 일반적으로 기본 게이트웨이(라우터)의 MAC 주소가 필요하다.
IPv4: ARP(Address Resolution Protocol) 로 게이트웨이 IP → MAC을 조회
IPv6: Neighbor Discovery(ND) 사용
이렇게 얻은 목적 MAC = 게이트웨이, 목적 IP = 서버 IP로 프레임을 만들고, 라우터가 다음 홉으로 전달한다.
4) 전송 계층과 보안: TCP vs QUIC, TLS 1.3
(A) HTTP/2 경로: TCP + TLS
TCP 3-way handshake: SYN → SYN/ACK → ACK
옵션: MSS, 윈도우 스케일링, SACK 등
혼잡제어: CUBIC/BBR 등, Slow Start로 초기 전송량 점진 증가
TLS 1.3 핸드셰이크(대부분 1-RTT)
ClientHello: SNI(도메인 표시), ALPN(h2/h1.1 등), 지원 암호군, KeyShare
ServerHello + Certificate + Finished
OCSP Stapling, Certificate Transparency 로그 확인을 통해 인증서 유효성 점검
ALPN 결과가 h2라면 HTTP/2로 전환되어 하나의 TCP 연결에서 멀티플렉싱됩니다(헤드-오브-라인 블로킹은 TCP 레벨에서 여전히 존재).
(B) HTTP/3 경로: QUIC + TLS(내장)
QUIC은 UDP 위에서 동작하며 TLS 1.3이 프로토콜에 내장되어 있다.
연결·암호화가 통합된 1-RTT 핸드셰이크(재방문 시 0-RTT 가능)로 지연이 더 적고 스트림 단위 재전송으로 TCP의 HOL 문제를 완화한다.
포트는 보통 UDP/443, ALPN 결과가 h3.
요약: 오늘날 크롬↔구글 간 연결은 HTTP/3(QUIC) 를 우선 시도하고, 실패 시 HTTP/2(TCP/TLS) 로 폴백한다.
5) 애플리케이션 계층: 요청과 응답의 실제
요청 예시 (HTTP/1.1 표기)
GET / HTTP/1.1 Host: www.google.com User-Agent: Mozilla/5.0 ... Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 Accept-Encoding: gzip, br Accept-Language: ko-KR,ko;q=0.9 Connection: keep-alive
Host: 가상호스팅(하나의 IP에 여러 도메인)을 위해 필수
Accept-Encoding: gzip/br(Brotli) 압축 사용
쿠키: 세션/트래킹/설정 전달(처음 접근이라면 비어 있거나 최소한)
HTTP/2/3에서는 헤더가 HPACK/QPACK으로 압축되고, 프레임 단위로 멀티플렉싱된다
응답 예시
HTTP/1.1 200 OK content-type: text/html; charset=UTF-8 content-encoding: br cache-control: max-age=0, no-cache date: Wed, 24 Sep 2025 12:34:56 GMT strict-transport-security: max-age=31536000; includeSubDomains; preload
HSTS: 이후 이 도메인은 무조건 HTTPS
Cache-Control/ETag/Last-Modified: 이후 방문 시 조건부 요청(304) 로 트래픽 절감
Set-Cookie 시에는
Secure,HttpOnly,SameSite속성이 보안상 중요
6) 네트워크 경로의 디테일: MTU, 단편화, PMTUD
이더넷 MTU 1500바이트가 일반적이며, IP가 이를 넘으면 단편화가 필요하다.
현대 스택은 Path MTU Discovery(PMTUD) 로 경로상 MTU를 추정해 단편화를 피하려고 한다.
NIC TSO/GSO/GRO 같은 오프로딩이 실제 세그먼트 나눔을 하드웨어에 위임해 성능을 높인다.
7) 서버 측 구조: 로드밸런서·리버스 프록시·앱
Anycast IP로 들어온 트래픽 → 프론트 로드밸런서/엘라스틱 LB
TLS 종료(또는 패스스루) 후 리버스 프록시(NGINX/Envoy) → 애플리케이션 서버
캐시 계층(CDN/Edge, 내부 캐시), 이미지/정적 파일 압축/리사이징, A/B 테스트, WAF 등 다양한 계층이 끼어 있다다.
8) 브라우저 렌더링 파이프라인(첫 페인트까지)
HTML 파싱 → DOM
CSS 파싱 → CSSOM
Render Tree 생성(비가시 노드 제외)
Layout(리플로우): 각 노드의 기하(위치·크기) 계산
Paint: 레이어에 그리기
Composite: GPU 합성으로 화면에 표시
성능 팁(서버/클라이언트 협업)
<link rel="preload">,preconnect,dns-prefetch로 초기 지연 단축Critical CSS 인라인, JS는
defer/async로 렌더 블로킹 최소화HTTP/2/3의 멀티플렉싱으로 병렬 리소스 전송
Brotli 압축, 이미지 포맷(WebP/AVIF), 캐시 정책 정교화
9) 보안 관점에서 꼭 짚을 점
TLS 인증서 체인 검증: 루트 CA(신뢰 저장소) → 중간 CA → 서버 인증서
OCSP Stapling/CRL: 폐기 상태 확인
Mixed Content 차단: HTTPS 페이지에서 HTTP 리소스 로딩 금지
Same-Origin Policy & CORS: 스크립트/리소스 간 접근 제어
Service Worker: 첫 방문 시 등록될 수 있으며, 다음 방문부터 오프라인/프리캐시 활용
10) 연결 재사용/종료
HTTP/2/3는 하나의 연결로 여러 요청을 멀티플렉싱하므로, 탭 내 리소스들이 같은 오리진이면 연결을 재사용한다.
더 이상 보낼 데이터가 없으면
TCP: 애플리케이션이 TLS
close_notify후 FIN 시퀀스로 4-way 종료, TIME_WAIT 처리QUIC: 자체 CONNECTION_CLOSE 프레임으로 정리
11) “처음 접근” 시 자주 벌어지는 변주
HTTP→HTTPS 리다이렉트: HSTS 미적용 도메인은 초회에 301/308으로 HTTPS로 유도
IPv6 우선(Happy Eyeballs): v6/v4 동시 시도 후 더 빠른 경로 채택
지역/언어 감지: GeoIP·브라우저 언어 헤더로 초기 페이지/리다이렉트 결정
쿠키 배너/동의: 규정 준수(GDPR/CPRA 등)로 초기 렌더에 개입
부록 A) 계층별 데이터 단위 명칭 정리
애플리케이션: 메시지(HTTP 요청/응답)
전송(TCP/QUIC): 세그먼트/프레임
네트워크(IP): 패킷
데이터 링크(이더넷/Wi-Fi): 프레임
물리: 비트
부록 B) 최소 예시: 조건부 요청과 캐시
GET /app.js HTTP/1.1 Host: example.com If-None-Match: "abc123" If-Modified-Since: Wed, 24 Sep 2025 12:00:00 GMT
서버가 변경이 없음을 판단하면:
HTTP/1.1 304 Not Modified Cache-Control: max-age=31536000, immutable ETag: "abc123"
→ 바디 없이 빠른 응답, 네트워크 절약, 초기 렌더 가속
마무리
당신이 엔터를 누르는 수십~수백 밀리초 동안, 브라우저는 DNS 캐시/암호화된 전송/프로토콜 협상/멀티플렉싱/렌더 파이프라인을 연쇄적으로 구동한다.
'네트워크' 카테고리의 다른 글
| 🌐 HTTP란 무엇인가? (0) | 2025.09.16 |
|---|