LabHub

블로그

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

2026-04-15 · 19 분 읽기 · #networking#tcp#bbr#tls-1-3#http3#quic#dns#doh#bgp#anycast#cdn#websocket#webtransport#ebpf

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

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

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

Part 1 — TCP 혼잡 제어의 현대

전통: Loss-based

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

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

문제:

BBR — Google의 돌파 (2016)

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

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

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

Google의 YouTube 실험:

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에 도입, 기본 동작.

진단 도구

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엔 적용 안 함.

현대 암호화 선택

Post-Quantum Cryptography (PQC)

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

2024 NIST 표준 채택:

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의 해결:

2025년 현황

QUIC의 함정

Part 4 — DNS의 진화

기본 DNS의 취약점

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

DoT (DNS over TLS, RFC 7858, 2016)

DoH (DNS over HTTPS, RFC 8484, 2018)

논란:

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) 간 경로 광고. 인터넷의 "라우팅 테이블"을 만드는 프로토콜.

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

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

교훈:

BGP 하이재킹 사례

RPKI (Resource Public Key Infrastructure)

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

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

Part 6 — Anycast와 CDN 라우팅

Anycast란

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

Anycast vs DNS 기반 Geo-LB

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

CDN 내부

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

2024-2025 CDN 트렌드

Part 7 — 실시간 통신의 선택

WebSocket

Server-Sent Events (SSE)

const evt = new EventSource('/stream');
evt.onmessage = e => console.log(e.data);

WebTransport (QUIC 기반, 2024년 Chrome GA)

WebRTC (여전히 특수용)

선택 가이드

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

Part 8 — gRPC와 새로운 RPC

gRPC의 핵심

브라우저 한계

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

Connect (Buf, 2022)

tRPC

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

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

eBPF 기반 관측

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

패킷 캡처의 현대

클라우드 네이티브

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)

실사용자의 실제 측정.

분석의 기본 질문

이 다섯 질문이 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 — 학습 자료

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

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

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

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

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

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

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

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

댓글

아직 댓글이 없습니다.

로그인하면 댓글을 쓸 수 있습니다