네트워크 완전 가이드 — TCP·UDP·QUIC·HTTP/3·TLS 1.3·gRPC·WebSocket·CDN을 2025년 기준으로 한 번에 정리

프롤로그 — "왜 HTTP/3는 UDP를 쓰는가? 왜 TLS 1.3은 1-RTT인가?"

2025년 4월, 당신의 REST API가 한국에서 200ms, 미국에서 800ms 걸린다.

• 원인 1: TCP Handshake 1-RTT + TLS 1.2 Handshake 2-RTT = 3-RTT 오버헤드
• 원인 2: TCP Head-of-Line Blocking — 패킷 1개 손실 시 뒤 패킷 모두 대기
• 원인 3: CDN 없이 Origin에서 직접 서빙
• 해결: HTTP/3 + QUIC(0-RTT resumption) + Cloudflare Anycast → 200ms로 단축

Database(Ep 13)가 영속 상태를 다뤘다면, 네트워크는 상태를 옮기는 배관이다. 2025년 네트워크는 TCP에서 QUIC으로, REST에서 gRPC/tRPC로, Origin에서 Edge로 이동 중이다. Cloudflare는 Workers로 서버리스 엣지를, Fastly는 Compute@Edge로 WebAssembly를 민다.

이 글은 Season 2 Ep 14 — 네트워크. OSI 7계층부터 QUIC의 0-RTT, TLS 1.3 Handshake, gRPC Streaming, WebSocket 재연결 패턴, CDN Cache Invalidation까지. "패킷이 어디로 가는지"를 알면 디버깅이 달라진다.

1부 — OSI 7계층과 TCP/IP 4계층

OSI 7계층 (이론) vs TCP/IP 4계층 (실전)

실전에서는 TCP/IP 4계층이면 충분. OSI는 학술/인터뷰용.

패킷이 브라우저에서 서버까지 가는 길 (2025)

1. DNS lookup: api.example.com → 1.2.3.4 (UDP:53, DoH/DoT로 암호화 추세)
2. TCP Handshake: SYN → SYN-ACK → ACK (1-RTT)
   (또는 QUIC: Initial → Handshake → 1-RTT 데이터, 0-RTT resumption 가능)
3. TLS Handshake: ClientHello → ServerHello → Finished (TLS 1.3: 1-RTT)
4. HTTP Request: GET /api/users HTTP/2
5. 서버 처리 + DB 쿼리
6. HTTP Response: 200 OK + JSON
7. TCP Close: FIN → ACK → FIN → ACK (4-way)

총 왕복: TCP+TLS 1.2 = 3-RTT, QUIC+TLS 1.3 = 1-RTT, QUIC 0-RTT resumption = 0-RTT. 한국-미국 왕복 150ms 기준, TCP+TLS 1.2는 450ms 대기, QUIC 0-RTT는 0ms 대기.

2부 — TCP vs UDP vs QUIC

TCP — 신뢰성의 클래식

특징: 연결 지향, 신뢰성, 순서 보장, 혼잡 제어
Handshake: 3-way (SYN, SYN-ACK, ACK)
Window: Congestion + Flow Control
Retransmission: 패킷 손실 시 재전송
Ordering: sequence number로 순서 보장

장점: 안정적, OS 레벨 지원, 방화벽 통과 쉬움 단점:

• Handshake 1-RTT 오버헤드
• Head-of-Line Blocking: 패킷 1개 손실 시 뒤 패킷 모두 버퍼링
• Slow Start: 초기 대역폭 낮음
• 모바일 환경 취약 (IP 변경 시 재연결)

UDP — 최소주의 전송

특징: 비연결, 비신뢰, 순서 미보장
Handshake: 없음
Overhead: 8 bytes 헤더
Use cases: DNS, 게임, 영상 스트리밍, WebRTC, VoIP

장점: 빠름, 오버헤드 최소 단점: 애플리케이션이 신뢰성/순서 관리 책임 2025 현실: QUIC/HTTP/3의 기반, DNS over HTTPS(DoH)

QUIC — HTTP/3의 기반, 2025년 필수

2012년 Google이 SPDY의 한계를 극복하려 시작. 2021년 RFC 9000으로 표준화. "UDP 위에 TCP+TLS+HTTP/2를 재구현" — 근데 더 빠르게.

QUIC = UDP + Reliability + Ordering + TLS 1.3 + Multiplexing + 0-RTT

핵심 개선:

1. 0-RTT Resumption: 이전 세션 키로 첫 패킷에 데이터 포함
2. Stream-level Multiplexing: Stream 단위 HOL Blocking 제거 (TCP는 connection 단위)
3. Connection Migration: IP 변경되어도 Connection ID로 유지 (WiFi → LTE 전환 끊김 없음)
4. Always-encrypted: 패킷 메타데이터까지 암호화 (TLS 1.3 내장)
5. User-space 구현: 커널 업데이트 없이 배포 가능 (Chrome, Cloudflare가 push)

어댑션 2025: HTTPS 트래픽의 30%가 HTTP/3/QUIC (Cloudflare 기준).

• Google: 95%+ QUIC
• Meta: 75%+
• Cloudflare, Fastly: 기본 활성화
• 일반 CDN 고객: opt-in

TCP vs QUIC 벤치마크

3부 — HTTP/1.1 → HTTP/2 → HTTP/3 진화

HTTP/1.1 (1997) — 아직도 많이 쓰임

GET /users HTTP/1.1
Host: api.example.com
Accept: application/json

HTTP/1.1 200 OK
Content-Type: application/json
Content-Length: 42

{"users": [{"id": 1, "name": "Alice"}]}

장점: 단순, 텍스트 기반, 디버깅 쉬움 단점:

• 1 connection = 1 request at a time (HOL)
• 브라우저가 도메인당 connection 6개로 제한 → "domain sharding" hack
• Header 중복 (매 요청마다 Cookie, User-Agent 전송)

현재 쓰임: Server-to-Server, 간단한 REST, 레거시

HTTP/2 (2015) — 바이너리 멀티플렉싱

특징:
- 바이너리 프레이밍 (텍스트 X)
- 1 connection에서 여러 stream 동시 전송 (Multiplexing)
- Header Compression (HPACK)
- Server Push (deprecated in 2022)
- Stream Prioritization

개선 효과: First load 30% 빠름, 대역폭 효율 증가 한계: TCP 기반이라 여전히 connection-level HOL blocking

HTTP/3 (2022) — QUIC 위에서 재탄생

특징:
- QUIC 기반 (UDP)
- Stream-level 독립성 (HOL 제거)
- 0-RTT connection resumption
- Always HTTPS (TLS 1.3 내장)
- Connection Migration

2025 어댑션:

• Chrome, Safari, Firefox 모두 기본 지원
• Cloudflare, Fastly, AWS CloudFront 활성화
• YouTube, Instagram, Facebook 기본
• Node.js, Go, Rust 라이브러리 성숙 (quiche, quinn, msquic)

실전 활성화 (Caddy, Nginx)

# Caddyfile — HTTP/3 기본 활성화
example.com {
  reverse_proxy localhost:3000
  # HTTP/3 자동
}

# Nginx 1.25+
server {
  listen 443 ssl http2;
  listen 443 quic reuseport;
  add_header Alt-Svc 'h3=":443"; ma=86400';
  ssl_protocols TLSv1.3;
  ...
}

4부 — TLS 1.3과 HTTPS의 현재

TLS 1.3 vs 1.2 핵심 차이

TLS 1.3 Handshake (1-RTT)

ClientHello (key share + signature_algorithms + cipher_suites)
                  ─────►
                                ServerHello (key share)
                                EncryptedExtensions
                                Certificate
                                CertificateVerify
                                Finished
                  ◄─────
Finished
Application Data (HTTP request)  ─────►

1-RTT만에 암호화된 데이터 전송 시작. TLS 1.2는 2-RTT 필요했음.

0-RTT Resumption — 재접속은 즉시

첫 연결: 1-RTT로 key 교환 + PSK(Pre-Shared Key) 저장
재연결: ClientHello + PSK + HTTP Request (한 번에!)

주의: 0-RTT는 replay attack 취약. GET은 OK, POST/결제/상태 변경은 1-RTT 써야 함.

인증서 (Let's Encrypt 2025)

• 무료: Let's Encrypt, ZeroSSL
• ECDSA 권장: RSA 2048보다 빠르고 작음
• 자동화: Caddy, Traefik은 기본. Nginx는 certbot
• SAN: 와일드카드 vs 개별 (DNS-01 challenge로 와일드카드 가능)
• Expiry 90일: 자동 갱신 필수

# Let's Encrypt with certbot
sudo certbot --nginx -d example.com -d www.example.com
# 자동 갱신 (cron)
0 0,12 * * * certbot renew --quiet

mTLS — 서비스 간 인증

Server 인증 뿐 아니라 Client도 인증서로 증명
사용: Service Mesh (Istio, Linkerd), Zero Trust Network
도구: cert-manager + SPIFFE/SPIRE

5부 — REST vs gRPC vs GraphQL vs tRPC

REST (2000)

GET /api/users/1
Content-Type: application/json

{"id": 1, "name": "Alice"}

장점: 단순, 캐싱 쉬움, 모든 언어 지원 단점: Over/Under-fetching, N+1 쿼리, 버저닝 어려움

GraphQL (2015)

query {
  user(id: 1) {
    name
    posts { title }
  }
}

장점: 정확한 데이터 쿼리, 단일 엔드포인트, 스키마 강제 단점: 복잡, N+1 문제 (DataLoader 필요), 캐싱 어려움 2025 현실: Netflix, Shopify 유지. 하지만 "REST + 필드 선택(?fields=name,email)"이 더 간단하다는 인식 증가. 신규 프로젝트는 tRPC/REST 선호.

gRPC (2015)

// user.proto
service UserService {
  rpc GetUser(GetUserRequest) returns (User);
  rpc StreamUsers(Empty) returns (stream User);
  rpc ChatUsers(stream Message) returns (stream Message);
}

message GetUserRequest {
  int64 id = 1;
}

message User {
  int64 id = 1;
  string name = 2;
}

장점:

• 바이너리 직렬화(Protobuf) → REST JSON 대비 5-10x 빠름
• HTTP/2 + 스트리밍 4가지 모드 (unary, server-stream, client-stream, bidi-stream)
• 강타입, 코드 생성 자동화
• 서비스 간 통신 표준 (Kubernetes 내부 다수)

단점:

• 브라우저 직접 호출 어려움 (gRPC-Web 필요)
• 디버깅 어려움 (바이너리)
• Human-readable 아님

쓰는 곳: 마이크로서비스 간, Kubernetes, Envoy, Istio, TiKV, CockroachDB

tRPC (2022) — TypeScript End-to-End

// server
const appRouter = router({
  getUser: publicProcedure
    .input(z.object({ id: z.number() }))
    .query(async ({ input }) => {
      return await db.user.findUnique({ where: { id: input.id } });
    }),
});

// client
const user = await trpc.getUser.query({ id: 1 });
// ↑ 서버 스키마 그대로 타입 추론, 코드 생성 X

2025 현실: Next.js 풀스택 프로젝트에서 REST/GraphQL 대체하는 기본. Vercel, T3 Stack. 한계: TypeScript 전용, 서비스 간 통신(다른 언어)엔 gRPC

선택 가이드 2025

6부 — WebSocket vs SSE vs Long Polling vs WebTransport

실시간 양방향 통신 비교

WebSocket (2011) — 채팅의 왕

const ws = new WebSocket('wss://example.com/chat');
ws.onopen = () => ws.send(JSON.stringify({ type: 'hello' }));
ws.onmessage = (event) => console.log(JSON.parse(event.data));
ws.onclose = () => console.log('closed');

특징:

• HTTP로 시작 → Upgrade 헤더로 WebSocket 전환
• TCP connection 유지
• 양방향 binary/text 프레임
• ping/pong으로 keepalive

실전 함정:

• 재연결 로직 필수 — 네트워크 끊기면 자동 복구 안 됨
• Backpressure — 메시지 너무 빨리 오면 버퍼 오버플로우
• 인증 — WebSocket upgrade 시 쿠키/토큰 전달
• 로드밸런싱 — sticky session 또는 Redis pub/sub

// 재연결 with exponential backoff
class RobustWebSocket {
  connect() {
    this.ws = new WebSocket(this.url);
    this.ws.onclose = () => {
      setTimeout(() => this.connect(), Math.min(this.retry * 2, 30000));
      this.retry *= 2;
    };
    this.ws.onopen = () => { this.retry = 1000; };
  }
}

SSE (Server-Sent Events) — 단방향 간단

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

// server (Express)
app.get('/api/stream', (req, res) => {
  res.setHeader('Content-Type', 'text/event-stream');
  setInterval(() => {
    res.write(`data: ${JSON.stringify({ time: Date.now() })}\n\n`);
  }, 1000);
});

장점: 자동 재연결, HTTP 기반, 방화벽 통과 쉬움 단점: 서버→클라이언트만, 브라우저 6 connection 제한

2025 현실: LLM Streaming의 기본. ChatGPT, Claude API는 SSE 사용.

WebTransport (2024+, 신기술)

WebSocket의 한계(TCP HOL, TLS 1.2)를 해결
기반: HTTP/3 + QUIC
특징: 양방향, stream + datagram, 0-RTT
상태: Chrome, Safari TP 지원. 2025년 점진적 확산

쓰일 곳: 실시간 게임, VR, 고빈도 데이터 스트리밍

7부 — CDN, Edge Computing, Anycast

CDN 기본 원리

User → DNS → 가장 가까운 PoP → Cache HIT/MISS → Origin

용어:

• PoP (Point of Presence): CDN 서버 위치 (전 세계 200-300개)
• Edge: PoP에 있는 컴퓨팅 노드
• Origin: 원본 서버 (AWS, GCP 등)
• Cache HIT: PoP에 캐시됨 (빠름)
• Cache MISS: Origin까지 fetch
• Anycast: 같은 IP 주소를 전 세계 PoP가 광고 → BGP가 가장 가까운 곳으로 라우팅

CDN 2025 랜드스케이프

Cloudflare Workers — Edge 컴퓨팅의 표준

// worker.js
export default {
  async fetch(request, env) {
    const url = new URL(request.url);
    if (url.pathname === '/api/user') {
      const user = await env.DB.prepare('SELECT * FROM users WHERE id=?')
        .bind(url.searchParams.get('id'))
        .first();
      return Response.json(user);
    }
    return fetch(request); // passthrough
  },
};

특징:

• 전 세계 300+ PoP에서 실행
• V8 isolate 기반 → 5ms cold start (Lambda는 100ms+)
• 50ms CPU 제한 (무료 10ms)
• D1(SQLite), KV, R2(S3 호환), Durable Objects, Queues

쓰임: A/B testing, 인증 프록시, 이미지 리사이징, AI inference, 지역별 리다이렉트

Cache-Control 헤더 이해

Cache-Control: public, max-age=3600, s-maxage=86400, stale-while-revalidate=60

• public: CDN/브라우저 모두 캐시
• private: 브라우저만 (CDN X)
• max-age=3600: 브라우저 1시간
• s-maxage=86400: CDN 1일 (우선)
• stale-while-revalidate=60: 만료 후 60초는 stale 서빙, 백그라운드 갱신
• no-cache: 매번 Origin에 확인 (If-Modified-Since)
• no-store: 절대 캐시 X
• immutable: 절대 변경 안 됨 (해시된 자산)

Cache Invalidation (유명한 2대 난제 중 하나)

전략 비교:

1. Path purge: /api/user/1 특정 URL 제거
2. Surrogate key / Cache Tag: Cache-Tag: user:1 → 태그 기준 일괄 제거 (Fastly, Cloudflare Enterprise)
3. Versioning: /api/v2/user/1 — 새 버전 배포
4. Content hash: /static/app.a3f9.js — 파일 내용 변경되면 해시 변경

2025 현실: 대규모 시스템은 Surrogate Key + stale-while-revalidate.

Origin Shield — CDN 앞의 CDN

Edge → Origin Shield (단일 PoP) → Origin

효과: 300개 PoP가 각자 Origin 치는 대신 1개 Shield가 Origin 침 → Origin 부하 90% 감소.

8부 — DNS, Anycast, BGP

DNS 2025 — 빠르고 암호화된

DoH (DNS over HTTPS): 1.1.1.1, 8.8.8.8 (Cloudflare, Google) DoT (DNS over TLS): 포트 853 DNSSEC: 서명으로 변조 방지 (2024년부터 ccTLD 대부분 지원)

DNS 레코드 타입 핵심

Anycast — 하나의 IP, 수백 개 위치

1.1.1.1 (Cloudflare DNS)
전 세계 300개 PoP가 같은 IP를 BGP로 광고
사용자 패킷은 가장 가까운 PoP로 자동 라우팅

장점: DDoS 완화(공격 분산), 지연 감소 단점: TCP connection은 state 유지되어야 해서 복잡 (Cloudflare Unimog 같은 LB 필요)

BGP — 인터넷의 라우팅 프로토콜

한 줄 요약: "나는 1.2.3.0/24를 가지고 있어" — ISP들이 서로 광고 사고 사례: 2021 Facebook outage — BGP 광고 실수로 자사 DNS 접근 불가 → 6시간 다운 보안: RPKI(Route Origin Authorization)로 BGP hijacking 방지

9부 — 네트워크 디버깅 툴킷

레이어별 도구

L1-L2: ethtool, mii-tool (잘 안 씀)
L3 IP: ping, traceroute, mtr
L4 TCP/UDP: netstat, ss, tcpdump, Wireshark
L7 HTTP: curl, httpie, Postman, Wireshark (HTTPS는 TLS 키 필요)
DNS: dig, nslookup, dog (Rust)

필수 명령어

# 1. 연결 확인
ping google.com
curl -I https://example.com  # 헤더만

# 2. DNS
dig example.com A +short
dig @1.1.1.1 example.com  # 특정 resolver 사용

# 3. 경로 확인
traceroute google.com
mtr google.com  # 실시간 경로 + 패킷 손실

# 4. 소켓 상태
ss -tunap  # TCP/UDP, 리스닝, PID
ss -s      # 요약 (ESTABLISHED 개수 등)

# 5. 패킷 캡처
sudo tcpdump -i any -w capture.pcap port 443
wireshark capture.pcap  # GUI로 분석

# 6. HTTP/3 테스트
curl --http3 https://cloudflare.com -v

# 7. TLS 분석
openssl s_client -connect example.com:443 -tls1_3
# 또는 modern 도구
testssl.sh example.com

성능 측정

# 대역폭
iperf3 -s  # server
iperf3 -c server.com -t 30  # client

# 응답 시간 (curl format)
curl -w "@curl-format.txt" -o /dev/null -s https://example.com
# curl-format.txt:
# time_namelookup:  %{time_namelookup}s\n
# time_connect:     %{time_connect}s\n
# time_appconnect:  %{time_appconnect}s\n
# time_starttransfer: %{time_starttransfer}s\n
# time_total:       %{time_total}s\n

10부 — 네트워크 성능 튜닝

TCP 튜닝 (Linux)

# /etc/sysctl.conf
net.core.rmem_max = 134217728          # 수신 버퍼 128MB
net.core.wmem_max = 134217728          # 송신 버퍼 128MB
net.ipv4.tcp_rmem = 4096 87380 134217728
net.ipv4.tcp_wmem = 4096 65536 134217728
net.ipv4.tcp_congestion_control = bbr  # Google BBR (cubic 기본보다 좋음)
net.ipv4.tcp_fastopen = 3              # TFO (0-RTT for TCP)
net.core.somaxconn = 65535             # accept queue

BBR — Google이 만든 혼잡 제어

기존 CUBIC: 패킷 손실 → 혼잡 가정 → 윈도우 줄임
BBR: 대역폭(BtlBw) + 지연(RTprop) 추정 → 실제 용량 대비 전송
효과: 고지연 네트워크(국제선)에서 2-10x 처리량
사용: YouTube, Google Cloud 기본

Keep-Alive는 무조건 켜라

HTTP: Connection: keep-alive (HTTP/1.1 기본)
TCP: SO_KEEPALIVE
이유: 새 연결 Handshake 비용 (TCP 1-RTT + TLS 1-RTT)
주의: Load balancer timeout보다 client keepalive 짧게

CDN 활용 체크리스트

• 정적 자산(JS/CSS/이미지) CDN 서빙
• Cache-Control: public, max-age=31536000, immutable (해시된 파일)
• HTML은 stale-while-revalidate
• API 응답도 캐시 가능하면 캐시 (GET, 공개)
• Brotli 압축 활성화 (gzip보다 20% 작음)
• HTTP/3 활성화
• 이미지: WebP/AVIF, <picture> fallback
• Origin Shield (대규모)
• Cache Tag 기반 purge

11부 — 실전 장애 시나리오 5가지

케이스 1: "API가 간헐적으로 느림"

증상: 평소 50ms, 가끔 5000ms 스파이크 디버깅:

1. DNS TTL 확인 — 짧으면 DNS lookup 매번 발생
2. Keep-alive 확인 — 새 connection마다 TLS handshake
3. Connection pool 확인 — pool exhausted → 새 connection 대기 해결: DNS TTL 늘리고, HTTP client에 connection pool 크게

케이스 2: "한국에서만 느림"

증상: 미국 50ms, 한국 500ms 원인: Origin이 us-east, CDN 없음 해결: CDN 추가, Seoul PoP 사용, Origin Shield

케이스 3: "WebSocket이 끊김"

증상: 30초마다 끊어짐 원인: Load balancer idle timeout (AWS ALB 60초, Cloudflare 100초) 해결: ping/pong 30초 간격, LB timeout 늘림

케이스 4: "HTTP/3 켰더니 느려짐"

증상: HTTP/2 대비 느림 원인: 기업 방화벽/VPN이 UDP:443 차단 → fallback to HTTP/2 해결: Alt-Svc 헤더 설정, QUIC bit 확인, fallback 정상 동작 확인

케이스 5: "TLS handshake가 800ms"

증상: 정상 150ms, 가끔 800ms 원인: OCSP stapling 미사용 → 브라우저가 CA에 revocation 확인 해결: Nginx ssl_stapling on;, Must-Staple 인증서

12부 — Zero Trust와 Service Mesh

Zero Trust Network

원칙: "네트워크 내부도 신뢰하지 않는다"
구현:
- mTLS (서비스 간 상호 인증)
- 짧은 인증서 TTL (1시간)
- Identity-aware proxy (Google IAP, Cloudflare Access)
- Microsegmentation (NetworkPolicy)

Service Mesh 비교

2025 현실: Cilium이 CNI + Service Mesh 통합으로 세대교체 중. eBPF로 사이드카 없이 mTLS.

13부 — 6개월 로드맵

1개월차: curl, dig, ss, tcpdump 익숙해지기. 내 서비스 TCP/TLS handshake 측정 2개월차: HTTP/1.1 → 2 → 3 차이 실습. Caddy로 HTTP/3 활성화 3개월차: TLS 1.3, Let's Encrypt, mTLS 실습. ALPN, SNI 이해 4개월차: REST, gRPC, tRPC 작은 서비스 각각 구현. 성능 비교 5개월차: CDN 도입 (Cloudflare). Cache-Control, Surrogate Key, Origin Shield 6개월차: 장애 시뮬레이션 (tc로 지연/손실 주입). BBR, TCP 튜닝. Zero Trust 개념

14부 — 체크리스트 12개

• HTTP/3 활성화 (Alt-Svc 헤더 확인)
• TLS 1.3 only, TLS 1.0/1.1 disable
• HSTS 헤더 (max-age=31536000; includeSubDomains; preload)
• Let's Encrypt 자동 갱신 (certbot renew)
• OCSP stapling 활성화
• BBR congestion control
• TCP keep-alive + HTTP keep-alive
• CDN 도입 (정적 자산 + API 캐시)
• Brotli 압축
• 이미지 WebP/AVIF
• HTTP 캐시 헤더 정책 문서화
• WebSocket 재연결 + backpressure

15부 — 안티패턴 10가지

1. HTTP만 서빙 (HTTPS 미적용) → 브라우저가 "안전하지 않음" 경고
2. TLS 1.0/1.1 유지 → PCI-DSS 위반, 취약점
3. CDN 없이 글로벌 서비스 → 한국 사용자 800ms 지연
4. Keep-alive 비활성화 → 매 요청 handshake
5. Cache-Control 미설정 → CDN 캐시 활용 못함
6. GraphQL 캐싱 안 함 → N+1 폭발
7. WebSocket 재연결 로직 없음 → LB timeout 시 영구 끊김
8. DNS TTL 너무 김 (86400) → 장애 시 페일오버 느림
9. Cache Invalidation을 수동으로 → 스케일 불가, Surrogate Key 필수
10. TCP BBR 미적용 → 국제선 느림

마무리 — "패킷이 어디로 가는지 알면 디버깅이 달라진다"

네트워크는 보이지 않는다. 그래서 느리면 범인을 모른다.

• DNS 느림? dig로 확인
• TLS 느림? openssl s_client로 확인
• 중간 네트워크 느림? mtr로 확인
• CDN 캐시 안 됨? curl -I로 헤더 확인
• HTTP/3 안 됨? curl --http3 -v로 확인

2025년 네트워크의 핵심 키워드는 QUIC, Edge, Zero Trust. 이 셋이 HTTP를 재정의하고, CDN을 Edge로 확장하고, 보안을 기본값으로 만든다.

다음 글은 Season 2 Ep 15 — 클라우드 네이티브 완전 가이드. Kubernetes, Service Mesh, Serverless, FaaS, Container Runtime, eBPF까지. 네트워크가 배관이면, 클라우드 네이티브는 그 위의 도시다.

다음 글 예고 — "클라우드 네이티브 완전 가이드: Kubernetes·Serverless·eBPF·Container"

Season 2 Ep 15는 2025년 인프라의 표준, 클라우드 네이티브. 다음 글은:

• Kubernetes 핵심 개념 (Pod, Service, Ingress, CRD)
• Serverless vs Container vs VM 선택
• eBPF 혁명 (Cilium, Falco, Pixie)
• Container Runtime (containerd, Kata, Firecracker)
• GitOps (ArgoCD, Flux)
• Cost optimization (Karpenter, Spot)

배관 위에 도시를 짓는다. 다음 글에서.