Skip to content

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

한국어
0%
정확도 0%
💡 왼쪽 원문을 읽으면서 오른쪽에 따라 써보세요. Tab 키로 힌트를 받을 수 있습니다.
원문 렌더가 준비되기 전까지 텍스트 가이드로 표시합니다.

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

"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는 뭘 하고 있는가?" 다음 글에서.

현재 단락 (1/213)

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

작성 글자: 0원문 글자: 8,330작성 단락: 0/213