Skip to content
Published on

실전 네트워크 엔지니어링 — TCP BBR, TLS 1.3, HTTP/3 QUIC, DNS/DoH, BGP, Anycast CDN, WebSocket/SSE/WebTransport 완벽 가이드 (2025)

🇰🇷KO🇺🇸EN🇯🇵JA
필사 모드
Authors

왜 네트워크를 프로토콜 레이어로 이해해야 하는가

"CDN 붙이고 HTTPS 쓰면 끝"이던 시대는 지났다. 2025년 개발자가 마주치는 네트워크 문제:

  • 앱이 아시아에선 빠른데 유럽에선 느리다 — Anycast 라우팅/레이턴시 이슈.
  • TLS 핸드셰이크가 RTT 4번 소모 — 1.3 + 0-RTT로 줄일 수 있다.
  • HTTP/2인데 여전히 느림 — 헤드오브라인 블로킹, QUIC이 답.
  • DNS 조회만 300ms — DoH/ECS 설정 미비.
  • 실시간 기능 구축 — WebSocket? SSE? WebTransport?
  • Facebook, Google, Cloudflare의 대규모 장애가 BGP로 — 인터넷 밑바닥이 흔들릴 수 있음.
  • LLM 스트리밍 토큰 전송 — SSE/gRPC streaming이 사실상 표준.

이 글은 **"패킷 레벨에서 앱 성능을 설명하는 엔지니어"**가 되기 위한 지도다.

Part 1 — TCP 혼잡 제어의 현대

전통: Loss-based

TCP는 패킷 손실을 혼잡의 신호로 본다. Reno, NewReno, CUBIC이 대표.

cwnd (혼잡 윈도우) 증가 → 손실 감지 → cwnd 절반

문제:

  • 진짜 혼잡이 아니라 버퍼 오버플로(bufferbloat)에서 손실 발생.
  • 손실 없으면 계속 증가 → 큰 버퍼 채우기 → 지연 증가.

BBR — Google의 돌파 (2016)

"손실이 아니라 **대역폭-지연의 곱(BDP)**을 측정하자."

RTprop = 관찰된 최소 RTT
BtlBw = 관찰된 최대 전송률
BDP = RTprop × BtlBw

cwnd를 BDP에 맞춰 유지. 버퍼를 채우지 않아 레이턴시가 극적으로 감소.

Google의 YouTube 실험:

  • 처리량 14% 증가
  • P99 재버퍼링 50% 감소
  • 평균 RTT 25% 감소

BBR v2 (2019): 공정성 개선. BBR v3 (2023): 프로덕션 기본 후보.

2024년 현실: Linux 커널 기본은 여전히 CUBIC. BBR을 쓰려면 sysctl net.ipv4.tcp_congestion_control=bbr. AWS, GCP, 대부분의 CDN이 BBR 사용 중.

PRR (Proportional Rate Reduction)

손실 복구 동안 cwnd를 급격히 떨어뜨리는 대신 비례적으로 감소. 2012년 Linux에 도입, 기본 동작.

진단 도구

  • ss -i — socket info, cwnd, rtt.
  • tcptrace + xplot — 세션 분석.
  • pping (eBPF) — RTT 관측.
  • Cloudflare's eBPF-based RTT monitoring.

Part 2 — TLS 1.3 혁명

TLS 1.2 vs 1.3 핸드셰이크

1.2: 2-RTT (Client Hello → Server Hello + Cert → Client Key Exchange → Finished). 1.3: 1-RTT — Client Hello에 키 교환 포함.

0-RTT (Early Data)

재방문 시 RTT 0. Client가 첫 패킷에 데이터를 실어 보냄.

ClientHello + EarlyData → Server
ServerHello + Finished + AppData ← Server

위험: Replay Attack. 같은 요청이 여러 번 처리될 수 있음. GET처럼 멱등한 요청에만 허용. Cloudflare, Fastly가 기본 지원하되 POST/PUT엔 적용 안 함.

현대 암호화 선택

  • ChaCha20-Poly1305 — 모바일/저성능 기기에서 AES-GCM보다 빠름.
  • X25519 — 키 교환 기본.
  • Ed25519 — 서명.
  • P-256/P-384 — FIPS 호환 필요 시.

Post-Quantum Cryptography (PQC)

양자 컴퓨터가 RSA/ECDSA를 깰 수 있다는 위협에 대비.

2024 NIST 표준 채택:

  • ML-KEM (Kyber) — 키 캡슐화.
  • ML-DSA (Dilithium) — 서명.

2023년 Cloudflare + Google X25519+Kyber 하이브리드 TLS를 Chrome에 기본 활성화. 2024년 Apple iMessage PQ3 발표.

"Harvest Now, Decrypt Later" 공격에 대한 대응. 지금 TLS 암호화 트래픽을 저장했다가, 미래에 양자 컴퓨터로 복호화하려는 국가 정보기관 위협.

Certificate Transparency (CT)

모든 발급된 인증서가 공개 로그에 기록. 2024년 CT 로그 크기 100억 건 돌파. MITM 용 위조 인증서를 발급 즉시 탐지 가능.

Part 3 — HTTP/3 + QUIC

왜 QUIC인가

HTTP/2의 Head-of-Line Blocking(HoL): 하나의 스트림에서 패킷 하나 손실 → TCP 레벨에서 뒤 스트림 전체 블록.

QUIC의 해결:

  • UDP 기반 — TCP의 순서 보장을 우회.
  • 스트림 간 독립 — 한 스트림 손실이 다른 스트림 안 막음.
  • Connection ID — IP/포트 바뀌어도(WiFi ↔ 5G) 연결 유지.
  • 내장 TLS 1.3 — 별도 handshake 없음.
  • 0-RTT + 1-RTT — 빠른 재연결.

2025년 현황

  • HTTP/3 RFC 9114 (2022).
  • **Cloudflare 트래픽의 30%+**가 HTTP/3.
  • Google(YouTube, Gmail) 모두 기본.
  • Chrome/Firefox/Safari 전부 지원.
  • Nginx 1.25 안정, LiteSpeed/Caddy 네이티브.
  • Node.js node:quic (실험적).

QUIC의 함정

  • UDP 차단 네트워크 — 기업 방화벽이 UDP 443 막으면 폴백 필요.
  • 패킷 암호화 — 중간 박스가 내용을 못 봐서 기존 트래픽 분석 도구 무력.
  • 연결 마이그레이션이 IP/NAT와 상호작용 복잡.

Part 4 — DNS의 진화

기본 DNS의 취약점

평문 + UDP + 53포트. 누구나 감청, 변조 가능. ISP의 광고 삽입, 국가 검열의 주 포인트.

DoT (DNS over TLS, RFC 7858, 2016)

  • TCP 853 포트.
  • 명확한 DNS 식별 → 차단 쉬움.

DoH (DNS over HTTPS, RFC 8484, 2018)

  • TCP 443, HTTPS 트래픽과 섞임 → 차단 어려움.
  • Cloudflare 1.1.1.1, Google 8.8.8.8, Quad9 등이 지원.
  • Firefox 기본 활성화(2020), Chrome 선택적.

논란:

  • Captive portal (공항/호텔 WiFi) 작동 불가.
  • 기업 네트워크 정책 우회.
  • 중앙집중화 — Cloudflare로 DNS 쿼리 집중.

EDNS Client Subnet (ECS)

DNS 쿼리에 클라이언트 서브넷 정보 포함 → Geo-DNS가 정확한 응답 선택.

단점: 프라이버시 — DNS 해석자에 위치가 노출.

Cloudflare 1.1.1.1은 프라이버시 이유로 ECS를 기본적으로 보내지 않음. 이 때문에 일부 CDN(Akamai 등)에서 최적 라우팅이 되지 않을 수 있음.

DNSSEC

DNS 응답의 디지털 서명. 변조 방어. 보급률 여전히 30% 미만. 복잡성 + 운영 부담이 보급 걸림돌.

Part 5 — BGP와 인터넷의 기저

BGP란

Border Gateway Protocol — AS(Autonomous System) 간 경로 광고. 인터넷의 "라우팅 테이블"을 만드는 프로토콜.

  • 각 AS가 자기가 도달 가능한 prefix를 이웃에게 알림.
  • 정책에 따라 경로 선택(가장 짧은 AS 경로, 지역 선호 등).
  • 신뢰 기반 — 누가 "나 이 IP 대역 소유" 하고 주장하면 웬만해선 믿음.

Facebook 6시간 장애 (2021년 10월 4일)

원인: 백본 유지보수 명령이 잘못되어, Facebook의 BGP 광고가 전 세계에서 사라짐. Facebook의 DNS도 Facebook 자체 AS에 있어 함께 접근 불가. 엔지니어가 건물에 들어가 물리적으로 고쳐야 했다 — 그런데 사원증 시스템도 Facebook 네트워크였다.

교훈:

  • 관리 네트워크는 프로덕션과 분리하라.
  • BGP 변경은 단계적 롤아웃.
  • Out-of-band 접근을 반드시 준비.

BGP 하이재킹 사례

  • 2008 YouTube — 파키스탄 ISP가 "내가 YouTube" 라고 광고 → 전 세계 YouTube 트래픽이 파키스탄으로.
  • 2018 MyEtherWallet — BGP 하이재킹으로 DNS 탈취 → 암호화폐 탈취.
  • 2022 KlaySwap — 한국 암호화폐 거래소 BGP 하이재킹.

RPKI (Resource Public Key Infrastructure)

AS가 광고할 수 있는 prefix에 대한 암호학적 증명.

2022년 말, IPv4 경로의 50%+가 RPKI 검증됨. 2024년 기준 60%+. Cloudflare, Google, AWS 모두 적극 채택.

Part 6 — Anycast와 CDN 라우팅

Anycast란

같은 IP 주소를 여러 지점에서 동시에 광고. BGP가 각 클라이언트에 "가장 가까운" 지점으로 라우팅.

  • Cloudflare 1.1.1.1, Google 8.8.8.8 — 전 세계 수백 지점에서 같은 IP.
  • Cloudflare Workers/Fastly Compute의 엣지 네트워크가 기반.

Anycast vs DNS 기반 Geo-LB

  • Anycast: 네트워크 레벨, BGP가 결정. 빠른 페일오버.
  • DNS Geo: DNS가 결정. TTL 때문에 페일오버 느림. 단, ECS로 정교함.

Cloudflare = Anycast 중심. Akamai = 전통적으로 DNS 기반 + 수많은 POP. Fastly = Anycast + 적은 수의 강력한 POP.

CDN 내부

Varnish 기반 CDN vs ATS (Apache Traffic Server) vs 자체 구현.

  • 캐시 계층: Edge → Regional → Origin Shield.
  • Cache Key: URL + Vary 헤더 + 쿠키 (조심!) .
  • Stale-while-revalidate, stale-if-error: 오래된 값을 보여주며 백그라운드 갱신.
  • ESI (Edge Side Includes): 엣지에서 HTML 조각 조립.

2024-2025 CDN 트렌드

  • Edge Compute — 단순 캐싱을 넘어 로직 실행(이전 글의 Edge Computing 참조).
  • Private Traffic Management — BGP Anycast로 자체 AS 운영하는 기업 증가.
  • eBPF 기반 L4 LB — Katran(Facebook), Cilium.

Part 7 — 실시간 통신의 선택

WebSocket

  • 1 connection, 양방향, 임의 메시지.
  • 프록시·로드밸런서 대응 필요(HTTP 업그레이드).
  • Socket.IO = WebSocket + 폴백 + reconnection + rooms.

Server-Sent Events (SSE)

  • 단방향(서버→클라이언트).
  • HTTP 1.1 장기 연결.
  • 재연결 + 이벤트 ID 자동.
  • LLM 스트리밍에 사실상 표준 (ChatGPT API, Claude API 모두 SSE).
const evt = new EventSource('/stream');
evt.onmessage = e => console.log(e.data);

WebTransport (QUIC 기반, 2024년 Chrome GA)

  • UDP-like(unreliable) + 스트림.
  • WebSocket의 후계자 후보.
  • 게임, VR, 실시간 미디어에 이상적.
  • Firefox, Safari 미지원(2025 기준) — 아직 얼리어답터.

WebRTC (여전히 특수용)

  • P2P + 미디어 스트림.
  • 화상회의, 원격 제어.
  • NAT traversal(STUN/TURN) 복잡.

선택 가이드

요구선택
서버 푸시만 필요, 재연결 자동SSE
양방향 텍스트/제어 메시지WebSocket
저지연·unreliable OK (게임)WebTransport
P2P 미디어WebRTC
RPC + 스트리밍gRPC-Web / Connect

Part 8 — gRPC와 새로운 RPC

gRPC의 핵심

  • Protobuf 기반 스키마.
  • HTTP/2 스트리밍.
  • 4가지 모드: unary, server streaming, client streaming, bidirectional.

브라우저 한계

HTTP/2 low-level 제어를 JS가 못 해서 gRPC-Web 필요. Envoy 프록시로 번역.

Connect (Buf, 2022)

  • gRPC, gRPC-Web, Connect 프로토콜을 한 서버에서.
  • 브라우저에서 직접 호출 가능.
  • TypeScript 지원 최상위.
  • 2024년 Vercel, Shopify, Buf 자사 인프라 채택 확산.

tRPC

TypeScript 전용, 스키마 없이 타입 추론으로 엔드투엔드 타입 안전성. 모노레포 + TS 프로젝트에 최적.

Part 9 — 관측(Observability) — 네트워크 레벨

eBPF 기반 관측

이전 글(Observability)에서 다룬 eBPF. 네트워크 레벨에서:

  • Cilium — K8s CNI + 네트워크 정책 + 관측.
  • Pixie — eBPF로 서비스 메시 없이 L7 트래픽 관측.
  • Katran — Facebook의 eBPF L4 LB.
  • Hubble — Cilium 플로우 관측.

패킷 캡처의 현대

  • tcpdump — 여전히 기본.
  • Wireshark — GUI 분석.
  • tshark — Wireshark의 CLI. 스크립팅 가능.
  • termshark — Wireshark TUI.

클라우드 네이티브

  • VPC Flow Logs (AWS/GCP).
  • AWS Traffic Mirroring — 패킷 자체를 복사해 분석.
  • Datadog Network Performance Monitoring.

Part 10 — 일상 문제 해결 루틴

"느려요"가 들어왔을 때

  1. 클라이언트 지역/ISP 확인 — traceroute, mtr.
  2. DNS 조회 시간 — dig +trace.
  3. TLS 핸드셰이크 — curl -w "@trace.txt".
  4. TTFB(Time To First Byte) — 서버 처리 시간.
  5. TCP 재전송 — tcpdump + 통계.
  6. 대역폭 vs 레이턴시 — iperf3으로 측정.

Real User Monitoring(RUM)

실사용자의 실제 측정.

  • Cloudflare RUM, Datadog RUM, Sentry Performance.
  • Web Vitals 실사용자 수집.

분석의 기본 질문

  • "느린 건 네트워크인가, 서버인가, 클라이언트인가?"
  • "P50인가 P99인가?"
  • "특정 지역만인가, 전역인가?"
  • "특정 ISP만인가?"
  • "시간대 상관 있는가?"

이 다섯 질문이 90%의 원인을 좁혀준다.

Part 11 — 2025년 네트워크 체크리스트 (12항목)

  1. TLS 1.3 + PQC 하이브리드 사용 — Cloudflare가 기본 제공.
  2. HTTP/3 활성화 — CDN 설정 한 줄.
  3. HSTS preload — 초기 요청도 보호.
  4. DNS는 Anycast + DoH 지원 제공자 사용.
  5. BBR 혼잡 제어 — Linux 서버 sysctl로 설정.
  6. IPv6 지원 — 이제는 필수. 특히 모바일 트래픽.
  7. Rate Limiting은 CDN Edge에서 — 오리진 도달 전 차단.
  8. WebSocket 대신 SSE (단방향이면) — 더 안정적.
  9. LLM 스트리밍은 SSE — 클라이언트 구현 간단.
  10. CDN Cache Key 설계 — 불필요한 Vary 제거.
  11. Out-of-band 관리 네트워크 — Facebook 사건의 교훈.
  12. 관측: 레이턴시 P99, 에러율, 재전송률 기본 SLI.

Part 12 — 10대 안티패턴

  1. Allow-Origin: *으로 만능 해결 — 보안 글에서 이미 다뤘다.
  2. DNS 조회 결과 무한 캐싱 — TTL 존중.
  3. WebSocket으로 대용량 파일 전송 — HTTP가 낫다.
  4. Keep-Alive 없는 단기 HTTP 연결 남발 — 핸드셰이크 폭주.
  5. CDN을 정적 자산에만 사용 — 동적 응답도 캐싱 가능.
  6. 로컬 Nginx 기본값으로 프로덕션 운영 — 워커·버퍼 튜닝 필수.
  7. TLS 재협상(renegotiation) — DoS 벡터. 끄는 게 낫다.
  8. 인증서 만료를 사람이 체크 — 자동 갱신 + 모니터링.
  9. Anycast 없이 단일 리전 — 글로벌 서비스면 필수.
  10. UDP 차단 환경 미고려 — HTTP/3 폴백 설계.

Part 13 — 학습 자료

  • 책: High Performance Browser Networking (Ilya Grigorik) — 무료 공개, 네트워크 성능의 고전.
  • 책: Computer Networking: A Top-Down Approach (Kurose & Ross).
  • 블로그: Cloudflare Blog (프로덕션 네트워크 이야기의 보고), Fastly Engineering.
  • 도구: Wireshark, Chrome DevTools Network 패널, WebPageTest.
  • 실습: Cloudflare Workers 무료 티어로 엣지 실험.
  • RFC: 9000 (QUIC), 9114 (HTTP/3), 8446 (TLS 1.3) — 직접 읽어볼 만하다.

마치며 — 네트워크는 보이지 않는 시스템의 척추

코드는 보인다. DB 쿼리도 보인다. 그런데 네트워크는 안 보인다. 그래서 엔지니어가 가장 무시하기 쉽고, 가장 비싼 값을 치르는 영역이 되곤 한다.

2025년 엔지니어에게 네트워크 지식은:

  • CDN 비용의 30%를 절감하고,
  • P99 레이턴시의 40%를 줄이고,
  • 대규모 장애를 막는 직접적 수단이다.

"네트워크는 인프라팀 일"이라는 시대는 끝났다. Edge Compute, LLM Streaming, Realtime Collab, IoT — 요즘 뜨는 영역 모두 네트워크가 핵심이다.

그리고 기억하자: Facebook의 6시간 장애는 누구에게나 일어날 수 있다. 규모가 크면 장애도 크고, 많은 것이 서로 얽혀 있다. 네트워크가 흔들리면 그 위의 모든 것이 흔들린다.

다음 글 예고 — "운영체제의 현대적 이해" — 프로세스/스레드, 가상 메모리, IO_URING, Coroutine, 컨테이너 격리, GPU 드라이버, NUMA까지

네트워크 아래엔 OS가 있다. 다음 글은 한 레이어 더 내려간다.

  • 프로세스 vs 스레드 vs 코루틴 — 현대 런타임이 택하는 것
  • Linux io_uring — epoll의 후계자, 왜 혁명인가
  • Virtual Memory와 페이지 테이블 — 메모리 관리의 현대
  • cgroups + namespaces — Docker는 이 두 개로 만들어진다
  • eBPF 심층 — 커널에 코드를 주입하는 안전한 방법
  • NUMA — 대규모 서버에서 CPU가 메모리에 접근하는 비용
  • GPU 드라이버와 UVM — LLM 추론이 GPU를 쓰는 방식
  • Linux Scheduler — CFS에서 EEVDF로(2024)
  • Zero-Copy, DMA, RDMA — 초고성능의 열쇠
  • WSL2와 Hyper-V — 개발자가 매일 쓰지만 모르는 계층

"내 앱 밑에서 OS는 뭘 하고 있는가?" 다음 글에서.

Discuss on Twitter • View on GitHub