탐색으로 돌아가기
Browser9 / 24 단계

Network

DNS · TCP · TLS · HTTP

주소창에 URL을 넣으면 DNS 조회 → TCP 핸드셰이크 → TLS 핸드셰이크 → HTTP 요청/응답 순으로 리소스를 가져온다.

브라우저가 URL을 화면에 띄우기까지의 네트워크 계층은 DNS → TCP → TLS → HTTP 순으로 쌓인다. 먼저 DNS 리졸버(recursive resolver)가 도메인 이름을 IP로 변환하는데, '재귀 질의(recursive query)'인 것은 클라이언트(stub)→리졸버 구간뿐이고, 캐시에 없으면 리졸버는 루트 네임서버(root) → TLD 네임서버(.com 등) → 권한 네임서버(authoritative)에 차례로 '반복 질의(iterative query)'하며 각 단계가 돌려주는 referral을 따라가 최종 IP를 얻는다. 그다음 TCP 3-way handshake(SYN → SYN-ACK → ACK)로 신뢰성 있는 연결을 맺고, 포트·시퀀스 번호를 협상하며 흐름 제어(flow control)와 혼잡 제어(congestion control)로 전송 속도를 조절한다. HTTPS라면 그 위에서 TLS 핸드셰이크가 일어나 인증서로 서버 신원을 검증하고, 비대칭키(asymmetric)로 대칭 세션키(symmetric)를 안전하게 교환한 뒤 이후 데이터는 대칭키로 빠르게 암호화한다. 마지막으로 HTTP가 요청(메서드·헤더·바디)과 응답(상태코드·헤더·바디)을 주고받으며, 프로토콜은 HTTP/1.1(텍스트, 순차)에서 HTTP/2(바이너리 프레이밍·멀티플렉싱, TCP 위)로, 다시 HTTP/3(QUIC/UDP 위, HoL 블로킹 해소)로 진화했다. 반복 요청은 HTTP 캐시로 절약하고, 지리적으로 분산된 CDN이 콘텐츠를 사용자 가까이에서 제공해 지연(latency)을 줄인다.

내부 구성

스텁 리졸버 (Stub Resolver)
OS/브라우저에 내장된 최소 DNS 클라이언트로, 애플리케이션의 도메인 질의를 재귀 리졸버로 전달한다
재귀 리졸버 (Recursive Resolver)
클라이언트를 대신해 root→TLD→authoritative를 차례로 질의해 최종 IP를 찾아주는 DNS 서버. 결과를 TTL 동안 캐시한다
루트 네임서버 (Root Nameserver)
도메인 확장자(.com/.net 등)를 보고 해당 TLD 네임서버 주소로 리졸버를 안내한다
TLD 네임서버 (TLD Nameserver)
.com·.org·.kr 같은 최상위 도메인을 관리하며 해당 도메인의 권한 네임서버로 안내한다
권한 네임서버 (Authoritative Nameserver)
특정 도메인의 실제 DNS 레코드(A/AAAA/CNAME 등)를 보유하고 최종 답을 제공한다
DNS 캐시 (DNS Cache)
브라우저·OS·리졸버 각 계층에 존재하며 TTL 동안 조회 결과를 저장해 반복 질의의 왕복을 없앤다
TCP 3-way Handshake
SYN→SYN-ACK→ACK로 양측 시퀀스 번호를 동기화하고 연결을 수립한다
포트 & 소켓 (Port / Socket)
IP+포트 조합으로 프로세스 단위 종단점을 식별한다(예: HTTPS 443). 연결은 4-튜플로 유일하게 구분된다
흐름 제어 (Flow Control)
수신자 윈도우(receive window)로 송신 속도를 조절해 수신 버퍼 오버플로를 막는다
혼잡 제어 (Congestion Control)
네트워크 혼잡을 감지해 전송률을 조절한다(slow start, congestion avoidance 등)
TLS 핸드셰이크 (TLS Handshake)
cipher suite 협상, 인증서 검증, 키 교환을 수행해 암호화 채널을 확립한다(TLS 1.3은 1-RTT, 0-RTT 재개 지원)
인증서 & PKI (Certificate / CA)
CA가 서명한 서버 인증서로 서버 신원과 공개키를 검증해 중간자 공격을 막는다
비대칭키 / 대칭키 (Asymmetric / Symmetric Key)
비대칭키로 세션키를 안전하게 합의하고, 실제 데이터는 빠른 대칭키로 암호화한다
HTTP 요청/응답 (Request / Response)
요청은 메서드·URL·헤더·바디, 응답은 상태코드·헤더·바디로 구성되는 애플리케이션 계층 메시지다
HTTP 메서드 & 상태코드 (Methods / Status Codes)
GET/POST/PUT/DELETE 등으로 의미를 표현하고 2xx/3xx/4xx/5xx로 결과를 나타낸다
HTTP 헤더 (Headers)
캐싱(Cache-Control), 인증(Authorization), 콘텐츠 협상(Accept), 쿠키 등 요청·응답 메타데이터를 담는다
HTTP/1.1 · HTTP/2 · HTTP/3
1.1은 텍스트·순차, 2는 바이너리 멀티플렉싱(TCP), 3은 QUIC/UDP로 HoL 블로킹을 해소한 프로토콜 버전이다
HTTP 캐시 (Cache)
ETag·Last-Modified·Cache-Control로 재요청 여부를 판단해 네트워크 왕복과 대역폭을 절약한다
CDN (Content Delivery Network)
지리적으로 분산된 엣지 서버에서 콘텐츠를 캐싱·제공해 사용자와의 물리적 거리로 인한 지연을 줄인다

핵심 포인트

  • DNS는 계층적 분산 시스템으로, 재귀 질의는 클라이언트→리졸버 구간뿐이고 리졸버는 root→TLD→authoritative에 반복(iterative) 질의하며 각 단계 캐시로 대부분의 왕복을 생략한다
  • TCP 3-way handshake(SYN/SYN-ACK/ACK)로 연결을 맺고 시퀀스 번호·흐름 제어·혼잡 제어로 신뢰성 있는 순차 전송을 보장한다
  • TLS는 TCP 연결 위에서 인증서로 서버를 검증하고 비대칭키로 대칭 세션키를 교환한 뒤, 실제 데이터는 대칭키로 암호화한다
  • HTTP 요청은 메서드·URL·헤더·바디, 응답은 상태코드·헤더·바디로 구성되며 헤더가 캐싱·인증·콘텐츠 협상을 제어한다
  • HTTP/1.1은 텍스트·순차, HTTP/2는 바이너리 멀티플렉싱(TCP), HTTP/3는 QUIC/UDP 기반으로 HoL 블로킹과 핸드셰이크 왕복을 줄인다
  • HTTP 캐시(Cache-Control·ETag 등)는 재요청을 줄이고, CDN은 엣지에서 콘텐츠를 제공해 물리적 거리로 인한 지연을 줄인다
  • QUIC은 전송+암호화 핸드셰이크를 1-RTT로 합치고, 스트림별 독립 전송으로 패킷 손실이 다른 스트림을 막지 않으며, 연결 마이그레이션을 지원한다

심화

면접에서 깊이를 가르는 지점은 'HTTP/2가 멀티플렉싱을 하는데 왜 HTTP/3가 필요한가'이다. HTTP/2는 한 TCP 연결에서 여러 스트림을 논리적으로 다중화하지만, TCP 자체가 바이트 스트림을 순서대로 보장하기 때문에 패킷 하나만 손실돼도 그 뒤의 모든 스트림 데이터가 재전송을 기다리며 막힌다. 이것이 'TCP 레벨 Head-of-Line 블로킹'이고, 애플리케이션 레벨 멀티플렉싱으로는 해결되지 않는다. HTTP/3는 전송 계층을 UDP 기반 QUIC으로 바꿔 스트림을 전송 계층에서 독립시켜, 한 스트림의 패킷 손실이 다른 스트림을 막지 않게 했다. 게다가 QUIC은 TCP 핸드셰이크와 TLS 핸드셰이크를 하나로 합쳐 1-RTT(재접속 시 0-RTT)로 연결을 세우고, connection ID 기반이라 Wi-Fi↔셀룰러 전환 시에도 연결이 끊기지 않는 연결 마이그레이션(connection migration)을 지원한다. 또 하나 실무적으로 중요한 미묘함은 'TLS 1.3의 0-RTT는 공짜가 아니다'라는 점이다. 0-RTT 데이터는 재전송(replay) 공격에 취약하므로 멱등(idempotent)하지 않은 요청(예: 결제 POST)에는 쓰면 안 된다. 또 DNS 단계에서도 최근에는 프라이버시를 위해 DoH(DNS over HTTPS)/DoT가 쓰이는데, 이는 리졸버로 가는 질의 자체를 암호화해 경로상 감청을 막지만 리졸버 운영자에게 질의를 집중시키는 트레이드오프가 있다. 이처럼 각 계층의 최적화는 항상 지연·보안·프라이버시 사이의 균형 문제로 귀결된다.

쉽게 말하면 친구 집에 가려고 주소를 찾고(DNS), 길을 뚫고(TCP), 비밀 통로를 만든 뒤(TLS), 초인종을 눌러 물건을 받는(HTTP) 것.

면접 예상 질문

#DNS#TCP#TLS#HTTP#핸드셰이크