김신건의 로그 - 위키 / network

[Network] CORS: Same-Origin Policy, preflight, credentials

koa (김신건) — Thu, 16 Jul 2026 00:00:00 GMT

정의

CORS (Cross-Origin Resource Sharing) 는 Same-Origin Policy (SOP) 의 완화 메커니즘. 브라우저가 origin 이 다른 리소스에 조건부로 접근 할 수 있게 한다.

[!IMPORTANT] CORS 는 브라우저의 보안 모델. 서버 -> 서버 호출에는 영향 없음. curl, Postman 도 CORS 적용 안 함. 오로지 브라우저가 JS 코드의 cross-origin fetch 를 막거나 허용한다.

Origin = scheme + host + port

URL	Origin
`https://app.example.com/page`	`https://app.example.com`
`https://app.example.com:443`	`https://app.example.com` (default port)
`http://app.example.com`	`http://app.example.com` (scheme 다름)
`https://api.example.com`	`https://api.example.com` (host 다름)

Simple Request vs Preflight

flowchart TD
    Q{"요청이 Simple?"}
    Q -->|예| S["즉시 보냄"]
    Q -->|아니오| P["OPTIONS preflight 먼저"]
    S --> CHECK1["응답의 ACAO 검증"]
    P --> CHECK2["preflight 응답 검증"]
    CHECK2 -->|허용| Send["실제 요청 전송"]
    CHECK2 -->|거절| Block["브라우저 차단"]

Simple Request 조건 (모두 만족)

Method: GET, HEAD, POST
헤더: 안전한 헤더 + Content-Type: application/x-www-form-urlencoded | multipart/form-data | text/plain
이벤트 listener 없음 (XHR upload)
ReadableStream body 없음

위 조건 하나라도 어기면 preflight. JSON Content-Type: application/json 도 preflight 유발.

Preflight 흐름

sequenceDiagram
    autonumber
    participant B as Browser
    participant S as Server

    B->>S: OPTIONS /api/users<br/>Origin: https://app.example.com<br/>Access-Control-Request-Method: POST<br/>Access-Control-Request-Headers: content-type, authorization
    S-->>B: 204 No Content<br/>Access-Control-Allow-Origin: https://app.example.com<br/>Access-Control-Allow-Methods: GET, POST, DELETE<br/>Access-Control-Allow-Headers: content-type, authorization<br/>Access-Control-Max-Age: 86400
    Note over B: 캐시 (Max-Age)
    B->>S: POST /api/users<br/>Origin: https://app.example.com<br/>Content-Type: application/json<br/>{...}
    S-->>B: 201 Created<br/>Access-Control-Allow-Origin: https://app.example.com

Response 헤더 가이드

헤더	의미
`Access-Control-Allow-Origin`	허용된 origin (하나만 또는 `*`)
`Access-Control-Allow-Methods`	preflight 응답에서 허용 method
`Access-Control-Allow-Headers`	허용 헤더
`Access-Control-Expose-Headers`	JS 가 읽을 수 있는 응답 헤더
`Access-Control-Max-Age`	preflight 캐시 (초)
`Access-Control-Allow-Credentials`	`true` 면 cookie/Authorization 허용

fetch('https://api.example.com/me', {
  credentials: 'include',   // cookie 보내기
});

이 경우 서버는 반드시:

Access-Control-Allow-Origin: https://app.example.com   # * 불가능
Access-Control-Allow-Credentials: true

[!CAUTION] Allow-Origin: * + Allow-Credentials: true 는 RFC 위반. 브라우저가 거절. credentials 가 필요하면 명시적 origin.

서버 구현 가이드

Express (Node.js)


app.use(cors({
  origin: ['https://app.example.com', 'https://staging.example.com'],
  credentials: true,
  methods: ['GET', 'POST', 'PUT', 'DELETE'],
  allowedHeaders: ['Content-Type', 'Authorization'],
  exposedHeaders: ['X-Total-Count'],
  maxAge: 86400,
}));

Spring Boot

@Configuration
public class CorsConfig {
    @Bean
    public WebMvcConfigurer corsConfigurer() {
        return new WebMvcConfigurer() {
            @Override
            public void addCorsMappings(CorsRegistry registry) {
                registry.addMapping("/api/**")
                    .allowedOrigins(
                        "https://app.example.com",
                        "https://staging.example.com"
                    )
                    .allowedMethods("GET", "POST", "PUT", "DELETE")
                    .allowedHeaders("Content-Type", "Authorization")
                    .exposedHeaders("X-Total-Count")
                    .allowCredentials(true)
                    .maxAge(86400);
            }
        };
    }
}

nginx

location /api/ {
    if ($request_method = OPTIONS) {
        add_header Access-Control-Allow-Origin  $http_origin;
        add_header Access-Control-Allow-Methods "GET, POST, PUT, DELETE, OPTIONS";
        add_header Access-Control-Allow-Headers "Content-Type, Authorization";
        add_header Access-Control-Allow-Credentials true;
        add_header Access-Control-Max-Age 86400;
        return 204;
    }

    add_header Access-Control-Allow-Origin  $http_origin always;
    add_header Access-Control-Allow-Credentials true always;
    proxy_pass http://backend;
}

[!WARNING] nginx 에서 $http_origin 를 그대로 반영하면 모든 origin 허용 과 같음. 허용된 origin 목록을 map 디렉티브로 먼저 검증해야 한다.

동적 Origin 허용 패턴

Allow-Origin 에 하나의 값만 담을 수 있다. 여러 origin 을 허용할 때:

const ALLOWED_ORIGINS = new Set([
  'https://app.example.com',
  'https://staging.example.com',
  'http://localhost:3000',
]);

app.use((req, res, next) => {
  const origin = req.headers.origin;
  if (ALLOWED_ORIGINS.has(origin)) {
    res.setHeader('Access-Control-Allow-Origin', origin);
    res.setHeader('Vary', 'Origin');       // CDN 캐시 분리
  }
  next();
});

Vary: Origin 이 없으면 CDN 이 다른 origin 의 응답 을 캐시해서 제공. 반드시 추가.

SOP 가 막는 것들

fetch('https://other.com') 의 응답 읽기
다른 origin iframe 의 DOM 접근
다른 origin 의 cookie 읽기

SOP 가 막지 않는 것 (CSRF 의 토대):

<form action="https://other.com"> 의 POST
<img src="https://other.com/api"> (GET)
<script src="https://other.com/api"> (실행됨)

CORS vs CSRF

	CORS	CSRF
본질	cross-origin fetch 허용	cross-origin 의 위조 요청 방어
방향	브라우저 -> 서버 허용	브라우저 -> 서버 거절
토대	Same-Origin Policy 의 완화	Same-Origin Policy 의 우회 방어
도구	Response 헤더 (ACAO)	CSRF token, SameSite cookie

자세한 건 [[csrf|CSRF]] 참고.

개발 환경 팁

로컬 개발 시 localhost:3000 (프론트) -> localhost:8080 (백엔드) 도 cross-origin.

프록시: vite.config.ts 의 server.proxy 로 /api/* 를 백엔드로 라우팅 (브라우저 관점에서 same-origin)
백엔드 allowOrigin: http://localhost:3000 을 명시적으로 허용
HTTPS 불일치: 로컬에서 http://, 프로덕션에서 https:// 를 혼용하면 다른 origin

흔한 함정

[!WARNING]

Allow-Origin: * 를 모든 경우에 박음: credentials 모드에서 동작 안 함.

preflight 응답에 200 보냄: 보통 204 No Content 가 정석. 200 도 동작은 하지만 관습 아님.

Vary: Origin 누락: CDN 이 다른 origin 응답 을 캐시. 모든 사용자에게 같은 origin 의 응답 이 감.

CORS 가 서버 보안이라고 오해: 브라우저 보안. curl 은 CORS 무시. 서버 보안은 auth, IP allowlist 등 별도.

로컬 환경만 허용: http://localhost:3000 만 허용해두고 프로덕션 cross-origin 미테스트.

CORS 디버깅 체크리스트

브라우저 콘솔에서 CORS 오류가 났을 때:

Network 탭 확인: OPTIONS preflight 가 발생했는지, 응답 코드 확인
응답 헤더 확인: Access-Control-Allow-Origin 이 실제로 존재하는지
origin 비교: 요청 Origin 헤더와 응답 ACAO 값이 정확히 일치하는지 (trailing slash 주의)
credentials 모드: credentials: 'include' 인데 ACAO: * 이면 실패
CDN 캐시: Vary: Origin 없이 캐싱된 preflight 응답이 문제일 수 있음

// 빠른 CORS 테스트
fetch('https://api.example.com/health', {
  method: 'OPTIONS',
  headers: {
    'Origin': 'https://app.example.com',
    'Access-Control-Request-Method': 'POST',
    'Access-Control-Request-Headers': 'content-type',
  },
}).then(res => {
  console.log('Status:', res.status);
  console.log('ACAO:', res.headers.get('access-control-allow-origin'));
  console.log('Credentials:', res.headers.get('access-control-allow-credentials'));
});

Private Network Access (PNA)

Chrome 94+ 에서 추가된 보안 정책. Public internet -> Private network (192.168.x.x, 10.x.x.x) 로의 요청도 preflight 를 요구.

# PNA preflight 에 추가 헤더
Access-Control-Request-Private-Network: true

# 서버 응답 필요
Access-Control-Allow-Private-Network: true

로컬 개발 서버 (localhost) 에 외부 스크립트가 접근할 때 발생. 서버에 위 헤더 추가 필요.

[Network] HTTP/3: QUIC 위의 HTTP, 0-RTT, connection migration

koa (김신건) — Thu, 16 Jul 2026 00:00:00 GMT

정의

HTTP/3 (2022, RFC 9114)는 HTTP의 전송 레이어를 [[tcp|TCP]] 에서 [[quic|QUIC]] 으로 교체한 버전이다. UDP 위에 QUIC, QUIC 위에 HTTP 구조다.

핵심 동기:

TCP HoL Blocking 해결: 스트림 단위 패킷 손실 격리
0-RTT 핸드셰이크: 재방문 시 연결 지연 제로
Connection Migration: IP 변경 시 연결 유지

flowchart TB
    HTTP["HTTP/3 semantics\n(RFC 9114)"]
    QUIC["QUIC\n멀티스트림 + 암호화 + 혼잡제어\n(RFC 9000)"]
    UDP["UDP"]
    IP["IP"]

    HTTP --> QUIC --> UDP --> IP

HTTP 버전 비교

항목	HTTP/1.1	HTTP/2	HTTP/3
전송 계층	TCP	TCP	QUIC (UDP)
멀티플렉싱	없음 (keep-alive)	TCP 스트림 내	QUIC 독립 스트림
HoL Blocking	TCP + 앱 레벨	TCP 레벨	없음
핸드셰이크	1 RTT + TLS	1 RTT + TLS	1 RTT (TLS 통합)
재접속	1 RTT	1 RTT	0 RTT
헤더 압축	없음	[[hpack	HPACK]]
서버 Push	없음	있음 (사실상 폐기)	없음
Connection Migration	불가	불가	가능
암호화	선택	선택	필수 (TLS 1.3 통합)

Handshake: 0-RTT의 마법

sequenceDiagram
    autonumber
    participant C as Client
    participant S as Server

    rect rgb(220,240,220)
    Note over C,S: 첫 방문 (1-RTT)
    C->>S: Initial (TLS ClientHello + crypto frames)
    S-->>C: Initial + Handshake (server params + cert)
    C->>S: Handshake (finish) + HTTP/3 request
    S-->>C: HTTP/3 response + session ticket
    end

    rect rgb(255,235,220)
    Note over C,S: 재방문 (0-RTT)
    C->>S: 0-RTT data (HTTP/3 request + cached session params)
    S-->>C: HTTP/3 response (즉시)
    end

QUIC은 TLS 1.3 핸드셰이크를 전송 계층 협상과 통합한다. 첫 방문은 1 RTT, 이전 연결의 세션 티켓을 캐시해두면 재접속 시 0 RTT로 데이터를 즉시 전송할 수 있다.

[!CAUTION] 0-RTT는 replay 공격에 취약하다. 비멱등 요청(POST, DELETE, 결제)을 0-RTT로 보내면 중간자가 같은 요청을 반복 재생할 수 있다. GET/HEAD 같은 안전한 메서드만 0-RTT를 허용하고, 나머지는 반드시 1-RTT 이후 처리해야 한다.

TCP HoL Blocking vs QUIC Stream 독립

flowchart TB
    subgraph T["HTTP/2 over TCP"]
        TS["stream 1, 3, 5가\n같은 TCP 시퀀스 안"]
        TPacket1["패킷 1: stream 1 데이터"]
        TPacket2["패킷 2: stream 3 데이터 (손실!)"]
        TPacket3["패킷 3: stream 5 데이터"]
        TBlock["stream 1, 5 모두 대기"]
        TS --> TPacket1 & TPacket2 & TPacket3
        TPacket2 -.->|"TCP는 순서 보장 필요"| TBlock
    end
    subgraph Q["HTTP/3 over QUIC"]
        QS["stream 1, 3, 5가\n각자 독립 시퀀스"]
        QPacket1["패킷 1: stream 1 (도착)"]
        QPacket2["패킷 2: stream 3 (손실)"]
        QPacket3["패킷 3: stream 5 (도착)"]
        QOK["stream 1, 5 즉시 처리"]
        QWait["stream 3만 대기"]
        QS --> QPacket1 & QPacket2 & QPacket3
        QPacket1 --> QOK
        QPacket3 --> QOK
        QPacket2 --> QWait
    end

HTTP/2는 TCP 레이어에서 스트림 1, 3, 5를 하나의 바이트 스트림으로 전송한다. 패킷 2가 손실되면 TCP가 재전송을 완료할 때까지 패킷 3도 애플리케이션에 전달되지 않는다. 이것이 TCP 레벨 HoL Blocking이다.

HTTP/3 QUIC은 스트림을 독립 단위로 격리한다. stream 3 패킷이 손실되어도 stream 1과 5는 즉시 애플리케이션에 전달된다.

Connection Migration

WiFi에서 4G로 전환, NAT 재할당 등 IP가 바뀌어도 연결이 유지된다.

sequenceDiagram
    participant C as Client
    participant S as Server

    C->>S: WiFi IP 192.168.1.10:54321 (conn_id=XYZ)
    S-->>C: 응답 (conn_id=XYZ)
    Note over C: 지하철 진입, 4G 전환
    Note over C: IP 변경: 10.0.0.5:65432
    C->>S: 4G IP 10.0.0.5:65432 (conn_id=XYZ)
    Note over S: Connection ID XYZ로 식별 (IP 무관)
    S-->>C: 응답 (conn_id=XYZ, 연결 유지)
    Note over C,S: TLS 세션 유지, 처음부터 다시 안 함

TCP는 (src IP, src port, dst IP, dst port) 4-tuple로 연결을 식별하므로 IP가 바뀌면 연결이 끊긴다. QUIC은 Connection ID로 연결을 식별하여 IP/포트 변경을 투명하게 처리한다.

QPACK 헤더 압축

[[hpack|HPACK]]의 순서 의존성 문제를 해결한 변형이다.

flowchart LR
    E["QPACK Encoder\n(클라이언트)"]
    D["QPACK Decoder\n(서버)"]

    E -->|"인코더 스트림\n동적 테이블 업데이트"| D
    D -->|"디코더 스트림\n테이블 업데이트 ACK"| E
    E -->|"요청 스트림\n헤더 블록 (인덱스 참조)"| D

항목	HPACK (HTTP/2)	QPACK (HTTP/3)
동적 테이블	단일 스트림에서 인라인 업데이트	별도 인코더/디코더 스트림
순서 의존성	있음 (TCP가 보장)	없음 (QUIC 스트림 독립)
HOL 블로킹	TCP 레벨	QPACK 레벨 동기화로 제거

Alt-Svc: HTTP/3 협상 방법

브라우저는 HTTP/3를 처음부터 알 수 없다. 서버가 Alt-Svc 헤더로 HTTP/3 지원을 알린다.

HTTP/1.1 200 OK
Alt-Svc: h3=":443"; ma=86400, h3-29=":443"; ma=86400

이후 브라우저는 UDP 443 포트로 QUIC 연결을 시도하고, 성공하면 HTTP/3를 사용한다. 실패하면 HTTP/2나 HTTP/1.1로 fallback한다.

실전: 서버 설정

nginx (1.25+)

server {
    listen 443 quic reuseport;   # HTTP/3 UDP
    listen 443 ssl;              # HTTP/2 TCP fallback

    ssl_certificate     /path/to/cert.pem;
    ssl_certificate_key /path/to/key.pem;
    ssl_protocols       TLSv1.3;  # QUIC은 TLS 1.3 필수

    # 브라우저에 HTTP/3 지원 알림
    add_header Alt-Svc 'h3=":443"; ma=86400';

    # QUIC 버퍼 최적화
    quic_retry on;  # QUIC Retry 패킷으로 DoS 방어
}

Cloudflare Workers (HTTP/3 자동)

// Cloudflare Workers는 HTTP/3를 자동 협상
// 별도 설정 없이 h3 지원
export default {
  async fetch(request, env) {
    // request.cf.httpProtocol 로 클라이언트 프로토콜 확인
    const proto = request.cf?.httpProtocol;  // "HTTP/3" | "HTTP/2" | "HTTP/1.1"
    return new Response(`Protocol: ${proto}`);
  },
};

HTTP/3 연결 테스트

# curl로 HTTP/3 요청 (curl 7.88+, QUIC 빌드 필요)
curl --http3 https://cloudflare.com -I

# HTTP/3 협상 확인
curl -v --http3 https://example.com 2>&1 | grep -E "ALPN|http"
# * ALPN: h3

# 연결 없이 HTTP/3 즉시 시도
curl --http3-prior-knowledge https://example.com

# Python httpx로 HTTP/3
# pip install httpx[http3]
import httpx
with httpx.Client(http2=True) as client:
    response = client.get("https://example.com")
    print(response.http_version)  # HTTP/3 또는 HTTP/2

도입 현황 (2026)

영역	비중
Cloudflare / Fastly / Akamai (CDN)	기본 활성
Google 서비스	전면 HTTP/3
모바일 앱 (iOS, Android)	빠르게 증가
일반 웹 사이트 (브라우저 트래픽)	약 35%+
기업 내부망 (방화벽 UDP 차단)	더딤

브라우저 지원 현황: Chrome, Firefox, Safari, Edge 모두 HTTP/3를 지원한다 (2022년 이후 기본 활성).

[!NOTE] 방화벽이 UDP 443 포트를 차단하면 HTTP/3 fallback이 발생해 HTTP/2 (TCP)로 내려간다. 사내망 환경에서 HTTP/3가 동작하지 않는 가장 흔한 원인이다.

흔한 함정

[!WARNING]

방화벽 UDP 차단: 기업망, 일부 ISP에서 UDP 443을 차단한다. Alt-Svc로 광고하더라도 실제 사용률을 모니터링해야 한다.

0-RTT replay 공격: POST, DELETE, 결제 등 비멱등 요청을 0-RTT로 허용하면 재생 공격 가능. GET/HEAD만 0-RTT 허용.

Connection ID 추적: Connection ID가 식별자처럼 쓰일 수 있어 프라이버시 우려. RFC 9000은 주기적 Connection ID 변경을 권장.

로드 밸런서 UDP 해싱 문제: 전통적 LB는 5-tuple(IP+포트) 해싱. IP 변경 시 다른 백엔드로 라우팅될 수 있다. Connection ID 기반 라우팅 지원 LB 필요.

세션 티켓 공유: 다중 서버 환경에서 0-RTT를 위해 세션 티켓을 서버 간 공유해야 한다. 미공유 시 0-RTT 실패.

CPU 비용: QUIC의 사용자 공간 구현은 커널 바이패스 없이 암호화 비용이 TCP+TLS보다 높을 수 있다.

[Network] NAT: Network Address Translation

koa (김신건) — Thu, 16 Jul 2026 00:00:00 GMT

정의

NAT (Network Address Translation) 는 IP 패킷의 헤더에서 소스 또는 목적지 IP 주소(포트 포함)를 변환하는 기법이다. 주로 사설 IP와 공인 IP 간 매핑에 사용된다.

왜 필요한가

flowchart LR
    subgraph Private["사설망 (192.168.0.0/24)"]
        H1["호스트 A\n192.168.0.10"]
        H2["호스트 B\n192.168.0.11"]
        H3["호스트 C\n192.168.0.12"]
    end

    Router["라우터 / NAT 장비\n공인 IP: 203.0.113.5"]
    Internet["인터넷"]

    H1 & H2 & H3 --> Router --> Internet

IPv4 주소 고갈: 전 세계 IPv4 주소는 약 43억 개뿐이다. 사내 100대 호스트가 공인 IP 1개를 공유하면 99개를 절약한다.
보안: 내부 호스트의 실제 IP를 외부에 노출하지 않는다.
정책 제어: 특정 내부 서비스만 선택적으로 외부에 노출할 수 있다.

종류

SNAT (Source NAT)

아웃바운드 트래픽의 소스 IP/포트를 공인 IP로 변경한다. 홈 라우터나 AWS NAT Gateway의 기본 동작이다.

sequenceDiagram
    participant H as "호스트\n192.168.1.10:12345"
    participant R as "NAT 라우터\n203.0.113.5"
    participant S as "외부 서버\n1.2.3.4:443"

    H->>R: src=192.168.1.10:12345, dst=1.2.3.4:443
    Note over R: 매핑 테이블 등록\n192.168.1.10:12345 -> 203.0.113.5:54321
    R->>S: src=203.0.113.5:54321, dst=1.2.3.4:443
    S-->>R: src=1.2.3.4:443, dst=203.0.113.5:54321
    Note over R: 매핑 테이블 조회\n203.0.113.5:54321 -> 192.168.1.10:12345
    R-->>H: src=1.2.3.4:443, dst=192.168.1.10:12345

DNAT (Destination NAT)

인바운드 트래픽의 목적지 IP/포트를 내부 서버로 변경한다. 포트 포워딩이 대표적인 예시다.

sequenceDiagram
    participant C as "외부 클라이언트\n8.8.8.8"
    participant R as "NAT 라우터\n203.0.113.5:80"
    participant S as "내부 웹 서버\n192.168.1.10:8080"

    C->>R: dst=203.0.113.5:80
    Note over R: DNAT 규칙 적용\n:80 -> 192.168.1.10:8080
    R->>S: dst=192.168.1.10:8080
    S-->>R: src=192.168.1.10:8080
    R-->>C: src=203.0.113.5:80

사용 예:

웹 서버 포트 포워딩 (공인 :80 -> 내부 :8080)
쿠버네티스 NodePort
로드 밸런서의 VIP(Virtual IP) 처리

PAT (Port Address Translation, NAPT)

포트까지 포함한 매핑으로 한 공인 IP를 여러 내부 호스트가 공유한다. 실제로 대부분의 NAT는 PAT를 의미한다.

내부 주소	공인 주소 매핑
192.168.1.10:12345	203.0.113.5:1001
192.168.1.11:12345	203.0.113.5:1002
192.168.1.10:12346	203.0.113.5:1003

포트 번호 공간은 65535개이므로 한 공인 IP로 수만 개의 동시 연결을 처리할 수 있다. 단, 연결이 많아지면 포트 고갈이 발생한다.

NAT 매핑 테이블

NAT 매핑 테이블 (PAT 예시)

| Proto | 내부 IP         | 내부 Port | 외부 IP         | 외부 Port | 상태     | 타임아웃 |
|-------|-----------------|-----------|-----------------|-----------|----------|----------|
| TCP   | 192.168.1.10    | 12345     | 203.0.113.5     | 1001      | ESTABLISHED | 300s  |
| TCP   | 192.168.1.11    | 12345     | 203.0.113.5     | 1002      | TIME_WAIT   | 30s   |
| UDP   | 192.168.1.10    | 54321     | 203.0.113.5     | 2001      | ACTIVE      | 60s   |

TCP: 연결 상태(SYN/ESTABLISHED/FIN)를 추적해 매핑 유지
UDP: stateless이므로 마지막 패킷 이후 일정 시간 후 만료 (보통 60-300초)
ICMP: echo id 기반 매핑

NAT 종류별 동작 차이 (RFC 3489 분류)

타입	설명	P2P 적합성
Full Cone NAT	내부 IP:Port가 외부 IP:Port에 고정 매핑. 누구나 외부 포트로 연결 가능	가장 좋음
Restricted Cone NAT	내부에서 먼저 통신한 외부 IP만 접근 허용	중간
Port Restricted Cone NAT	외부 IP + 포트까지 제한	어려움
Symmetric NAT	목적지마다 다른 포트 할당. 가장 엄격	매우 어려움

클라우드에서의 NAT

AWS

flowchart LR
    subgraph PrivateSubnet["프라이빗 서브넷"]
        EC2["EC2 Instance\n10.0.1.10"]
    end
    subgraph PublicSubnet["퍼블릭 서브넷"]
        NATGW["NAT Gateway\n탄력적 IP: 52.x.x.x"]
    end
    IGW["Internet Gateway"]
    Internet["Internet"]

    EC2 --> NATGW --> IGW --> Internet

NAT Gateway: AWS 관리형 서비스. 고가용성, 자동 확장. 시간당 + 데이터 전송량 과금.
NAT Instance: 직접 관리하는 EC2. 비용 절감 가능하지만 단일 장애점.

실무에서는 NAT Gateway를 권장하며, 비용 절감 시 VPC Endpoint로 S3/DynamoDB 트래픽을 NAT 없이 직접 연결한다.

iptables로 Linux NAT 직접 구성

# SNAT: 내부망 아웃바운드 트래픽을 eth0 IP로 변환
iptables -t nat -A POSTROUTING -s 192.168.1.0/24 -o eth0 -j MASQUERADE

# DNAT: 80 포트를 내부 8080으로 포워딩
iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 80 -j DNAT \
  --to-destination 192.168.1.10:8080

# 포워딩 활성화
echo 1 > /proc/sys/net/ipv4/ip_forward

# 현재 NAT 테이블 확인
iptables -t nat -L -n -v

NAT Traversal

P2P 통신 (WebRTC, 게임, VoIP)에서 NAT 뒤에 있는 피어끼리 직접 연결을 맺으려면 NAT를 뚫어야 한다.

flowchart TB
    subgraph NAT_A["NAT A (Symmetric)"]
        A["피어 A\n192.168.1.10"]
    end
    subgraph NAT_B["NAT B (Full Cone)"]
        B["피어 B\n10.0.0.5"]
    end
    STUN["STUN 서버\n(공인 IP)"]
    TURN["TURN 서버\n(릴레이)"]

    A -->|"1. 내 공인 IP:Port 확인 요청"| STUN
    STUN -->|"2. 203.0.113.5:54321 응답"| A
    B -->|"1. 내 공인 IP:Port 확인 요청"| STUN
    STUN -->|"2. 198.51.100.1:22345 응답"| B
    A <-->|"3. 직접 연결 시도 (Hole Punching)"| B
    A <-->|"실패 시 릴레이"| TURN
    TURN <-->|"릴레이"| B

STUN (Session Traversal Utilities for NAT)

자신의 공인 IP:포트를 발견하고 NAT 타입을 파악한다. 두 피어가 서로 공인 주소를 교환하고 동시에 패킷을 보내 NAT에 홀을 뚫는다 (UDP Hole Punching). Symmetric NAT 환경에서는 실패할 수 있다.

TURN (Traversal Using Relays around NAT)

STUN으로 직접 연결이 불가능할 때 모든 트래픽을 릴레이 서버를 통해 전달한다. 항상 동작하지만 서버 대역폭 비용이 발생하며 지연이 증가한다.

ICE (Interactive Connectivity Establishment)

[[webrtc|WebRTC]]에서 사용하는 프레임워크. STUN/TURN을 조합해 최적 경로를 자동 선택한다.

ICE Candidate 우선순위:
1. host candidate (직접 연결)
2. server reflexive candidate (STUN을 통한 공인 IP)
3. relay candidate (TURN 릴레이)

실전 예시: AWS VPC NAT 구성

# AWS CLI로 NAT Gateway 생성
# 1. EIP (Elastic IP) 할당
EIP=$(aws ec2 allocate-address --domain vpc --query AllocationId --output text)

# 2. 퍼블릭 서브넷에 NAT Gateway 생성
NATGW=$(aws ec2 create-nat-gateway \
  --subnet-id subnet-public-xxx \
  --allocation-id $EIP \
  --query NatGateway.NatGatewayId --output text)

# 3. 프라이빗 서브넷 라우트 테이블에 NAT Gateway 경로 추가
aws ec2 create-route \
  --route-table-id rtb-private-xxx \
  --destination-cidr-block 0.0.0.0/0 \
  --nat-gateway-id $NATGW

비용 최적화: S3, DynamoDB 트래픽은 VPC Endpoint를 통해 NAT 없이 직접 연결하면 NAT Gateway 비용을 줄일 수 있다.

# S3 VPC Endpoint 생성 (NAT 없이 S3 접근)
aws ec2 create-vpc-endpoint \
  --vpc-id vpc-xxx \
  --service-name com.amazonaws.ap-northeast-2.s3 \
  --route-table-ids rtb-private-xxx

함정

[!WARNING]

NAT 매핑 만료: UDP 연결은 마지막 패킷 후 60-300초면 매핑이 만료된다. WebSocket, 게임 소켓 등 장기 연결은 주기적으로 keep-alive 패킷을 전송해야 한다.

Hairpin NAT 미지원: 내부 호스트가 자기 공인 IP로 접근하면 일부 NAT 장비가 처리 못한다. 192.168.1.10이 203.0.113.5:80에 접근하려 할 때 반환 경로가 없어 실패한다.

Symmetric NAT와 STUN 조합 불가: 모바일 LTE 망은 Symmetric NAT가 많아 UDP Hole Punching이 실패한다. TURN 릴레이가 필요하다.

포트 고갈 (Port Exhaustion): 대규모 NAT Gateway에서 연결 수가 포트 수 (65535) 를 초과하면 새 연결이 거부된다. AWS NAT Gateway는 IP당 55000개 동시 연결을 권고한다.

NAT + IPSec 충돌: ESP 프로토콜은 포트가 없어 PAT가 다중 연결을 구분하지 못한다. NAT-T (UDP 캡슐화)로 우회한다.

[Network] WebSocket: HTTP upgrade, frame, ping/pong

koa (김신건) — Thu, 16 Jul 2026 00:00:00 GMT

정의

WebSocket (RFC 6455)은 HTTP/1.1 Upgrade로 시작하는 양방향 영속 메시지 채널이다. 하나의 [[tcp|TCP]] 연결 위에서 서버와 클라이언트가 임의 시점에 메시지를 push할 수 있다.

HTTP는 클라이언트가 요청해야 서버가 응답하는 단방향 구조다. WebSocket은 이 제약을 제거해 서버가 먼저 메시지를 보낼 수 있게 한다.

주요 활용: 실시간 채팅, 트레이딩 시세, 멀티플레이어 게임, 알림 시스템, 공동 편집, 라이브 대시보드.

Handshake: HTTP Upgrade

sequenceDiagram
    autonumber
    participant C as Client
    participant S as Server

    C->>S: GET /chat HTTP/1.1<br/>Host: example.com<br/>Upgrade: websocket<br/>Connection: Upgrade<br/>Sec-WebSocket-Key: dGhlIHNhbXBsZSBub25jZQ==<br/>Sec-WebSocket-Version: 13
    S-->>C: HTTP/1.1 101 Switching Protocols<br/>Upgrade: websocket<br/>Connection: Upgrade<br/>Sec-WebSocket-Accept: s3pPLMBiTxaQ9kYGzzhZRbK+xOo=

    Note over C,S: 이후 같은 TCP 위에서 WS frame 양방향 교환
    C->>S: WS frame (text: "hello")
    S->>C: WS frame (서버 push: "world")
    C->>S: WS frame (binary: 이미지 데이터)

Sec-WebSocket-Accept는 클라이언트가 보낸 key와 고정 GUID를 결합한 SHA-1 해시의 Base64 인코딩이다:

Accept = Base64(SHA-1(Sec-WebSocket-Key + "258EAFA5-E914-47DA-95CA-C5AB0DC85B11"))

이 절차는 프로토콜 착각(평범한 HTTP 응답으로 오해)을 방지하기 위한 핸드셰이크 무결성 검증이다.

Frame 구조

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-------+-+-------------+-------------------------------+
|F|R|R|R| opcode|M| Payload len |    Extended payload length    |
|I|S|S|S|  (4)  |A|     (7)     |             (16/64)           |
|N|V|V|V|       |S|             |   (if payload len == 126/127) |
| |1|2|3|       |K|             |                               |
+-+-+-+-+-------+-+-------------+-------------------------------+
|     Extended payload length continued, if payload len == 127  |
+ - - - - - - - - - - - - - - - +-------------------------------+
|                               |Masking-key, if MASK set to 1  |
+-------------------------------+-------------------------------+
|    Masking-key (continued)    |          Payload Data         |
+-------------------------------- - - - - - - - - - - - - - - - +
:                     Payload Data continued ...                :
+---------------------------------------------------------------+

필드	크기	설명
FIN	1 bit	마지막 fragment이면 1
RSV1-3	각 1 bit	확장에 예약 (압축 확장은 RSV1 사용)
opcode	4 bit	메시지 타입
MASK	1 bit	페이로드 마스킹 여부
Payload len	7 bit	125 이하면 직접 길이, 126이면 다음 2 bytes, 127이면 다음 8 bytes
Masking-key	4 bytes	MASK=1일 때만 존재
Payload Data	가변	실제 데이터 (마스킹된 경우 XOR 복호화)

Opcode 목록

opcode	의미
0x0	Continuation (이전 frame 이어짐)
0x1	Text (UTF-8 인코딩)
0x2	Binary
0x8	Close
0x9	Ping
0xA	Pong

[!IMPORTANT] 클라이언트 발 frame은 반드시 MASK 처리 (XOR with 4-byte masking key). 캐시 포이즈닝 공격 방지 목적이다. 서버 발 frame은 unmask. 이를 위반하면 서버는 연결을 즉시 닫아야 한다.

Ping / Pong (keep-alive)

sequenceDiagram
    participant C as Client
    participant S as Server

    loop 30초마다
        S->>C: PING frame (opcode 0x9)
        C-->>S: PONG frame (opcode 0xA, payload 동일)
    end
    Note over S: 90초 PONG 없음 시 close frame 전송

Ping/Pong의 목적:

NAT 매핑 유지: NAT 장비는 유휴 UDP/TCP 연결을 일정 시간 후 만료. 주기적 ping으로 방지
프록시 idle close 방지: nginx, ALB 같은 중간 장비의 idle timeout 초과 방지
연결 생존 확인: 상대방이 살아있는지 확인 (silent disconnect 감지)

[!TIP] NAT 일반 idle timeout은 약 60-300초다. Ping 간격은 30-60초가 권장값이다. AWS ALB의 기본 idle timeout은 60초이므로 30초 이하 ping을 사용해야 한다.

Subprotocol

Sec-WebSocket-Protocol: chat, soap

클라이언트가 지원하는 서브프로토콜 목록을 전송하면, 서버는 그 중 하나를 선택해 응답 헤더에 반환한다.

HTTP/1.1 101 Switching Protocols
Sec-WebSocket-Protocol: chat

서브프로토콜로 흔히 사용하는 것:

STOMP (Simple Text Oriented Messaging Protocol): Spring WebSocket에서 주로 사용
MQTT over WebSocket: IoT 브로커 연결
GraphQL over WebSocket (graphql-ws, subscriptions-transport-ws)
WAMP (Web Application Messaging Protocol)

WSS (WebSocket Secure)

wss://는 WebSocket over TLS다. 운영 환경에서는 사실상 필수다:

ws:// 는 일부 ISP와 프록시가 차단 또는 내용 변조 가능
https:// 페이지에서 ws:// 연결은 브라우저가 mixed content로 거부
대부분의 WAF와 로드 밸런서가 WSS에 최적화

flowchart LR
    Browser["브라우저\nwss://example.com/chat"]
    LB["로드 밸런서\n(TLS 종료)"]
    WS["WebSocket 서버\nws://10.0.0.5:8080"]

    Browser <-->|"wss (TLS)"| LB
    LB <-->|"ws (평문, 내부망)"| WS

실무에서는 로드 밸런서가 TLS를 종료하고 내부에서 평문 ws://로 전달하는 구성이 일반적이다.

실전 예시

Node.js (ws 라이브러리)

const WebSocket = require("ws");

// 서버
const wss = new WebSocket.Server({ port: 8080 });

wss.on("connection", (ws, req) => {
  console.log(`클라이언트 연결: ${req.socket.remoteAddress}`);

  // 30초마다 ping
  const pingInterval = setInterval(() => {
    if (ws.readyState === WebSocket.OPEN) {
      ws.ping();
    }
  }, 30000);

  ws.on("pong", () => {
    console.log("pong 수신, 연결 살아있음");
  });

  ws.on("message", (data) => {
    const message = data.toString();
    console.log(`수신: ${message}`);
    // 같은 채널 모든 클라이언트에게 broadcast
    wss.clients.forEach((client) => {
      if (client.readyState === WebSocket.OPEN) {
        client.send(JSON.stringify({ text: message }));
      }
    });
  });

  ws.on("close", (code, reason) => {
    clearInterval(pingInterval);
    console.log(`연결 종료: ${code} ${reason}`);
  });
});

Python (websockets)

import asyncio
import websockets

async def handler(websocket, path):
    try:
        async for message in websocket:
            print(f"수신: {message}")
            await websocket.send(f"echo: {message}")
    except websockets.exceptions.ConnectionClosed:
        print("연결 종료")

async def main():
    # ping_interval=20: 20초마다 ping, ping_timeout=10: 10초 응답 없으면 close
    async with websockets.serve(handler, "localhost", 8080,
                                 ping_interval=20, ping_timeout=10):
        await asyncio.Future()  # 영원히 실행

asyncio.run(main())

브라우저 클라이언트

const ws = new WebSocket("wss://example.com/chat", ["chat"]); // 서브프로토콜 지정

ws.onopen = (event) => {
  console.log("연결됨, 서브프로토콜:", ws.protocol);
  ws.send(JSON.stringify({ type: "join", room: "general" }));
};

ws.onmessage = (event) => {
  const data = JSON.parse(event.data);
  console.log("수신:", data);
};

ws.onclose = (event) => {
  console.log(`종료: code=${event.code}, reason=${event.reason}, clean=${event.wasClean}`);
  // 자동 재연결 (exponential backoff)
  setTimeout(() => reconnect(), 1000);
};

ws.onerror = (error) => {
  console.error("WebSocket 오류:", error);
};

// 명시적 종료 (1000: 정상 종료)
// ws.close(1000, "사용자 로그아웃");

패턴: 채팅 Fan-out

flowchart LR
    C1["Client 1"] -->|"ws"| N1["Server Node A"]
    C2["Client 2"] -->|"ws"| N2["Server Node B"]
    C3["Client 3"] -->|"ws"| N1

    N1 -->|"PUBLISH msg"| Redis[("Redis Pub/Sub\n또는 Streams")]
    N2 -->|"SUBSCRIBE"| Redis
    N1 -->|"SUBSCRIBE"| Redis

    Redis -->|"fan-out"| N1 & N2

단일 서버는 in-memory로 fan-out 가능하지만, 다중 서버 환경에서는 Redis Pub/Sub 또는 Streams로 노드 간 메시지를 전달해야 한다.

닫기 핸드셰이크

sequenceDiagram
    participant C as Client
    participant S as Server

    C->>S: Close frame (opcode 0x8, code=1000, reason="done")
    S-->>C: Close frame (echo back)
    Note over C,S: 양방향 TCP 연결 종료

Close 코드:

1000: 정상 종료
1001: Going Away (탭 닫기, 서버 재시작)
1008: Policy Violation
1011: Unexpected Error
4000-4999: 애플리케이션 정의 코드 (사용자 정의)

대안 비교

기술	방향	영속성	주요 용도
WebSocket	양방향	영속	채팅, 게임, 트레이딩
SSE	서버 -> 클라이언트	영속	알림, 라이브 피드
Long Polling	양방향 (서버 hold)	짧음	레거시 fallback
HTTP/2 Push	단방향 (폐기됨)	-	-
WebRTC DataChannel	P2P 양방향	영속	게임, 파일 공유
WebTransport	양방향 다중스트림	영속	WebSocket 차세대 대안

자세한 비교는 [[realtime-comparison|실시간 기술 비교]] 참고.

함정

[!WARNING]

Idle timeout 사고: AWS ALB, nginx의 기본 idle timeout은 60초다. PING/PONG 간격이 60초 이상이면 연결이 silent close된다. 반드시 idle timeout보다 짧은 ping 간격 설정 필요.

Backpressure 부재: 서버가 빠르게 send하면 클라이언트 수신 버퍼가 가득 찬다. 애플리케이션 레벨 flow control (ACK/credit 방식) 이 필요하다.

Sticky Session 필요: 같은 사용자의 WebSocket 요청이 같은 서버 노드에 라우팅되어야 한다. LB cookie 또는 IP hash를 사용하거나, Redis pub/sub으로 모든 노드에 fan-out.

CORS가 WebSocket에 적용 안 됨: Origin 헤더는 브라우저가 자동 설정하지만 서버가 수동으로 검증해야 한다. 미검증 시 CSRF 공격에 취약. ws.upgradeReq.headers.origin 를 허용 목록과 대조.

메모리 leak: 연결이 close될 때 이벤트 리스너, 타이머, 방 구독을 모두 해제해야 한다. ws.on("close") 핸들러에서 clearInterval, 구독 해제 필수.

대용량 이진 데이터: WebSocket 위에서 파일 전송 시 단편화(fragmentation)가 발생하면 조각을 합쳐야 한다. FIN 비트로 마지막 fragment 판단.

DTLS

koa (김신건) — Thu, 16 Jul 2026 00:00:00 GMT

정의

DTLS (Datagram Transport Layer Security)는 [[udp|UDP]] 위에서 동작하는 [[tls|TLS]]의 변형이다. 데이터그램 기반 통신에 TLS와 동등한 보안 보장(서버 인증, 키 교환, 암호화, 무결성)을 제공하면서 UDP의 특성(비순서, 손실 허용, 비연결)을 그대로 유지한다.

[[webrtc|WebRTC]] DataChannel, VoIP, IoT, VPN 등 UDP를 사용하는 보안 통신에 광범위하게 쓰인다.

왜 TLS가 아닌 DTLS인가

[[tls|TLS]]는 [[tcp|TCP]]의 “순서 보장된 신뢰성 있는 스트림” 위에서 설계되었다.

flowchart LR
    subgraph TLS_STACK["TLS 스택 가정"]
        T1["순서 보장"]
        T2["손실 없음"]
        T3["중복 없음"]
        T4["암묵적 시퀀스 번호"]
    end
    subgraph UDP_REALITY["UDP 현실"]
        U1["순서 뒤바뀜 가능"]
        U2["패킷 손실 가능"]
        U3["패킷 중복 가능"]
        U4["시퀀스 번호 없음"]
    end

    TLS_STACK -- "충돌" --> UDP_REALITY

비교 항목	TLS (TCP 위)	DTLS (UDP 위)
핸드셰이크 순서	가정됨 (TCP 보장)	메시지 번호화 + 재전송
시퀀스 번호	암묵적 (전송 안 함)	명시적 (레코드 헤더에 포함)
패킷 손실	TCP가 재전송 처리	레코드 손실/중복 허용
큰 메시지 처리	TCP 스트림으로 분할	레코드 fragmentation 지원
DoS 방어	TCP SYN Cookies	Cookie Exchange (HelloVerifyRequest)

핸드셰이크 플로우

sequenceDiagram
    participant C as Client
    participant S as Server

    Note over C,S: Cookie Exchange (DoS 방어)
    C->>S: ClientHello (랜덤 값 포함)
    S-->>C: HelloVerifyRequest (Cookie 포함)
    C->>S: ClientHello (Cookie 포함하여 재전송)

    Note over C,S: 핸드셰이크 본체
    S-->>C: ServerHello + Certificate + ServerHelloDone
    C->>S: ClientKeyExchange + ChangeCipherSpec + Finished
    S-->>C: ChangeCipherSpec + Finished

    Note over C,S: 데이터 교환 시작
    C->>S: DTLS 레코드 (seq=0)
    S-->>C: DTLS 레코드 (seq=0)
    C->>S: DTLS 레코드 (seq=1) - 손실
    C->>S: DTLS 레코드 (seq=1) - 재전송 (타임아웃 후)
    S-->>C: DTLS 레코드 (seq=1) - ACK

핵심: 손실된 핸드셰이크 메시지는 타이머 기반 재전송으로 복구한다. 타이머는 지수 백오프 방식으로 늘어난다 (초기 1초, 최대 60초).

UDP는 소스 IP 스푸핑이 쉬워 서버가 대량의 핸드셰이크 상태를 만들어두게 하는 증폭 공격에 취약하다.

sequenceDiagram
    participant A as "공격자\n(스푸핑 IP 사용)"
    participant S as Server

    A->>S: ClientHello (src IP: 피해자 IP)
    Note over S: 상태 저장 없이 Cookie만 계산
    S-->>A: HelloVerifyRequest (Cookie = HMAC(ClientHello))
    Note over A: 피해자 IP로 Cookie 도달 안 함
    Note over S: Cookie 재전송 없으면 핸드셰이크 진행 안 함

서버는 HelloVerifyRequest를 보낼 때 어떤 상태도 저장하지 않는다. 클라이언트가 Cookie를 포함한 ClientHello를 재전송했을 때 비로소 핸드셰이크를 진행한다. HMAC으로 서명된 Cookie이므로 위조 불가.

버전

버전	출시	기반 TLS	핵심 변경
DTLS 1.0	2006	TLS 1.1	첫 UDP TLS 표준
DTLS 1.2	2012 (RFC 6347)	TLS 1.2	현재 가장 널리 사용
DTLS 1.3	2022 (RFC 9147)	TLS 1.3	1-RTT / 0-RTT, 연결 ID

DTLS 1.3은 TLS 1.3의 1-RTT 핸드셰이크 단축, 0-RTT 재접속, 개선된 암호화 스위트를 그대로 가져왔다.

사용처

1. WebRTC DataChannel

브라우저 간 P2P 데이터 채널은 모두 DTLS로 암호화된다.

flowchart TD
    SIG["시그널링 서버\n(SDP 교환)"]
    A["피어 A"]
    B["피어 B"]
    ICE["ICE / STUN / TURN\n(NAT 통과)"]

    A <-->|"SDP offer/answer\n(인증서 fingerprint 교환)"| SIG
    SIG <--> B
    A <-->|"DTLS 핸드셰이크\n(fingerprint 검증)"| ICE
    ICE <-->|"DTLS-SCTP\n데이터 전송"| B

흐름:

시그널링으로 양쪽 인증서 fingerprint 사전 교환
DTLS 핸드셰이크로 키 확립 (fingerprint 검증)
SCTP over DTLS로 DataChannel 데이터 전송

WebRTC에서 DTLS는 MITM 방어를 위해 인증서 fingerprint를 시그널링 채널로 사전 교환하는 방식을 쓴다.

2. DTLS-SRTP (미디어 채널)

WebRTC 음성/영상 트래픽은 SRTP로 암호화하지만, SRTP 키는 DTLS 핸드셰이크로 협상한다.

DTLS 핸드셰이크 → keying material 추출 → SRTP 키 파생
      ↓
RTP/SRTP 미디어 데이터 전송 (DTLS 레코드 아님)

이를 DTLS-SRTP (RFC 5764)라 부른다. 핸드셰이크만 DTLS이고 실제 미디어는 SRTP 패킷으로 전송된다.

3. VPN / OpenVPN UDP 모드

OpenVPN은 TCP 모드와 UDP 모드를 지원한다. UDP 모드에서 DTLS와 유사한 자체 보안 레이어를 사용한다. WireGuard는 별도 프로토콜을 사용하지만 UDP 위 암호화라는 점에서 같은 범주다.

4. IoT: CoAP + DTLS

CoAP (Constrained Application Protocol)는 IoT 기기를 위한 HTTP 대안이다. UDP 위에서 동작하며, 보안 레이어로 DTLS를 사용한다. TLS를 쓰기에 너무 자원이 제한적인 기기(MCU)에서 DTLS 1.2가 표준이다.

CoAP (UDP/5683)   → 평문 (테스트 환경)
CoAPS (UDP/5684)  → DTLS 암호화 (운영 환경)

레코드 구조

DTLS 레코드 헤더에는 TLS와 달리 epoch + sequence number가 명시적으로 포함된다.

DTLS 1.2 레코드 헤더 (13 bytes):

+--+--+--+--+--+--+--+--+--+--+--+--+--+
|CT|  Version | Epoch |  Sequence Num   |Length|
|1B|   2B     |  2B   |      6B         |  2B  |
+--+--+--+--+--+--+--+--+--+--+--+--+--+

CT: Content Type (Handshake=22, Alert=21, ApplicationData=23)
Epoch: 키 교환 횟수 (재키잉 시 증가)
Sequence Num: 레코드 순서 번호 (중복 탐지에 사용)

수신측은 슬라이딩 윈도우로 시퀀스 번호를 추적하여 재전송 중복과 재생 공격을 방어한다.

실전 예시

Python으로 DTLS 서버/클라이언트

# pip install dtls (PyDTLS 패키지)
from dtls import do_patch
do_patch()  # SSL 모듈을 DTLS 지원으로 패치

import ssl
import socket

# DTLS 서버
def dtls_server():
    sock = socket.socket(socket.AF_INET, socket.SOCK_DGRAM)
    sock.bind(("0.0.0.0", 4433))

    ctx = ssl.SSLContext(ssl.PROTOCOL_DTLS_SERVER)
    ctx.load_cert_chain("server.crt", "server.key")

    with ctx.wrap_socket(sock, server_side=True) as ssock:
        data, addr = ssock.recvfrom(1024)
        print(f"수신: {data} from {addr}")
        ssock.sendto(b"Hello from DTLS server!", addr)

OpenSSL로 DTLS 테스트

# DTLS 서버 시작
openssl s_server -dtls1_2 -port 4433 -cert server.crt -key server.key

# DTLS 클라이언트 연결
openssl s_client -dtls1_2 -connect localhost:4433

# DTLS 1.3 (OpenSSL 3.2+)
openssl s_server -dtls -port 4433 -cert server.crt -key server.key
openssl s_client -dtls -connect localhost:4433

# Wireshark 캡처 - DTLS 패킷 확인
# 필터: dtls
# 복호화: Edit > Preferences > Protocols > DTLS > RSA keys list

WebRTC DataChannel DTLS fingerprint 확인

// 브라우저에서 DataChannel DTLS 인증서 fingerprint 확인
const pc = new RTCPeerConnection();

// 로컬 인증서 fingerprint (시그널링으로 상대방에게 전달)
const cert = await RTCPeerConnection.generateCertificate({ name: "ECDSA", namedCurve: "P-256" });
console.log(cert.getFingerprints());
// [{ algorithm: "sha-256", value: "AA:BB:CC:..." }]

// SDP에서 fingerprint 확인
const offer = await pc.createOffer();
const sdpLines = offer.sdp.split("\n");
const fingerprintLine = sdpLines.find(l => l.startsWith("a=fingerprint:"));
console.log(fingerprintLine);
// a=fingerprint:sha-256 AA:BB:CC:DD:...

DTLS vs QUIC 비교

[[quic|QUIC]]도 UDP 위에서 TLS 1.3을 사용하지만, DTLS와는 다른 방식으로 동작한다.

항목	DTLS	QUIC
레이어	순수 보안 레이어	전송 + 보안 통합
TLS 방식	TLS 1.3 핸드셰이크 응용	TLS 1.3 직접 통합 (QUIC 레코드)
신뢰성	하위 프로토콜이 처리 (SCTP 등)	QUIC 스트림 내장
헤더 압축	없음	QPACK
멀티플렉싱	SCTP 조합 필요	내장
주 사용처	WebRTC, IoT, VPN	HTTP/3, WebTransport

QUIC은 “UDP 위에서 모든 것을 새로 만든” 반면, DTLS는 “기존 TLS를 UDP에 적응시킨” 접근이다.

함정

[!WARNING]

재전송 비용: 핸드셰이크 패킷 손실 시 타이머 기반 재전송이 발생한다. 고손실 환경에서 초기 연결이 TCP+TLS보다 느릴 수 있다.

MTU 제약: UDP 패킷이 MTU(일반적으로 1500 bytes, 터널링 시 더 작음)를 초과하면 IP fragmentation이 발생한다. DTLS 핸드셰이크 메시지가 큰 경우 레코드 단위 fragmentation이 필요하다.

Cookie 검증 우회: DoS 방어용 Cookie Exchange를 비활성화하는 구현도 있다. 공개 서버에서는 반드시 활성화해야 한다.

epoch rollover: epoch 필드(2 bytes)는 65535회 재키잉 후 오버플로우한다. 장기 실행 세션에서 주의.

인증서 검증 생략: 특히 IoT 구현에서 self-signed 인증서를 검증하지 않는 경우가 많다. DTLS가 있어도 MITM에 취약해진다.

HPACK

koa (김신건) — Thu, 16 Jul 2026 00:00:00 GMT

정의

HPACK (RFC 7541)은 [[http-2|HTTP/2]]에서 요청/응답 헤더를 압축하는 방식이다.

[[http-1-1|HTTP/1.1]]에서 헤더는 매 요청마다 평문 텍스트로 반복 전송되었다. 한 페이지 로드에 수십 건의 요청이 발생하면 헤더만으로 수십 KB가 낭비된다. HPACK은 정적 테이블 + 동적 테이블 + Huffman 인코딩 세 가지를 조합해 헤더 중복을 제거한다.

문제 상황: HTTP/1.1 헤더의 낭비

GET /api/users HTTP/1.1
Host: example.com
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7)
Accept: application/json
Accept-Language: ko-KR,ko;q=0.9
Accept-Encoding: gzip, deflate, br
Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9...
Cookie: session_id=abc123; _ga=GA1.2.xxx

동일한 호스트에 50개 병렬 요청을 보내면, 위 헤더가 50번 그대로 반복된다. Authorization, Cookie처럼 큰 헤더가 매번 전송되어 모바일처럼 대역폭이 제한된 환경에서 특히 비효율적이다.

압축 원리

Static Table (정적 테이블)

자주 쓰이는 헤더 이름/값 조합 61개를 사전 정의한 고정 인덱스.

Index | Header Name          | Header Value
------+----------------------+-------------------
1     | :authority           |
2     | :method              | GET
3     | :method              | POST
4     | :path                | /
5     | :path                | /index.html
6     | :scheme              | http
7     | :scheme              | https
8     | :status              | 200
...
61    | www-authenticate     |

:method GET 이 필요하면 인덱스 2 한 바이트만 전송하면 된다.

Dynamic Table (동적 테이블)

연결 단위로 양쪽(클라이언트/서버)이 공유하는 헤더 캐시.

sequenceDiagram
    participant C as Client
    participant S as Server

    Note over C,S: 첫 번째 요청
    C->>S: "Authorization: Bearer TOKEN123" (리터럴로 전송 + 동적 테이블 인덱스 62 등록)
    S-->>C: 200 OK

    Note over C,S: 두 번째 요청
    C->>S: 인덱스 62 (1 바이트) - 동일 헤더
    S-->>C: 200 OK

동적 테이블은 FIFO 큐로 구성된다. 오래된 항목은 새 항목이 추가될 때 밀려나며, 테이블 최대 크기는 SETTINGS_HEADER_TABLE_SIZE 프레임으로 협상한다 (기본값 4096 bytes).

Huffman 인코딩

문자열로 전송해야 하는 헤더 값을 Huffman 코드로 추가 압축한다. HTTP 트래픽에서 자주 등장하는 문자에 짧은 코드를 배정해 ASCII 대비 약 30% 추가 절약을 달성한다.

'e' (0x65) → ASCII 8bit, Huffman 4bit (0b0000)
'a' (0x61) → ASCII 8bit, Huffman 5bit (0b00001)
'q' (0x71) → ASCII 8bit, Huffman 8bit (0b11101000)

인코딩 플로우

flowchart TD
    H["헤더 필드\n(name: value)"]
    Q1{"Static Table에\n존재하는가?"}
    Q2{"Dynamic Table에\n존재하는가?"}
    I1["인덱스 하나만 전송\n(1-2 바이트)"]
    I2["Dynamic Table 인덱스\n전송 (1-2 바이트)"]
    Q3{"Dynamic Table에\n추가할까?"}
    L1["리터럴 + 동적 등록\n(Huffman 압축 후)"]
    L2["리터럴만 전송\n(인덱싱 안 함)"]

    H --> Q1
    Q1 -->|"Yes"| I1
    Q1 -->|"No"| Q2
    Q2 -->|"Yes"| I2
    Q2 -->|"No"| Q3
    Q3 -->|"Yes"| L1
    Q3 -->|"No"| L2

헤더 값이 자주 바뀌는 경우 (예: Date, Content-Length) 는 동적 테이블 등록을 건너뛰어 테이블 공간 낭비를 방지한다. Cache-Control: no-cache처럼 민감 정보가 포함된 헤더는 Never Indexed 플래그로 중간 프록시의 캐시 저장을 금지할 수 있다.

압축 효과

시나리오	HTTP/1.1	HTTP/2 + HPACK
페이지 로드 50개 요청 (각 ~700 B)	~35 KB 헤더	~3-5 KB
모바일 네트워크 Slow Start 구간	큰 영향	작은 영향
동일 호스트 반복 API 호출	매번 전체 전송	첫 번째 이후 수 바이트

[[http-2|HTTP/2]]의 멀티플렉싱과 함께 HPACK은 HTTP/2의 두 번째 큰 성능 이득원이다.

보안 이슈: CRIME / HPACK Bomb

CRIME 공격

CRIME (Compression Ratio Info-leak Made Easy)은 TLS 압축 + HTTP 응답 압축을 함께 쓸 때 발생하는 사이드 채널 공격이다.

공격자가 임의 문자열을 요청에 주입할 수 있는 상황에서, 압축된 패킷 크기 변화를 관찰하여 헤더 값(쿠키, 세션 토큰 등)을 추측한다.

압축 전: "Cookie: secret=a..." → 크기 100
     +  "secret=a"          → 압축 시 중복 제거, 크기 95 (추측 성공)
          
압축 전: "Cookie: secret=a..." → 크기 100
     +  "secret=b"          → 다른 문자열, 중복 없음, 크기 102 (추측 실패)

HPACK은 이를 완전히 해결하지는 않는다. 공격자가 동일 HTTP/2 연결에서 요청을 보낼 수 있다면 동적 테이블 크기 변화를 관찰하는 비슷한 공격이 이론적으로 가능하다. RFC 7541 §7 보안 고려사항 참조.

[!WARNING] Never Indexed 플래그: Authorization, Cookie 같은 민감 헤더는 Literal Header Field Never Indexed 표현을 사용해 중간 노드(프록시)의 인덱싱을 막아야 한다. HTTP/2 라이브러리 대부분이 이를 자동 처리하지만, 커스텀 구현 시 반드시 확인.

HPACK Bomb

동적 테이블에 최대 크기(4 KB)까지 헤더를 채운 뒤, 그 모든 항목을 인덱스 참조로만 이루어진 헤더 블록을 수십만 개 전송한다. 수신측은 작은 바이트를 수백 MB 메모리로 팽창시키며 디코딩해야 한다.

# 공격자 전송: 9 바이트 헤더 블록
# 수신측 메모리 요구: 수 MB

- 동적 테이블 가득 채움 (4 KB)
- 참조만 있는 헤더 블록 10만 개 전송 → 테이블 전체 팽창 반복

[!CAUTION] 서버 구현 시 SETTINGS_MAX_HEADER_LIST_SIZE와 최대 헤더 블록 크기를 반드시 제한해야 한다. HTTP/2 라이브러리의 기본 설정을 확인하고 적절한 상한을 설정할 것.

QPACK: HTTP/3에서의 개선

[[quic|QUIC]] 위에서는 HPACK의 순서 의존성 문제가 발생한다. HTTP/2는 TCP 위에서 동작해 헤더 블록이 순서대로 도착하지만, HTTP/3의 QUIC은 스트림이 독립적이다.

문제: 동적 테이블 업데이트가 스트림 A에서 도착했는데, 스트림 B의 헤더가 그 업데이트를 참조한다면? QUIC에서는 스트림 B가 먼저 도착할 수 있다.

QPACK 해결책 (RFC 9204):

flowchart LR
    E["Encoder\n(클라이언트)"]
    D["Decoder\n(서버)"]
    ES["Encoder Stream\n(단방향, 테이블 업데이트)"]
    DS["Decoder Stream\n(단방향, ACK)"]
    RS["Request Stream\n(각 HTTP 요청)"]

    E -->|"동적 테이블 업데이트"| ES --> D
    D -->|"테이블 업데이트 확인"| DS --> E
    E -->|"헤더 블록 (인덱스 참조)"| RS --> D

인코더 스트림과 디코더 스트림이 분리되어 동적 테이블 업데이트가 독립적으로 전달된다. 요청 스트림은 해당 업데이트가 도착했다는 확인을 받은 뒤에만 인덱스를 참조한다.

항목	HPACK	QPACK
대상 프로토콜	HTTP/2 (TCP)	HTTP/3 (QUIC)
동적 테이블	단일 스트림 순서 의존	독립 인코더/디코더 스트림
순서 보장 필요	Yes (TCP가 보장)	No (QUIC 스트림 독립)
HOL 블로킹	TCP 계층에서 처리	QPACK 레벨 동기화로 해결

실전 예시

헤더 인코딩 직접 관찰 (Python)

# hpack 패키지로 HPACK 인코딩/디코딩 실습
# pip install hpack

import hpack

encoder = hpack.Encoder()
decoder = hpack.Decoder()

headers = [
    (":method", "GET"),
    (":path", "/api/users"),
    (":scheme", "https"),
    (":authority", "example.com"),
    ("authorization", "Bearer my-token"),
    ("accept", "application/json"),
]

# 인코딩
encoded = encoder.encode(headers)
print(f"인코딩 전 헤더 길이: {sum(len(k)+len(v)+2 for k,v in headers)} bytes")
print(f"HPACK 인코딩 후: {len(encoded)} bytes")

# 디코딩
decoded = decoder.decode(encoded)
print(f"디코딩 결과: {decoded}")

nginx에서 HPACK 확인

# HTTP/2 + HPACK 요청 전송
curl -v --http2 https://example.com/api/users -H "Authorization: Bearer token123"

# 응답 헤더에서 HTTP/2 확인
# < HTTP/2 200
# < content-type: application/json
# < content-length: 512

# Wireshark에서 HTTP/2 헤더 관찰:
# 필터: http2.header.name == "authorization"

동적 테이블 크기 협상

# Python h2 라이브러리로 SETTINGS 프레임 제어
# pip install h2

import h2.connection
import h2.config

config = h2.config.H2Configuration(client_side=True)
conn = h2.connection.H2Connection(config=config)

# 동적 테이블 최대 크기를 8192 bytes로 설정
conn.initiate_connection()
conn.update_settings({
    h2.settings.SettingCodes.HEADER_TABLE_SIZE: 8192,
    h2.settings.SettingCodes.MAX_HEADER_LIST_SIZE: 65536,
})

함정

[!WARNING]

동적 테이블은 연결 단위: 연결이 끊기면 테이블도 초기화된다. HTTP/2 연결 풀링이 끊기는 상황 (재배포, 로드 밸런서 교체 등)에서 첫 몇 개 요청은 압축 효율이 낮다.

프록시가 테이블 공유 안 함: 클라이언트-프록시, 프록시-서버 각각 별개 HPACK 컨텍스트. 프록시를 거치면 클라이언트 테이블이 서버에 전달되지 않는다.

헤더 순서가 성능에 영향: 자주 등장하는 헤더를 먼저 보내면 동적 테이블 효율이 높아진다.

HPACK Bomb 방어 필수: SETTINGS_MAX_HEADER_LIST_SIZE로 헤더 목록 최대 크기 제한. 기본값이 없는 구현도 있으므로 명시적 설정 필요.

[Network] IP: IPv4, IPv6, CIDR

koa (김신건) — Wed, 15 Jul 2026 00:00:00 GMT

정의

IP (Internet Protocol) 주소 는 인터넷에서 노드를 식별하는 논리 주소다. IPv4 (32bit) 와 IPv6 (128bit) 두 버전이 현재 병존한다.

IP 는 [[OSI 7 Layer]] 의 L3 (Network Layer) 에서 동작하며, 라우터가 패킷을 목적지까지 전달하는 기반이 된다.

IPv4

4 개 8bit 옥텟: 192.168.1.1. 총 2^32 (약 43억 개), 이미 고갈 상태.

주소 구조 (CIDR)

IP:      192  .  168  .   1   .   1
Binary: 11000000.10101000.00000001.00000001
        |<--- 네트워크 부분 (prefix) --->| 호스트|

192.168.1.0/24 표기에서 /24 는 앞 24 bit 가 네트워크 식별자, 뒤 8 bit 가 호스트 주소임을 의미한다.

특수 주소 범위

범위	CIDR	용도
사설 A	10.0.0.0/8	대규모 사내망
사설 B	172.16.0.0/12	중규모 네트워크
사설 C	192.168.0.0/16	홈 라우터 기본
루프백	127.0.0.0/8	localhost
링크 로컬	169.254.0.0/16	APIPA (DHCP 실패 시 자동 할당)
멀티캐스트	224.0.0.0/4	그룹 전송
브로드캐스트	255.255.255.255/32	서브넷 전체 전송

CIDR 서브넷 계산

CIDR	서브넷 마스크	호스트 수	용도
/8	255.0.0.0	16,777,214	대형 사내망 (Class A)
/16	255.255.0.0	65,534	중형 사내망 (Class B)
/24	255.255.255.0	254	일반 서브넷 (Class C)
/28	255.255.255.240	14	소형 서브넷
/30	255.255.255.252	2	P2P 링크
/32	255.255.255.255	1	단일 호스트

[!IMPORTANT] /24 서브넷에서 256개 IP 중 254개만 사용 가능하다. 첫 주소(192.168.1.0)는 네트워크 주소, 마지막 주소(192.168.1.255)는 브로드캐스트 주소로 예약된다.

서브넷 계산 예시

VPC 10.0.0.0/16 분할:
  Public subnet:  10.0.1.0/24   → 254 호스트
  Private subnet: 10.0.2.0/24   → 254 호스트
  DB subnet:      10.0.3.0/24   → 254 호스트
  Reserved:       10.0.4.0/24 ~ 10.0.255.0/24

IPv6

128bit 주소, 16진수 8 그룹으로 표기: 2001:0db8:85a3:0000:0000:8a2e:0370:7334

연속된 0 그룹 축약: 2001:db8:85a3::8a2e:370:7334

IPv4 vs IPv6 비교

특성	IPv4	IPv6
비트 수	32	128
주소 수	약 43억	약 3.4 x 10^38
표기	점 표기 `192.168.1.1`	콜론 16진수 `::1`
헤더 크기	20 byte (가변)	40 byte (고정)
NAT 필요	필수 (주소 부족)	불필요
서브넷 기본	가변	/64 (LAN 하나)
체크섬	헤더에 포함	제거됨 (상위 계층 위임)

IPv6 특수 주소

주소	의미
`::1`	loopback (IPv4 의 `127.0.0.1`)
`fe80::/10`	link-local (라우터를 넘지 않음)
`fc00::/7`	unique local (사설 주소, IPv4 의 `10.0.0.0/8` 유사)
`ff00::/8`	멀티캐스트
`2000::/3`	글로벌 유니캐스트 (공인 주소)

Public vs Private

flowchart LR
    subgraph LAN["사내 / 가정 LAN (사설 IP)"]
        PC1["PC1: 192.168.1.10"]
        PC2["PC2: 192.168.1.11"]
        Phone["모바일: 192.168.1.50"]
    end
    NAT["NAT 라우터\n공인: 203.0.113.5"]
    Internet["인터넷"]
    PC1 --> NAT
    PC2 --> NAT
    Phone --> NAT
    NAT --> Internet

Public IP: 인터넷에서 직접 라우팅 가능. ISP 가 할당.

Private IP: 로컬 네트워크 전용. 외부에서 직접 접근 불가. NAT 를 통해 공인 IP 와 매핑.

NAT (Network Address Translation)

IPv4 고갈 문제를 보완하기 위해 라우터가 내부 사설 주소를 외부 공인 주소로 변환한다.

sequenceDiagram
    participant PC as PC192168110
    participant R as RouterNAT
    participant S as WebServer
    PC->>R: SRC=192.168.1.10:4000 DST=1.2.3.4:80
    R->>S: SRC=203.0.113.5:12345 DST=1.2.3.4:80
    note over R: NAT 테이블에 매핑 기록
    S->>R: SRC=1.2.3.4:80 DST=203.0.113.5:12345
    R->>PC: SRC=1.2.3.4:80 DST=192.168.1.10:4000

NAT 는 연결 추적(connection tracking) 이 필요하며, [[stateful-vs-stateless-firewall|Stateful Firewall]] 과 함께 동작한다.

자세한 내용: [[network-nat|NAT]].

DHCP

동적 IP 할당 프로토콜. 4단계 DORA 플로우:

sequenceDiagram
    participant C as Client
    participant D as DHCPServer
    C->>D: DHCPDISCOVER (broadcast)
    D->>C: DHCPOFFER (IP 제안, lease 시간)
    C->>D: DHCPREQUEST (제안 수락)
    D->>C: DHCPACK (확정, lease 시작)
    note over C,D: IP 임차 기간 만료 전 갱신 필요

Discover: 클라이언트가 브로드캐스트로 DHCP 서버 탐색
Offer: 서버가 사용 가능한 IP 와 임차 기간 제안
Request: 클라이언트가 특정 IP 를 요청
Acknowledge: 서버가 IP 할당 확정

IP 패킷 구조 (IPv4)

 0       4       8      16      24      32 bit
 +-------+-------+-------+-------+-------+
 |Version|  IHL  |  ToS  |    Total Len  |
 +-------+-------+-------+---------------+
 |     Identification    |Flags|Frag Offs|
 +-------+-------+-------+-------+-------+
 |   TTL |Protocol|    Header Checksum   |
 +-------+-------+-------+-------+-------+
 |           Source Address              |
 +-------+-------+-------+-------+-------+
 |        Destination Address            |
 +-------+-------+-------+-------+-------+
 |         Options (optional)            |
 +-------+-------+-------+-------+-------+

주요 필드:

TTL (Time to Live): 라우터 통과 시마다 1 감소. 0 이 되면 패킷 폐기하고 ICMP Time Exceeded 전송 (루프 방지, traceroute 원리)
Protocol: 상위 계층 식별 (TCP=6, UDP=17, ICMP=1)
Flags + Fragment Offset: MTU 초과 패킷을 단편화 (분할) 하기 위한 필드

실전 예시

AWS VPC 서브넷 설계

VPC:            10.0.0.0/16       (65,534 개 IP)
  Public AZ-a:  10.0.1.0/24       (254 개, 인터넷 게이트웨이)
  Public AZ-b:  10.0.2.0/24       (254 개, 인터넷 게이트웨이)
  Private AZ-a: 10.0.11.0/24      (254 개, NAT 게이트웨이)
  Private AZ-b: 10.0.12.0/24      (254 개, NAT 게이트웨이)
  DB AZ-a:      10.0.21.0/24      (254 개, 외부 접근 불가)
  DB AZ-b:      10.0.22.0/24      (254 개, 외부 접근 불가)

IPv4/IPv6 이중 스택 (Dual Stack)

현재 인터넷은 IPv4 와 IPv6 를 동시 운용한다. 서버는 두 주소 모두 수신하고, 클라이언트는 Happy Eyeballs (RFC 8305) 로 더 빠른 쪽을 선택한다.

# 서버 측 이중 스택 리슨 확인
ss -tn -l '( sport = :80 or sport = :443 )'
# IPv6 형식으로 IPv4 도 포함: ::ffff:0.0.0.0

# IPv6 연결 확인
curl -6 https://ipv6.google.com

네트워크 디버깅 커맨드

# IP 주소 확인
ip addr show           # Linux
ifconfig               # macOS / 구형

# 라우팅 테이블
ip route show
route -n               # 구형

# ICMP ping (L3 연결성)
ping 1.1.1.1
ping6 2606:4700:4700::1111   # IPv6

# 경로 추적 (TTL 활용)
traceroute 1.1.1.1

함정

[!WARNING]

/24 = 256개 호스트? 네트워크 주소와 브로드캐스트 주소를 빼면 254개.

Private IP = 보안? NAT 뒤라도 내부 네트워크에서는 직접 접근 가능. 방화벽 별도 필수.

IPv6 에는 NAT 불필요 = 모든 디바이스가 공인 IP. 기존 NAT 기반 보안 정책을 IPv6 에 그대로 적용하면 외부 노출 위험.

/32 는 단일 호스트, /0 은 모든 IP. 라우팅 테이블이나 ACL 작성 시 혼동 주의.

172.16.0.0/12 = 172.16.0.0 ~ 172.31.255.255. 12bit prefix 라 172.16~172.31 범위. 직관적이지 않으므로 주의.

참고

[[network-nat|NAT]]
[[network-cidr-subnetting|CIDR / 서브네팅]]
[[network-dns|DNS]]
[[TCP]], [[UDP]]

[Network] OSI 7 Layer: 각 계층의 의미와 실전 매핑

koa (김신건) — Wed, 15 Jul 2026 00:00:00 GMT

정의

OSI 7 Layer 모델 은 네트워크 통신을 7 계층으로 추상화 한 ITU-T 표준 (1984). 실제 인터넷은 TCP/IP 4-5 계층 이지만, OSI 의 개념적 분리 가 디버깅 / 도구 분류 의 토대가 된다.

{}

7 Layer 매트릭스

Layer	이름	PDU (단위)	주요 프로토콜	도구
L7	Application	message	HTTP, gRPC, DNS, SMTP, MQTT, SSH	curl, postman
L6	Presentation	data	TLS, JSON, Protobuf, MIME, gzip	openssl
L5	Session	session	NetBIOS, RPC, 대부분 통합	-
L4	Transport	segment	TCP, UDP, QUIC, SCTP	netstat, ss, tcpdump
L3	Network	packet	IP, ICMP, BGP, OSPF	traceroute, ping
L2	Data Link	frame	Ethernet, WiFi, ARP, MAC	arp, wireshark
L1	Physical	bit	케이블, 무선 신호, 전기/광 신호	-

TCP/IP 와의 매핑

실제 인터넷은 4-5 계층 의 TCP/IP. OSI 의 5/6/7 이 Application 으로 통합:

flowchart TB
    subgraph OSI["OSI 7 Layer"]
        O7[L7 Application]
        O6[L6 Presentation]
        O5[L5 Session]
        O4[L4 Transport]
        O3[L3 Network]
        O2[L2 Data Link]
        O1[L1 Physical]
    end
    subgraph TCPIP["TCP/IP 4 Layer"]
        T4[Application]
        T3[Transport]
        T2[Internet]
        T1[Link]
    end
    O7 --> T4
    O6 --> T4
    O5 --> T4
    O4 --> T3
    O3 --> T2
    O2 --> T1
    O1 --> T1

각 계층 깊게

L7 Application

사용자 의도와 가장 가까운 계층. 응용 프로그램이 직접 사용하는 프로토콜.

프로토콜	포트	설명
HTTP/1.1	80	텍스트 기반 웹 요청/응답
HTTPS	443	HTTP + TLS
HTTP/2	443	멀티플렉싱, 헤더 압축
HTTP/3	443 (UDP)	QUIC 기반
DNS	53 (UDP/TCP)	도메인 → IP 변환
SMTP	25 / 465 (TLS)	이메일 전송
SSH	22	암호화 원격 셸
gRPC	443	HTTP/2 위 RPC 프레임워크

예시:

GET /api/users HTTP/1.1
Host: example.com
Authorization: Bearer eyJhbGci...

자세한 건 [[HTTP/1.1]], [[HTTP/2]], [[HTTP/3]], [[gRPC]], [[network-dns]].

L6 Presentation

데이터 표현 변환 계층. 직렬화, 압축, 암호화.

역할	예
암호화 / 복호화	TLS (실제로는 L4-L7 사이)
직렬화	JSON, Protobuf, MessagePack, CBOR
압축	gzip, deflate, brotli, zstd
문자 인코딩	UTF-8, MIME Base64

현대 프로토콜에서는 L5/L6 경계가 모호하고, 응용 계층(L7) 과 통합되는 경우가 많다.

L5 Session

세션 관리 계층. 대화의 시작/유지/종료.

현대에서는 L7 의 일부 또는 애플리케이션 자체 가 담당한다.

HTTP cookie: 상태 없는 HTTP 위에서 세션 유지
JWT: 토큰 기반 세션 상태 관리
WebSocket: HTTP Upgrade 후 지속 세션 유지

L4 Transport

end-to-end 신뢰성 + 흐름 제어. 포트 번호로 프로세스 식별.

프로토콜	신뢰성	순서 보장	흐름제어	주요 사용
TCP	O	O	O	HTTP, SSH, DB 연결
UDP	X	X	X	DNS, VoIP, 게임, QUIC
QUIC	O	O (stream 별)	O	HTTP/3
SCTP	O	옵션	O	WebRTC DataChannel

포트 범위:

Well-known (0-1023): HTTP(80), HTTPS(443), SSH(22), DNS(53)
Registered (1024-49151): 애플리케이션 공식 등록
Dynamic/Ephemeral (49152-65535): 클라이언트 임시 포트

자세한 건 [[TCP]], [[UDP]], [[QUIC]].

L3 Network

IP 라우팅. 패킷이 목적지까지 어떤 경로로 갈지 결정. 라우터의 영역.

프로토콜	역할
IPv4 / IPv6	주소 지정 및 패킷 전달
ICMP	제어 메시지 (ping, traceroute, TTL Exceeded)
BGP	인터넷 AS 간 경로 교환 (인터넷의 뼈대)
OSPF / IS-IS	AS 내부 링크 상태 라우팅
ARP	IP → MAC 주소 매핑 (L2/L3 경계)

TTL (Time to Live): 각 라우터 통과 시 1 감소, 0 이 되면 폐기. traceroute 는 TTL 을 1씩 증가시키며 각 라우터의 ICMP TTL Exceeded 응답을 수집.

자세한 건 [[IP]].

L2 Data Link

같은 LAN 안 의 MAC 주소 기반 통신. 스위치, WiFi AP 의 영역.

프로토콜	설명
Ethernet (IEEE 802.3)	유선 LAN 표준, 최대 1500 byte MTU
WiFi (IEEE 802.11)	무선 LAN, 802.11ax (WiFi 6)
ARP	IP 주소를 MAC 주소로 변환
VLAN (802.1Q)	하나의 물리 스위치를 논리적으로 분리
PPP	점대점 링크 (WAN, DSL)

Ethernet 프레임 구조:

[Dest MAC (6B)][Src MAC (6B)][EtherType (2B)][Payload][FCS (4B)]

L1 Physical

실제 전기 / 광 신호. 비트를 물리적 신호로 변환.

유선: Cat5e/Cat6 (1Gbps), Cat7/Cat8 (10Gbps), 광섬유 (SM/MM)
무선: 2.4GHz / 5GHz / 6GHz 대역
장비: 허브, 리피터, NIC (Network Interface Card)

패킷의 캡슐화

송신 측이 데이터를 아래 계층으로 내려보낼 때 각 계층이 헤더를 추가(캡슐화). 수신 측은 역순으로 헤더를 제거(역캡슐화).

flowchart TB
    L7Msg["L7 HTTP: GET /api/x"]
    L7Msg -->|"L6/L5 처리"| L6Frame["+ TLS 암호화 래퍼"]
    L6Frame -->|"L4 TCP 헤더 추가"| L4Frame["TCP header + payload"]
    L4Frame -->|"L3 IP 헤더 추가"| L3Frame["IP header + TCP segment"]
    L3Frame -->|"L2 Ethernet 프레임 래핑"| L2Frame["Ethernet header + IP packet + FCS"]
    L2Frame -->|"L1 변환"| Bit["bits on wire"]

각 계층이 자기 헤더 를 덧붙임. 수신 측은 역순으로 벗겨 올라간다.

실제 패킷 크기 예시

HTTP 요청 200 byte
  + TLS 레코드 헤더: 5 byte
  = TLS payload: 205 byte
    + TCP 헤더: 20 byte
    = TCP segment: 225 byte
      + IP 헤더: 20 byte
      = IP packet: 245 byte
        + Ethernet 헤더: 14 byte
        + Ethernet FCS: 4 byte
        = Ethernet frame: 263 byte

실전: 어디서 무엇이 깨졌나?

문제 진단의 층 별 도구:

flowchart TB
    Issue{문제 발생} --> Q1{ping 가능?}
    Q1 -->|아니오| L3Layer["L3 문제<br/>routing, firewall, DNS"]
    Q1 -->|예| Q2{telnet/nc port?}
    Q2 -->|아니오| L4Layer["L4 문제<br/>port closed, firewall"]
    Q2 -->|예| Q3{TLS handshake OK?}
    Q3 -->|아니오| L6Layer["L6 문제<br/>cert, SNI"]
    Q3 -->|예| Q4{HTTP 200?}
    Q4 -->|아니오| L7Layer["L7 문제<br/>application, auth"]
    Q4 -->|예| AppLogic["애플리케이션 로직"]

도구	담당 계층	용도
`ping`	L3 (ICMP)	기본 연결성 확인
`traceroute` / `tracert`	L3	경로 추적, 지연 구간 식별
`nc / telnet host port`	L4	포트 개방 여부 확인
`nmap`	L4	포트 스캔
`openssl s_client`	L6 (TLS)	TLS 핸드셰이크 확인
`curl -v`	L7 (HTTP)	HTTP 요청/응답 전체 확인
`dig / nslookup`	L7 (DNS)	도메인 → IP 조회
`tcpdump / wireshark`	L2-L7 (raw)	패킷 캡처 및 분석
`ss / netstat`	L4	소켓 연결 상태 확인

실전 디버깅 시나리오

서비스가 갑자기 응답 없을 때:

# 1. L3: 기본 연결성
ping api.example.com

# 2. L3: 경로 추적
traceroute api.example.com

# 3. L4: 포트 접근
nc -zv api.example.com 443

# 4. L6: TLS 핸드셰이크
openssl s_client -connect api.example.com:443 -servername api.example.com

# 5. L7: HTTP 요청
curl -v https://api.example.com/health

계층 간 상호작용 예시

HTTP/1.1 GET 요청이 서버에 도달하기까지:

sequenceDiagram
    participant App as L7 Application
    participant TLS as L6 TLS
    participant TCP as L4 TCP
    participant IP as L3 IP
    participant ETH as L2 Ethernet
    App->>TLS: HTTP 요청 평문
    TLS->>TCP: 암호화된 TLS 레코드
    TCP->>IP: TCP 세그먼트
    IP->>ETH: IP 패킷
    ETH->>ETH: 비트 전송
    note over ETH: 물리 계층 전달 후 역순 복원

흔한 함정

[!WARNING]

“L7 문제”로 단정: 실제는 L4 timeout 일 수 있다. 계층별로 위에서 아래로 분리 진단.

TLS 가 L4 라는 오해: TLS 는 L5/L6 사이. L4 (TCP/UDP) 위에서 동작.

HTTPS 인증서 문제를 방화벽 탓으로: openssl s_client 로 핸드셰이크 만 따로 확인.

DNS 가 L7 인지 L3 인지 혼동: DNS 는 L7 (애플리케이션). UDP/TCP 53 위에서 동작.

QUIC 은 L4?: QUIC 은 L3 (IP/UDP) 위에서 L4+L5+L6 역할을 모두 수행. 기존 OSI 모델로 정확히 분류 어려움.

Head-of-Line Blocking

koa (김신건) — Wed, 15 Jul 2026 00:00:00 GMT

정의

Head-of-Line Blocking (HOLB) 은 처리 순서가 정해진 큐에서 맨 앞 항목의 지연이 그 뒤 항목 전체의 지연으로 전파되는 현상이다.

네트워크 프로토콜에서는 HTTP, TCP 두 계층 모두에서 발생할 수 있으며, HTTP 버전에 따라 해결 범위가 다르다.

HTTP/1.1 의 HOL Blocking

HTTP/1.1 은 pipelining 을 통해 한 TCP 연결에서 여러 요청을 연속 전송할 수 있지만, 응답은 반드시 요청 순서대로 반환해야 한다.

sequenceDiagram
    participant C as Client
    participant S as Server
    C->>S: GET /slow-api
    C->>S: GET /icon.png
    C->>S: GET /style.css
    note over S: slow-api 5초 처리 중
    S-->>C: 200 /slow-api
    S-->>C: 200 /icon.png
    S-->>C: 200 /style.css

/icon.png 와 /style.css 는 즉시 응답 가능해도 /slow-api 가 끝날 때까지 대기해야 한다.

브라우저가 도메인당 6개 TCP 연결을 병렬 유지하는 이유: HOL 영향을 연결별로 분산하기 위함.

TCP 레벨 HOL Blocking

[[TCP]] 는 순서 보장을 위해 수신 버퍼에서 순서대로만 애플리케이션에 전달한다. 중간 패킷이 손실되면 이미 수신된 후속 패킷들도 버퍼에 묶인다.

sequenceDiagram
    participant S as Sender
    participant R as Receiver
    S->>R: Seq 1 도착
    S->>R: Seq 2 손실
    S->>R: Seq 3 버퍼 대기
    S->>R: Seq 4 버퍼 대기
    R->>S: SACK 요청, Seq 2 누락
    note over R: Seq 3,4 수신됐지만 앱 전달 불가
    S->>R: Seq 2 재전송
    note over R: Seq 2 수신 후 2,3,4 순서 전달

TCP 재전송 타임아웃(RTO) 이 길수록, 손실율이 높은 네트워크일수록 이 대기가 길어진다.

재전송 큐와 버퍼 팽창

TCP 의 HOL 이 심각해지는 조건:

높은 RTT 환경: RTO = 2 x RTT 기본값. RTT 가 100ms 면 RTO 200ms 이상
무선 환경 손실: WiFi, LTE 에서 패킷 손실율 2% 이상이면 TCP HOL 체감 심화
Bufferbloat: 중간 라우터 버퍼가 과잉 증가 → 큐잉 지연이 HOL 효과를 증폭
Fast Retransmit: 3개 중복 ACK 로 RTO 없이 즉시 재전송 가능하지만 HOL 은 그대로

HTTP/2 가 해결한 것과 해결 못한 것

HTTP/2 의 스트림 멀티플렉싱 은 HTTP 레벨 HOL 을 해결한다. 단일 TCP 연결에서 stream ID 로 구분된 frame 을 인터리브해 송수신한다.

flowchart LR
    subgraph H2["HTTP/2 단일 TCP 연결"]
        F1["Stream 1: GET /api/users"]
        F2["Stream 3: GET /logo.png"]
        F3["Stream 5: GET /style.css"]
    end
    Wire["TCP 스트림 (frame 인터리브)"]
    F1 -.->|frame| Wire
    F2 -.->|frame| Wire
    F3 -.->|frame| Wire

그러나 TCP 레벨의 HOL Blocking 은 여전히 남는다. 한 TCP 패킷 손실 시, 손실된 패킷이 어느 스트림에 속하든 TCP 는 해당 연결의 모든 스트림을 블로킹한다.

수준	HTTP/1.1	HTTP/2	HTTP/3 (QUIC)
HTTP 레벨 HOL	있음	없음	없음
TCP 레벨 HOL	있음	있음	해당 없음
연결당 동시 스트림	1 (pipelining)	다수	다수
손실 환경 성능	낮음	HTTP/1.1 보다 낮을 수 있음	높음

[!WARNING] 패킷 손실율이 높은 환경(WiFi, 이동통신)에서는 HTTP/2 가 HTTP/1.1 여러 병렬 연결보다 오히려 느릴 수 있다. 단일 TCP 연결에서 HOL 이 발생하면 멀티플렉싱된 모든 스트림이 동시에 블로킹되기 때문이다.

[[QUIC]] 가 해결한 것

QUIC 은 UDP 위에서 각 스트림이 독립적인 전송 제어 를 갖는다. 한 스트림의 패킷 손실은 다른 스트림에 영향을 미치지 않는다.

flowchart TB
    subgraph QUIC["QUIC 연결 (UDP 기반)"]
        SA["Stream A: 비디오"]
        SB["Stream B: 오디오"]
        SC["Stream C: 메타데이터"]
    end
    Loss["Stream A 패킷 손실"] --> SA
    SA -->|"Stream A 재전송만"| SA
    SB -->|"영향 없음"| OK["정상 수신"]
    SC -->|"영향 없음"| OK

각 스트림은 자체 시퀀스 번호와 ACK 를 관리하므로, 스트림 간 의존성이 없다.

QUIC 연결 내부
  Stream 1 (seq: 0-100, ACK: 87)
    └── seq 88 손실 → Stream 1 만 재전송 대기
  Stream 2 (seq: 0-50, ACK: 50) → 계속 진행
  Stream 3 (seq: 0-30, ACK: 30) → 계속 진행

[[HTTP/3]] 은 QUIC 위에서 동작하며, TCP 의 HOL Blocking 을 근본적으로 해결한다.

QUIC Connection Migration

[[QUIC]] 는 HOL 해결 외에도 Connection ID 기반으로 IP/Port 변경 시에도 기존 연결을 유지한다. 와이파이에서 셀룰러로 전환해도 TCP 처럼 연결이 끊기지 않는다.

HOL 의 영향 측정

HOL 의 영향은 패킷 손실율과 RTT 에 따라 크게 달라진다.

손실율별 최대 throughput 저하 (이론적 추정)

패킷 손실율	TCP 단일 연결	HTTP/2 (30 streams)	HTTP/3 (QUIC)
0%	기준	기준	기준
0.1%	-5% 내외	-15% 내외	-1% 내외
1%	-20% 내외	-40% 내외	-3% 내외
2%	-40% 내외	-60% 내외	-5% 내외

HTTP/2 의 멀티플렉싱 특성상 스트림이 많을수록 HOL 에 의한 cascading 블로킹 효과가 커진다.

실제 관찰 지표

# 패킷 손실율 측정
ping -c 100 8.8.8.8 | tail -2

# TCP 재전송율 확인
netstat -s | grep retransmit
ss -s

# tcpdump 로 TCP retransmit 관찰
tcpdump -i eth0 'tcp[tcpflags] & tcp-push != 0' -nn

실전 예시

브라우저 6-연결 전략 (HTTP/1.1 시대)

Chrome 등 브라우저는 도메인당 최대 6개의 TCP 연결을 유지해 HOL 를 병렬 분산시켰다.

Domain Sharding: static1.example.com, static2.example.com 등 서브도메인으로 리소스를 분산해 연결 한도를 우회하는 기법. HTTP/1.1 최적화였지만 HTTP/2 이후에는 오히려 TLS 핸드셰이크 오버헤드만 키운다.

HTTP/3 채택 현황

Cloudflare, Fastly 등 CDN:

클라이언트 to 엣지: HTTP/3 (QUIC) 우선 사용
엣지 to 오리진: HTTP/2 또는 HTTP/3

클라이언트 쪽 HOL 는 QUIC 으로 해결하고, 신뢰할 수 있는 데이터센터 네트워크에서는 HTTP/2 도 무방하다.

고성능 게임 / 실시간 스트리밍

TCP 기반 게임에서 패킷 손실로 전체 화면이 멈추는 현상(stutter) 이 발생할 수 있다. UDP 기반 자체 프로토콜이나 WebRTC DataChannel 로 게임 state, 오디오, 채팅을 독립 스트림으로 처리.

계층별 비교표

프로토콜	HOL 발생 계층	해결 방법	비고
HTTP/1.1 pipelining	HTTP + TCP 모두	6개 병렬 연결	브라우저 기본 동작
HTTP/2	TCP 레벨만	QUIC 전환	손실 환경에서 취약
HTTP/3 (QUIC)	없음	-	UDP 방화벽 차단 주의
WebSocket	TCP 레벨	-	장기 연결이므로 영향 누적
gRPC + HTTP/2	TCP 레벨	gRPC over QUIC	실험적 지원

SACK (Selective ACK) 으로 HOL 부분 완화

기본 TCP 는 손실 패킷 이후 모든 것을 재전송해야 했지만, SACK (RFC 2018) 은 수신된 비연속 구간을 명시해 실제로 손실된 것만 재전송하게 한다.

Without SACK:
  Sender → Receiver: 1, 2, 3, 4, 5
  2번 손실 → 2, 3, 4, 5 모두 재전송

With SACK:
  Receiver → Sender: ACK 2 요청, SACK [3-5 수신됨]
  → 2 만 재전송

SACK 은 HOL 을 제거하지는 않지만 재전송 데이터양을 줄여 블로킹 시간을 단축한다. 현대 운영체제는 기본적으로 SACK 을 활성화한다.

다른 사례

HOL Blocking 은 네트워크 외 일반 큐 처리 시스템에서도 발생한다.

데이터베이스 단일 큐 워커: 앞 작업이 느리면 뒤 작업 전체 블로킹
Kafka 파티션: 파티션 내 메시지는 순서 보장, 파티션 간은 독립 처리
멀티스레드 ordered 결과 병합: 스레드 풀 결과를 순서대로 머지하는 단계에서 발생
데이터베이스 MVCC: 장시간 트랜잭션이 vacuum 프로세스를 블로킹

해결책은 보통 독립 처리 단위로 분할 (sharding, partitioning, stream 격리).

스위치 레벨 HOL

네트워크 스위치에서도 같은 현상이 발생한다. 입력 포트에서 출력 포트로 패킷을 전달할 때, 출력 포트가 바쁘면 그 포트로 향하는 패킷이 큐의 앞을 차지해 다른 포트로 향하는 패킷을 블로킹한다.

Virtual Output Queue (VOQ) 는 출력 포트별로 별도 큐를 만들어 이를 해결하는 기법이다. 고성능 스위치에서 사용된다.

함정

[!CAUTION]

HTTP/2 = HOL 완전 해결? HTTP 레벨만 해결. 패킷 손실 환경에서는 TCP HOL 이 HTTP/1.1 다중 연결보다 더 나쁠 수 있음.

HTTP/3 = 항상 빠름? UDP 차단 방화벽에서는 HTTP/2 fallback 발생. 기업 네트워크에서 HTTP/3 비율이 낮은 이유.

연결 많으면 무조건 유리? HTTP/2 이후에는 Domain Sharding 이 TLS 핸드셰이크 오버헤드만 가중.

TCP HOL = 패킷 손실만? Bufferbloat (버퍼 팽창) 도 큐잉 지연을 일으켜 유사 HOL 효과를 냄.

RTT 낮으면 HOL 무관? RTT 가 낮아도 손실율이 높으면 HOL 재전송 대기가 반복됨.

브라우저에서 HOL 체험

개발자 도구 Network 탭에서 HTTP/1.1 vs HTTP/2 의 차이를 직접 확인할 수 있다.

# HTTP/1.1 강제 (curl)
curl --http1.1 -o /dev/null -s -w "%{time_total}\n" https://example.com

# HTTP/2 사용 (기본)
curl -o /dev/null -s -w "%{time_total}\n" https://example.com

# HTTP/3 시도 (지원 시)
curl --http3 -o /dev/null -s -w "%{time_total}\n" https://example.com

Chrome DevTools: Network 탭 → Protocol 컬럼 활성화. h2 (HTTP/2), h3 (HTTP/3), http/1.1 구분 가능.

QUIC

koa (김신건) — Wed, 15 Jul 2026 00:00:00 GMT

정의

QUIC (Quick UDP Internet Connections)은 Google이 2012년 처음 제안하고 2021년 RFC 9000으로 표준화된 [[udp|UDP]] 기반 전송 프로토콜이다. [[http-3|HTTP/3]]의 기반이 된다.

기존 [[tcp|TCP]]가 가지는 문제들을 OS 커널 수정 없이, 사용자 영역에서 해결하기 위해 [[udp|UDP]] 위에 구현되었다.

언제 쓰이나

HTTP/3: 브라우저와 서버 간 최신 웹 전송 (Google, Cloudflare, Facebook 기본 활성)
WebTransport: 브라우저에서 양방향 스트림 (WebSocket 대체 후보)
게임 / 실시간 미디어: 저지연 + 패킷 손실 내성
모바일 앱: Wi-Fi / 셀룰러 전환 시 연결 유지 (Connection Migration)

TCP vs QUIC 핸드셰이크

sequenceDiagram
    participant C as Client
    participant S as Server
    Note over C,S: TCP + TLS 1.3 (최초, 2 RTT)
    C->>S: SYN
    S->>C: SYN-ACK
    C->>S: ACK + TLS ClientHello
    S->>C: TLS ServerHello + Cert
    C->>S: TLS Finished + HTTP 요청
    S->>C: HTTP 응답
    Note over C,S: QUIC (최초, 1 RTT)
    C->>S: Initial + TLS ClientHello
    S->>C: Initial + ServerHello + Handshake + 1-RTT Data
    C->>S: Handshake Finished + HTTP/3 요청
    S->>C: HTTP/3 응답
    Note over C,S: QUIC 재접속 (0-RTT)
    C->>S: 0-RTT Data + ClientHello
    S->>C: 서버 응답

QUIC 은 TLS 1.3 핸드셰이크를 전송 계층 협상과 통합했다. 최초 연결은 1 RTT, 세션 티켓을 캐시해 두면 재접속은 0-RTT 로 데이터를 즉시 전송할 수 있다.

핵심 특성

1. Stream 격리와 HOL Blocking 해결

[[head-of-line-blocking|Head-of-Line Blocking]]: TCP 의 bytestream 모델에서 한 패킷 손실이 그 이후 모든 데이터를 막는다. QUIC 은 스트림을 독립 단위로 격리해, 한 스트림의 패킷 손실이 다른 스트림에 영향을 주지 않는다.

flowchart LR
    subgraph "TCP (단일 바이트스트림)"
        P1["패킷 1"] --> P2["패킷 2 손실"] --> P3["패킷 3 대기"]
    end
    subgraph "QUIC (독립 스트림)"
        S1["스트림 A: 패킷 1, 3 전달"]
        S2["스트림 B: 패킷 2 손실 (독립)"]
        S3["스트림 C: 패킷 4 즉시 전달"]
    end

2. TLS 1.3 통합

전송과 암호화 협상이 분리되어 있지 않다. QUIC 패킷은 헤더를 제외하고 항상 암호화된다. 중간 네트워크 장비가 내부를 들여다볼 수 없어 이후 프로토콜 확장도 방화벽에 차단될 우려가 없다.

3. Connection ID 와 Connection Migration

TCP 는 (소스 IP, 소스 포트, 목적지 IP, 목적지 포트) 4-tuple 로 연결을 식별한다. 모바일 환경에서 Wi-Fi 에서 셀룰러로 전환하면 IP 가 바뀌어 연결이 끊긴다.

QUIC 은 별도의 Connection ID 로 연결을 식별한다. IP 나 포트가 바뀌어도 같은 Connection ID 로 연결을 유지한다.

flowchart LR
    Phone["스마트폰"] -->|"IP: 192.168.1.5 (Wi-Fi)"| Server["서버\nConnection ID: 0xABCD"]
    Phone -->|"IP: 10.0.0.2 (LTE)"| Server
    Note["같은 Connection ID\n연결 유지"]

4. 사용자 영역 구현

TCP 는 OS 커널에 구현되어 있어 변경 배포가 느리다. QUIC 은 브라우저와 서버 라이브러리가 구현해 OS 업데이트 없이 새 기능을 배포할 수 있다.

TCP 대비 정리

항목	TCP	QUIC
기반	OS 커널	사용자 영역 라이브러리
HOL Blocking	있음	스트림 단위 격리
최초 핸드셰이크	2-3 RTT	1 RTT
재접속	1 RTT	0 RTT
연결 식별	IP + Port 4-tuple	Connection ID
IP 변경 시	연결 끊김	Migration 유지
암호화	TLS 별도 계층	항상 암호화 (TLS 통합)
헤더 압축	HTTP/2 [[hpack	HPACK]]

실전: HTTP/3 서버 설정 (nginx)

# nginx 1.25+ 기준 HTTP/3 + QUIC 설정
server {
    listen 443 quic reuseport;
    listen 443 ssl;

    ssl_certificate     /path/to/cert.pem;
    ssl_certificate_key /path/to/key.pem;
    ssl_protocols       TLSv1.3;

    # Alt-Svc 헤더로 브라우저에 QUIC 지원 알림
    add_header Alt-Svc 'h3=":443"; ma=86400';
}

실전: QUIC 연결 확인

# curl 로 HTTP/3 요청 (curl 7.88+ + QUIC 빌드 필요)
curl --http3 https://cloudflare.com -I

# HTTP/3 협상 확인
curl -v --http3 https://example.com 2>&1 | grep "ALPN"
# ALPN: h3

# Python (aioquic 라이브러리)
# pip install aioquic

import asyncio
from aioquic.asyncio import connect
from aioquic.quic.configuration import QuicConfiguration

async def quic_client():
    config = QuicConfiguration(is_client=True)
    async with connect("example.com", 443, configuration=config) as conn:
        # QUIC 연결 위에서 HTTP/3 스트림 열기
        reader, writer = await conn.create_stream()
        writer.write(b"GET / HTTP/3\r\n\r\n")
        data = await reader.read(4096)
        print(data)

asyncio.run(quic_client())

QUIC 패킷 구조

QUIC 패킷 (UDP 페이로드)
+------------------+------------------+
| Header (암호화)  | Payload (암호화) |
+------------------+------------------+
| Packet Type      | STREAM Frame     |
| Connection ID    | ACK Frame        |
| Packet Number    | CRYPTO Frame     |
+------------------+------------------+

TCP 와 달리 QUIC 패킷은 헤더 일부를 제외하고 전부 암호화된다. 중간 장비 (라우터, 방화벽) 는 Connection ID 와 패킷 번호 정도만 볼 수 있다.

약점 및 주의점

[!WARNING] UDP 차단 방화벽: 기업망, 일부 ISP 에서 UDP 포트 443 을 차단하거나 throttling 한다. HTTP/3 클라이언트는 TCP 기반 HTTP/2 fallback 을 반드시 구현해야 한다. 실제로 전체 트래픽의 5-10% 는 fallback 이 발생한다.

[!CAUTION] 0-RTT 재전송 공격: 0-RTT 데이터는 서버가 재생(replay) 을 방지하기 어렵다. 멱등하지 않은 요청 (POST, 결제 등) 을 0-RTT 로 보내면 replay 공격 위험이 있다. RFC 9000 §8.1 참조.

약점	상세
UDP 차단	기업 방화벽, ISP throttling
CPU 비용	커널 바이패스 없이 암호화 비용이 TCP+TLS 보다 높을 수 있음
NAT rebinding	Connection Migration 과 NAT 동작 충돌 가능
생태계	TCP 에 비해 라이브러리/디버거 성숙도 낮음
패킷 캡처	WireShark 등 도구에서 내부 분석이 어려움

QUIC 구현체

구현체	언어	비고
quiche (Cloudflare)	Rust	고성능, nginx/curl 에서 사용
ngtcp2	C	libev 기반, 범용
msquic (Microsoft)	C	Windows 내장, .NET 지원
quic-go	Go	순수 Go, HTTP/3 서버 구현에 자주 사용
aioquic	Python	연구/테스트 목적
MsQuic + NGINX	C/C++	기업 배포 표준

WebTransport

QUIC 위에서 브라우저가 양방향 스트림을 직접 열 수 있는 API. WebSocket 과 달리 HTTP 프록시를 거치지 않고 다중 독립 스트림을 사용할 수 있다.

// WebTransport (Chrome 97+, HTTP/3 기반)
const transport = new WebTransport("https://example.com/transport");
await transport.ready;

const stream = await transport.createBidirectionalStream();
const writer = stream.writable.getWriter();
await writer.write(new TextEncoder().encode("hello"));

const reader = stream.readable.getReader();
const { value } = await reader.read();
console.log(new TextDecoder().decode(value));

도입 현황 (2026 기준)

도입 사례	상세
Google	검색, YouTube, Gmail 기본 QUIC
Cloudflare	모든 CDN 트래픽
Meta	자사 서비스 대부분
Apple	iOS 네트워킹 스택 내장
주요 브라우저	Chrome, Firefox, Safari, Edge 모두 지원

TCP 에서 QUIC 으로 마이그레이션 체크리스트

실제 서비스에 HTTP/3 (QUIC) 을 도입할 때 확인해야 할 사항:

UDP 허용 확인: 서버 방화벽, 로드 밸런서, CDN 이 443/UDP 를 허용하는가
Alt-Svc 헤더: 브라우저에 HTTP/3 엔드포인트를 알리는 헤더 추가
Fallback 보장: UDP 차단 환경에서 자동으로 TCP/HTTP2 로 내려가는가
인증서 TLS 1.3: QUIC 은 TLS 1.3 필수. 1.2 이하는 불가
성능 모니터링: QUIC 연결 비율, fallback 비율, 지연시간을 분리 측정
로드 밸런서: QUIC Connection ID 기반 라우팅을 지원하는 LB 선택 (ngx_quic_lb 등)
세션 티켓 공유: 다중 서버 환경에서 0-RTT 재접속을 위해 세션 티켓을 공유해야 함

QUIC 버전

버전	상태	비고
gQUIC	Google 내부	표준화 이전 구버전, 점진 폐기
QUIC v1	RFC 9000 (2021)	현재 표준, HTTP/3 기반
QUIC v2	RFC 9369 (2023)	암호화 개선, 마이그레이션 신호 보강

TCP

koa (김신건) — Wed, 15 Jul 2026 00:00:00 GMT

정의

TCP (Transmission Control Protocol) 는 신뢰성 있는 연결 지향 전송 계층 프로토콜이다. RFC 9293 으로 정의되어 있다. HTTP/1.1·2, SMTP, SSH, FTP 등 인터넷의 대부분 응용 프로토콜이 TCP 위에서 동작한다.

[[UDP]] 와 대비된다. UDP 가 “보내고 잊는” 방식이라면 TCP 는 “확실히 도착한, 순서대로 전달”.

핵심 특성

연결 지향 (Connection-oriented): 통신 전에 3-way handshake 로 연결 확립
순서 보장 (In-order delivery): 패킷에 sequence number 부여, 수신측에서 재정렬
신뢰성 (Reliable): ACK 미수신 시 재전송, 손실 자동 복구
흐름 제어 (Flow Control): receiver window 로 수신측 처리 속도 맞춤
혼잡 제어 (Congestion Control): 네트워크 혼잡 시 송신 속도 조절 (Reno, Cubic, BBR 등)

TCP 헤더 구조

 0         1         2         3
 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|          Source Port          |       Destination Port        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                        Sequence Number                        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                    Acknowledgment Number                      |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|DataOff|Rsvd |U|A|P|R|S|F|          Window Size              |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|           Checksum            |         Urgent Pointer        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

주요 필드:

Sequence Number: 이 세그먼트 첫 바이트의 스트림 내 위치
Acknowledgment Number: 다음으로 기대하는 바이트 번호
Window Size: 수신 버퍼의 남은 공간 (흐름 제어)
Flags: SYN (연결 시작), ACK (확인), FIN (종료), RST (강제 종료), PSH (즉시 전달)

3-way Handshake (연결 수립)

{}

sequenceDiagram
    participant C as Client
    participant S as Server
    C->>S: SYN (seq=x)
    S->>C: SYN-ACK (seq=y, ack=x+1)
    C->>S: ACK (ack=y+1)
    note over C,S: 연결 수립 완료

SYN: “내 시작 번호는 x, 연결하겠다”
SYN-ACK: “OK, 내 시작 번호는 y, 너의 x+1 번째를 기다린다”
ACK: “알겠어, 너의 y+1 번째를 기다린다”

1 RTT 소요. [[TLS]] 까지 추가하면 보통 2-3 RTT.

[!IMPORTANT] SYN Flood 공격: 악의적인 클라이언트가 SYN 만 보내고 ACK 를 보내지 않아 서버의 SYN 백로그 큐를 소진시킨다. SYN Cookies 로 서버 측 상태 저장 없이 방어 가능.

4-way Handshake (연결 종료)

{}

sequenceDiagram
    participant C as Client
    participant S as Server
    C->>S: FIN (seq=u)
    S->>C: ACK (ack=u+1)
    note over S: 서버는 아직 데이터 전송 가능
    S->>C: FIN (seq=v)
    C->>S: ACK (ack=v+1)
    note over C: TIME_WAIT 상태 진입

각 방향(C→S, S→C) 을 독립적으로 종료하므로 4단계가 필요. 마지막 ACK 를 보낸 클라이언트는 TIME_WAIT 상태로 2 x MSL (Maximum Segment Lifetime, 보통 60s~4min) 동안 대기한다. 지연 도착 패킷이 새 연결을 오염시키는 것을 방지하기 위함.

흐름 제어 (Flow Control)

수신측이 처리 가능한 속도보다 빠르게 데이터가 들어오는 것을 방지.

Sender                                        Receiver
  │── Data (3000 bytes) ─────────────────────→ │ rwnd=65535
  │ ←── ACK, rwnd=30000 ────────────────────── │
  │── Data (10000 bytes) ───────────────────→ │ rwnd=30000
  │ ←── ACK, rwnd=20000 ────────────────────── │
  │── Data (20000 bytes) ───────────────────→ │
  │ ←── ACK, rwnd=0 (Zero Window) ─────────── │ 수신 버퍼 꽉 참
  │   [전송 중단, Zero Window Probe 대기]       │
  │ ←── ACK, rwnd=32768 ────────────────────── │ 버퍼 비워짐
  │── Data 재개 ────────────────────────────→ │

Receive Window (rwnd): 수신 버퍼의 남은 공간
Zero Window: rwnd=0 이면 송신 중단. 주기적으로 Zero Window Probe 전송
Window Scaling (RFC 7323): 16bit 윈도우를 최대 30bit (1GB) 로 확장. 대역폭 지연 곱이 큰 네트워크에서 필요

혼잡 제어 (Congestion Control)

네트워크 혼잡을 감지하고 송신 속도를 조절하는 TCP 의 핵심 메커니즘.

상태 전환

flowchart LR
    SS["Slow Start\ncwnd 지수 증가"]
    CA["Congestion Avoidance\ncwnd 선형 증가"]
    FR["Fast Recovery\ncwnd 절반 후 선형"]
    SS -->|"cwnd >= ssthresh"| CA
    CA -->|"3 dup ACK"| FR
    FR -->|"새 ACK"| CA
    CA -->|"timeout"| SS
    SS -->|"timeout"| SS

Slow Start: cwnd (Congestion Window) 를 1 MSS 에서 시작, ACK 마다 1 MSS 증가 (지수 증가)
Congestion Avoidance: ssthresh 도달 후, RTT 마다 1 MSS 씩 선형 증가
Fast Recovery: 3개 중복 ACK 수신 시 ssthresh = cwnd/2, cwnd = ssthresh + 3. 타임아웃과 달리 Slow Start 로 돌아가지 않음

알고리즘 비교

알고리즘	손실 감지	장점	단점	사용처
Reno	패킷 손실	단순, 범용	고 BDP 에서 대역폭 낭비	범용
Cubic	손실 + 시간 함수	Reno 대비 처리량 개선	손실 기반 한계	Linux 기본
BBR	대역폭-지연 모델	버퍼 팽창 없이 최대 처리량	구현 복잡, 공정성 이슈	Google, Cloudflare

BBR (Bottleneck Bandwidth and RTT): 패킷 손실 대신 RTT 와 대역폭을 직접 측정해 최적 전송 속도를 산출한다. Bufferbloat 방지 효과도 있다.

재전송 (Retransmission)

ACK 가 오지 않으면 재전송. 두 가지 트리거:

RTO (Retransmission Timeout): 타이머 만료 시 재전송. 초기 RTO = 1s, 지수 백오프 적용
Fast Retransmit: 3개의 중복 ACK (Duplicate ACK) 수신 시 즉시 재전송

sequenceDiagram
    participant S as Sender
    participant R as Receiver
    S->>R: Seq 100
    S->>R: Seq 200 (손실)
    S->>R: Seq 300
    R->>S: ACK 200 (Seq 100 확인, 200 요청)
    S->>R: Seq 400
    R->>S: ACK 200 (Dup ACK)
    S->>R: Seq 500
    R->>S: ACK 200 (Dup ACK)
    S->>R: Seq 600
    R->>S: ACK 200 (Dup ACK 3번째)
    note over S: Fast Retransmit 발동
    S->>R: Seq 200 재전송
    R->>S: ACK 700 (모두 확인)

SACK (Selective ACK): 수신된 비연속 구간을 명시해, 실제 손실된 것만 재전송 가능.

Without SACK: 200 손실 → 200, 300, 400, 500, 600 모두 재전송
With SACK:    200 손실 → 200 만 재전송 (300-600 수신 확인)

TCP 의 한계

문제	설명	해결 시도
연결 비용	매번 3-way handshake (1 RTT)	HTTP keep-alive, [[QUIC]]
[[Head-of-Line Blocking]]	한 패킷 손실이 같은 연결의 모든 스트림 영향	[[QUIC]] 가 스트림 격리로 완전 해결
연결 변경 시 끊김	IP/Port 바뀌면 새 연결 수립 필요	[[QUIC]] Connection Migration
커널 종속	OS 업데이트 없이는 개선 불가	[[QUIC]] 사용자 영역 구현

실전 예시

TCP 연결 상태 확인

# 확립된 연결 목록
ss -tn state established

# TIME_WAIT 상태 확인
ss -tn state time-wait | wc -l

# 포트별 연결 수
ss -tn | awk 'NR>1 {print $5}' | cut -d: -f2 | sort | uniq -c | sort -rn

TIME_WAIT 과다 문제

대량의 단기 HTTP/1.0 요청 또는 특정 로드 밸런서 구성에서 TIME_WAIT 소켓이 포트를 점유해 EADDRINUSE 발생.

# TIME_WAIT 소켓 재사용 허용 (클라이언트 측)
sysctl net.ipv4.tcp_tw_reuse=1

# FIN_WAIT2 대기 시간 축소
sysctl net.ipv4.tcp_fin_timeout=15

Nagle 알고리즘

작은 패킷을 모아 하나로 전송해 네트워크 효율을 높인다. SSH, 텔넷, 게임처럼 낮은 지연이 중요한 경우 TCP_NODELAY 옵션으로 비활성화.

import socket
sock = socket.socket()
sock.setsockopt(socket.IPPROTO_TCP, socket.TCP_NODELAY, 1)

함정

[!WARNING]

HTTP keep-alive 와 TIME_WAIT 혼동: HTTP keep-alive 는 응용 계층(TCP 연결 유지), TIME_WAIT 는 TCP 계층(종료 후 대기). 별개 개념.

RTT = 네트워크 거리만? RTT 에는 패킷 왕복 시간 외에 큐잉 지연, 처리 지연도 포함된다.

Nagle 알고리즘 방치: 낮은 지연이 중요한 서비스 (채팅, 게임) 에서 Nagle 이 활성화된 채로 소량 메시지를 반복 전송하면 지연 누적.

TCP_NODELAY 와 TCP_CORK 혼동: NODELAY 는 소량 패킷 즉시 전송, CORK 는 패킷 모아서 전송 (반대 효과).

사용처

HTTP/1.1, HTTP/2 (HTTPS 포함)
WebSocket (HTTP Upgrade 후 TCP 그대로)
SSH, SMTP, FTP
데이터베이스 프로토콜 대부분 (PostgreSQL, MySQL wire protocol)

TLS / SSL

koa (김신건) — Wed, 15 Jul 2026 00:00:00 GMT

정의

TLS (Transport Layer Security) 는 [[TCP]] (또는 [[UDP]] 위 [[QUIC]]) 위에서 동작하는 암호화·인증 프로토콜이다. SSL 은 TLS 의 전신 (Netscape 1995, 더 이상 사용되지 않음).

웹의 HTTPS 가 바로 “HTTP + TLS”. 인증서 검증, 키 교환, 암호화된 데이터 전송 모두 TLS 가 담당한다.

버전 역사

버전	출시	상태
SSL 1.0	1994	내부 사용, 공개 안 됨
SSL 2.0	1995	폐기 (취약점 다수)
SSL 3.0	1996	폐기 (POODLE 공격)
TLS 1.0	1999	폐기 (BEAST 공격)
TLS 1.1	2006	폐기
TLS 1.2	2008	현재도 널리 사용
TLS 1.3	2018	권장, [[QUIC]] 에 통합됨

[!CAUTION] “SSL 인증서” 라는 용어는 관습적으로 남아있지만, 실제로 사용되는 건 TLS 다. SSL 1.0~3.0 은 모두 폐기되었다.

TLS 가 하는 일

서버 인증: 인증서로 “당신이 정말 example.com 입니까?” 검증
키 교환: 양측이 공유할 대칭키를 안전하게 생성 (ECDHE 등)
대칭 암호화: 이후 데이터를 AES-GCM, ChaCha20-Poly1305 등으로 암호화
무결성 검증: 메시지 변조 감지 (AEAD 알고리즘에 내장)

핵심 개념

비대칭 vs 대칭 암호의 역할 분리

	알고리즘 예	사용 시점	특성
비대칭 (공개키)	RSA, ECDSA, ECDHE	핸드셰이크 단계	느림, 인증서 검증·키 교환에만 사용
대칭	AES-GCM, ChaCha20	응용 데이터 단계	빠름, 핸드셰이크에서 합의한 세션 키로 암호화

핸드셰이크에서 비대칭으로 안전하게 세션 키를 만들고, 이후 모든 데이터는 빠른 대칭 암호로 처리한다.

Forward Secrecy

ECDHE (Elliptic Curve Diffie-Hellman Ephemeral) 기반 키 교환은 매 세션마다 새 키를 만든다. 서버의 장기 비밀키가 나중에 유출되어도 과거 세션은 복호화 불가. TLS 1.3 은 이런 ephemeral 키 교환만 허용한다.

AEAD (Authenticated Encryption with Associated Data)

암호화와 무결성 검증을 한 번에 수행하는 알고리즘. 별도의 MAC 계산 없이 변조 감지 가능. TLS 1.3 은 AEAD 만 허용한다.

TLS 1.2 Full Handshake (2-RTT)

{}

단계별 흐름:

ClientHello: 클라이언트가 지원하는 cipher suite 목록 + random 값을 보낸다.
ServerHello + Certificate + ServerKeyExchange + ServerHelloDone: 서버가 cipher 를 고르고, 인증서 체인 + 서버 측 키 교환 파라미터를 한 번에 보낸다.
ClientKeyExchange + ChangeCipherSpec + Finished: 클라이언트가 pre-master 비밀을 보내고, 이후 대칭키 모드로 전환한다는 신호와 함께 Finished 메시지를 보낸다.
ChangeCipherSpec + Finished: 서버도 대칭키 모드로 전환했음을 알리고 Finished 로 핸드셰이크 무결성을 검증한다.

총 2 RTT 소요. 응용 데이터 전송은 그 이후부터.

TLS 1.3 Handshake (1-RTT)

{}

TLS 1.3 의 핵심 개선:

KeyShare 동봉

ClientHello 에 클라이언트가 미리 계산한 DH 공개키 후보 (KeyShare) 를 동봉한다. 서버는 같은 cipher / 그룹을 선택하면 즉시 같은 세션 키를 도출할 수 있다.

인증서를 핸드셰이크 안에서 암호화

TLS 1.2 에서는 인증서가 평문으로 전송되었으나 TLS 1.3 에서는 ServerHello 직후부터 핸드셰이크 메시지도 (handshake traffic key 로) 암호화된다. 사용자가 어떤 도메인을 방문하는지 외부에서 보기 어려워진다. (단, SNI 는 여전히 평문, ECH 로 보완 중)

0-RTT Resumption

이전 세션의 PSK (Pre-Shared Key) 또는 세션 티켓을 첨부하면, 첫 패킷에 응용 데이터를 동봉할 수 있다. RTT 0 으로 응답 시작 가능.

⚠️ 0-RTT 는 replay attack 위험이 있다. 같은 데이터가 재전송될 수 있으므로 멱등(idempotent) 요청 (GET 등) 에만 권장. 결제 같은 부작용 있는 요청은 1-RTT 로 강제해야 한다.

Cipher Suite 단순화

TLS 1.2 의 약한 cipher (RC4, 3DES, CBC mode 등) 가 모두 제거되었다. 5개의 AEAD cipher suite 만 남았다.

Cipher Suite

TLS 협상에서 선택하는 알고리즘 조합.

TLS 1.2 cipher suite 구조

TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
    │      │        │            │
    │      │        │            └── MAC/HMAC: SHA256
    │      │        └─────────────── 암호화: AES-128-GCM
    │      └──────────────────────── 서명/인증: RSA
    └─────────────────────────────── 키 교환: ECDHE

TLS 1.3 cipher suite (단순화)

키 교환은 별도로 협상하고 cipher suite 에서 분리됨:

Cipher Suite	AEAD 알고리즘	HKDF
TLS_AES_256_GCM_SHA384	AES-256-GCM	SHA-384
TLS_AES_128_GCM_SHA256	AES-128-GCM	SHA-256
TLS_CHACHA20_POLY1305_SHA256	ChaCha20-Poly1305	SHA-256

ChaCha20-Poly1305: AES 하드웨어 가속이 없는 모바일 기기에서 더 빠르다. Android 저가형 기기에서 성능 이점이 크다.

인증서 체인 검증

{}

브라우저는 서버가 보낸 인증서가 신뢰할 수 있는지 다음 절차로 검증한다.

도메인 일치 확인: 인증서의 SAN (Subject Alternative Name) 또는 CN 이 접속한 도메인과 일치하는가
만료 확인: notBefore ~ notAfter 범위 안에 있는가
체인 서명 검증: Leaf 인증서의 서명을 Intermediate CA 의 공개키로 검증, Intermediate 의 서명을 Root CA 의 공개키로 검증
Root 일치 확인: 체인의 최상위가 OS / 브라우저의 truststore 에 내장된 신뢰된 Root CA 인가
폐기 여부 확인 (선택): OCSP (Online Certificate Status Protocol) 또는 CRL (Certificate Revocation List) 로 인증서가 revoke 되지 않았는지

서버는 보통 Leaf + Intermediate 만 전송한다. Root 는 클라이언트가 이미 truststore 에 가지고 있다.

인증서 발급 흐름

단계	누가	무엇을
1. CSR 생성	서버 운영자	도메인 + 공개키로 CSR (Certificate Signing Request) 만든다
2. 도메인 소유 증명	운영자, CA	DNS TXT 레코드 (DNS-01) 또는 HTTP `/.well-known/` (HTTP-01)
3. 서명	CA	검증 통과 시 CA 의 비밀키로 Leaf 인증서에 서명
4. 갱신	서버 운영자	Let’s Encrypt 는 90일, 보통 60일 전 자동 갱신

Let’s Encrypt, Cloudflare 등이 무료 + 자동화된 TLS 인증서를 제공하면서 HTTPS 가 사실상 표준이 되었다.

mTLS (Mutual TLS)

일반 TLS 는 서버만 인증서를 제시한다. mTLS 는 클라이언트도 인증서를 제시해 양방향 인증을 수행한다.

sequenceDiagram
    participant C as Client
    participant S as Server
    C->>S: ClientHello
    S->>C: ServerHello, Certificate, CertificateRequest
    C->>S: Certificate, CertificateVerify, Finished
    S->>C: Finished
    note over C,S: 양방향 인증 완료

주요 사용 사례:

서비스 메시 (Istio, Linkerd): Pod 간 통신에 자동 mTLS 적용
제로 트러스트 아키텍처: 내부 서비스 간 상호 인증
B2B API: 특정 파트너사만 접근 허용

SNI (Server Name Indication)

TLS ClientHello 에 접속하려는 도메인 이름을 포함하는 확장.

필요한 이유: 하나의 IP 에 여러 도메인(가상 호스팅) 이 있을 때, 서버가 어떤 인증서를 제시해야 할지 알기 위함.

ClientHello
  extensions:
    server_name: "www.example.com"   <- 평문 전송

[!CAUTION] SNI 는 평문으로 전송돼 네트워크 관찰자가 사용자가 방문하는 도메인을 볼 수 있다. ECH (Encrypted Client Hello) 가 이를 해결하는 중 (RFC 진행 중, Cloudflare 등 일부 지원).

ALPN (Application-Layer Protocol Negotiation)

ClientHello 에서 지원하는 응용 프로토콜을 협상하는 TLS 확장. 80/443 포트를 유지하면서 HTTP/1.1, HTTP/2 를 구분한다.

ClientHello
  extensions:
    alpn: ["h2", "http/1.1"]    <- 클라이언트 선호 순서

ServerHello
  extensions:
    alpn: "h2"                   <- 서버가 선택

# ALPN 협상 확인
openssl s_client -connect example.com:443 -alpn h2 2>&1 | grep "ALPN"

Session Resumption

TLS 핸드셰이크 비용을 줄이는 방법. 완전 핸드셰이크를 생략하고 이전 세션을 재사용.

방식	TLS 버전	서버 상태	설명
Session ID	1.2	서버 저장	서버가 ID 반환, 클라이언트가 다음 연결 때 제시
Session Ticket	1.2 / 1.3	클라이언트 저장	서버가 암호화된 상태를 티켓으로 전달
PSK / 0-RTT	1.3	없음	이전 세션 키로 첫 패킷에 데이터 포함

Session Ticket 은 서버 측 상태 저장이 불필요해 수평 확장에 유리하다. 단, 티켓 암호화 키가 로테이션되어야 Forward Secrecy 가 보장된다.

[[QUIC]] 와 TLS

QUIC 은 TLS 1.3 을 전송 계층에 통합했다.

프로토콜 조합	핸드셰이크 RTT
TCP + TLS 1.2	TCP (1 RTT) + TLS (2 RTT) = 3 RTT
TCP + TLS 1.3	TCP (1 RTT) + TLS (1 RTT) = 2 RTT
QUIC (TLS 1.3 통합)	1 RTT (full) 또는 0 RTT (resume)

QUIC 은 핸드셰이크와 전송을 분리하지 않고, 같은 패킷 안에서 처리한다. 결과적으로 HTTP/3 는 첫 페이지 로딩이 HTTP/2 보다 빠르다.

실전 예시

openssl 로 TLS 확인

# TLS 핸드셰이크 확인
openssl s_client -connect example.com:443 -servername example.com

# TLS 1.3 강제
openssl s_client -connect example.com:443 -tls1_3

# ALPN 협상 확인
openssl s_client -connect example.com:443 -alpn h2

# 인증서 상세 정보
openssl s_client -connect example.com:443 2>/dev/null | openssl x509 -noout -text

nginx TLS 1.3 설정

ssl_protocols TLSv1.2 TLSv1.3;
ssl_ciphers HIGH:!aNULL:!MD5;

# Session resumption
ssl_session_tickets on;
ssl_session_timeout 1d;
ssl_session_cache shared:SSL:10m;

# OCSP Stapling
ssl_stapling on;
ssl_stapling_verify on;

# HSTS
add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always;

Let’s Encrypt 자동 갱신

# 인증서 발급
certbot --nginx -d example.com -d www.example.com

# 갱신 테스트
certbot renew --dry-run

# systemd timer 로 자동 갱신
systemctl enable --now certbot.timer

약점과 주의점

인증서 관리 비용: 갱신 자동화 (ACME / certbot / cert-manager) 가 필수. 만료 사고는 흔하다.
중간자 (MITM) 위험: 사내 프록시나 일부 디바이스가 truststore 에 자체 CA 를 심어 트래픽을 가로채는 경우가 있다.
0-RTT replay: TLS 1.3 의 0-RTT 는 부작용 있는 요청에 사용 금지.
SNI 노출: 어떤 도메인에 접속하는지는 ClientHello 의 SNI 에 평문으로 노출됨. ECH 로 점진적 해결 중.
신뢰 모델 자체의 한계: 약 150개 Root CA 중 하나라도 침해되면 임의의 도메인을 위장할 수 있음. Certificate Transparency (CT) 로 발급 로그 공개 의무화.

함정

[!WARNING]

TLS = 종단간 암호화? TLS 는 전송 경로 암호화. 서버에서 복호화되므로 서버 측 데이터는 평문. E2E 암호화는 별도 구현 필요.

인증서 = 보안 증명? 인증서는 도메인 소유를 증명할 뿐. 사이트의 콘텐츠나 운영 주체의 신뢰성을 보장하지 않음.

인증서 유출 = 치명적? 인증서에는 공개키만 포함됨. 비밀키가 유출돼야 실제 위험. 인증서 자체 유출은 무해.

TLS 1.3 0-RTT 오남용: GET 이 아닌 POST/PUT/DELETE 에 0-RTT 를 허용하면 replay 공격으로 중복 처리 위험.

HTTPS = 암호화 완료? 사내 프록시나 DLP 솔루션이 자체 CA 로 트래픽을 가로챌 수 있음 (SSL inspection).

UDP

koa (김신건) — Wed, 15 Jul 2026 00:00:00 GMT

정의

UDP (User Datagram Protocol)는 비연결·비신뢰 전송 계층 프로토콜이다. RFC 768 (1980) 로 정의되었다. [[tcp|TCP]] 와 대비된다.

“보내고 잊는다(fire-and-forget)”, 송신측은 패킷을 던지고 끝, 받았는지 안 받았는지 확인하지 않는다.

언제 쓰이나

신뢰성보다 저지연·저오버헤드가 더 중요할 때.

DNS: 작은 질의·응답, 응답 안 오면 재시도하면 됨
실시간 미디어: 비디오 통화에서 1 프레임 손실은 재전송할 시간이 없음, 다음 프레임이 더 중요
게임: 위치 업데이트가 1 패킷 잃어도 다음 패킷이 곧 옴
DHCP, NTP, SNMP: 단순한 요청·응답
[[quic|QUIC]] / [[http-3|HTTP/3]]: UDP 위에서 신뢰성·순서 보장을 사용자 영역에서 직접 구현

헤더 구조

UDP 패킷 헤더는 총 8 bytes (TCP 의 20+ bytes 와 대비).

{}

필드	크기	설명
Source Port	2 bytes	송신측 포트
Destination Port	2 bytes	수신측 포트
Length	2 bytes	헤더 + 데이터 길이
Checksum	2 bytes	무결성 검증

TCP 헤더 (20 bytes 이상, 옵션 포함 시 최대 60 bytes) 와 비교하면, UDP 헤더는 응용에 필요한 최소 정보만 담는다. 흐름 제어, 혼잡 제어, 재전송 등 모든 신뢰성 메커니즘을 제거한 결과다.

전송 방식, Fire-and-Forget

{}

sequenceDiagram
    participant A as 송신측
    participant N as 네트워크
    participant B as 수신측
    A->>N: 데이터그램 1
    N->>B: 데이터그램 1 도착
    A->>N: 데이터그램 2
    N--xB: 데이터그램 2 손실
    A->>N: 데이터그램 3
    N->>B: 데이터그램 3 도착
    Note over A: 손실 여부 모름, 계속 전송
    Note over B: 1, 3 수신. 2 누락 인지 못함

UDP 는 핸드셰이크 없이 즉시 송신한다. ACK 없음, 손실되어도 송신측은 알 수 없다.

TCP 와 비교

항목	TCP	UDP
연결	3-way handshake 필요	연결 없음
신뢰성	손실 재전송	없음
순서	보장	보장 안 함
흐름 제어	있음	없음
혼잡 제어	있음	없음
헤더 크기	20-60 bytes	8 bytes
지연시간	높음	낮음
브로드캐스트/멀티캐스트	불가	가능

MTU 와 단편화

MTU (Maximum Transmission Unit): 이더넷 표준 1500 bytes. IP 헤더 20 bytes + UDP 헤더 8 bytes = 실데이터 최대 1472 bytes (이더넷 기준).

이보다 큰 데이터그램은 IP 계층에서 단편화(fragmentation) 된다.

flowchart LR
    D["UDP 데이터그램\n3000 bytes"] -->|"IP 단편화"| F1["IP 프래그먼트 1\n1480 bytes"]
    D --> F2["IP 프래그먼트 2\n1480 bytes"]
    D --> F3["IP 프래그먼트 3\n40 bytes"]
    F1 -->|"수신측 재조립"| R["재조립된 데이터그램"]
    F2 --> R
    F3 --> R

[!WARNING] 단편화는 성능 저하 + 재조립 실패 위험이 있다. 중간 라우터에서 한 조각만 잃어도 전체 데이터그램을 드롭한다. 실전에서는 Path MTU Discovery 로 경로 MTU 를 알아낸 뒤 그 이하로 전송한다.

최적 페이로드 크기 = Path MTU - IP 헤더 - UDP 헤더
이더넷 기준: 1500 - 20 - 8 = 1472 bytes

브로드캐스트 / 멀티캐스트

UDP 는 1:N 전송을 지원한다. TCP 는 1:1 연결만 가능.

전송 방식	설명	UDP	TCP
유니캐스트	1:1	O	O
브로드캐스트	1:네트워크 전체	O	X
멀티캐스트	1:그룹 구독자	O	X

DHCP: 브로드캐스트로 서버 탐색
mDNS / DNS-SD: 로컬 서비스 발견 (Bonjour)
IPTV: 멀티캐스트로 동일 스트림을 여러 수신자에 전달

”UDP 위에 신뢰성을 다시 만든다”는 역설

[[quic|QUIC]], [[webrtc|WebRTC]] DTLS/SRTP, 게임 엔진의 reliable UDP 가 모두 UDP 위에서 TCP 와 유사한 기능을 직접 구현한다. 왜?

TCP 의 한계를 우회: OS 커널 의존, [[head-of-line-blocking|Head-of-Line Blocking]], 연결 변경 시 끊김
선택적 신뢰성: 메시지마다 “ordered / unordered, reliable / unreliable” 선택 가능
빠른 진화: 사용자 영역 구현이라 OS 업데이트 없이 개선

flowchart TB
    UDP["UDP (비연결, 비신뢰)"]
    UDP --> QUIC["QUIC\n신뢰성 + 순서 + 암호화 + 멀티스트림"]
    UDP --> WebRTC["WebRTC DTLS/SRTP\n암호화 미디어 스트림"]
    UDP --> Game["게임 Reliable UDP\n선택적 신뢰성"]
    UDP --> DNS["DNS\n단순 질의/응답"]
    UDP --> NTP["NTP / SNMP\n단순 프로토콜"]

UDP 의 “단순함”은 양날의 검, 직접 구현해야 하지만 그만큼 유연하다.

실전 예시

DNS 질의 (Python)

import socket
import struct

def build_dns_query(hostname: str) -> bytes:
    """간이 DNS A 레코드 요청 패킷"""
    transaction_id = b"\xab\xcd"
    flags = b"\x01\x00"   # 표준 질의
    questions = b"\x00\x01"
    answers = rrcount = additional = b"\x00\x00"
    
    # QNAME 인코딩
    qname = b""
    for part in hostname.split("."):
        qname += bytes([len(part)]) + part.encode()
    qname += b"\x00"
    
    qtype = b"\x00\x01"   # A 레코드
    qclass = b"\x00\x01"  # IN (인터넷)
    return transaction_id + flags + questions + answers + rrcount + additional + qname + qtype + qclass


def dns_lookup(hostname: str) -> bytes:
    sock = socket.socket(socket.AF_INET, socket.SOCK_DGRAM)  # SOCK_DGRAM = UDP
    sock.settimeout(2.0)
    
    query = build_dns_query(hostname)
    sock.sendto(query, ("8.8.8.8", 53))  # Google Public DNS
    
    # 응답이 없으면 timeout 예외 -> 재시도 (애플리케이션 레벨 신뢰성)
    response, _ = sock.recvfrom(512)
    sock.close()
    return response

실시간 게임 위치 동기화

import socket
import struct
import time

sock = socket.socket(socket.AF_INET, socket.SOCK_DGRAM)

def send_position(x: float, y: float, seq: int, server: tuple):
    # 패킷: seq(4B) + x(4B) + y(4B) = 12 bytes
    payload = struct.pack("!Iff", seq, x, y)
    sock.sendto(payload, server)
    # ACK 없음: 손실된 위치는 무시, 다음 패킷이 곧 도착

SERVER = ("game.example.com", 7777)
seq = 0
while True:
    send_position(player.x, player.y, seq, SERVER)
    seq += 1
    time.sleep(0.05)  # 20 Hz 업데이트

UDP 서버 (에코 서버)

import socket

def udp_echo_server(port: int = 9999):
    sock = socket.socket(socket.AF_INET, socket.SOCK_DGRAM)
    sock.bind(("0.0.0.0", port))
    print(f"UDP Echo Server on port {port}")

    while True:
        data, addr = sock.recvfrom(1024)
        print(f"Received {len(data)} bytes from {addr}")
        sock.sendto(data, addr)  # 에코 (연결 없이 즉시 응답)

함정

[!WARNING] NAT 는 UDP 를 잘 모른다. TCP 는 SYN/FIN 으로 상태를 추적하지만 UDP 는 상태가 없어 NAT 테이블 타임아웃이 짧다 (보통 30초). 장시간 UDP 세션이 필요하면 keepalive 패킷으로 NAT 테이블을 유지해야 한다.

[!CAUTION] UDP 증폭 공격 (DRDoS): 요청 패킷은 작고 응답이 매우 클 수 있는 DNS, NTP, SSDP 등에서 소스 IP 를 위조한 UDP 요청으로 증폭 공격이 발생한다. 공개 UDP 서비스는 응답 크기 제한 + 소스 IP 검증 필수.

[!IMPORTANT] 체크섬은 IPv4 에서 선택 사항이었다. 하지만 현대 OS 는 기본적으로 체크섬을 계산한다. IPv6 에서는 UDP 체크섬이 필수다. 체크섬은 내용 변조 감지는 하지만 재전송을 보장하지는 않는다.

UDP 포트 번호 주요 사례

잘 알려진 UDP 포트 (Well-Known Ports):

포트	프로토콜	설명
53	DNS	도메인 이름 조회
67/68	DHCP	IP 주소 자동 할당
123	NTP	시간 동기화
161/162	SNMP	네트워크 장비 관리
443	QUIC	HTTP/3 (TLS over UDP)
5353	mDNS	로컬 서비스 발견
5004	RTP	실시간 미디어 전송

Stateful vs Stateless Firewall

koa (김신건) — Tue, 07 Jul 2026 00:00:00 GMT

정의

방화벽 (Firewall) 은 네트워크 트래픽을 정책에 따라 허용/차단 하는 보안 장치. 상태 관리 방식으로 두 유형이 있습니다.

Stateless (상태 비저장): 각 패킷을 독립적 으로 검사. 이전 패킷과 관계 없음.
Stateful (상태 저장): 연결 (connection) 상태를 추적 하여 관련 패킷을 인식.

이 차이가 AWS VPC 의 Security Group (stateful) 과 Network ACL (stateless) 의 근본입니다.

왜 상태 추적이 문제인가

TCP 통신은 양방향

TCP 연결은 3-way handshake 이후 양방향 데이터 흐름:

Client (192.168.1.10:54321)                Server (10.0.0.5:443)
       ─────── SYN ───────>
       <──── SYN+ACK ─────
       ─────── ACK ───────>
       ─────── HTTP GET ─>
       <──── HTTP 200 ────
       ─────── FIN ───────>
       <────── FIN ────────

방화벽 규칙 관점:

Outbound (client → server): dst 10.0.0.5:443 tcp
Inbound (server → client): src 10.0.0.5:443 tcp (응답)

Stateless Firewall

각 패킷을 규칙과 매칭. 연결 개념 없음.

특징

양방향 규칙 명시 필수: outbound 뿐 아니라 return traffic 도 별도 허용
간단, 빠름: 상태 테이블 없어 리소스 적음
에페메랄 포트 문제: 클라이언트 소스 포트가 랜덤 (32768-65535) 이라 방화벽이 예측 불가

규칙 예시 (stateless)

Client 가 dst port 443 으로 웹서핑 하려면:

Outbound:  ALLOW  proto=TCP  src=any:any  dst=any:443
Inbound:   ALLOW  proto=TCP  src=any:443  dst=any:1024-65535   ← 응답 허용 별도

Inbound 규칙 없으면 웹 응답이 방화벽에 막힘. Stateless 는 대칭 규칙 필수.

순서 & 우선순위

Stateless 는 대개 번호 기반 순서 매칭. 첫 매칭 규칙이 적용:

100: ALLOW  tcp  src=any  dst=443
110: ALLOW  tcp  src=443  dst=1024-65535
120: DENY   tcp  src=any  dst=any                ← 남은 모두 차단

Stateful Firewall

연결 테이블 (state table / conntrack) 유지. 첫 패킷의 outbound 규칙이 통과하면 관련 return traffic 은 자동 허용.

특징

한 방향만 규칙 정의: return 은 자동
연결 추적: TCP handshake, 진행 상태 인지
UDP 유사 처리: “요청/응답” 쌍을 시간 window 로 추적
ICMP 도 매칭: request/reply
리소스 사용: 연결당 상태 테이블 엔트리

규칙 예시 (stateful)

같은 웹 브라우징:

Outbound:  ALLOW  proto=TCP  dst=any:443

Inbound 규칙 불필요. 방화벽이 outbound 시 연결 등록 -> return 자동 인식.

Connection Tracking 상태

Linux netfilter conntrack 이 관리하는 상태:

NEW: 첫 패킷 (SYN)
ESTABLISHED: 3-way handshake 완료, 데이터 전송 중
RELATED: 기존 연결의 파생 (FTP data 등)
INVALID: 알 수 없는 상태
UNTRACKED: 추적 안 함

방화벽 규칙에서 state ESTABLISHED,RELATED 는 자동 허용의 근간.

Stateful vs Stateless 비교

특성	Stateless	Stateful
연결 인식	X	O
양방향 규칙	명시 필요	자동
에페메랄 포트	별도 처리	자동
메모리 사용	낮음	연결당
성능	빠름	상태 테이블 조회
DDoS 저항	강함 (상태 소진 안 됨)	상태 테이블 소진 가능
관리 편의	규칙 많고 복잡	규칙 적고 명확
디버깅	규칙 매칭 만	상태 + 규칙

AWS VPC 의 두 계층

VPC 는 두 방화벽 계층 을 정의:

Security Group (SG) - Stateful

인스턴스 (ENI) 단위
화이트리스트 (allow only): 명시 허용, 나머지 deny
Stateful: 응답 자동 허용
인바운드 + 아웃바운드 규칙
기본: 모든 outbound 허용, 모든 inbound 차단
여러 SG 를 한 ENI 에 붙일 수 있음 (union)

Network ACL (NACL) - Stateless

서브넷 단위
allow / deny 둘 다 (블랙리스트 가능)
Stateless: 응답도 명시 규칙 필요
번호 순서 매칭 (낮은 번호 우선)
기본 NACL: all in/out 허용. Custom NACL: 기본 all deny.

SG vs NACL 상세 비교

특성	Security Group	Network ACL
범위	ENI (인스턴스)	서브넷
상태	Stateful	Stateless
규칙 유형	Allow only	Allow + Deny
평가 순서	모든 규칙 (union)	번호 순 (첫 매칭)
기본 정책	Deny (in), Allow (out)	(Default NACL) Allow all
적용	인스턴스 시작 시 or 연결	자동 (서브넷)
개수 제한	ENI 당 5 SG (기본)	서브넷 당 1 NACL
규칙 개수	SG 당 60 (기본)	NACL 당 20 (기본)
참조	다른 SG 참조 가능	IP CIDR 만
로깅	VPC Flow Logs (간접)	마찬가지

Stateful/Stateless 실전 시나리오

시나리오 1: 웹 서버가 인터넷에서 요청 받기

Security Group (stateful):

Inbound:   ALLOW  TCP 80,443  from 0.0.0.0/0
Outbound:  ALLOW  ALL         to   0.0.0.0/0   (기본)

응답 자동 허용. 끝.

Network ACL (stateless):

Inbound:   100 ALLOW  TCP 80,443       from 0.0.0.0/0
           110 ALLOW  TCP 1024-65535   from 0.0.0.0/0   ← 서버 -> 클라 응답 (예:패키지 다운로드) 인바운드
Outbound:  100 ALLOW  TCP 80,443       to   0.0.0.0/0   (server-side 응답)

Actually with servers, the pattern is:
Inbound:   100 ALLOW  TCP 80,443       from 0.0.0.0/0    (client → server 요청)
           110 ALLOW  TCP 1024-65535   from 0.0.0.0/0    (server → client 응답의 대칭 트래픽 아님)
Outbound:  100 ALLOW  TCP 1024-65535   to   0.0.0.0/0    (server → client 응답, 에페메랄 dst)
           110 ALLOW  TCP 80,443       to   0.0.0.0/0    (서버가 outbound 요청 시)

Stateless 는 응답까지 명시 필요 = 에페메랄 포트 범위 허용 필수.

시나리오 2: 서버가 외부 API 호출

Server (10.0.1.5) → api.example.com:443

Security Group (stateful): outbound TCP 443 만. NACL: outbound TCP 443 + inbound TCP 1024-65535 (에페메랄).

시나리오 3: DDoS 방어

Stateless NACL: 알려진 악의 IP 블랙리스트 (Deny 규칙). SG 는 deny 없음.
Stateful SG: 정상 트래픽 허용, 나머지 차단.

두 계층 병행.

Defense in Depth (심층 방어)

VPC 는 두 방화벽 계층 + 추가:

Internet
  ↓
[AWS WAF / Shield]              ← Layer 7 / DDoS
  ↓
[Route 53 / CloudFront]         ← DNS / Edge
  ↓
[Application Load Balancer]     ← LB SG
  ↓
[NACL (Subnet)]                 ← Layer 3/4 stateless
  ↓
[Security Group (ENI)]          ← Layer 3/4 stateful
  ↓
[Host firewall (iptables)]      ← OS 수준
  ↓
[Application-level auth]        ← 앱 인증

각 계층은 독립. 한 계층 실패해도 다른 계층 방어.

다른 방화벽 예

Stateless

AWS NACL
iptables INPUT chain without conntrack
AWS Global Accelerator flow rules
초기 라우터 ACL

Stateful

AWS Security Group
AWS Network Firewall (stateful engine)
iptables + conntrack (Linux 기본)
pf (BSD), nftables
Palo Alto, Fortinet, Check Point (모든 next-gen firewall)
Windows Firewall

연결 테이블 크기

Stateful 은 연결당 메모리:

Linux conntrack: ~300 bytes/entry
100만 연결 = ~300 MB
DDoS: 대량 half-open 연결로 테이블 소진 유발

방어:

nf_conntrack_max 증가
SYN cookies (Linux 기본)
짧은 timeout

AWS Network Firewall (2020+)

VPC 안의 관리형 방화벽 서비스. Stateful + Stateless 둘 다 지원.

Stateless rule engine: 5-tuple 매칭 (Suricata syntax 지원)
Stateful rule engine: 연결 추적, Suricata 규칙 (IDS/IPS)
TLS SNI 검사: 도메인 기반 필터
위협 인텔리전스: AWS managed feeds
Gateway Load Balancer 통합: 3rd-party appliance 뒤에

Advanced 시나리오: NACL/SG 로 부족한 딥 검사.

함정

[!WARNING] NACL 는 stateless. 응답 트래픽 별도 허용 필수. Ephemeral port range (1024-65535 또는 32768-61000) 열어야.

[!CAUTION] SG 는 모든 규칙 union. 여러 SG 붙이면 허용이 OR. 잘못 붙이면 예상보다 넓게 허용.

[!WARNING] SG deny 규칙 없음. Whitelist 만. 특정 IP 차단은 NACL 로.

[!IMPORTANT] NACL 규칙 번호는 sparse 하게 (100, 200, 300). 나중 규칙 삽입 여지.

[!CAUTION] NACL 순서가 중요. 낮은 번호가 먼저 매칭. Deny 를 아래 두면 위 allow 가 우선.

[!WARNING] Return traffic 잘 몰라서 NACL “AllowAll” 로 두는 실수. Stateless 라서 그렇게 두면 방어 무의미.

[!IMPORTANT] SG 는 인스턴스 재부팅 없이 즉시 변경. NACL 도 마찬가지. 신속한 대응 가능.

[Network] gRPC: HTTP/2 + Protobuf, 4가지 streaming 패턴

koa (김신건) — Thu, 25 Jun 2026 00:00:00 GMT

정의

gRPC 는 HTTP/2 위에서 Protobuf 직렬화 로 동작하는 고성능 RPC 프레임워크. Google 내부 Stubby 의 오픈소스 후계.

핵심 4가지:

Protobuf: IDL + binary 직렬화 (JSON 대비 수배 작고 빠름)
HTTP/2: multiplexing + binary framing
Streaming 4종: unary, server-stream, client-stream, bidi
Code generation: .proto → 다국어 stub 자동 생성

Proto 정의

syntax = "proto3";
package shop.v1;

service Shop {
  // Unary: 1 req → 1 res
  rpc GetItem(GetItemRequest) returns (Item);

  // Server streaming: 1 req → N res
  rpc ListItems(ListRequest) returns (stream Item);

  // Client streaming: N req → 1 res
  rpc UploadEvents(stream Event) returns (UploadAck);

  // Bidirectional: N req ↔ N res
  rpc Chat(stream Message) returns (stream Message);
}

message Item {
  string id = 1;
  string name = 2;
  int32 price_cents = 3;
}

4가지 Streaming 패턴

flowchart TB
    subgraph Unary["Unary RPC"]
        U1[Client] -->|1 request| U2[Server]
        U2 -->|1 response| U1
    end
    subgraph ServerStream["Server Streaming"]
        S1[Client] -->|1 request| S2[Server]
        S2 -->|stream of N| S1
    end
    subgraph ClientStream["Client Streaming"]
        C1[Client] -->|stream of N| C2[Server]
        C2 -->|1 response| C1
    end
    subgraph BiDi["Bidirectional Streaming"]
        B1[Client] -->|stream of N| B2[Server]
        B2 -->|stream of M| B1
    end

패턴	사용
Unary	일반 API
Server stream	라이브 피드, log tail, 실시간 시세
Client stream	파일 업로드, 이벤트 일괄 전송
Bidi stream	채팅, 게임, 협업

HTTP/2 위 동작

{}

:method = POST
:scheme = https
:path = /shop.v1.Shop/GetItem
:authority = api.example.com
content-type = application/grpc
grpc-encoding = gzip
grpc-accept-encoding = identity,deflate,gzip
grpc-timeout = 1S

<protobuf-encoded body>

각 RPC = HTTP/2 stream 하나. Trailers 로 grpc-status, grpc-message 전달.

Status Code

코드	의미
0 OK	성공
1 CANCELLED	클라이언트가 cancel
2 UNKNOWN	정체불명 에러
3 INVALID_ARGUMENT	입력 오류
4 DEADLINE_EXCEEDED	timeout
5 NOT_FOUND	리소스 없음
6 ALREADY_EXISTS	중복
7 PERMISSION_DENIED	권한
8 RESOURCE_EXHAUSTED	quota 초과
9 FAILED_PRECONDITION	사전조건 위배
10 ABORTED	동시성 충돌
11 OUT_OF_RANGE	범위 외
12 UNIMPLEMENTED	구현 안됨
13 INTERNAL	내부 에러
14 UNAVAILABLE	일시 불가, retry 권장
15 DATA_LOSS	손실
16 UNAUTHENTICATED	인증 실패

[!IMPORTANT] UNAVAILABLE (14) 만 retry 안전. DEADLINE_EXCEEDED (4) 는 side effect 가 발생했을 수 있어 idempotent operation 만 retry.

Deadline (timeout)

# Python
response = stub.GetItem(req, timeout=1.0)  # 1초

# 또는 metadata
metadata = (("grpc-timeout", "1S"),)

클라이언트의 deadline 은 서버에 전파 (header). 서버가 더 깊은 RPC 를 부르면 남은 deadline 만 전달. 분산 timeout chaining.

gRPC vs REST

항목	gRPC	REST
Wire 포맷	Binary (Protobuf)	Text (JSON)
크기	수배 작음	크다
Schema	IDL 필수	옵션 (OpenAPI)
Streaming	4 모드	SSE / WebSocket 별도
브라우저 직접 호출	grpc-web 필요	기본 지원
Debugging	도구 필요	curl 가능
캐싱	직접 구현	HTTP cache
Mobile / IoT	유리	OK

내부 microservice 통신 → gRPC. 외부 public API → REST/GraphQL.

gRPC-Web

브라우저는 HTTP/2 trailer 미지원 → Envoy / proxy 가 gRPC ↔ gRPC-Web 변환:

flowchart LR
    Browser -->|gRPC-Web<br/>over HTTP/1.1| Envoy
    Envoy -->|gRPC<br/>over HTTP/2| Backend

흔한 함정

[!WARNING]

Field number 재사용 = proto 의 tag 번호 가 wire format 의 identity. 한 번 쓴 번호 영구히 reserved.

required 필드 = proto2 의 legacy. proto3 는 모든 필드가 optional 류. required 사용 금지.

string vs bytes = string 은 UTF-8 검증. binary 데이터는 bytes.

stream 의 완료 표시 = 클라이언트 stream 은 반드시 half-close (closeSend) 해야 서버가 finalize.

Interceptor (미들웨어)

# Python: 서버 interceptor, 인증 검사
class AuthInterceptor(grpc.ServerInterceptor):
    def intercept_service(self, continuation, handler_call_details):
        metadata = dict(handler_call_details.invocation_metadata)
        if metadata.get('authorization') != 'Bearer valid-token':
            def deny(request, context):
                context.abort(grpc.StatusCode.UNAUTHENTICATED, 'Invalid token')
            return grpc.unary_unary_rpc_method_handler(deny)
        return continuation(handler_call_details)

Interceptor = gRPC 의 미들웨어. 인증, 로깅, 메트릭, retry 등 횡단 관심사 처리. 체인 가능.

Metadata (Header 역할)

# 클라이언트: metadata 전송
metadata = [
    ('request-id', 'abc-123'),
    ('x-tenant-id', 'org-1'),
]
response = stub.GetItem(req, metadata=metadata)

# 서버: metadata 수신
def GetItem(self, request, context):
    md = dict(context.invocation_metadata())
    tenant = md.get('x-tenant-id')
    ...

Metadata = HTTP 헤더 역할. 요청마다 전달되며 Interceptor 에서도 읽기 가능.

Health Check Protocol

// grpc.health.v1.Health 표준
service Health {
  rpc Check(HealthCheckRequest) returns (HealthCheckResponse);
  rpc Watch(HealthCheckRequest) returns (stream HealthCheckResponse);
}

# K8s 1.24+ 네이티브 gRPC probe
livenessProbe:
  grpc:
    port: 50051
    service: shop.v1.Shop
  initialDelaySeconds: 5

grpc_health_probe -addr=:50051 -service=shop.v1.Shop

Load Balancing

flowchart LR
    Client --> Envoy["Envoy / L7 LB"]
    Envoy -->|round-robin| B1[Backend 1]
    Envoy -->|round-robin| B2[Backend 2]
    Envoy -->|round-robin| B3[Backend 3]

HTTP/2 multiplexing 때문에 TCP 레벨 (L4) LB 는 단일 서버로 몰림. L7 LB 또는 클라이언트 사이드 LB 필요.

방식	설명	사용
클라이언트 사이드	DNS 조회 후 round-robin	gRPC core 기본 지원
Envoy proxy	sidecar 패턴, Istio	서비스 메시 환경
K8s HeadlessService	Pod IP 직접 노출	클라이언트 LB 와 조합

ConnectRPC (gRPC 대안)

ConnectRPC (buf.build) = HTTP/1.1, HTTP/2 모두 지원. curl 로 테스트 가능. gRPC 호환. 브라우저 직접 호출 (grpc-web proxy 불필요). 2026 시점 생태계 성장 중.

[Network] HTTP/1.1: keep-alive, pipelining, chunked transfer

koa (김신건) — Thu, 25 Jun 2026 00:00:00 GMT

정의

HTTP/1.1 (1997, RFC 9112 으로 재정리) 는 텍스트 기반 stateless request/response 프로토콜. 2026 시점에도 대부분의 트래픽이 HTTP/1.1 + 일부 HTTP/2/3 분포.

핵심 진화 (HTTP/1.0 대비):

기능	HTTP/1.0	HTTP/1.1
기본 연결	매 요청 새 TCP	Persistent (keep-alive)
Host 헤더	옵션	필수 (가상호스팅)
Chunked transfer	없음	있음
캐시 제어	`Expires`	`Cache-Control`
부분 요청	없음	Range / 206 Partial Content

메시지 구조

{}

GET /api/users/42 HTTP/1.1
Host: api.example.com
User-Agent: curl/8.1
Accept: application/json

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

{"id":42,"name":"koa","tier":"pro"}

Keep-Alive (Persistent Connection)

{}

Connection: keep-alive 헤더로 TCP 연결 재사용. 한 연결에서 여러 요청/응답. TLS 핸드셰이크 비용 절감의 결정적 기능.

sequenceDiagram
    autonumber
    participant C as Client
    participant S as Server

    C->>S: TCP SYN / handshake (3-way)
    S-->>C: SYN-ACK
    C->>S: GET /a
    S-->>C: 200 OK (Connection: keep-alive)
    C->>S: GET /b (같은 TCP)
    S-->>C: 200 OK
    C->>S: GET /c (같은 TCP)
    S-->>C: 200 OK
    Note over C,S: idle timeout (예: 60s) 후 close

헤더 / 설정	의미
`Connection: keep-alive`	연결 재사용 (HTTP/1.1 기본)
`Connection: close`	응답 후 즉시 close
`Keep-Alive: timeout=60, max=100`	idle 60s, max 100 요청

[!TIP] 서버 (nginx, ELB) 의 idle timeout 과 클라이언트 connection pool TTL 의 불일치가 간헐적 connection reset 의 가장 흔한 원인. 보통 클라이언트 < 서버 로 잡는다.

Pipelining (구현 함정)

같은 연결에서 응답을 기다리지 않고 여러 요청 동시 전송. Head-of-Line Blocking 문제 → 실전 거의 사용 안 됨.

요청: A → B → C → D (즉시 연속)
응답: A → B → C → D (반드시 순서대로)

문제: A 가 느리면 B/C/D 도 모두 대기

→ HTTP/2 의 multiplexing 이 이 문제를 프레임 인터리빙 으로 해결. 자세한 건 [[head-of-line-blocking]] / [[HTTP/2]].

HTTP Method 의미론

Method	멱등	안전	용도
`GET`	O	O	리소스 조회
`HEAD`	O	O	헤더만 조회 (본문 없음)
`OPTIONS`	O	O	허용 메서드 확인 (CORS preflight)
`PUT`	O	X	리소스 전체 교체
`DELETE`	O	X	리소스 삭제
`POST`	X	X	리소스 생성 / 액션
`PATCH`	X	X	리소스 부분 수정

멱등 (idempotent): 같은 요청을 여러 번 보내도 결과 동일
안전 (safe): 서버 상태를 변경하지 않음

[!IMPORTANT] PUT 은 전체 교체, PATCH 는 부분 수정. REST API 에서 혼용하면 클라이언트가 누락 필드를 null 로 덮어쓰는 버그 발생.

Content-Length vs Chunked

본문 끝을 알리는 두 가지 방법:

# 1. Content-Length (크기 미리 알 때)
HTTP/1.1 200 OK
Content-Length: 12345

<12345 bytes>

# 2. Transfer-Encoding: chunked (streaming)
HTTP/1.1 200 OK
Transfer-Encoding: chunked

7\r\n
Mozilla\r\n
9\r\n
Developer\r\n
0\r\n
\r\n

방식	동작	사용
`Content-Length`	정확한 바이트 수	정적 파일, 작은 응답
`chunked`	청크 단위 전송	streaming (SSE, long-poll, 대용량 응답)

[!IMPORTANT] 동일 응답에 두 방식 모두 설정 하면 RFC 위반. 일부 프록시는 chunked 우선, 일부는 Content-Length 우선 → HTTP Request Smuggling 공격의 토대. 항상 하나만.

상태 코드 카테고리

범위	의미	대표
1xx	Informational	`100 Continue`, `101 Switching Protocols`
2xx	Success	`200 OK`, `201 Created`, `204 No Content`, `206 Partial Content`
3xx	Redirection	`301 Moved Permanently`, `302 Found`, `304 Not Modified`, `307 Temporary Redirect`, `308 Permanent Redirect`
4xx	Client Error	`400 Bad Request`, `401 Unauthorized`, `403 Forbidden`, `404 Not Found`, `409 Conflict`, `422 Unprocessable`, `429 Too Many Requests`
5xx	Server Error	`500`, `502 Bad Gateway`, `503 Service Unavailable`, `504 Gateway Timeout`

[!NOTE] 307/308 vs 302/301 의 핵심 차이: 307/308 은 HTTP method 를 보존. POST → 302 → GET 의 옛 클라이언트 동작 이 307 에서는 POST → POST.

Range Requests (206 Partial Content)

대용량 파일 다운로드 재개, 동영상 seek 에 사용:

# 요청: 0~999 바이트
GET /video.mp4 HTTP/1.1
Range: bytes=0-999

# 응답
HTTP/1.1 206 Partial Content
Content-Range: bytes 0-999/50000000
Content-Length: 1000

<1000 bytes>

서버가 Range 를 지원하면 Accept-Ranges: bytes 헤더를 응답에 포함. 지원 안 하면 200 OK 로 전체 응답.

Content Negotiation

클라이언트가 선호 포맷 / 언어 / 인코딩 을 헤더로 협상:

Accept: application/json, text/html;q=0.9, */*;q=0.8
Accept-Language: ko-KR, ko;q=0.9, en;q=0.8
Accept-Encoding: gzip, br, deflate

헤더	의미
`Accept`	응답 MIME 타입 선호도
`Accept-Language`	언어 선호도
`Accept-Encoding`	압축 방식 (gzip, br)
`Content-Type`	실제 응답 타입
`Content-Encoding`	실제 압축 방식

[!TIP] br (Brotli) 는 gzip 대비 20-30% 더 압축. 모던 브라우저 + HTTPS 환경에서 br 우선 설정 권장. nginx: brotli on; brotli_comp_level 6;

Cache 헤더 (HTTP/1.1 의 가장 큰 진화)

Cache-Control: public, max-age=3600, must-revalidate
ETag: "abc123"
Last-Modified: Wed, 25 Jun 2026 12:00:00 GMT

flowchart LR
    A[클라이언트<br/>If-None-Match: abc123] --> B[서버]
    B -->|ETag 일치| C[304 Not Modified<br/>body 없음]
    B -->|ETag 불일치| D[200 OK<br/>새 본문 + 새 ETag]

자세한 캐시 패턴은 [[network-http-caching]] 참고.

HTTP 인증 기초

# 서버가 인증 요구
HTTP/1.1 401 Unauthorized
WWW-Authenticate: Bearer realm="api"

# 클라이언트 재요청
GET /api/me HTTP/1.1
Authorization: Bearer eyJhbGci...

스킴	특징
`Basic`	Base64 인코딩 (HTTPS 필수)
`Bearer`	JWT / OAuth 토큰
`Digest`	해시 기반 (거의 미사용)
`API-Key`	커스텀 헤더 (`X-API-Key`)

[!WARNING] Authorization 헤더는 브라우저 캐시에 저장되지 않음. 반면 쿠키는 HttpOnly + Secure + SameSite=Strict 설정 시 XSS / CSRF 방어.

흔한 함정

[!WARNING]

Host 헤더 누락 = HTTP/1.1 에서 400 Bad Request. 가상호스팅 때문에 필수.

Content-Length 거짓말 = 본문이 짧으면 클라이언트가 무한 대기, 길면 다음 요청과 섞임 (smuggling).

Connection: close 남발 = TCP/TLS 비용 폭증. 명시적 이유 없으면 기본 keep-alive.

Cache-Control: no-cache 와 no-store 혼동 = no-cache 는 재검증 필요, no-store 는 저장 자체 금지.

[Network] HTTP/2: multiplexing, HPACK, server push의 종말

koa (김신건) — Thu, 25 Jun 2026 00:00:00 GMT

정의

HTTP/2 (2015, RFC 9113) 는 HTTP/1.1 의 문법은 유지하되 전송을 바이너리 + 멀티플렉싱 으로 바꾼다. Head-of-Line Blocking (HTTP 레벨) 해결이 핵심.

핵심 변경 3가지:

Binary framing: 텍스트 → 바이너리. 파싱 효율 + 정확성.
Stream multiplexing: 한 TCP 연결에서 여러 stream 병렬.
HPACK 헤더 압축: 반복 헤더의 압축 + 인덱싱.

Binary Framing

HTTP/1.1 의 텍스트 메시지 가 frame 으로 분해:

Frame Type	의미
`DATA`	본문
`HEADERS`	헤더
`PRIORITY`	스트림 우선순위
`RST_STREAM`	스트림 취소
`SETTINGS`	연결 설정
`PUSH_PROMISE`	server push (대부분 비활성)
`PING`	keep-alive 측정
`GOAWAY`	연결 종료
`WINDOW_UPDATE`	flow control
`CONTINUATION`	큰 헤더 분할

flowchart LR
    H1["HTTP/1.1 메시지<br/>(텍스트)"] -->|HTTP/2| Frames
    Frames["[HEADERS frame]<br/>[DATA frame]<br/>[DATA frame]"]

Multiplexing

{}

한 TCP 연결에서 여러 stream (요청/응답 쌍) 이 frame 인터리빙 으로 동시 진행:

sequenceDiagram
    autonumber
    participant C as Client
    participant S as Server

    C->>S: HEADERS stream=1 (GET /a)
    C->>S: HEADERS stream=3 (GET /b)
    C->>S: HEADERS stream=5 (GET /c)
    S-->>C: HEADERS stream=3 (작은 응답 먼저)
    S-->>C: DATA stream=3 (완료)
    S-->>C: HEADERS stream=1
    S-->>C: DATA stream=5 (부분)
    S-->>C: DATA stream=1 (부분)
    S-->>C: DATA stream=1 (완료)
    S-->>C: DATA stream=5 (완료)

항목	HTTP/1.1	HTTP/2
동시 요청	N개 TCP 연결	1 TCP, N streams
HoL Blocking (HTTP)	있음 (pipelining)	없음
헤더 압축	없음	HPACK
Binary	텍스트	binary

[!IMPORTANT] Multiplexing 은 HTTP 레벨의 HoL blocking 만 해결. TCP 패킷 손실 이 발생하면 그 아래 모든 stream 이 대기. 이 한계가 HTTP/3 (QUIC) 의 등장 이유.

HPACK 헤더 압축

반복되는 헤더 (User-Agent, Cookie 등) 를 인덱스로 참조. Static Table (61개 미리 정의) + Dynamic Table (연결마다 갱신) + Huffman.

요청 1: :method=GET, :path=/a, user-agent=Mozilla/5.0...
→ 보내고 dynamic table 에 등록 (예: index 62)

요청 2: :method=GET, :path=/b, user-agent=Mozilla/5.0...
→ index 62 만 보냄 (수십 바이트 → 1 바이트)

자세한 건 [[hpack]] 참고.

[!CAUTION] CRIME / BREACH 공격 의 변형 (HPACK 압축 oracle). 일반적으로 안전하지만, 비밀 헤더 + 사용자 입력이 같은 응답 에 들어가면 위험.

Server Push (사실상 폐기)

/index.html 요청에 서버가 미리 /style.css, /app.js 도 push:

sequenceDiagram
    C->>S: GET /index.html
    S-->>C: PUSH_PROMISE /style.css
    S-->>C: PUSH_PROMISE /app.js
    S-->>C: 200 /index.html
    S-->>C: 200 /style.css (요청 없이 미리)
    S-->>C: 200 /app.js (요청 없이 미리)

[!WARNING] 2022 Chrome 이 server push 를 제거. push 캐시 적중률이 낮고 bandwidth 낭비 + priority 충돌. 2026 시점 server push 는 사실상 죽은 기능. 대신 103 Early Hints + <link rel=preload> 패턴.

h2 vs h2c

프로토콜	의미
`h2`	TLS 위 HTTP/2 (대부분)
`h2c`	cleartext (내부 네트워크, gRPC mesh)

브라우저는 h2 만. 서버끼리는 h2c 도 흔함 (TLS 종료를 가까운 sidecar/proxy 에서).

Flow Control

스트림 / 연결마다 window size. WINDOW_UPDATE 로 backpressure. TCP 의 sliding window 와 별개 application 레벨 제어.

flowchart LR
    Server -->|WINDOW_UPDATE +65535| Client
    Client -->|"DATA (window 안에서만)"| Server

흔한 함정

[!WARNING]

다수 TCP 연결의 습관 = HTTP/2 환경에서 6 connections per origin 같이 옛 패턴을 유지하면 멀티플렉싱 효과 0.

Connection, Upgrade, Proxy-Connection 헤더 = HTTP/2 에서 금지된 헤더. 보내면 연결 RST.

Priority 잘못 설정 = 일부 클라이언트가 priority frame 무시. RFC 9218 의 priority hints 가 더 신뢰.

PUSH 의존 코드 = 위 server push 폐기 때문에 fallback 필수.

Connection Preface

HTTP/2 연결의 첫 24 바이트 = magic octets:

PRI * HTTP/2.0\r\n\r\nSM\r\n\r\n

이후 클라이언트 SETTINGS frame 전송. h2c (cleartext) 직접 연결 식별에 사용. h2 (TLS+ALPN) 에서는 ALPN 협상 후 magic 전송.

ALPN 협상

HTTP/2 를 사용하려면 TLS 핸드셰이크 중 ALPN (Application-Layer Protocol Negotiation) 으로 버전 협상.

sequenceDiagram
    participant C as Client
    participant S as Server
    C->>S: TLS ClientHello + ALPN: h2, http/1.1
    S-->>C: TLS ServerHello + ALPN: h2
    Note over C,S: 이후 HTTP/2 바이너리 프레임 교환

식별자	의미
`h2`	TLS 위 HTTP/2 (브라우저 표준)
`h2c`	Cleartext HTTP/2 (내부망, gRPC mesh)
`http/1.1`	ALPN fallback (h2 미지원 시)

서버 설정 예:

Nginx: listen 443 ssl; http2 on; (nginx 1.26+ 권장)
Caddy: 자동 ALPN 협상 (별도 설정 불필요)
Go net/http: h2.ConfigureServer 또는 기본 TLS 서버
Java Netty: ApplicationProtocolNegotiationHandler

Stream 상태 머신

각 HTTP/2 stream 은 상태 머신. RST_STREAM 으로 언제든지 즉시 취소.

stateDiagram-v2
    [*] --> idle
    idle --> open : HEADERS 전송 또는 수신
    open --> half_closed_local : END_STREAM 전송
    open --> half_closed_remote : END_STREAM 수신
    half_closed_local --> closed : RST_STREAM 또는 END_STREAM 수신
    half_closed_remote --> closed : RST_STREAM 또는 END_STREAM 전송
    open --> closed : RST_STREAM
    closed --> [*]

상태	의미
`idle`	미사용. 클라이언트 = 홀수 ID, 서버 push = 짝수 ID
`open`	양방향 송수신 가능
`half_closed_local`	로컬 전송 완료, 수신만
`half_closed_remote`	원격 전송 완료, 송신만
`closed`	완전 종료. ID 재사용 불가

[!NOTE] 스트림 ID 는 단조 증가. 연결 수명 동안 최대 2^31 개. 한도 도달 시 GOAWAY 로 연결 재시작.

gRPC 와 HTTP/2

gRPC 는 HTTP/2 를 전송 계층으로 사용. Protobuf 를 DATA frame 에 실어 보낸다.

flowchart LR
    Caller["gRPC Caller<br/>Protobuf 직렬화"]
    Caller --> H2["HTTP/2 DATA frames"]
    H2 --> Mux["Stream Multiplexing<br/>단일 TCP 연결"]
    Mux --> Svr["gRPC Server<br/>Protobuf 역직렬화"]

HTTP/2 개념	gRPC 매핑
stream 1개	RPC 호출 1개
`HEADERS` frame	gRPC metadata, trailer
`DATA` frame	Protobuf payload
`RST_STREAM`	오류 취소
`SETTINGS: MAX_CONCURRENT_STREAMS`	최대 동시 RPC 수 제한

gRPC 4가지 통신 모드:

모드	방향	적합 예
Unary	1:1	단순 API 호출
Server streaming	1:N	실시간 피드, 로그 스트림
Client streaming	N:1	파일 업로드, 배치 수집
Bidirectional streaming	N:N	채팅, 협업, 게임

[!WARNING] L4 LB 앞 gRPC: 1 TCP 연결 = 1 백엔드 고착 → 편향 분산. L7 gRPC-aware LB (Envoy, Istio, k8s Ingress) 로 stream 레벨 분산 필요. 자세히는 [[grpc]].

HTTP/2 vs HTTP/3 빠른 비교

항목	HTTP/2	HTTP/3
전송 계층	TCP	QUIC (UDP 기반)
HoL Blocking	TCP 패킷 손실 시 전 스트림 대기	스트림별 독립 (없음)
헤더 압축	HPACK (dynamic table)	QPACK
0-RTT 재개	없음	있음 (session ticket)
배포 성숙도	광범위	CDN, 모던 브라우저 지원 확대 중

자세히는 [[http-3]] 참고.

실전 체크리스트

항목	확인 방법
h2 협상 여부	`curl -I --http2 https://example.com`
ALPN 선택값	`openssl s_client -alpn h2 -connect example.com:443`
Chrome h2 세션	`chrome://net-internals/#http2`
금지 헤더 제거	`Connection`, `Upgrade`, `Keep-Alive` 없애기
Server push 제거	`http2_push` 지시자 제거, `103 Early Hints` 로 대체
gRPC LB	Envoy 또는 client-side LB 적용
우선순위 힌트	RFC 9218 Extensible Priorities (Urgency, Incremental 헤더)

[Network] Load Balancer: L4 vs L7, 알고리즘, sticky session

koa (김신건) — Thu, 25 Jun 2026 00:00:00 GMT

정의

Load Balancer 는 트래픽을 여러 백엔드로 분산 하는 인프라. 수평 확장 + 가용성 + 무중단 배포 의 토대.

{}

L4 vs L7

구분	L4 (Transport)	L7 (Application)
본 계층	TCP/UDP	HTTP/gRPC/WebSocket
보는 정보	IP + port	URL, 헤더, 쿠키, body
처리 비용	가벼움	무거움 (parse)
기능	단순 분산	path/header routing, rewrite, auth, rate limit
TLS 종료	옵션 (passthrough 가능)	보통 종료 후 분배
예	AWS NLB, HAProxy TCP, IPVS	AWS ALB, nginx, Envoy, Traefik

flowchart LR
    subgraph L4
        C1[Client] -->|TCP| LB4[L4 LB]
        LB4 -->|TCP forward| B1[Backend 1]
        LB4 -->|TCP forward| B2[Backend 2]
    end
    subgraph L7
        C2[Client] -->|HTTP| LB7[L7 LB]
        LB7 -->|URL = /api| BA[API service]
        LB7 -->|URL = /static| BS[Static service]
    end

알고리즘

알고리즘	동작
Round Robin	순서대로
Weighted RR	가중치 비율
Least Connections	현재 연결 가장 적은 백엔드
Least Response Time	평균 응답 시간 가장 짧은
IP Hash	클라이언트 IP 해시 → 같은 IP 는 같은 백엔드
Consistent Hashing	hash 링 → 노드 추가/제거 시 최소 재분배
Random (P2C)	무작위 2개 중 덜 바쁜

Power of Two Choices (P2C)

flowchart LR
    R[Request] -->|random pick 2| P[Pool of N]
    P --> S1[Server A: load=5]
    P --> S2[Server B: load=8]
    P -->|선택| S1

[!TIP] 완전 random 보다 좋고 least-conn 보다 cheap. Netflix, Twitter 등 대규모 서비스의 기본.

Consistent Hashing

노드 추가/제거 시 N/M 만 재분배 (vs 일반 hash 의 전체 재분배).

flowchart LR
    Ring(("Hash Ring<br/>0 → 2^32")) --> N1[Node A<br/>at hash 100]
    Ring --> N2[Node B<br/>at hash 500]
    Ring --> N3[Node C<br/>at hash 900]
    Key1[key: hash 300] -->|시계방향| N2
    Key2[key: hash 700] -->|시계방향| N3

Sticky session, cache 라우팅, DB sharding.
virtual node (각 노드를 수십 개 ring 점) 로 분포 균등화.

Health Check

sequenceDiagram
    loop 30초마다
        LB->>Backend: GET /health
        Backend-->>LB: 200 OK
    end
    Note over Backend: 다운
    LB->>Backend: GET /health
    Backend-xLB: timeout
    Note over LB: 3회 연속 실패 → 풀에서 제외

Active: LB 가 주기 ping.
Passive: 실제 요청 실패율로 판단.
Composite: 둘 다.

[!CAUTION] Health check 가 너무 단순 (예: 200 OK 만) 하면 DB 다운인데 healthy 로 판정. deep health (DB, cache 까지 ping) vs shallow health (애플리케이션만) 의 분리.

Sticky Session

방식	동작	단점
Cookie	LB 가 쿠키 박음	쿠키 위변조 / 제거 시 깨짐
IP Hash	클라이언트 IP 기준	NAT 뒤 사용자가 같은 노드 몰림
Application	앱이 자기 ID 응답 헤더로	구현 복잡

자세한 건 [[Sticky Session]] 참고.

보안 / 옵저버빌리티

L7 LB 의 추가 능력:

TLS termination (인증서 관리)
WAF (SQLi, XSS 차단)
Rate limiting
Request/response 로깅
Header rewrite, redirect
Path-based routing
A/B testing, canary

실전 LB 선택

도구	L4/L7	사용처
AWS ALB	L7	AWS 표준 L7
AWS NLB	L4	초저지연, gRPC, WebSocket
AWS CLB	L4/L7	(legacy)
nginx	L7 (L4 옵션)	self-host 가장 흔함
HAProxy	L4/L7	고성능
Envoy	L7	service mesh, gRPC
Traefik	L7	K8s 친화
IPVS	L4	커널 모듈, 극저지연
Caddy	L7	자동 TLS

흔한 함정

[!WARNING]

WebSocket 의 idle timeout = ALB 60s default 가 silent close. ping/pong 으로.

gRPC 의 long-lived HTTP/2 연결 = L4 LB 의 connection 단위 분산 때문에 불균등 분포. gRPC 자체 load balancing (Envoy, GRPC client-side LB) 필요.

Health check 의 서버 자살 = HC 자체가 부하 → 서버 다운. 분리된 endpoint + 경량 응답.

Sticky session + auto-scaling = scale-in 시 stuck 사용자 세션 손실. 세션을 외부 store (Redis) 로 옮기는 게 정통.

Connection Draining (드레이닝)

배포/유지보수 시 서버를 안전하게 풀에서 제거하는 과정.

sequenceDiagram
    participant LB as Load Balancer
    participant Old as Old Server
    participant New as New Server
    LB->>Old: 새 연결 중단 신호
    LB->>New: 새 연결 전달
    Old-->>LB: 진행 중 요청 처리 완료 대기
    Old-->>LB: 완전 종료
    Note over LB,Old: grace period 30-60s 내 완료

AWS ALB: deregistration delay (default 300s, 조정 가능)
Kubernetes: terminationGracePeriodSeconds + readiness probe 제거
드레이닝 없이 즉시 종료 = 진행 중 요청 손실.

Blue-Green 배포 / Canary 배포

LB 는 무중단 배포의 핵심 인프라.

flowchart LR
    LB[Load Balancer]
    Blue["Blue v1.0<br/>기존 버전"]
    Green["Green v1.1<br/>신 버전"]
    LB -->|"100% → 0%"| Blue
    LB -->|"0% → 100%"| Green

전략	설명	롤백 속도
Blue-Green	동시 운영, 트래픽 전환	즉시
Canary	소수 % 부터 점진 증가	비율 감소
Rolling	순차 교체 (구/신 혼재)	느림
Shadow	복제 트래픽, 결과 비교	없음

[!TIP] Canary 기준 지표: 에러율, P99 지연, 비즈니스 메트릭. 이상 감지 시 자동 롤백 (Argo Rollouts, Flagger).

DSR (Direct Server Return)

트래픽 반환 경로를 LB 를 거치지 않고 서버에서 클라이언트로 직접 전달.

flowchart LR
    Client -->|"요청 via LB"| LB["L4 LB"]
    LB -->|"포워딩 (DIP to RIP)"| Server
    Server -->|"응답 직접 반환"| Client

응답 트래픽 (보통 요청 대비 10x 이상) 이 LB 를 우회 → LB 처리량 병목 해소.
주로 L4 LB (IPVS, HAProxy) 에서 구현.
서버가 VIP (Virtual IP) 를 loopback 에 설정해야 함.

Global LB vs Regional LB

구분	Global LB	Regional LB
역할	DNS 기반 지역 선택	지역 내 서버 분산
지연 최적화	GeoDNS + anycast	지역 내 최적
예	AWS Route 53, Cloudflare	AWS ALB, nginx
페일오버 단위	지역 전체 이전	서버 단위

flowchart TD
    User[글로벌 사용자]
    User --> DNS["GeoDNS / Anycast"]
    DNS --> RegionA["Region A (서울) ALB"]
    DNS --> RegionB["Region B (도쿄) ALB"]
    RegionA --> SA1[Server A1]
    RegionA --> SA2[Server A2]
    RegionB --> SB1[Server B1]

[!CAUTION] DNS TTL 이 길면 지역 이전 시 일부 사용자가 오래된 IP 를 캐시. TTL 60-120s 권장. Active-Active 구성에서 데이터 동기화 전략 필수.

클라이언트 사이드 LB

인프라 LB 대신 클라이언트가 서버 목록을 직접 관리하여 선택.

구분	서버 사이드 LB	클라이언트 사이드 LB
예	AWS ALB, nginx	gRPC, Ribbon (Netflix)
장점	투명, 단순	레이턴시 1 hop 감소
단점	중앙 병목 가능	클라이언트 복잡도
서버 목록	LB 가 관리	서비스 레지스트리 (Consul, etcd)

[!NOTE] 마이크로서비스 환경에서 gRPC 는 기본 클라이언트 사이드 LB (round-robin, pick-first). Kubernetes headless service 와 함께 사용.

실전 LB 설정 패턴

상황	권장 설정
WebSocket	idle timeout 조정 (>60s), `proxy_read_timeout` 증가
gRPC	HTTP/2 지원 LB, keepalive 설정
Auto-scaling	Connection Draining 활성화, Health check 간격 단축
무중단 배포	Blue-Green 또는 Canary + draining
세션 유지 필요	Sticky session (단, Redis 세션 스토어 권장)
초저지연	DSR 고려 (L4), IPVS

[Network] Realtime 전송 비교: Polling / SSE / WebSocket / WebRTC

koa (김신건) — Thu, 25 Jun 2026 00:00:00 GMT

정의

실시간 (서버 → 클라이언트) 데이터 전송 의 7가지 패턴 비교.

{}

결정 트리

flowchart TD
    Q1{양방향 필요?}
    Q1 -->|아니오| Q2{영속 연결 OK?}
    Q1 -->|예| Q3{브라우저 / 네이티브?}
    Q2 -->|예| SSE[SSE]
    Q2 -->|아니오| Q4{레거시 호환?}
    Q4 -->|예| LP[Long Polling]
    Q4 -->|아니오| Poll[Polling]
    Q3 -->|브라우저| WS[WebSocket]
    Q3 -->|P2P 미디어| RTC[WebRTC]

7가지 비교

패턴	방향	영속	프로토콜	사용
Short Polling	C → S	짧음	HTTP	단순 / legacy
Long Polling	C → S	짧음 (hold)	HTTP	legacy fallback
HTTP/2 server push	S → C	(폐기)	HTTP/2	(deprecated)
SSE	S → C	영속	HTTP	알림, 라이브 피드
WebSocket	양방향	영속	RFC 6455	채팅, 게임
WebTransport	양방향 (datagrams)	영속	HTTP/3 + QUIC	차세대 (실험적)
WebRTC DataChannel	양방향 (P2P)	영속	DTLS + SCTP	게임 P2P, 파일

Polling

sequenceDiagram
    loop 5초마다
        C->>S: GET /new
        S-->>C: 200 [] (변화 없음)
    end
    Note over C,S: 5초 후
    C->>S: GET /new
    S-->>C: 200 [msg1]

가장 단순. 가장 비효율적.
평균 지연 = polling 간격 / 2.
메시지 없어도 매 요청 발생 → 서버 부담.

[!CAUTION] 자주 polling = 서버 부담. 드물게 polling = 지연 큼. 둘 다 안 좋음.

Long Polling

sequenceDiagram
    C->>S: GET /new (대기 30s)
    Note over S: 이벤트 없음, hold
    Note over S: 메시지 도착!
    S-->>C: 200 [msg1]
    C->>S: GET /new (즉시 다음 요청)
    Note over S: timeout 30s
    S-->>C: 200 [] (timeout)
    C->>S: GET /new (재시도)

적은 빈도, 낮은 지연.
legacy 환경 (옛 IE, 일부 프록시) 의 fallback.
connection 점유 가 polling 보다 길다 → 서버 connection pool 압박.

SSE (단방향 영속)

자세한 건 [[SSE]] 참고.

sequenceDiagram
    C->>S: GET /stream
    S-->>C: 200 (영속)
    S-->>C: data: msg1\n\n
    S-->>C: data: msg2\n\n
    Note over C: 끊김 시 자동 재연결
    S-->>C: data: msg3\n\n

서버 → 클라이언트 일방향 충분하면 제일 단순.
자동 재연결 + Last-Event-ID 재개.
프록시 / 방화벽 친화 (HTTP).

WebSocket (양방향 영속)

자세한 건 [[WebSocket]] 참고.

sequenceDiagram
    C->>S: HTTP Upgrade (handshake)
    S-->>C: 101 Switching Protocols
    C-->>S: WS frame
    S-->>C: WS frame

양방향 + 영속. 채팅 / 게임 / 협업 / 트레이딩.
HTTP 위에서 시작하지만 별도 프레임 프로토콜.

WebTransport (실험적, 차세대)

HTTP/3 (QUIC) 위 양방향 + unreliable datagram + bidirectional streams. WebSocket + UDP datagram 의 결합.

2026 시점 모던 브라우저 지원 진입.
게임 + 라이브 영상 + AR/VR.
아직 대중적 도입 전.

WebRTC DataChannel (P2P)

{}

클라이언트 ↔ 클라이언트 직접. 서버는 signaling 만.
DTLS + SCTP 위.
P2P 게임, 파일 전송, 영상통화 보조.
NAT traversal (STUN/TURN) 복잡도.

처리량 vs 지연 vs 복잡도

WebRTC 시그널링: STUN / TURN

P2P 연결 수립을 위한 시그널링 서버 + NAT traversal.

sequenceDiagram
    participant A as Client A
    participant Sig as Signaling Server
    participant ST as STUN/TURN
    participant B as Client B
    A->>Sig: SDP Offer
    Sig->>B: SDP Offer
    B->>Sig: SDP Answer
    Sig->>A: SDP Answer
    A->>ST: STUN Binding Request
    ST-->>A: Public IP:Port
    B->>ST: STUN Binding Request
    ST-->>B: Public IP:Port
    A-->>B: ICE Candidates 교환
    Note over A,B: P2P 연결 수립

컴포넌트	역할
STUN	공인 IP:Port 탐색 (cheap, UDP)
TURN	NAT 뒤 relay (expensive, 모든 트래픽 경유)
ICE	STUN + TURN 조합으로 최적 경로 탐색
SDP	미디어 능력 / 코덱 협상

[!CAUTION] TURN 서버 없으면 Symmetric NAT (기업 방화벽) 뒤 클라이언트 연결 불가. 실서비스는 TURN 필수. TURN 비용 = 전체 트래픽 relay.

스케일링 전략

각 패턴별 서버 사이드 스케일링 고려사항:

flowchart TD
    LB[L7 Load Balancer]
    LB -->|"SSE / WebSocket"| Sticky["Sticky Session 필요"]
    LB -->|"Polling"| Stateless["완전 Stateless 분산"]
    Sticky --> Redis["Redis Pub/Sub<br/>노드 간 메시지 팬아웃"]
    Redis --> N1[Node 1]
    Redis --> N2[Node 2]
    Redis --> N3[Node 3]

패턴	스케일링 방식	핵심 도구
Polling	Stateless, 그냥 확장	없음
Long Polling	Connection 수 관리	Nginx keep-alive 튜닝
SSE	Sticky session + 팬아웃	Redis Pub/Sub
WebSocket	Sticky session + 팬아웃	Redis Pub/Sub, Socket.IO
WebRTC	시그널링 서버 분리	STUN/TURN 별도

자세히는 [[redis-pubsub-vs-streams]], [[sticky-session]].

구현 패턴 비교

기술	Node.js 서버	브라우저 클라이언트
SSE	`res.write('data: ...\n\n')`	`new EventSource('/stream')`
WebSocket	`ws`, `socket.io`, `uWebSockets.js`	`new WebSocket('wss://...')`
Long Polling	일반 HTTP, timeout 30s	`fetch` + 재시도 루프
WebRTC	`node-webrtc`, Mediasoup	`RTCPeerConnection` API

SSE 연결 한계: HTTP/1.1 = 브라우저당 도메인 6 연결 제한. HTTP/2 에서는 다중 SSE 가능.

브라우저 지원 & 제약

기능	Chrome	Firefox	Safari	IE/Edge legacy
SSE	지원	지원	지원	SSE 없음
WebSocket	지원	지원	지원	IE11 지원
WebRTC	지원	지원	지원 (iOS 제한)	미지원
WebTransport	지원 (실험)	지원 (실험)	미지원	미지원

[!NOTE] iOS Safari 는 SSE 응답 버퍼링 문제 가 있음 (iOS 14 이전). text/event-stream + 작은 청크 크기로 완화. iOS WebRTC 는 Audio 백그라운드 제한 있음.

흔한 함정

[!WARNING]

SSE + nginx 버퍼링 = 기본 response buffering 으로 메시지 지연. X-Accel-Buffering: no + proxy_buffering off 필수.

WebSocket + ALB 60s idle timeout = heartbeat ping/pong 으로 연결 유지.

WebRTC + CORS = 시그널링 서버 CORS 설정 + TURN 서버 credential 보호.

Long Polling 서버 연결 수 = 클라이언트 N명 = 서버 N개 연결 점유. non-blocking I/O (Node.js, async Python) 필수.

SSE 재연결 폭풍 = 서버 재시작 시 모든 클라이언트 동시 재연결. Last-Event-ID + jitter 로 분산.

[Network] SSE (Server-Sent Events): 단방향 영속 스트림

koa (김신건) — Thu, 25 Jun 2026 00:00:00 GMT

정의

Server-Sent Events (SSE) 는 HTTP 위 단방향 (서버 → 클라이언트) 영속 스트림. text/event-stream MIME + 클라이언트의 EventSource API.

장점: HTTP/1.1 위에서 동작, 자동 재연결, 브라우저 native, 프록시/방화벽 친화.

메시지 포맷

data: hello\n
\n

data: line 1\n
data: line 2\n
\n

event: ping\n
data: {"t":1234}\n
\n

id: 42\n
data: msg\n
retry: 5000\n
\n

필드	의미
`data:`	본문 (여러 줄 가능, JOIN 으로 합쳐짐)
`event:`	커스텀 이벤트 이름 (없으면 `message`)
`id:`	메시지 ID. 재연결 시 `Last-Event-ID` 헤더로 보냄
`retry:`	재연결 간격 (ms)
`\n\n`	메시지 끝 구분

서버 응답

HTTP/1.1 200 OK
Content-Type: text/event-stream
Cache-Control: no-cache
Connection: keep-alive

data: {"price":42000}\n
\n

data: {"price":42100}\n
\n

클라이언트 (브라우저)

const es = new EventSource('/api/prices/stream');

es.onopen = () => console.log('open');

es.onmessage = (e) => {
  const data = JSON.parse(e.data);
  console.log('price', data.price);
};

es.addEventListener('ping', (e) => {
  console.log('ping', e.data);
});

es.onerror = (e) => {
  // 자동 재연결 (브라우저가 처리)
  console.log('error', e);
};

// 명시 종료
es.close();

동작 흐름

sequenceDiagram
    autonumber
    participant C as Client
    participant S as Server

    C->>S: GET /stream<br/>Accept: text/event-stream
    S-->>C: 200 OK<br/>Content-Type: text/event-stream
    loop 연결 유지
        S-->>C: data: ...\n\n
    end
    Note over C: 네트워크 끊김
    Note over C: 자동 재시도 (3s 기본)
    C->>S: GET /stream<br/>Last-Event-ID: 42
    S-->>C: 200 OK (id=43 부터 재개)

[!TIP] 서버는 Last-Event-ID 헤더를 검증하고 그 ID 이후 이벤트 만 보내야 완벽한 재개. 보통 이벤트 ID 를 DB 또는 Redis Stream offset 으로.

백엔드 구현 (Node)

app.get('/stream', (req, res) => {
  res.writeHead(200, {
    'Content-Type': 'text/event-stream',
    'Cache-Control': 'no-cache',
    'Connection': 'keep-alive',
  });

  const lastId = req.headers['last-event-id'];
  const startFrom = lastId ? +lastId + 1 : 0;

  let id = startFrom;
  const t = setInterval(() => {
    res.write(`id: ${id}\n`);
    res.write(`data: ${JSON.stringify({ t: Date.now() })}\n\n`);
    id++;
  }, 1000);

  req.on('close', () => clearInterval(t));
});

백엔드 구현 (Python / FastAPI)

from fastapi import FastAPI
from fastapi.responses import StreamingResponse
import asyncio, json, time

app = FastAPI()

async def event_generator(last_event_id: int = 0):
    event_id = last_event_id + 1
    while True:
        payload = json.dumps({"t": time.time(), "id": event_id})
        yield f"id: {event_id}\ndata: {payload}\n\n"
        event_id += 1
        await asyncio.sleep(1)

@app.get("/stream")
async def stream(last_event_id: int = 0):
    return StreamingResponse(
        event_generator(last_event_id),
        media_type="text/event-stream",
        headers={
            "Cache-Control": "no-cache",
            "X-Accel-Buffering": "no",   # nginx proxy buffering 비활성화
        },
    )

[!TIP] FastAPI / Starlette 는 StreamingResponse 로 SSE 를 쉽게 구현. X-Accel-Buffering: no 헤더로 nginx 버퍼링 비활성화 필수.

SSE vs WebSocket vs Polling

항목	SSE	WebSocket	Long Polling
방향	서버 → 클라이언트	양방향	양방향
프로토콜	HTTP/1.1 (또는 H2/H3)	자체 (RFC 6455)	HTTP
자동 재연결	내장	직접 구현	직접
텍스트 / 바이너리	텍스트만 (UTF-8)	둘 다	텍스트
프록시 / 방화벽 친화	최고	보통	최고
브라우저 호환	모던 OK	모던 OK	모두
서버 자원 (idle 연결)	가벼움	가벼움	무거움 (반복 연결)

[!IMPORTANT] 서버 → 클라이언트 일방향 푸시 (알림, 라이브 피드, 진행률) 면 SSE 가 거의 항상 더 단순. 양방향이 진짜 필요할 때만 WebSocket.

HTTP/2 위 SSE

HTTP/2 에서는 multiplexing 으로 여러 SSE stream + 일반 요청 한 연결에서. HTTP/1.1 의 6 connection limit 문제 해결.

Fan-out / Scale-out 아키텍처

SSE 서버가 여러 인스턴스로 수평 확장될 때, 이벤트를 모든 인스턴스에 전파하는 fan-out 레이어가 필요:

flowchart LR
    API["API Server<br/>(이벤트 발행)"]
    Redis["Redis Pub/Sub<br/>또는 Streams"]
    W1["SSE Worker 1"]
    W2["SSE Worker 2"]
    W3["SSE Worker 3"]
    C1[User A]
    C2[User B]
    C3[User C]
    API --> Redis
    Redis --> W1
    Redis --> W2
    Redis --> W3
    W1 --> C1
    W2 --> C2
    W3 --> C3

API Server 가 이벤트를 Redis Pub/Sub 채널에 발행
각 SSE Worker 가 채널을 구독, 연결된 클라이언트에 전달
클라이언트는 어느 Worker 에 연결되든 동일 이벤트 수신

[!IMPORTANT] Sticky session 없이 수평 확장 가능. 단 Redis 가 SPOF 가 되므로 Redis Cluster 또는 Sentinel 구성 권장.

인증 패턴

EventSource 는 커스텀 헤더 (Authorization) 를 지원하지 않음. 대안:

방법	구현	보안
쿠키	브라우저 자동 전송	HttpOnly + SameSite=Strict
URL 쿼리 파라미터	`?token=xxx`	HTTPS 필수, 로그 노출 주의
초기 핸드셰이크 토큰	REST 로 단기 토큰 발급 후 SSE URL 에 포함	권장 패턴

// 초기 핸드셰이크 패턴
const { streamToken } = await fetch('/api/stream-token', {
  headers: { Authorization: `Bearer ${jwt}` },
}).then(r => r.json());

const es = new EventSource(`/api/stream?token=${streamToken}`);

활용

알림 / 토스트: 새 알림이 도착했을 때 push
라이브 대시보드: 메트릭 실시간
AI Streaming (LLM 응답): OpenAI / Anthropic SDK 의 streaming 이 SSE 위에서
빌드 / 배포 로그 tail
주식 / 코인 시세 (단방향 충분)
진행률 표시: 파일 업로드, 배치 작업 진행 상황

흔한 함정

[!WARNING]

PROXY 의 response buffering = nginx 의 proxy_buffering on 이 모든 데이터를 모아 보냄. SSE 는 즉시 flush 필요. proxy_buffering off + X-Accel-Buffering: no 헤더.

HTTP/1.1 의 6 connection limit = 한 도메인에 6개 이상 SSE 불가. HTTP/2 로 해결.

EventSource 가 재연결 시 자동 인데 지수 백오프 없음 = 서버 과부하 위험. 서버에서 retry: 헤더로 조정.

CORS preflight + EventSource = EventSource 는 기본 헤더만 지원. 커스텀 헤더 (Authorization) 가 필요하면 URL 쿼리 또는 쿠키.

[Voice AI] WebRTC: PeerConnection, ICE, STUN/TURN, SFU

koa (김신건) — Thu, 25 Jun 2026 00:00:00 GMT

정의

WebRTC = 브라우저 / 모바일 P2P 실시간 미디어 + 데이터 표준. 음성, 비디오, 데이터 채널. 2026 시점 voice agent + 영상 통화 + 화면 공유 의 표준.

동작 직관

{}

핵심 컴포넌트

flowchart TB
    JS["JavaScript API"]
    JS --> PC[RTCPeerConnection]
    JS --> GU[getUserMedia]
    JS --> DC[RTCDataChannel]
    PC --> Media["미디어 트랙 (Audio/Video)"]
    PC --> Sig["Signaling (별도 채널)"]
    PC --> ICE[ICE candidates]
    ICE --> STUN[STUN server]
    ICE --> TURN["TURN server (relay)"]
    PC --> DTLS[DTLS handshake]
    PC --> SRTP["SRTP (암호화 미디어)"]

API	역할
`getUserMedia`	마이크 / 카메라 접근
`RTCPeerConnection`	P2P 연결
`RTCDataChannel`	임의 데이터
`RTCRtpSender/Receiver`	미디어 송수신 제어

Signaling (WebRTC 가 직접 다루지 않음)

sequenceDiagram
    autonumber
    participant A as Browser A
    participant Sig as Signaling Server<br/>(WebSocket)
    participant B as Browser B

    A->>A: createOffer (SDP)
    A->>Sig: send offer
    Sig->>B: relay offer
    B->>B: setRemoteDescription
    B->>B: createAnswer (SDP)
    B->>Sig: send answer
    Sig->>A: relay answer
    A->>A: setRemoteDescription

    par 양쪽 ICE candidates
        A->>Sig: ICE candidate
        Sig->>B: relay
        B->>Sig: ICE candidate
        Sig->>A: relay
    end

    A->>B: P2P 직접 연결 (DTLS + SRTP)

Signaling 은 WebRTC 표준 외부. WebSocket / HTTP 폴링 등 자유.

SDP (Session Description Protocol)

v=0
o=- 1719318060 2 IN IP4 127.0.0.1
s=-
t=0 0
m=audio 9 UDP/TLS/RTP/SAVPF 111 103 104
a=rtpmap:111 opus/48000/2
a=rtpmap:103 ISAC/16000
a=fmtp:111 minptime=10;useinbandfec=1
a=setup:actpass
a=fingerprint:sha-256 AC:8D:...
...

코덱 / 포맷 / 보안 / ICE 후보 등. offer/answer 모델.

ICE / STUN / TURN

flowchart LR
    A[Browser A] -->|"behind NAT"| Net[(Internet)]
    B[Browser B] -->|"behind NAT"| Net
    A -.STUN query.-> STUN[STUN server]
    STUN -.public IP/port.-> A
    A -.candidate exchange.-> B
    A -->|direct| B
    A -.failed?.-> TURN["TURN server (relay)"]
    TURN -->|relay| B

	STUN	TURN
역할	내 공용 IP/Port 알려줌	미디어 중계 (P2P 실패 시)
부하	낮음	높음 (모든 미디어 흐름)
비용	거의 0	비쌈 (대역폭)
예	`stun:stun.l.google.com:19302`	coturn (self-host)

약 20% 의 사용자가 symmetric NAT / 방화벽 때문에 TURN 필요. coturn 운영 필수.

ICE Candidate 유형

ICE 는 여러 후보를 수집해 우선순위 순으로 연결 시도합니다.

유형	설명	예
host	로컬 NIC IP/port	`192.168.1.5:50001`
srflx (Server Reflexive)	STUN 으로 알아낸 공용 IP/port	`203.0.113.7:50001`
prflx (Peer Reflexive)	상대방이 받은 내 패킷에서 알아낸 주소	NAT 연결 중 발견
relay	TURN 서버 주소	`198.51.100.2:3478`

우선순위: host > srflx > prflx > relay. Symmetric NAT 이면 host/srflx 모두 실패하고 relay 로 fallback.

ICE Restart

네트워크 변경 (wifi → LTE 전환 등) 시 기존 ICE 연결이 끊깁니다. pc.restartIce() 로 새 offer 를 만들어 ICE 를 재수집하면 연결을 유지할 수 있습니다.

async function handleNetworkChange() {
  pc.restartIce();
  const offer = await pc.createOffer({ iceRestart: true });
  await pc.setLocalDescription(offer);
  // signaling 으로 offer 전송
}

DataChannel (임의 데이터)

const dc = pc.createDataChannel('chat', { ordered: true });
dc.onopen = () => dc.send('hello');
dc.onmessage = (e) => console.log(e.data);

모드	의미
ordered + reliable	TCP 같은 (기본)
unordered + unreliable	UDP 같은 (게임)
reliable + maxPacketLifeTime	시간 한도

SFU (Selective Forwarding Unit)

P2P 는 N 명 → N×(N-1)/2 연결. 4명 = 6 연결, 10명 = 45 연결. 폭발.

flowchart TB
    subgraph P2P["P2P (mesh)"]
        A1[A] --- B1[B]
        A1 --- C1[C]
        A1 --- D1[D]
        B1 --- C1
        B1 --- D1
        C1 --- D1
    end
    subgraph SFU["SFU (server forwards)"]
        SFUS[SFU Server]
        A2[A] --> SFUS
        SFUS --> A2
        B2[B] --> SFUS
        SFUS --> B2
        C2[C] --> SFUS
        SFUS --> C2
        D2[D] --> SFUS
        SFUS --> D2
    end

	P2P (mesh)	SFU	MCU
적합	1:1 / 작은 그룹	5-100 명	TV/대규모
클라이언트 부하	N-1 stream	1 publish + 멀티 download	1 stream
서버 비용	0	중간 (forwarding)	높음 (transcoding)
예	일반 WebRTC	LiveKit, mediasoup, Janus	Jitsi Videobridge

DTLS-SRTP (미디어 암호화)

WebRTC 는 모든 미디어를 DTLS-SRTP 로 암호화합니다. DTLS 로 키 교환 후 SRTP 로 미디어 패킷을 암호화.

DTLS: UDP 위의 TLS. 핸드셰이크에서 a=fingerprint:sha-256 ... (SDP 에서 교환된 인증서 지문) 검증
SRTP: 대칭키로 RTP 패킷의 payload 암호화 + HMAC-SHA1 무결성

브라우저에서 평문 WebRTC 는 표준상 불가. MITM 차단.

Simulcast / SVC (다중 해상도 스트림)

SFU 에서 화면 크기가 다른 구독자에게 서로 다른 품질을 주기 위한 기술.

Simulcast: 송신자가 같은 영상을 여러 해상도 (720p, 360p, 180p) 로 동시 인코딩해 전송. SFU 가 선택.
SVC (Scalable Video Coding): 레이어 구조로 인코딩, 하위 레이어 위에 상위 레이어를 쌓는 방식. 대역폭 효율 좋음 (예: AV1-SVC, H264-SVC).

flowchart TB
    Sender["발신자"]
    Sender -->|"720p stream"| SFU
    Sender -->|"360p stream"| SFU
    Sender -->|"180p stream"| SFU
    SFU -->|"720p"| ClientHD["고대역폭 수신자"]
    SFU -->|"360p"| ClientMD["중대역폭 수신자"]
    SFU -->|"180p"| ClientLD["저대역폭 수신자"]

수신자 대역폭/CPU 에 따라 SFU 가 실시간으로 레이어를 전환해줍니다.

Bandwidth Estimation (REMB / TWCC)

WebRTC 는 수신자의 네트워크 상태를 추정해 송신자가 비트레이트를 자동 조절합니다.

알고리즘	방향	방식
REMB (Receiver Estimated Max Bitrate)	수신 → 송신	수신자가 추정 최대 속도를 RTCP 로 전송
TWCC (Transport-Wide Congestion Control)	수신 → 송신	수신 타임스탬프를 모두 보고, 송신측에서 추정

TWCC 가 더 정확하고 최신 표준. GCC (Google Congestion Control) 알고리즘이 TWCC 피드백을 사용합니다.

음성 에이전트 + WebRTC

flowchart LR
    User[Browser/Mobile] -->|WebRTC| SFU[LiveKit SFU]
    SFU -->|미디어 stream| Agent["Voice Agent (Pipecat / LiveKit Agents)"]
    Agent -->|STT| LLM
    LLM -->|TTS audio| Agent
    Agent -->|미디어 stream| SFU
    SFU -->|WebRTC| User

자세한 건 [[pipecat-livekit]].

WebRTC vs WebSocket vs HTTP/3 (voice)

항목	WebRTC	WebSocket	HTTP/3
Latency	최저 (UDP)	중간 (TCP)	중간
Packet loss	FEC + loss concealment	TCP 재전송 (HoL)	QUIC stream 별
Echo cancel	내장 (browser)	직접	직접
NAT 통과	ICE	TCP/HTTP 기본 OK	UDP 차단 위험
코덱	Opus, VP8/9, H264	직접	직접
사용	voice / video	일반	차세대

voice agent = WebRTC 가 거의 정답. 단 방화벽 UDP 차단 환경 은 WebSocket fallback.

getStats() 로 품질 모니터링

setInterval(async () => {
  const stats = await pc.getStats();
  stats.forEach(stat => {
    if (stat.type === 'inbound-rtp' && stat.kind === 'audio') {
      console.log('jitter', stat.jitter);
      console.log('packetsLost', stat.packetsLost);
      console.log('roundTripTime', stat.roundTripTime);
    }
  });
}, 2000);

주요 지표:

지표	기준 (음성 품질)
`jitter`	< 30ms 이면 양호
`packetsLost` (비율)	< 1% 이면 양호, > 5% 이면 품질 저하
`roundTripTime`	< 150ms 이면 양방향 통화에 OK
`framesDropped`	낮을수록 좋음 (영상)

흔한 함정

[!WARNING]

STUN 만 + TURN 없음 = 20% 사용자 연결 실패. coturn 운영 필수.

에코 (사용자 음성 마이크로 다시) = getUserMedia({ audio: { echoCancellation: true } }). AEC 필수.

Signaling = WebSocket 권장 = HTTP long-polling 은 느리고 깨짐 잦음.

mesh 4명+ 운영 = N² 폭발. SFU 로 반드시 전환.

SDP 직접 편집 = browser 버전마다 다름. libwebrtc / SFU lib 활용.

[Voice AI] WebSocket 미디어 스트림: 양방향 풀듀플렉스, 프레임 버퍼링

koa (김신건) — Thu, 25 Jun 2026 00:00:00 GMT

정의

WebSocket Media Stream = 양방향 바이너리 오디오 스트림. WebRTC 가 어려운 전화 / 서버↔서버 / 옛 클라이언트 에서 표준.

자세한 일반 WebSocket 은 [[WebSocket]].

풀듀플렉스 (Full Duplex)

flowchart LR
    Client -->|마이크 오디오 stream| Server
    Server -->|TTS 오디오 stream| Client
    Note[양방향 동시]

const ws = new WebSocket('wss://voice-agent.example.com/stream');
ws.binaryType = 'arraybuffer';

// 양방향
const audioContext = new AudioContext({ sampleRate: 16000 });

// Send: 마이크 → ws
const processor = audioContext.createScriptProcessor(2048, 1, 1);
processor.onaudioprocess = (e) => {
  const pcm = float32To16BitPCM(e.inputBuffer.getChannelData(0));
  if (ws.readyState === WebSocket.OPEN) {
    ws.send(pcm);
  }
};

// Receive: ws → 스피커
ws.onmessage = async (e) => {
  if (e.data instanceof ArrayBuffer) {
    const pcm = new Int16Array(e.data);
    const float32 = int16ToFloat32(pcm);
    audioQueue.push(float32);
    playFromQueue();
  } else {
    // JSON event
    const event = JSON.parse(e.data);
    handleEvent(event);
  }
};

프레임 버퍼링

flowchart LR
    Net[네트워크 jitter] --> Buf[Jitter Buffer]
    Buf -->|일정 속도| Player[Audio Player]
    Note["jitter buffer 가 일정 속도로 재생,<br/>네트워크 변동 흡수"]

class JitterBuffer:
    def __init__(self, target_ms=100):
        self.queue = deque()
        self.target_ms = target_ms

    def push(self, chunk_with_ts):
        # timestamp 순으로 정렬 삽입
        heapq.heappush(self.queue, chunk_with_ts)

    def pop(self):
        # buffer 가 충분히 차면 일정 속도로 pop
        if self._buffered_ms() >= self.target_ms:
            return heapq.heappop(self.queue)
        return None

구성	의미
Target	보통 50-150ms (latency vs 안정성 trade-off)
Adaptive	네트워크 jitter 측정 → buffer 크기 동적 조정

Twilio Media Streams

<!-- Twilio TwiML -->
<!-- mdx-component: Response -->

  <Connect>
    <Stream url="wss://your-server/stream">
      <!-- mdx-component: Parameter -->
    </Stream>
  </Connect>

# 서버
@app.websocket("/stream")
async def media_stream(ws: WebSocket):
    await ws.accept()
    while True:
        msg = await ws.receive_json()
        if msg["event"] == "start":
            stream_sid = msg["start"]["streamSid"]
        elif msg["event"] == "media":
            payload = base64.b64decode(msg["media"]["payload"])
            # mulaw 8kHz → PCM 16kHz 변환
            pcm = mulaw_to_pcm(payload)
            await stt_send(pcm)
        elif msg["event"] == "stop":
            break

        # TTS 결과 전송
        if tts_audio_chunk:
            mulaw = pcm_to_mulaw(tts_audio_chunk)
            await ws.send_json({
                "event": "media",
                "streamSid": stream_sid,
                "media": {"payload": base64.b64encode(mulaw).decode()},
            })

오디오 포맷

형식	사용처
PCM 16-bit 16kHz mono	표준 (STT, 내부)
mulaw 8kHz	전화 (PSTN, Twilio)
Opus	압축 (대역폭 제한)
AAC	iOS / 일부 SDK

Sample Rate 변환

import resampy

def resample_to_16k(audio: np.ndarray, sr: int) -> np.ndarray:
    if sr == 16000:
        return audio
    return resampy.resample(audio, sr, 16000)

Twilio = 8kHz mulaw → 내부 STT 가 16kHz PCM 이면 resampling 필요.

Binary + JSON 혼용

# Pattern 1: 모두 binary (audio 만)
ws.send(pcm_bytes)

# Pattern 2: JSON event + binary
ws.send(json.dumps({"type": "start", "session": session_id}))
ws.send(pcm_bytes)
ws.send(json.dumps({"type": "stop"}))

# Pattern 3: JSON with base64 audio (Twilio 식)
ws.send(json.dumps({
    "event": "media",
    "media": {"payload": base64.b64encode(pcm).decode()},
}))

Base64 = 33% 크기 증가. 대역폭 critical = binary frame.

Heartbeat / Reconnect

class VoiceWebSocket:
    async def heartbeat_loop(self):
        while True:
            await asyncio.sleep(20)
            try:
                await self.ws.ping()
            except Exception:
                await self.reconnect()
                return

    async def reconnect(self):
        for attempt in range(5):
            try:
                self.ws = await connect(self.url)
                # Session 복구
                await self.ws.send_json({"type": "resume", "session": self.session_id})
                return
            except Exception:
                await asyncio.sleep(2 ** attempt)

Backpressure

class BoundedWebSocket:
    """WebSocket buffer 가 차면 입력 drop 또는 압축"""
    MAX_BUFFER = 1024 * 1024  # 1MB

    async def send_safe(self, data):
        if self.ws.transport.get_write_buffer_size() > self.MAX_BUFFER:
            # 옛 데이터 drop (오디오는 lossy OK)
            return False
        await self.ws.send(data)
        return True

자세한 backpressure 는 [[backpressure]].

흔한 함정

[!WARNING]

base64 사용 = 대역폭 33% 증가. Binary frame 권장.

Jitter buffer 없음 = 네트워크 변동 시 오디오 끊김. 100ms buffer.

Sample rate 불일치 = 16kHz 데이터를 8kHz 로 처리 → 발음 깨짐.

Heartbeat 부재 = NAT timeout (60s) 후 silent close.

압축 안 함 (큰 PCM) = 1분 통화 = 1.92MB (16kHz, 16-bit). Opus / mulaw 압축.

[Network] CIDR와 Subnetting

koa (김신건) — Wed, 24 Jun 2026 00:00:00 GMT

정의

CIDR (Classless Inter-Domain Routing) 은 IPv4 / IPv6 주소를 prefix length 로 표기하는 표준. 1993년 등장 (RFC 1519, 현재 RFC 4632).

192.168.1.0/24
        ↑
        prefix length = 상위 24 bit 가 network, 하위 8 bit 가 host

CIDR 이전의 class-based (A/B/C) 는 비효율적 → 클래스 폐지, prefix 자유 지정.

CIDR 표기

주소 / prefix
192.168.1.0/24       → 256 개 IP (호스트 254 개 + network + broadcast)
192.168.0.0/16       → 65536 개 IP
10.0.0.0/8           → 16,777,216 개 IP

2001:db8::/32        → IPv6 prefix
fe80::/64            → 일반 IPv6 subnet (호스트 64 bit)

prefix = network bit 수. host bit = 32 - prefix (IPv4) 또는 128 - prefix (IPv6).

subnet mask 변환

prefix    binary subnet mask                 dotted decimal
/8        11111111.00000000.00000000.00000000   255.0.0.0
/16       11111111.11111111.00000000.00000000   255.255.0.0
/24       11111111.11111111.11111111.00000000   255.255.255.0
/25       11111111.11111111.11111111.10000000   255.255.255.128
/30       11111111.11111111.11111111.11111100   255.255.255.252
/32       11111111.11111111.11111111.11111111   255.255.255.255  (단일 host)

CIDR notation 이 dotted mask 보다 간결 + 라우터 설정에 일관됨.

host 수 계산

/N 의 host 수 = 2^(32-N) - 2:

Prefix	IP 총 개수	사용 가능 host
/24	256	254 (network + broadcast 제외)
/25	128	126
/26	64	62
/27	32	30
/28	16	14
/29	8	6
/30	4	2 (point-to-point link)

-2 는 network address (모두 0) + broadcast (모두 1) 제외.

예외:

/31 : 2 host (P2P, RFC 3021)
/32 : 1 host (single)

subnet 계산 예

192.168.1.130/25 의 subnet:

binary: 192.168.1.10000010
mask  : 11111111.11111111.11111111.10000000

network: 192.168.1.10000000 = 192.168.1.128
broadcast: 192.168.1.11111111 = 192.168.1.255
host range: 192.168.1.129 ~ 192.168.1.254

/24 를 2 개 /25 로 분할:

192.168.1.0/25: 0 ~ 127 (network 0, broadcast 127, host 1-126)
192.168.1.128/25: 128 ~ 255 (network 128, broadcast 255, host 129-254)

VLSM (Variable Length Subnet Masking)

같은 organization 안에서 subnet 마다 prefix 다르게:

회사 네트워크: 10.0.0.0/16

  ├── 본사 (host 1000개):     10.0.0.0/22   (1022 host)
  ├── 지사 A (host 100개):    10.0.4.0/25   (126 host)
  ├── 지사 B (host 50개):     10.0.4.128/26  (62 host)
  ├── DMZ (host 6개):         10.0.4.192/29  (6 host)
  └── 관리 vlan:              10.0.4.200/29  (6 host)

VLSM 이 없으면 모든 subnet 이 같은 크기 = 낭비.

라우팅 (longest prefix match)

라우터는 가장 긴 prefix 가 매칭되는 경로 선택:

라우팅 테이블:
0.0.0.0/0           → default (interface eth0)
10.0.0.0/8          → eth1
10.1.0.0/16         → eth2
10.1.5.0/24         → eth3

목적지: 10.1.5.20
→ 매칭: /0 (default), /8, /16, /24 4개
→ 가장 긴 /24 선택 → eth3

supernetting (route summarization)

작은 subnet 여러 개를 큰 prefix 로 묶기:

10.1.0.0/24
10.1.1.0/24
10.1.2.0/24
10.1.3.0/24
   ↓ 묶으면
10.1.0.0/22

라우팅 테이블 크기 줄여 라우터 부하 감소. BGP 의 핵심.

private vs public

RFC 1918 private (인터넷 라우팅 불가):

10.0.0.0/8
172.16.0.0/12
192.168.0.0/16

NAT 로 public IP 공유 ([[network-nat]]). 사내 / docker / k8s 모두 위 범위 사용.

조직 1: 10.0.0.0/8
조직 2: 10.0.0.0/8
└─ 충돌 없음 (각자 사설)
└─ VPN 연결 시 충돌 (overlap)

큰 조직은 VPN / merger 대비 충돌 회피 가능한 범위 선택.

IPv6 subnetting

IPv6 은 보통 /64 subnet (host 64 bit). ISP 가 organization 에 /48 또는 /56 부여:

/48 organization → 65536 개 /64 subnet
/56 organization → 256 개 /64 subnet

예: 2001:db8:1234::/48
  ├── 2001:db8:1234:0001::/64  (sub-1)
  ├── 2001:db8:1234:0002::/64  (sub-2)
  └── 2001:db8:1234:0003::/64

IPv6 의 /64 가 표준인 이유: SLAAC (Stateless Address Autoconfiguration) 가 MAC → host 64 bit 자동 생성.

자주 보는 시나리오

시나리오 1: AWS VPC

VPC: 10.0.0.0/16

  ├── subnet-public-a:   10.0.1.0/24 (AZ-a, public)
  ├── subnet-public-b:   10.0.2.0/24 (AZ-b, public)
  ├── subnet-private-a:  10.0.10.0/24 (AZ-a, private)
  └── subnet-private-b:  10.0.20.0/24 (AZ-b, private)

VPC 의 /16 안에서 /24 들로 subdivide. AZ 별 + public/private 별.

시나리오 2: Kubernetes

Pod CIDR:     10.244.0.0/16   (Pod IP pool)
Service CIDR: 10.96.0.0/12    (ClusterIP pool)

  Node 1: 10.244.0.0/24   (256 pod 한계)
  Node 2: 10.244.1.0/24
  Node 3: 10.244.2.0/24

CNI plugin (Calico, Flannel) 이 위 할당. 노드 수 × subnet 크기가 Pod CIDR 보다 작아야.

시나리오 3: P2P link

라우터 간 직접 연결은 host 2 개면 충분:

RouterA --- 10.255.1.0/30 --- RouterB
  .1                            .2

/30: network=.0, host=.1+.2, broadcast=.3. 또는 /31 (RFC 3021).

빠른 계산 트릭

"몇 host?"

/24 → 2^8 - 2 = 254
/25 → 2^7 - 2 = 126
/26 → 2^6 - 2 = 62
/27 → 2^5 - 2 = 30
/28 → 2^4 - 2 = 14
/29 → 2^3 - 2 = 6
/30 → 2^2 - 2 = 2

/N 의 host = 2^(32-N) - 2.

"몇 subnet?"

/24 를 /26 으로 → 4 개 (host bit 2 → 2^2)
/24 를 /27 으로 → 8 개
/16 을 /24 로 → 256 개

prefix 가 길어진 bit 수 = 2 의 지수.

함정과 베스트 프랙티스

VPC / overlay 의 CIDR 미리 큰 범위로: 작게 잡으면 나중에 확장 불가
subnet 충돌 회피: VPN / multi-cloud 환경에서 organization 별 다른 prefix
AWS VPC: /16 권장: subnet 분할 여지
Docker 의 기본 172.17.0.0/16 충돌 시: daemon.json 으로 변경
K8s 의 Pod CIDR + Service CIDR + Node IP 가 충돌 금지
IPv6 의 /64 는 거의 절대 분할 X: SLAAC 망가짐
longest prefix match 가 라우터 결정 규칙
summarization 으로 라우팅 테이블 축소: BGP 환경에서 critical

[Network] DNS: 도메인 이름 해석

koa (김신건) — Wed, 24 Jun 2026 00:00:00 GMT

정의

DNS (Domain Name System) 는 도메인 이름 (example.com) 을 IP 주소 (93.184.216.34) 로 변환하는 분산 데이터베이스. 인터넷의 가장 중요한 인프라.

기본 동작:

클라이언트 → resolver 에게 “example.com 의 IP” 요청
resolver → root → TLD → authoritative 서버를 순회 (recursive)
resolver → 결과를 캐시 + 클라이언트에 반환

L7 protocol, 보통 UDP 53 port (큰 응답은 TCP 53, modern 은 DoT/DoH).

도메인 계층

.                              ← root (.)
├── com.                       ← TLD
│   ├── google.com.            ← second-level
│   │   ├── www.google.com.    ← subdomain
│   │   └── mail.google.com.
│   └── example.com.
├── kr.                        ← ccTLD
│   └── naver.kr.
└── org.

오른쪽에서 왼쪽으로 읽기. . 가 root.

FQDN (Fully Qualified Domain Name): www.example.com. (마지막 . 까지).

DNS Record 종류

Type	용도	예시
A	IPv4 주소	`example.com → 93.184.216.34`
AAAA	IPv6 주소	`example.com → 2606:2800:220:1::6:34`
CNAME	별칭 (canonical name)	`www.example.com → example.com`
MX	메일 서버 + 우선순위	`example.com → 10 mail.example.com`
NS	nameserver	`example.com → ns1.example.com`
TXT	임의 텍스트 (SPF, DKIM, 인증)	`v=spf1 ...`
SRV	service location (port + host)	`_sip._tcp.example.com → 10 60 5060 sip.example.com`
PTR	reverse lookup (IP → 도메인)	`34.216.184.93.in-addr.arpa → example.com`
CAA	cert authority 제한	`example.com → issue "letsencrypt.org"`
SOA	zone authority	`nameserver, email, serial, refresh, ...`
DNSKEY / DS / RRSIG	DNSSEC 서명	-

Resolution 흐름

client → recursive resolver → root → TLD → authoritative
         ("8.8.8.8" 등)

상세:

1. 클라이언트: "www.example.com 의 A 레코드?"
       ↓
2. recursive resolver (ISP, 8.8.8.8, 1.1.1.1)
   - 캐시 hit 시 즉시 반환
   - 캐시 miss:
       ↓
3. root (.) 에 질문: ".com 의 nameserver?"
   - 응답: "a.gtld-servers.net 등"
       ↓
4. .com TLD 에 질문: "example.com 의 nameserver?"
   - 응답: "ns1.example.com 등"
       ↓
5. example.com 의 authoritative 에 질문: "www.example.com 의 A?"
   - 응답: "93.184.216.34"
       ↓
6. resolver 캐시 + 클라이언트에 반환

각 단계는 TTL 만큼 캐시. 일반적으로 5분 ~ 24시간.

recursive vs iterative

recursive query: “최종 답을 줘”
- 클라이언트 → resolver
iterative query: “당신이 아는 것만 줘”
- resolver → root / TLD / authoritative

대부분 OS / 브라우저는 recursive 만 사용. resolver 가 iterative 로 순회.

캐싱과 TTL

DNS 응답에 TTL (초). 짧으면 변경 빠르게 반영, 길면 부하 감소.

www.example.com.    300    IN    A    93.184.216.34
                    ↑
                    300 초 (5분) 캐시

다층 캐싱:

브라우저 cache (~수분)
OS resolver cache (systemd-resolved, dnsmasq)
ISP / public resolver cache
authoritative cache 없음 (source of truth)

서비스 마이그레이션 / DNS 변경 시 TTL 미리 줄이기 (1시간 → 60초) 가 일반 패턴.

CNAME 함정

www.example.com.    300    IN    CNAME    example.com.
example.com.        300    IN    A        93.184.216.34

www.example.com 조회 → CNAME → example.com 다시 조회 → A.

함정:

apex / root 에는 CNAME 불가 (RFC). example.com 에는 CNAME 안 됨.
- 회피: AWS Route 53 의 ALIAS (CNAME 처럼 보이지만 A 레코드 반환)
CNAME 체인 길어지면 latency: 가능하면 직접 A

DNS over HTTPS (DoH) / DNS over TLS (DoT)

기존 DNS = 평문 UDP 53. 도청 / 변조 가능.

DoT (RFC 7858): TLS 위에서 DNS. Port 853.
DoH (RFC 8484): HTTPS 위에서 DNS. Port 443. 일반 HTTPS 트래픽처럼 보임.

브라우저 (Firefox, Chrome) 가 기본 DoH 활성화 중. 단점: ISP / 기업의 DNS 기반 필터링 우회 가능 → 정책 충돌.

DoQ (DNS over QUIC) 도 표준화 (RFC 9250).

DNSSEC

응답의 서명 검증:

.            DNSKEY  → ZSK / KSK (root signing key)
com.         DS      → .com 의 KSK 해시 (root 가 서명)
example.com. DS      → example.com 의 KSK 해시 (.com 이 서명)
example.com. RRSIG   → A 레코드의 서명

resolver 가 root → TLD → authoritative 전 chain 검증.

복잡 + 운영 어려움 → 채택률 낮음 (Top 1M 사이트의 약 4%). 큰 ISP / 정부 사이트는 적용.

EDNS (Extension)

DNS 메시지 크기 확장 (기본 512 byte → 4096 등)
EDNS Client Subnet (ECS): resolver 가 클라이언트 subnet 을 authoritative 에 전달 → geo-IP 정확도 향상 (CDN 핵심)

실용 예: 서비스 운영

A 레코드 + CDN

www.example.com    300    A    104.21.x.x   (Cloudflare edge)
www.example.com    300    A    172.67.x.x   (다른 edge)

여러 A 레코드 = round-robin 또는 anycast 라우팅.

MX 우선순위

example.com    3600    MX    10    primary-mail.example.com
example.com    3600    MX    20    backup-mail.example.com

낮은 숫자 = 높은 우선순위. primary 실패 시 backup.

TXT (SPF / DKIM / DMARC)

이메일 인증:

example.com    300    TXT    "v=spf1 include:_spf.google.com ~all"
default._domainkey.example.com  300  TXT  "v=DKIM1; k=rsa; p=MIGfMA0..."
_dmarc.example.com  300  TXT  "v=DMARC1; p=reject; rua=mailto:..."

스팸 / 위장 방지의 필수.

Health check + failover

Route 53 / Cloudflare 같은 managed DNS 가 health check 수행:

primary 가 200 OK → primary A 반환
primary 가 5xx → backup A 반환

TTL 짧게 (30~60초) 두면 빠른 failover.

DNS 측정 도구

# 기본 lookup
dig example.com
dig example.com AAAA
dig example.com MX

# 특정 resolver
dig @8.8.8.8 example.com

# 전체 trace
dig +trace example.com

# 짧게
dig +short example.com

# nslookup (legacy)
nslookup example.com

# host (간결)
host example.com

# DoH
curl -H 'Accept: application/dns-json' \
  'https://1.1.1.1/dns-query?name=example.com&type=A'

자주 보는 함정

함정 1: 캐시 stale

DNS 변경 후 일부 사용자 / ISP 가 옛 IP 캐시 → 일관성 문제. TTL 미리 줄이기.

함정 2: round-robin 의 불균등

A 레코드 여러 개를 resolver 가 순서대로 반환하지만 클라이언트가 첫 IP 만 시도하면 불균등. anycast / load balancer 가 더 정확.

함정 3: SOA refresh / retry

secondary nameserver 가 primary 의 변경을 늦게 감지. SOA 의 refresh / retry / expire 값 적절히.

함정 4: PTR 이 없으면 이메일 거부

송신 메일 서버의 PTR (reverse DNS) 가 매칭 안 되면 스팸 처리. 자체 SMTP 운영 시 필수.

함정 5: split-horizon DNS

내부에서 api.example.com → 사내 IP, 외부에서 → public IP. VPN 전환 시 캐시 혼선 가능.

함정과 베스트 프랙티스

TTL 운영 변경 전 미리 줄이기: 마이그레이션 24시간 전부터
DNSSEC 은 큰 조직만: 운영 복잡, 채택률 낮음
DoH / DoT 활용: 도청 방지
SPF + DKIM + DMARC 필수: 이메일 운영 시
multiple authoritative nameserver: 단일 장애점 회피 (보통 2~4개)
EDNS Client Subnet: CDN 의 geo-IP 정확도 의존성
PTR 도 관리: 메일 / SSH 인증 영향
monitoring: TTL, 응답 시간, error rate (NXDOMAIN 등)
dig +trace 가 디버깅의 가장 강력한 도구

[Network] HTTP Caching: Cache-Control, ETag, Last-Modified

koa (김신건) — Wed, 24 Jun 2026 00:00:00 GMT

정의

HTTP Caching 은 HTTP 응답을 클라이언트 / 중간 proxy / CDN 이 보관해 같은 요청을 다시 처리하지 않게 하는 메커니즘. 성능 + 비용 절감의 핵심.

3가지 levels:

Private cache: 브라우저 (사용자 1명만)
Shared cache: CDN, reverse proxy (여러 사용자)
Origin cache: 서버 자체 (e.g., Redis)

이 페이지는 HTTP layer 의 1, 2번 (Cache-Control, ETag 등).

캐시 전략의 두 축

"신선함 (freshness)": TTL 기반 - 만료 전까진 캐시 사용 (서버 안 가)
"검증 (validation)": ETag / Last-Modified - 서버에 "변경됐어?" 물어봄

조합:

fresh: 캐시 즉시 사용 (네트워크 X)
stale + valid (304): 캐시 사용 + 짧은 검증 요청
stale + invalid (200): 새 응답 받기

Cache-Control

핵심 directive:

Directive	의미
`max-age=N`	N 초 동안 fresh
`s-maxage=N`	shared cache (CDN) 만 적용
`public`	모든 cache 에 저장 가능
`private`	브라우저만 (CDN 금지)
`no-cache`	캐시 OK 하지만 사용 전 반드시 검증
`no-store`	절대 캐시 금지 (민감 정보)
`must-revalidate`	만료 후 stale 사용 금지, 검증 필수
`immutable`	절대 안 바뀜 (검증도 안 함)
`stale-while-revalidate=N`	만료 후 N 초 동안 stale 반환 + 백그라운드 갱신
`stale-if-error=N`	서버 에러 시 N 초 동안 stale 사용

응답 예

HTTP/1.1 200 OK
Content-Type: text/css
Cache-Control: public, max-age=31536000, immutable
ETag: "abc123"

body { ... }

immutable + 긴 max-age = “이 자원은 절대 안 바뀐다” → CDN / 브라우저 완전 신뢰. Vite / webpack 의 hashed filename (app.abc123.css) 패턴에 최적.

요청 측 Cache-Control

GET /api/data HTTP/1.1
Cache-Control: no-cache    # 강제 검증
Cache-Control: max-age=0   # 동일
Cache-Control: no-store    # 캐시 비활성

ETag (Entity Tag)

응답의 unique identifier (보통 hash):

HTTP/1.1 200 OK
ETag: "v2.1-abc123"

다음 요청에서 클라이언트가 If-None-Match 로 보냄:

GET /api/data HTTP/1.1
If-None-Match: "v2.1-abc123"

서버 응답:

변경 없음 → 304 Not Modified (body 없음, 짧음)
변경 있음 → 200 OK + 새 body + 새 ETag

Strong vs Weak ETag

ETag: "abc123"        # strong (byte-for-byte 동일)
ETag: W/"abc123"      # weak (의미적으로 동일, gzip 후도 OK)

대부분 weak 가 적합 (compression, encoding 차이 무시).

Last-Modified

ETag 의 timestamp 버전:

HTTP/1.1 200 OK
Last-Modified: Wed, 24 Jun 2026 10:00:00 GMT

요청:

GET /api/data HTTP/1.1
If-Modified-Since: Wed, 24 Jun 2026 10:00:00 GMT

응답: 304 또는 200.

ETag 와 Last-Modified 둘 다 있으면 ETag 우선. ETag 만으로 충분한 경우 많음.

Vary

같은 URL 인데 응답이 다를 수 있을 때 (Accept-Encoding 별 gzip/br, Accept-Language 별 i18n):

HTTP/1.1 200 OK
Vary: Accept-Encoding, Accept-Language

캐시가 Vary 헤더에 명시된 헤더 값별로 별도 저장:

Accept-Encoding: gzip → gzip 버전 캐시
Accept-Encoding: br → brotli 버전 캐시

⚠️ Vary 가 너무 많으면 캐시 hit 률 ↓. 가능하면 적게 사용.

Vary: User-Agent 는 일반적으로 비추천 (UA 종류가 많음 → 거의 캐시 miss).

Age & Expires

HTTP/1.1 200 OK
Cache-Control: max-age=3600
Age: 1200         # 캐시에서 1200 초 머묾 (남은 신선도 2400초)
Expires: Wed, 24 Jun 2026 11:00:00 GMT  # legacy

Age 가 CDN 디버깅에 유용. Expires 는 HTTP/1.0 legacy, Cache-Control 우선.

Pragma (deprecated)

Pragma: no-cache

HTTP/1.0 호환용. Cache-Control: no-cache 가 표준.

패턴 별 권장 설정

Static asset (hash 파일명, immutable)

GET /assets/app.abc123.js

Cache-Control: public, max-age=31536000, immutable

1년 + immutable. CDN edge 에서 영구 사용.

HTML (변경 가능, 항상 신선)

GET /index.html

Cache-Control: no-cache, must-revalidate
ETag: "v1"

ETag 로 검증, 변경 시 새 HTML 받기. SPA 의 index.html 패턴.

API (변경 빈도 보통)

GET /api/products

Cache-Control: private, max-age=60, stale-while-revalidate=300
ETag: "x"

60초 fresh, 그 후 5분간 stale 반환 + 백그라운드 갱신. 사용자 경험과 부하의 균형.

Private user data

GET /api/me

Cache-Control: private, no-cache, no-store

CDN 캐시 금지, 브라우저도 캐시 안 함.

GET /api/public/articles

Cache-Control: public, max-age=300, s-maxage=3600

브라우저는 5분, CDN 은 1시간. s-maxage 가 max-age override (shared cache 만).

CDN 통합

대부분 CDN (Cloudflare, Fastly, CloudFront) 가 위 헤더 자동 처리. 추가 제어:

Cache-Control: public, max-age=300
CDN-Cache-Control: max-age=3600      # CDN 전용
Cloudflare-CDN-Cache-Control: max-age=86400   # Cloudflare 만

origin 부담 줄이려면 CDN 에 길게 캐시 + 클라이언트엔 짧게.

캐시 invalidation

수동:

# Cloudflare API
curl -X POST "https://api.cloudflare.com/.../purge_cache" \
  -H "Authorization: Bearer $TOKEN" \
  -d '{"files":["https://example.com/path"]}'

또는 URL 에 hash / version 포함:

/assets/app.abc123.js → 새 빌드는 /assets/app.def456.js (URL 자체가 바뀌므로 invalidation 불필요)

자주 보는 함정

함정 1: no-cache vs no-store 혼동

no-cache : 캐시 OK, 사용 전 검증
no-store : 캐시 자체 금지

민감 정보는 no-store. “항상 최신” 만 원하면 no-cache + ETag.

Set-Cookie 가 있는 응답을 CDN 이 캐시하면 모든 사용자가 같은 cookie 받음 (재앙). 보통 CDN 이 자동 회피하지만 명시:

Cache-Control: private    # 또는 no-store

함정 3: Vary: * 또는 너무 많은 Vary

캐시 hit 률 0%. 불필요한 Vary 제거.

함정 4: 짧은 max-age + 큰 트래픽 = origin 부하

CDN 에 s-maxage 길게 + 클라이언트엔 max-age 짧게 분리.

함정 5: Authorization 헤더와 캐시

Authorization 헤더 있는 요청은 기본적으로 캐시 안 됨 (RFC 9111). Cache-Control: public 명시 시만.

함정 6: 응답 status

비-2xx 도 캐시 가능:

301 Moved Permanently : 영구 캐시 (브라우저가 매우 길게)
404 Not Found : 짧게 캐시 가능 (다음 요청도 404 위험)

디버깅

브라우저 DevTools Network 탭:

(memory cache) / (disk cache) : 히트
200 : origin / CDN 응답
304 : 검증 hit
Cache-Control, ETag, Age 헤더 확인

CDN debug header:

cf-cache-status: HIT/MISS/REVALIDATED (Cloudflare)
x-cache: HIT/MISS (CloudFront, Fastly)

함정과 베스트 프랙티스

Static asset 은 immutable + 1년 + URL hash: 가장 효율적
HTML 은 ETag + no-cache: SPA 와 자연스러움
API 는 stale-while-revalidate 적극 활용: UX 향상
Vary 는 최소화: hit 률 보호
no-store 와 private 차이 명확히 인지
CDN debug header 모니터링: hit 률 추적
invalidation 보다 versioned URL: 더 안전
민감 데이터는 no-store
stale-if-error 로 자동 fallback: origin 다운 시 UX 보호

[Network] IP: IPv4, IPv6, 패킷 구조, fragmentation

koa (김신건) — Wed, 24 Jun 2026 00:00:00 GMT

정의

IP (Internet Protocol) 는 OSI L3 (네트워크 계층) 의 핵심 프로토콜. best-effort delivery (재전송 없음, 순서 보장 없음, 손실 가능). 신뢰성은 TCP 같은 상위 layer 가 담당.

두 버전:

IPv4: 32-bit 주소 (≈ 43억), 1981년 RFC 791
IPv6: 128-bit 주소 (사실상 무한), 1998년 RFC 2460 → 2017년 RFC 8200

현재 인터넷은 듀얼 스택. 점진적 IPv6 전환 중 (구글 클라이언트 통계 약 40-50%).

IPv4 주소

Dotted decimal: 192.168.1.1 = 32-bit (4 octet, 0~255 each).

범위	종류	예시
0.0.0.0/8	미지정 / “this network”	0.0.0.0
10.0.0.0/8	private (Class A)	10.x.x.x
127.0.0.0/8	loopback	127.0.0.1
169.254.0.0/16	link-local (DHCP 실패 시)	169.254.x.x
172.16.0.0/12	private (Class B)	172.16-31.x.x
192.168.0.0/16	private (Class C)	192.168.x.x
224.0.0.0/4	multicast	224.0.0.1
255.255.255.255	broadcast	-

NAT 가 있는 이유: IPv4 고갈 → 사설망 안에서 private + 인터넷 진출 시 NAT 가 public IP 로 변환. [[network-nat]] 참고.

IPv6 주소

Colon-separated hex: 2001:0db8:85a3:0000:0000:8a2e:0370:7334.

축약 규칙:

각 그룹의 leading zero 생략: 2001:db8:85a3:0:0:8a2e:370:7334
연속 0 그룹은 :: 한 번만 사용 가능: 2001:db8:85a3::8a2e:370:7334

특수 주소:

::1 : loopback (IPv4 의 127.0.0.1)
:: : 미지정 (0.0.0.0)
fe80::/10 : link-local
fc00::/7 : ULA (Unique Local, private)
2000::/3 : global unicast

IPv6 는 broadcast 없음 (multicast 만). NDP (Neighbor Discovery Protocol) 가 ARP 대체.

IPv4 헤더 (20 byte 기본)

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-------+-------+---------------+-------------------------------+
|Version|  IHL  |Type of Service|          Total Length         |
+-------+-------+---------------+-----+-------------------------+
|         Identification        |Flags|      Fragment Offset    |
+---------------+---------------+-----+-------------------------+
|  Time to Live |    Protocol   |         Header Checksum       |
+---------------+---------------+-------------------------------+
|                       Source Address                          |
+---------------------------------------------------------------+
|                    Destination Address                        |
+---------------------------------------------------------------+
|                    Options (옵션, 가변)                       |
+---------------------------------------------------------------+

핵심 필드:

Version: 4
IHL: 헤더 길이 (32-bit word 단위, 기본 5 = 20 byte)
Total Length: 전체 패킷 크기 (max 65535)
Identification + Flags + Fragment Offset: fragmentation 용
TTL: hop 수 제한 (0 도달 시 ICMP TTL Exceeded 후 폐기)
Protocol: 다음 layer (TCP=6, UDP=17, ICMP=1)
Source/Destination: 32-bit IP

IPv6 헤더 (고정 40 byte)

+-------+--------------+----------------------+
|Version| Traffic Class|     Flow Label       |
+-------+--------------+----------------------+
|    Payload Length    | Next Header | Hop Lim|
+----------------------+-------------+--------+
|             Source Address (128 bit)        |
+---------------------------------------------+
|          Destination Address (128 bit)      |
+---------------------------------------------+

IPv6 의 단순화:

고정 길이 (옵션은 extension header)
헤더 checksum 제거 (L2/L4 가 검증)
fragmentation 없음 (source 만, router 는 거부)
Flow Label: QoS

Fragmentation (IPv4)

MTU (Maximum Transmission Unit): link 가 한 번에 전송 가능한 최대 크기.

Ethernet: 1500 byte
VPN tunnel: 줄어들 수 있음 (1400 등)

IP 패킷이 MTU 보다 크면 fragmentation:

원본: 4000 byte 패킷
   ↓ MTU 1500 link
fragment 1: 1500 byte (More Fragments=1)
fragment 2: 1500 byte (More Fragments=1, offset=1480)
fragment 3: 1040 byte (More Fragments=0, offset=2960)

목적지 host 에서 reassembly. 함정:

한 fragment 손실 = 전체 재전송 필요
보안: fragment overlap 공격
IPv6 는 source-only fragmentation (router 는 거부 + ICMPv6 Too Big)

PMTUD (Path MTU Discovery)

Don’t Fragment (DF) flag 켜고 보내며 router 가 “Too Big” ICMP 반환하면 줄임:

source ─→ link 1500 ─→ tunnel 1400 ─→ destination
       ↓ DF=1, 1500
       ← ICMP "Frag needed, MTU=1400"
       ↓ retry with 1400
       ✓

ICMP 차단된 환경에선 PMTUD 깨짐 (“PMTUD black hole”). TCP MSS clamping 으로 회피.

ICMP (Internet Control Message Protocol)

IP 의 control plane:

Echo Request/Reply: ping
Destination Unreachable: 목적지 도달 불가
TTL Exceeded: traceroute 의 원리
Fragmentation Needed: PMTUD
Redirect: 더 좋은 route 알림 (보안상 위험)

ICMPv6 는 더 광범위 (NDP, MLD 등 통합).

TTL (Time To Live)

각 router 통과 시 1 씩 감소. 0 도달 시 패킷 폐기 + ICMP Time Exceeded.

목적: 라우팅 루프 무한 폭주 방지. 일반적 OS 기본값:

Linux: 64
Windows: 128
Cisco router: 255

traceroute 가 이걸 활용:

traceroute google.com
# TTL=1 보냄 → 1번째 router 가 TTL Exceeded 반환 (그 router 의 IP 노출)
# TTL=2 보냄 → 2번째 router 가 반환
# ...

각 hop 의 IP 와 latency 측정. [[network-cidr-subnetting]] 참고.

주요 함정

함정 1: NAT 뒤의 IP

192.168.1.10 에서 외부 접속 시 라우터가 SNAT → public IP. 외부에서 보면 라우터의 IP. inbound 는 port forwarding 필요.

함정 2: IPv6 dual-stack 의 happy eyeballs

브라우저는 IPv4 / IPv6 둘 다 시도해 빠른 쪽 사용. IPv6 라우팅이 깨졌어도 IPv4 fallback 되므로 사용자는 모름 → 진단 어려움.

함정 3: MTU mismatch

Docker / Kubernetes 의 overlay network 가 보통 MTU 1450 (encapsulation overhead). 호스트가 1500 으로 보내면 성능 저하 / 패킷 손실.

# 진단
ping -M do -s 1472 google.com   # 1472 + 28 (IP+ICMP) = 1500

함정 4: IPv4 exhaustion 과 CGNAT

ISP 의 Carrier-Grade NAT 환경에서 같은 IP 가 수천 명 공유. P2P / inbound 어려움. IPv6 보급 가속 이유.

IP 라우팅 흐름

flowchart LR
    A["호스트 A (192.168.1.10)"] -->|"1. 패킷 생성"| R1["Router/NAT"]
    R1 -->|"2. public IP 변환"| ISP[인터넷 라우터]
    ISP -->|"3. longest prefix match"| R2[Edge Router]
    R2 -->|"4. TTL 감소 후 전달"| B["호스트 B (8.8.8.8)"]
    ISP -->|"TTL=0, ICMPv4 반환"| A

각 hop 에서 라우터 동작:

목적지 IP 의 라우팅 테이블 longest prefix match 조회
매칭 경로 없으면 default route (0.0.0.0/0) 사용
TTL 1 감소. 0 이면 패킷 폐기 + ICMP Time Exceeded 반환

서브넷 / CIDR

CIDR (Classless Inter-Domain Routing): 가변 길이 prefix 로 IP 대역 표현.

192.168.1.0/24
          └─ prefix 24 bit → subnet mask 255.255.255.0
               → 192.168.1.0 ~ 192.168.1.255 (256개 주소)
               → 사용 가능: 192.168.1.1 ~ 192.168.1.254 (네트워크 주소/브로드캐스트 제외)

Prefix	주소 수	사용 가능	용도
/30	4	2	P2P 링크
/29	8	6	소규모
/24	256	254	일반 LAN
/22	1024	1022	중규모
/16	65536	65534	대규모 VPC

Subnetting 계산

10.0.0.0/8 (Class A private) 를 /24 로 쪼개면:
  10.0.0.0/24, 10.0.1.0/24, ..., 10.255.255.0/24 → 65536 개 서브넷

AWS VPC 설계 예:
  10.0.0.0/16
    ├── Public:  10.0.1.0/24
    ├── Private: 10.0.2.0/24
    └── DB:      10.0.3.0/24

bitwise AND 로 네트워크 주소 계산:

IP:   192.168.1.100 = 11000000.10101000.00000001.01100100
Mask: 255.255.255.0 = 11111111.11111111.11111111.00000000
AND:  192.168.1.0   = 11000000.10101000.00000001.00000000

ARP (Address Resolution Protocol)

IPv4 에서 L3 → L2 변환: IP 주소 → MAC 주소 결정.

송신: ARP Request (broadcast)  "192.168.1.1 의 MAC 주소는?"
수신: ARP Reply (unicast)       "내 MAC 은 aa:bb:cc:dd:ee:ff"
캐싱: ARP 테이블에 IP-MAC 매핑 저장 (보통 TTL ~20분)

# ARP 테이블 확인
arp -n

# IPv6 NDP 테이블 (Neighbor Discovery Protocol)
ip -6 neigh

IPv6 에서는 NDP (Neighbor Discovery Protocol) 가 ARP 대체. ICMPv6 기반, Solicited-Node Multicast 사용 → broadcast 불필요.

함정과 베스트 프랙티스

항상 dual-stack 고려: IPv4 + IPv6 동시 지원
MTU 명시: container / VPN 환경에서 1500 가정 위험
traceroute / mtr 활용: 경로 진단의 기본
TTL 짧으면 우회: anycast / CDN 에서 같은 IP 가 여러 위치
PMTUD 깨질 때 MSS clamping: TCP 헤더에서 협상 가능한 최대 크기
private IP 충돌 회피: 사내 다중 사이트 시 RFC 1918 범위 신중 할당
IPv6 ULA: 사설망에선 fd00::/8 권장 (link-local 은 라우팅 안 됨)

김신건의 로그 - 위키 / network

[Network] CORS: Same-Origin Policy, preflight, credentials

정의

Origin = scheme + host + port

Simple Request vs Preflight

Simple Request 조건 (모두 만족)

Preflight 흐름

Response 헤더 가이드

Credentials (cookie / Authorization)

서버 구현 가이드

Express (Node.js)

Spring Boot

nginx

동적 Origin 허용 패턴

SOP 가 막는 것들

CORS vs CSRF

개발 환경 팁

흔한 함정

CORS 디버깅 체크리스트

Private Network Access (PNA)

관련 위키

[Network] HTTP/3: QUIC 위의 HTTP, 0-RTT, connection migration

정의

HTTP 버전 비교

Handshake: 0-RTT의 마법

TCP HoL Blocking vs QUIC Stream 독립

Connection Migration

QPACK 헤더 압축

Alt-Svc: HTTP/3 협상 방법

실전: 서버 설정

nginx (1.25+)

Cloudflare Workers (HTTP/3 자동)

HTTP/3 연결 테스트

도입 현황 (2026)

흔한 함정

관련 위키

[Network] NAT: Network Address Translation

정의

왜 필요한가

종류

SNAT (Source NAT)

DNAT (Destination NAT)

PAT (Port Address Translation, NAPT)

NAT 매핑 테이블

NAT 종류별 동작 차이 (RFC 3489 분류)

클라우드에서의 NAT

AWS

iptables로 Linux NAT 직접 구성

NAT Traversal

STUN (Session Traversal Utilities for NAT)

TURN (Traversal Using Relays around NAT)

ICE (Interactive Connectivity Establishment)

실전 예시: AWS VPC NAT 구성

함정

관련 위키

[Network] WebSocket: HTTP upgrade, frame, ping/pong

정의

Handshake: HTTP Upgrade

Frame 구조

Opcode 목록

Ping / Pong (keep-alive)

Subprotocol

WSS (WebSocket Secure)

실전 예시

Node.js (ws 라이브러리)

Python (websockets)

브라우저 클라이언트

패턴: 채팅 Fan-out

닫기 핸드셰이크

대안 비교

함정

관련 위키

DTLS

정의

왜 TLS가 아닌 DTLS인가

핸드셰이크 플로우

Cookie Exchange (DoS 방어)

버전

사용처

1. WebRTC DataChannel