(0) WebSocket 시리즈 용어집

WebSocket 프로토콜 시리즈의 용어집. 모든 레슨은 이 용어집의 표기를 따른다. 새 용어는 등장한 레슨에서 추가된다.

핸드셰이크

열림 핸드셰이크 (opening handshake)

WebSocket 연결을 시작하는 HTTP/1.1 형식의 요청/응답 교환. 성공하면 연결이 WebSocket 프로토콜로 전환된다. — RFC 6455 §4

Upgrade

HTTP/1.1의 프로토콜 전환 메커니즘. Upgrade: websocket + Connection: Upgrade 헤더 쌍으로 요청한다. — §4.1

101 Switching Protocols

서버가 프로토콜 전환을 수락했음을 알리는 상태 코드. 이 응답 이후 해당 TCP 연결에는 WebSocket 프레임만 흐른다. — §4.2

Sec-WebSocket-Key

클라이언트가 연결마다 새로 만드는 무작위 16바이트의 base64 값. 인증이 아니라 상대 서버의 WebSocket 이해 여부를 검증하기 위한 것. — §1.3

Sec-WebSocket-Accept

base64(SHA1(Key + 고정 GUID)) 로 계산되는 서버의 증명값. 틀리면 클라이언트는 연결을 실패 처리한다. — §1.3

부트스트랩 (bootstrapping)

기존 프로토콜을 발판 삼아 새 프로토콜 연결을 시동하는 절차. WebSocket은 맨땅이 아니라 HTTP 대화 위에서 시작한다: HTTP/1.1에서는 Upgrade 핸드셰이크, HTTP/2·3에서는 Extended CONNECT가 그 발판이다. — RFC 8441

전송 계층

TLS (Transport Layer Security)

TCP 위에 끼워 넣는 암호화 층 (구명칭 SSL). 암호화·무결성·서버 신원 확인을 제공한다. TCP+TLS+HTTP = https, TCP+TLS+WebSocket = wss. https 페이지는 mixed content 차단 때문에 wss만 쓸 수 있다. — RFC 8446

ws 와 wss

WebSocket URI 스킴 (ws://, wss://). 기본 포트는 각각 80, 443. wss는 TLS 위에서 동작한다. — §3

표준화 기구와 문서

IETF

인터넷 프로토콜(TCP, DNS, TLS, HTTP, WebSocket 프로토콜 등)의 표준화 기구. 표준을 RFC라는 번호 붙은 고정 문서로 발행한다. 브라우저와 무관하게 "기계끼리의 바이트"를 정한다. — ietf.org

WHATWG

브라우저 벤더들이 주도하는 웹 플랫폼 표준화 기구. HTML, DOM, fetch, WebSocket API 등을 Living Standard(계속 갱신되는 문서)로 관리한다. 2019년 W3C로부터 HTML/DOM 권한을 이양받았다. — whatwg.org

RFC 6455

WebSocket 와이어 프로토콜의 규범 문서. IETF 표준, 2011년 발행. 현재 버전 번호는 13. — IETF

WHATWG WebSockets Standard

브라우저 WebSocket API(생성자, 이벤트, readyState)의 규범 문서. HTML Standard에서 분리된 리빙 스탠다드. — WHATWG

프레임

프레임 (frame)

WebSocket 데이터의 최소 전송 단위. 최소 2바이트 헤더(FIN, opcode, MASK, 길이) + 페이로드로 구성된 바이너리 구조. — §5.2

opcode

프레임 헤더의 4비트 필드로, 페이로드 해석 방법을 지정. 데이터: 0x0 Continuation, 0x1 Text(UTF-8), 0x2 Binary. 컨트롤: 0x8 Close, 0x9 Ping, 0xA Pong. — §5.2

FIN

프레임 헤더의 첫 비트. 1이면 메시지의 마지막 조각, 0이면 단편화된 조각이 더 이어진다. — §5.2

마스킹 (masking)

클라→서버 프레임의 페이로드를 무작위 4바이트 키와 XOR하는 것 (페이로드[i] XOR 키[i mod 4]). 암호화가 아니라 중간 프록시 캐시 오염 방지 장치. 클라→서버 필수, 서버→클라 금지. — §5.3, §10.3

컨트롤 프레임 (control frame)

opcode 0x8~0xF인 프레임 (Close, Ping, Pong). 페이로드 125바이트 이하, 단편화 금지, 데이터 메시지의 조각 사이에 끼어들 수 있다. — §5.5

Ping과 Pong

생존 확인용 컨트롤 프레임 쌍 (0x9/0xA). Ping 수신 시 동일 페이로드의 Pong 응답이 MUST (Close를 이미 받았으면 면제). 브라우저는 자동 응답하며 JS에 노출하지 않는다. — §5.5.2–3

단편화 (fragmentation)

하나의 메시지를 여러 프레임(청크)으로 쪼개 보내는 것 — HTTP chunked 전송과 같은 발상. 첫 조각(FIN=0, 실제 opcode) → 중간(FIN=0, 0x0) → 마지막(FIN=1, 0x0). 브라우저 API에서는 보이지 않는다. — §5.4

keepalive

하트비트 (heartbeat, keepalive)

주기적 트래픽으로 (1) 중간 장비의 유휴 타임아웃을 막고 (2) 죽은 연결을 조기 감지하는 기법. 브라우저에 ping API가 없어 클라이언트 쪽은 앱 수준 메시지로 구현한다. 최악 감지 지연 ≈ 주기 + 타임아웃. — §5.5.2

반열림 연결 (half-open connection)

한쪽이 죽었지만 상대는 통지받지 못한 TCP 연결. 트래픽이 없으면 유휴와 구분 불가능 — 하트비트가 필요한 근본 이유.

종료와 재연결

종료 핸드셰이크 (closing handshake)

Close 프레임(0x8)을 서로 주고받은 뒤 TCP를 닫는 정상 종료 절차. 완료 후 닫히면 clean close. Close를 보내거나 받는 순간 CLOSING 상태가 된다. — §7.1.2

close code

Close 프레임 페이로드 첫 2바이트의 16비트 정수. 종료 이유를 전달한다. 1000 정상, 4000–4999 앱 자유. 1005/1006/1015는 와이어 금지(로컬 합성 전용). — §7.4

지수 백오프 (exponential backoff)

재시도 간격을 지수적으로 늘리는 전략. 비정상 종료 후 재연결에 랜덤 초기 지연과 함께 스펙이 SHOULD로 권고 — 동시 재연결 쇄도가 서버 복구를 막는 것을 방지. — §7.2.3

브라우저 API

readyState

브라우저 WebSocket 객체의 상태: 0 CONNECTING, 1 OPEN, 2 CLOSING, 3 CLOSED. RFC의 연결 상태 기계를 API로 노출한 것. — WHATWG

wasClean

CloseEvent의 불리언 속성. 종료 핸드셰이크가 완료된 뒤 TCP가 닫혔는지(clean close 여부)를 나타낸다. false + 1006이면 비정상 끊김. — WHATWG

HTTP/2·3 위의 WebSocket

SETTINGS 프레임

HTTP/2·3 연결 수립 직후 양쪽이 교환하는 설정값 목록(동시 스트림 수, 버퍼 크기 등). RFC 8441은 여기에 SETTINGS_ENABLE_CONNECT_PROTOCOL(0x8)을 추가 — 서버가 1로 보내면 Extended CONNECT 지원을 사전 선언(능력 광고)하는 것. — RFC 8441 §3

Extended CONNECT

HTTP 버전이 아니라 요청 방식의 이름. 프록시 터널용 메서드였던 CONNECT에 :protocol 의사 헤더를 더해, 스트림 하나를 "지정한 프로토콜을 말하는 터널"로 만드는 확장. HTTP/2·3에서 WebSocket을 시작하는 유일한 문이다. — RFC 8441 §4

의사 헤더 (pseudo-header)

HTTP/2·3에서 요청 줄("GET /chat HTTP/1.1")을 대신하는 : 접두사 헤더들 — :method, :path, :scheme, :authority, 그리고 RFC 8441이 추가한 :protocol. 일반 헤더보다 항상 앞에 온다. — RFC 9113 §8.3

압축 확장

확장 (extension)

핸드셰이크의 Sec-WebSocket-Extensions 헤더로 협상하는 프로토콜 추가 기능. 클라이언트가 제안, 서버가 파라미터를 조정해 수락. 수락되지 않으면 비압축 등 기본 동작으로 정상 진행 — 협상 실패 ≠ 연결 실패. — RFC 6455 §9

RSV1 (Per-Message Compressed)

프레임 헤더의 예약 비트 중 첫째. RFC 7692가 "이 메시지는 압축됨" 표시로 할당했다. 압축 메시지의 첫 프레임에만 1 — 비첫 조각·컨트롤 프레임에는 설정 금지(MUST NOT). — RFC 7692 §6

permessage-deflate

메시지 페이로드를 DEFLATE로 압축하는 유일한 표준 확장. 꼬리 4바이트(00 00 ff ff)를 잘라 보내고 수신 쪽이 복원한다. 컨트롤 프레임은 압축 대상이 아니다. — RFC 7692

context takeover

이전 메시지 압축에 쓴 LZ77 슬라이딩 윈도우(최근 바이트의 기억, 최대 32KB)를 다음 메시지에 재사용하는 것. 반복 JSON의 압축률을 크게 높이는 대신 연결마다 메모리를 상주시킨다. *_no_context_takeover·*_max_window_bits 파라미터가 이 트레이드오프의 조절 손잡이. — RFC 7692 §7

기타 표기

0x 표기 (hexadecimal)

"뒤 숫자는 16진수"라는 접두어. 16진수 한 자리 = 정확히 4비트 (0x0=0000 ~ 0xF=1111), 1바이트 = 두 자리. opcode(4비트)가 0x1처럼 한 자리로 표기되는 이유. 예: 0x81 = 1000 0001.

시리즈 글: 레슨 1 — WebSocket은 HTTP인가? 열림 핸드셰이크 · 레슨 2 — 프레임 구조: opcode와 마스킹 · 레슨 3 — 종료 핸드셰이크와 close code · 레슨 4 — ping/pong과 keepalive · 레슨 5 — HTTP/2·3 위의 WebSocket · 레슨 6 — 확장: permessage-deflate