김신건의 로그 - 위키 / network

[Network] IP: IPv4, IPv6, CIDR

koa (김신건) — Mon, 29 Jun 2026 00:00:00 GMT

정의

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

IPv4

4 개 8bit 옥텟: 192.168.1.1. 총 2³² ≈ 43억 개, 이미 고갈.

표준 주소 범위

클래스	범위	용도
사설 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
멀티캐스트	224.0.0.0/4

CIDR 표기

192.168.1.0/24 = 앞 24 bit 가 네트워크, 뒤 8 bit 가 호스트. 256 개 주소 (실제 254 개 사용).

IPv6

128bit, 2001:0db8:85a3:0000:0000:8a2e:0370:7334 (연속 0 은 :: 로 축약).

주소 수: 2^128 ≈ 3.4 × 10³⁸ 개
서브넷: /64 가 기본 (LAN 하나)
특별 주소: ::1 (loopback), fe80::/10 (link-local), fc00::/7 (unique local)

Public vs Private

Public IP: 인터넷에서 라우팅 가능. ISP 가 할당. Private IP: 로컬 네트워크. NAT 로 public 과 매핑 ([[network-nat|자세히]]).

DHCP

동적 IP 할당 프로토콜. 클라이언트가 요청하면 DHCP 서버가 임차 (lease).

참고

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

[Network] NAT: Network Address Translation

koa (김신건) — Mon, 29 Jun 2026 00:00:00 GMT

정의

NAT (Network Address Translation) 는 IP 주소를 변환하는 기법. 주로 사설 IP 를 public IP 로, 또는 반대로 매핑.

왜 필요한가

IPv4 주소 고갈: 사내 100 대 호스트가 1 public IP 공유
보안: 내부 호스트 은닉
정책: 특정 서비스만 외부 노출

종류

SNAT (Source NAT)

아웃바운드 트래픽의 source IP 를 변경. 홈 라우터 기본 동작:

내부 192.168.1.10:12345 → 203.0.113.5:12345
응답 오면 매핑 테이블 참조하여 원래 클라이언트로 전달

DNAT (Destination NAT)

인바운드 트래픽의 destination IP 를 변경. 포트 포워딩:

외부 203.0.113.5:80 → 내부 192.168.1.10:8080

PAT (Port Address Translation, NAPT)

포트까지 매핑. 한 public IP 를 여러 호스트가 공유:

192.168.1.10:12345 → 203.0.113.5:1001
192.168.1.11:12345 → 203.0.113.5:1002

거의 모든 실제 NAT 는 PAT.

클라우드 NAT

AWS

NAT Gateway: 관리형, 프라이빗 서브넷의 아웃바운드
NAT Instance: 자체 관리 EC2

흐름

private subnet → NAT Gateway (public subnet) → Internet Gateway → Internet

함정

NAT traversal: P2P (WebRTC, BitTorrent) 는 NAT 통과 어려움 → STUN, TURN 서버 필요
Hairpin NAT: 내부에서 자기 public IP 로 접근하는 경우
NAT 만료: 매핑 테이블은 유휴 시 만료 → long-lived TCP 는 keep-alive 필요

참고

[[network-ip|IP]]
[[network-cidr-subnetting|CIDR / 서브네팅]]
[[aws-vpc|AWS VPC]]

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

koa (김신건) — Thu, 25 Jun 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.

흔한 함정

[!WARNING]

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

preflight 응답에 200 보냄 = 보통 204 No Content 가 정석. 200 도 동작은 함.

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

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

로컬 개발 환경 (localhost:3000) 만 허용 으로 프로덕션 cross-origin 미테스트.

CORS vs CSRF

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

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

서버 구현 예시 (Express)


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,
}));

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"> (실행됨)

[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.

[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]].

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.

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]] 참고.

흔한 함정

[!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 필수.

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

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

정의

HTTP/3 (2022, RFC 9114) 는 HTTP 의 전송 레이어를 TCP → QUIC 으로 교체한 버전. UDP 위에 QUIC, QUIC 위에 HTTP.

핵심 동기: TCP HoL blocking 해결 + 0-RTT 핸드셰이크 + connection migration (IP 변경 시 연결 유지).

flowchart TB
    HTTP[HTTP semantics] --> QUIC[QUIC<br/>multi-streams + crypto + congestion]
    QUIC --> UDP[UDP]
    UDP --> IP[IP]

QUIC 의 핵심 (1분 요약)

{}

특성	TCP+TLS+HTTP/2	QUIC+HTTP/3
핸드셰이크	3-way + TLS = 2-3 RTT	1 RTT (또는 0-RTT 재방문)
HoL Blocking	TCP 레벨 발생	stream 별 독립
Connection migration	불가	가능 (NAT 변경, WiFi → 4G)
암호화	옵션	필수 (TLS 1.3 통합)
패킷 손실 영향	모든 stream 대기	해당 stream 만
구현 위치	OS (TCP) + 라이브러리 (TLS)	전부 user-space (배포 빠름)

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 request
    S-->>C: HTTP response
    end

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

[!CAUTION] 0-RTT 데이터는 replay 공격에 취약. 비멱등 요청 (POST 결제) 은 반드시 1-RTT 후 처리. GET / HEAD 같은 안전한 method 만 0-RTT 권장.

TCP HoL vs QUIC stream 독립

flowchart TB
    subgraph T["TCP (HTTP/2)"]
        TS["stream 1, 3, 5 가<br/>같은 TCP 시퀀스 안"]
        TPacket1[패킷 1: 일부 stream 1]
        TPacket2[패킷 2: 일부 stream 3, *손실!*]
        TPacket3[패킷 3: 일부 stream 5]
        TS --> TPacket1 & TPacket2 & TPacket3
        TPacket2 -.->|"모든 stream 대기"| Block1["모든 stream 대기"]
    end
    subgraph Q["QUIC (HTTP/3)"]
        QS["stream 1, 3, 5 가<br/>각자 시퀀스"]
        QPacket1[패킷 1: stream 1 ✓]
        QPacket2[패킷 2: stream 3, *손실*]
        QPacket3[패킷 3: stream 5 ✓]
        QS --> QPacket1 & QPacket2 & QPacket3
        QPacket2 -.->|stream 3 만 대기| Block2["stream 1, 5 계속"]
    end

Connection Migration

WiFi → 4G 전환, NAT 재할당 시 연결 유지. Connection ID 가 src IP/port 와 무관.

sequenceDiagram
    Client->>Server: WiFi IP 192.168.1.10:54321 (conn_id=XYZ)
    Server-->>Client: 응답 (conn_id=XYZ)
    Note over Client: 지하철 진입, 4G 전환
    Client->>Server: 4G IP 10.0.0.5:65432 (conn_id=XYZ)
    Server-->>Client: 응답 (같은 connection 이어감)
    Note over Client,Server: TLS / 세션 유지, 처음부터 다시 안 함

QPACK 헤더 압축

HPACK 의 순서 의존성 문제 를 해결한 변형. encoder/decoder stream 분리.

HPACK	QPACK
헤더가 정확한 순서	stream 독립 디코딩 가능
인덱스 갱신 → 모든 stream 영향	별도 stream 으로 동기화

도입 현황 (2026)

영역	비중
Cloudflare / Fastly / Akamai (CDN)	기본 활성
모바일 앱 (gRPC, 자체 클라이언트)	빠르게 증가
일반 웹 사이트 (브라우저 트래픽)	약 35%+
기업 내부 (방화벽 UDP 차단)	더딤

[!NOTE] 방화벽이 UDP 를 차단 하면 HTTP/3 fallback → HTTP/2 (TCP). 도입의 가장 큰 현실 장벽.

흔한 함정

[!WARNING]

방화벽 / 미들박스의 UDP 차단 = 사내망에서 H3 가 안 되는 가장 흔한 이유.

0-RTT 의 replay 위험 = POST / DELETE 등 비멱등은 0-RTT 거절.

Connection ID 가 식별자처럼 쓰임 = 추적 / privacy 우려. RFC 가 주기적 변경 권장.

부하 분산기의 UDP 5-tuple 해싱 = NAT 변경 시 다른 백엔드 로. connection ID 기반 라우팅 필요.

[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) 로 옮기는 게 정통.

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

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

정의

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

{}

7 Layer 매트릭스

Layer	이름	단위	예	도구
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	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, gRPC, DNS, SMTP, SSH.

HTTP: GET /api/users HTTP/1.1
DNS: A example.com → 93.184.216.34
gRPC: /shop.Shop/GetItem over HTTP/2

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

L6 Presentation

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

TLS (실제로는 L4-L7 사이)
JSON, Protobuf, MessagePack
gzip, deflate

L5 Session

세션 관리. 현대에서는 L7 의 일부 또는 애플리케이션 자체 가 담당. (HTTP cookie, JWT 등)

L4 Transport

end-to-end 신뢰성 + flow control.

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

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

L3 Network

IP 라우팅. 어떤 경로로 패킷이 갈지. 라우터의 영역.

IPv4, IPv6
ICMP (ping, traceroute)
BGP (인터넷 라우팅 프로토콜)
OSPF, IS-IS (내부 라우팅)

자세한 건 [[IP]].

L2 Data Link

같은 LAN 안 의 MAC 주소 기반 통신. Switch, WiFi AP.

Ethernet (IEEE 802.3)
WiFi (IEEE 802.11)
ARP (IP → MAC 매핑)
VLAN (Virtual LAN)

L1 Physical

실제 전기 / 광 신호. 케이블, 무선, 광섬유.

패킷의 캡슐화

flowchart TB
    L7Msg["L7 HTTP: GET /api/x"]
    L7Msg -->|L6/L5| L7Frame["+ TLS 암호화"]
    L7Frame -->|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]

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

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

문제 진단의 층 별 도구:

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`	L3
`nc / telnet host port`	L4
`nmap`	L4
`openssl s_client`	L6 (TLS)
`curl -v`	L7 (HTTP)
`dig / nslookup`	L7 (DNS)
`tcpdump / wireshark`	L2-L7 (raw)

흔한 함정

[!WARNING]

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

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

HTTPS 인증서 문제를 방화벽 탓 = openssl s_client 로 handshake 만 따로 확인.

DNS 가 L7 인지 L3 인지 헷갈림 = L7 (애플리케이션). UDP/TCP 53 위에서.

[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 복잡도

[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));
});

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 문제 해결.

활용

알림 / 토스트: 새 알림이 도착했을 때 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 쿼리 또는 쿠키.

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

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

정의

WebSocket (RFC 6455) 은 HTTP/1.1 upgrade 로 시작 하는 양방향 영속 메시지 채널. 한 TCP 위에서 서버 ↔ 클라이언트 임의 시점 push 가능.

활용: 실시간 채팅, 트레이딩 시세, 게임, 알림, 공동 편집, 라이브 대시보드.

Handshake: HTTP Upgrade

sequenceDiagram
    autonumber
    participant C as Client
    participant S as Server

    C->>S: GET /chat HTTP/1.1<br/>Upgrade: websocket<br/>Connection: Upgrade<br/>Sec-WebSocket-Key: dGhlIHNhbXBsZSBub25jZQ==<br/>Sec-WebSocket-Version: 13
    S-->>C: 101 Switching Protocols<br/>Upgrade: websocket<br/>Connection: Upgrade<br/>Sec-WebSocket-Accept: s3pPLMBiTxaQ9kYGzzhZRbK+xOo=
    Note over C,S: 이후 같은 TCP 위에서<br/>WS frame 양방향 교환
    C->>S: WS frame (text/binary)
    S->>C: WS frame (서버 push)

Sec-WebSocket-Accept = base64(SHA-1(key + “258EAFA5-E914-47DA-95CA-C5AB0DC85B11”)). handshake 무결성 검증.

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 ...                :
+ - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - +
|                     Payload Data continued ...                |
+---------------------------------------------------------------+

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

[!IMPORTANT] 클라이언트 → 서버 frame 은 반드시 MASK (XOR with 4-byte key). cache poisoning 방지 목적. 서버 → 클라이언트 는 unmask.

Ping / Pong (keep-alive)

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

[!TIP] NAT timeout 또는 프록시 idle close 를 방지. 보통 30~60초 간격. NAT 일반 idle timeout 이 60s 이므로.

Subprotocol

Sec-WebSocket-Protocol: chat, soap

서버가 선택해서 응답 헤더에 같은 것 반환. 클라이언트가 프로토콜 분기 (예: GraphQL over WS, MQTT over WS).

WSS (WebSocket Secure)

wss:// = WebSocket over TLS. 운영에서는 거의 필수:

일부 ISP / 프록시가 ws:// 를 차단
mixed content (https 페이지에서 ws://) 브라우저 거부
대부분의 WAF / LB 가 wss 에 최적화

흔한 함정

[!WARNING]

Idle timeout 사고 = ALB/nginx 의 60초 default 가 silent close. PING/PONG 간격 < idle timeout 필수.

Backpressure 부재 = 서버가 빠르게 send → 클라이언트 buffer 폭발. application 레벨 flow control (ACK / credit) 필요.

Sticky session 필요 = 같은 사용자가 같은 노드. LB cookie 또는 IP hash. 또는 connection ID + Redis pub/sub 으로 fan-out.

CORS 가 WebSocket 에 그대로 적용 안 됨 = Origin 헤더는 수동 검증. 미검증 시 CSRF.

패턴: 채팅 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 -->|Redis PUB| Redis[(Redis Pub/Sub)]
    N2 -->|Redis SUB| Redis
    N1 -->|Redis SUB| Redis
    Redis -->|fan-out| N1 & N2

자세한 fan-out 은 [[Redis Pub Sub vs Streams]] 참고.

대안 비교

기술	방향	영속성	사용
WebSocket	양방향	영속	채팅, 게임, 트레이딩
SSE	서버 → 클라이언트	영속	알림, 라이브 피드
Long polling	양방향 (서버에서 hold)	짧음	legacy fallback
HTTP/2 server push	폐기	-	-
WebRTC DataChannel	양방향 P2P	영속	게임, 파일

자세한 건 [[realtime-comparison]] 참고.

[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 운영 필수.

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

음성 에이전트 + 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.

흔한 함정

[!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 보급 가속 이유.

함정과 베스트 프랙티스

항상 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 은 라우팅 안 됨)

TLS / SSL

koa (김신건) — Mon, 15 Jun 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 만 남았다.

인증서 체인 검증

{}

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

도메인 일치 확인: 인증서의 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 가 사실상 표준이 되었다.

[[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 보다 빠르다.

약점과 주의점

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

DTLS

koa (김신건) — Sat, 13 Jun 2026 00:00:00 GMT

정의

DTLS (Datagram Transport Layer Security)는 [[UDP]] 위에서 동작하는 [[TLS]] 의 변형. 데이터그램 (UDP 패킷) 기반 통신에 보안을 제공한다.

[[QUIC]] 와 WebRTC DataChannel 등이 사용한다. TLS 와 거의 같은 보안 보장 (서버 인증, 키 교환, 암호화, 무결성)을 제공하지만 UDP 의 특성 (비순서, 손실, 비신뢰)을 다룬다.

왜 TLS 가 아닌 DTLS 인가

TLS 는 [[TCP]] 의 “순서 보장된 신뢰성 있는 stream” 위에서 설계되었다.

TLS 핸드셰이크 메시지는 정확한 순서로 수신될 것을 가정
TLS record 의 sequence number 는 암묵적 (보내지 않음, TCP 가 순서 보장)

UDP 환경에서는 이런 가정이 깨진다.

패킷 순서가 바뀜
패킷이 손실됨
패킷이 중복됨

DTLS 는 이를 다루기 위해:

TLS	DTLS
핸드셰이크 순서 가정	핸드셰이크 메시지 번호화 + 재전송
sequence number 암묵	sequence number 명시적 (record 헤더에 포함)
손실 가정 안 함	record 손실/중복 허용
record fragmentation X	record fragmentation 지원 (MTU 대응)

버전

버전	출시	기반 TLS
DTLS 1.0	2006	TLS 1.1
DTLS 1.2	2012	TLS 1.2
DTLS 1.3	2022 (RFC 9147)	TLS 1.3

DTLS 1.3 은 TLS 1.3 의 1-RTT / 0-RTT 핸드셰이크 개선을 그대로 가져왔다.

사용처

1. WebRTC DataChannel

브라우저 간 P2P 데이터 채널은 모두 DTLS 로 암호화된다. 시그널링으로 키 교환 fingerprint 를 미리 합의 → DTLS 핸드셰이크로 키 확립 → SCTP 데이터 송수신.

2. [[QUIC]] (간접적)

QUIC 은 TLS 1.3 핸드셰이크를 직접 통합 (DTLS 가 아닌). 그러나 비슷한 “UDP 위 보안” 문제를 같은 방식으로 해결한다.

3. VPN / IoT

OpenVPN UDP 모드, CoAP (IoT 프로토콜) 등이 DTLS 사용.

4. 미디어 (SRTP-DTLS)

WebRTC 의 미디어 채널은 SRTP 로 암호화되지만, SRTP 의 키는 DTLS 핸드셰이크로 합의한다 (DTLS-SRTP).

DTLS 의 한계

재전송 비용: 핸드셰이크 패킷 손실 시 재전송 → 초기 연결이 TCP+TLS 보다 느릴 수 있음
MTU 의존: UDP 패킷이 MTU 를 넘으면 IP fragmentation → 큰 핸드셰이크 record 는 분할 필요
DoS 공격 노출: UDP 는 spoofing 이 쉬워 핸드셰이크 시 cookie 메커니즘으로 보호 (HelloVerifyRequest)

Head-of-Line Blocking

koa (김신건) — Sat, 13 Jun 2026 00:00:00 GMT

정의

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

네트워크 프로토콜에서는 여러 층에서 발생할 수 있다.

HTTP/1.1 의 HOL Blocking

한 TCP 연결로 여러 요청을 순차 처리 (pipelining 사용해도), 첫 요청의 응답이 느리면 그 뒤 요청들도 모두 대기.

Request 1 →  (서버에서 5초 처리 중)
Request 2 →  (대기)
Request 3 →  (대기)
              ...
Response 1 ←
Response 2 ←  ← 5초 뒤에야 처리 시작
Response 3 ←

브라우저가 도메인당 6개 TCP 연결을 만드는 이유의 일부.

HTTP/2 가 해결한 것

HTTP/2의 multiplexing은 HTTP 레벨의 HOL Blocking을 해결한다. 한 TCP 연결에서 stream ID로 구분된 frame을 인터리브해 송수신.

그러나 TCP 레벨의 HOL Blocking은 여전히 남는다. 한 TCP 패킷이 손실되면, 그 패킷이 어느 stream에 속하든 TCP는 순서를 유지하기 위해 모든 stream의 후속 패킷을 대기시킨다.

[[QUIC]] 가 해결한 것

QUIC은 stream 격리를 본격적으로 구현한다. UDP 위에서 각 stream이 자기 sequence number와 ACK을 따로 관리. 한 stream의 패킷 손실은 다른 stream에 영향 없음.

→ HTTP/3 (QUIC 위에서 동작)이 TCP의 HOL Blocking을 근본적으로 해결.

다른 사례

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

데이터베이스의 단일 큐 워커
메시지 브로커의 partition 단위 순차 처리
멀티스레드 작업에서 ordered 처리

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

HPACK

koa (김신건) — Sat, 13 Jun 2026 00:00:00 GMT

정의

HPACK (RFC 7541)은 HTTP/2 에서 요청·응답 헤더를 압축하기 위해 설계된 방식.

HTTP/1.1 의 헤더는 매 요청마다 텍스트로 반복 전송되었다 (한 페이지 로드에 수십 KB가 헤더만으로 사용). HPACK 은 이를 동적·정적 인덱스 테이블로 줄인다.

압축 원리

Static Table

자주 쓰이는 헤더 이름·값 조합을 미리 정의한 고정 인덱스 (61개).

1: :authority
2: :method GET
3: :method POST
4: :path /
5: :path /index.html
...

요청에 :method GET 이 있으면 그냥 인덱스 2 한 바이트만 전송.

Dynamic Table

연결 단위로 유지되는 헤더 캐시. 처음 보낸 헤더는 인덱스로 등록되고, 다음 요청부터는 인덱스로만 전송.

Huffman 인코딩

문자열로 전송해야 할 경우 Huffman 코드로 압축. ASCII에 최적화되어 보통 ~30% 추가 절약.

효과

시나리오	HTTP/1.1	HTTP/2 + HPACK
페이지 로드 (50 요청, 각 헤더 ~700B)	~35 KB 헤더	~3-5 KB
모바일 네트워크 (TCP slow start 단계)	큰 영향	작은 영향
동일 호스트 반복 요청	반복 비용	거의 0

HTTP/2 의 multiplexing 외의 두 번째 큰 성능 이득.

보안 이슈

HPACK 의 dynamic table 은 CRIME/BREACH 같은 사이드 채널 공격 방어를 위해 일부 제약을 둔다 (예: 압축률을 외부에서 측정해 헤더 값을 추측하는 공격). RFC 7541 §7 의 보안 고려사항 참조.

HTTP/3 의 [[QUIC]] 환경에서는 HPACK 의 stream 간 의존성 문제를 해결한 QPACK (RFC 9204) 이 사용된다.

QUIC

koa (김신건) — Sat, 13 Jun 2026 00:00:00 GMT

정의

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

기존 TCP가 가지는 문제들을 OS 커널 수정 없이(=사용자 영역에서) 해결하기 위해 UDP 위에 구현되었다.

핵심 특성

Stream 격리: 한 연결 안에 여러 독립적인 stream. 한 stream의 패킷 손실이 다른 stream에 영향을 주지 않음 → TCP의 [[Head-of-Line Blocking]] 문제 해결
TLS 1.3 통합: 전송과 암호화 핸드셰이크가 분리되어 있지 않다. 최초 연결도 1-RTT, 재접속은 0-RTT 가능
Connection ID: IP나 포트가 바뀌어도 (와이파이 ↔ 셀룰러 전환) 같은 ID로 같은 연결 유지 (Connection Migration)
사용자 영역 구현: 브라우저·서버가 직접 구현 → OS 업데이트 없이 새 기능 배포 가능

TCP 대비 장점

	TCP	QUIC
전송	OS 커널	사용자 영역 (라이브러리)
HOL Blocking	있음	Stream 단위로 격리
최초 핸드셰이크	TCP 3-way + TLS = 2-3 RTT	1 RTT (TLS 통합)
재접속	1 RTT	0 RTT (TLS 1.3 세션 티켓)
Connection 식별	(IP, Port) 튜플	Connection ID
IP 변경 시	연결 끊김	Migration으로 유지

약점·주의점

UDP 차단: 일부 기업 방화벽은 UDP를 막거나 throttling함 → HTTP/3 ↔ HTTP/2 fallback 필요
CPU 부담: 사용자 영역 구현이라 패킷 처리 CPU 비용이 TCP보다 클 수 있음 (커널 우회 효과는 일부)
NAT rebinding: Connection Migration이 NAT 동작과 충돌할 수 있음

사용 사례

HTTP/3 (Google, Facebook, Cloudflare 등 대형 CDN)
WebTransport (브라우저 양방향 stream 신 API)
일부 게임·실시간 미디어 프로토콜

TCP

koa (김신건) — Sat, 13 Jun 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): 네트워크 혼잡 시 송신 속도 조절 (TCP Reno, Cubic, BBR 등)

3-way Handshake (연결 수립)

{}

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

Client                          Server
   │── SYN  (seq=x)  ────────────→ │
   │ ←──── SYN-ACK (seq=y, ack=x+1) ─── │
   │── ACK (ack=y+1) ────────────→ │
   ←── 데이터 송수신 가능 ──→

4-way Handshake (연결 종료)

{}

각 방향 (C→S, S→C)을 독립적으로 종료하므로 4단계가 필요. Client 는 마지막에 TIME_WAIT 상태로 2×MSL 동안 대기, 지연 패킷이 새 연결을 오염시키지 않게 하기 위함.

TCP 의 한계

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

사용처

HTTP/1.1, HTTP/2 (HTTPS 포함)
WebSocket (HTTP Upgrade 후 TCP 그대로 사용)
SSH, SMTP, FTP
Database 프로토콜 대부분 (PostgreSQL, MySQL wire protocol)

UDP

koa (김신건) — Sat, 13 Jun 2026 00:00:00 GMT

정의

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

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

핵심 특성

비연결(Connectionless): 핸드셰이크 없음, 즉시 송신
비순서: 수신 순서 보장 없음
비신뢰: 손실되어도 재전송 없음
가벼움: 헤더 8 bytes (TCP 의 20+ bytes 와 비교)
단순함: 흐름 제어 / 혼잡 제어 없음

헤더 구조

{}

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

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

전송 방식, Fire-and-Forget

{}

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

언제 UDP 를 쓰는가

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

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

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

QUIC, WebRTC SCTP, 게임 엔진의 reliable UDP, 모두 UDP 위에서 TCP 와 유사한 기능을 직접 구현한다. 왜?

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

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

김신건의 로그 - 위키 / network

[Network] IP: IPv4, IPv6, CIDR

정의

IPv4

표준 주소 범위

CIDR 표기

IPv6

Public vs Private

DHCP

참고

[Network] NAT: Network Address Translation

정의

왜 필요한가

종류

SNAT (Source NAT)

DNAT (Destination NAT)

PAT (Port Address Translation, NAPT)

클라우드 NAT

AWS

흐름

함정

참고

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

정의

Origin = scheme + host + port

Simple Request vs Preflight

Simple Request 조건 (모두 만족):

Preflight 흐름

Response 헤더 가이드

Credentials (cookie / Authorization)

흔한 함정

CORS vs CSRF

서버 구현 예시 (Express)

SOP 가 막는 것들

관련 위키

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

정의

Proto 정의

4가지 Streaming 패턴

HTTP/2 위 동작

Status Code

Deadline (timeout)

gRPC vs REST

gRPC-Web

흔한 함정

관련 위키

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

정의

메시지 구조

Keep-Alive (Persistent Connection)

Pipelining (구현 함정)

Content-Length vs Chunked

상태 코드 카테고리

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

흔한 함정

관련 위키

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

정의

Binary Framing

Multiplexing

HPACK 헤더 압축

Server Push (사실상 폐기)

h2 vs h2c

Flow Control

흔한 함정

관련 위키

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

정의

QUIC 의 핵심 (1분 요약)

Handshake: 0-RTT 의 마법

TCP HoL vs QUIC stream 독립

Connection Migration

QPACK 헤더 압축

도입 현황 (2026)

흔한 함정

관련 위키

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

정의

L4 vs L7

알고리즘