---
title: "official-doc / IETF RFC 6455 — The WebSocket Protocol"
source_type: official-doc
url: https://www.rfc-editor.org/rfc/rfc6455.html
archive_url:
related_branches: [feature-streaming-response-contract]
related_projects: [ca-skeleton]
tags: [websocket, rfc6455, ietf, full-duplex, tcp, http-upgrade, streaming, protocol, bidirectional]
created: 2026-06-02
last_reviewed: 2026-06-02
---

# IETF RFC 6455 — The WebSocket Protocol

> Layer: `raw/official-docs/` — IETF RFC 6455 (December 2011, Standards Track) 핵심 섹션 발췌.
> Strength 분류: `official-standard` — IETF Standards Track RFC.
> 검증된 요약은 `/ingest` 후 `wiki/concepts/` 에 별도 작성.

## Parent / 활용 branch (필수)

| Branch | 이 자료가 정당화하는 결정 |
|---|---|
| [[raw/branch-notes/feature-streaming-response-contract]] | WebSocket alternative 의 프로토콜 명세 근거 — full-duplex, HTTP Upgrade handshake, frame 구조, TCP 관계, 보안 요구사항 (client masking) |

## 출처 / Source

- 원본 URL: https://www.rfc-editor.org/rfc/rfc6455.html
- Datatracker URL: https://datatracker.ietf.org/doc/html/rfc6455
- 아카이브 URL: (미수집)
- 저자 / 조직: IETF — I. Fette (Google), A. Melnikov (Isode Ltd)
- 발행일: 2011-12 (December 2011, Proposed Standard / Standards Track)
- 마지막 확인일: 2026-06-02

## 왜 저장했는지 / Why archived

`feature-streaming-response-contract` 에서 WebSocket 은 SSE 와 함께 핵심 비교 alternative. RFC 6455 는 WebSocket 의 유일한 normative specification. full-duplex 특성, HTTP → WebSocket upgrade 메커니즘, 클라이언트 프레임 masking 요구사항, TCP 와의 관계를 claim 수준으로 확인하기 위해 보관. 특히 "HTTP 와 독립된 TCP-based 프로토콜" 정의가 ca-skeleton 의 reverse proxy 설정 부담 claim 의 근거.

## 핵심 인용 / Key quotes (verbatim)

> [Abstract] "The WebSocket Protocol enables two-way communication between a client running untrusted code in a controlled environment to a remote host that has opted-in to communications from that code. The security model used for this is the origin-based security model commonly used by web browsers. The protocol consists of an opening handshake followed by basic message framing, layered over TCP."

> [Abstract] "The goal of this technology is to provide a mechanism for browser-based applications that need two-way communication with servers that does not rely on opening multiple HTTP connections (e.g., using XMLHttpRequest or <iframe>s and long polling)."

> [§1.1 Background] "creating web applications that need bidirectional communication between a client and a server (e.g., instant messaging and gaming applications) has required an abuse of HTTP to poll the server for updates while sending upstream notifications as distinct HTTP calls."

> [§1.1 Background] "The server is forced to use a number of different underlying TCP connections for each client: one for sending information to the client and a new one for each incoming message."

> [§1.2 Protocol Overview] "After a successful handshake, clients and servers transfer data back and forth in conceptual units referred to in this specification as 'messages.'"

> [§1.2 Protocol Overview] "this is a two-way communication channel where each side can, independently from the other, send data at will"

> [§1.7 Relationship to TCP and HTTP] "The WebSocket Protocol is an independent TCP-based protocol. Its only relationship to HTTP is that its handshake is interpreted by HTTP servers as an Upgrade request."

> [§5.1 Overview, client masking] "a client MUST mask all frames that it sends to the server"

## Claims Extracted / 추출된 주장

| Claim ID | Claim (이 자료가 직접 말하는 것) | Evidence quote | Strength | Applies to | Does not prove |
|---|---|---|---|---|---|
| RFC6455-C1 | WebSocket 은 client-server 양방향(full-duplex) 통신을 단일 TCP 연결 위에서 제공 — 각 side 가 독립적으로 언제든지 데이터를 송신 가능 | [§1.2] "this is a two-way communication channel where each side can, independently from the other, send data at will" | `official-standard` | WebSocket 연결이 수립된 이후 data transfer phase | HTTP 연결 위에서 동작한다는 뜻은 아님 — handshake 이후 HTTP 와 무관한 독립 프로토콜 (`C5`) |
| RFC6455-C2 | WebSocket 의 탄생 배경: 기존 HTTP polling / long-polling 은 "HTTP 남용(abuse)"으로 서버가 각 클라이언트마다 여러 TCP 연결을 유지해야 했음 | [§1.1] "required an abuse of HTTP to poll the server for updates while sending upstream notifications as distinct HTTP calls." + "server is forced to use a number of different underlying TCP connections for each client" | `official-standard` | long-polling / HTTP polling 을 대체하는 시나리오 | WebSocket 이 항상 HTTP polling 보다 성능이 우수하다는 주장 — 특정 연결 패턴(희소 업데이트)에서는 SSE 나 polling 이 더 적합할 수 있음 |
| RFC6455-C3 | WebSocket 연결 수립은 HTTP Upgrade handshake 로 시작 (GET + Upgrade: websocket → 101 Switching Protocols) 하며, handshake 이후 TCP 연결은 HTTP 가 아닌 WebSocket 프레임 전송에 사용 | [§1.2] "GET /chat HTTP/1.1... Upgrade: websocket... HTTP/1.1 101 Switching Protocols" | `official-standard` | WebSocket 연결 수립 단계 | HTTP/1.1 이 아닌 HTTP/2 / HTTP/3 에서도 동일하게 동작한다는 뜻은 아님 — HTTP/2 위의 WebSocket 은 RFC 8441 별도 처리 |
| RFC6455-C4 | 클라이언트는 서버로 전송하는 모든 프레임을 반드시 마스킹(masking) 해야 한다 (MUST) | [§5.1] "a client MUST mask all frames that it sends to the server" | `official-standard` | WebSocket 클라이언트가 서버로 데이터를 보낼 때 (모든 경우) | 서버 → 클라이언트 방향은 masking 금지 (서버는 mask 하지 않음) |
| RFC6455-C5 | WebSocket 은 HTTP 와 독립적인 TCP-based 프로토콜이며, HTTP 와의 유일한 관계는 handshake 가 HTTP Upgrade request 로 해석된다는 점 | [§1.7] "The WebSocket Protocol is an independent TCP-based protocol. Its only relationship to HTTP is that its handshake is interpreted by HTTP servers as an Upgrade request." | `official-standard` | WebSocket 프로토콜의 계층 관계 | WebSocket 이 기존 HTTP reverse proxy (Nginx 등) 와 자동으로 호환된다는 뜻은 아님 — Upgrade request 처리를 위한 별도 proxy 설정 필요 |
| RFC6455-C6 | WebSocket 기본 포트: 일반 연결 80, TLS 연결 443 | [§1.7] "the WebSocket Protocol uses port 80 for regular WebSocket connections and port 443 for WebSocket connections tunneled over Transport Layer Security (TLS)." | `official-standard` | WebSocket 서버 포트 설정 | HTTP 와 동일 포트를 쓰면 방화벽 문제가 없다는 뜻 — 실제로 대부분의 기업 방화벽은 WebSocket Upgrade 를 별도 정책으로 처리 |

## Usage Boundaries / 적용 경계

- **이 자료가 직접 증명하는 것**:
  - `C1`: WebSocket 은 truly full-duplex — server→client, client→server 동시 가능
  - `C2`: WebSocket 의 존재 이유 = HTTP polling 의 비효율성 제거
  - `C3`: WebSocket 연결 수립은 HTTP Upgrade 필요 — 기존 HTTP/REST infrastructure 와 handshake 단계 공존
  - `C4`: 클라이언트 masking 은 MUST (보안 요구사항) — 구현 복잡도 기여
  - `C5`: handshake 이후 HTTP 와 무관 → reverse proxy 에서 WebSocket 전용 설정 필요
- **이 자료가 증명하지 않는 것**:
  - WebSocket 이 SSE 보다 특정 시나리오에서 항상 더 성능이 좋다는 주장
  - Spring WebSocket 구현 (STOMP 등) 의 구체적 API 동작 — Spring vendor doc 별도
  - Nginx / AWS ALB 에서 WebSocket Upgrade 처리 방법 — 각 proxy 문서 필요
  - HTTP/2 위의 WebSocket (RFC 8441) 동작 — 본 RFC 는 HTTP/1.1 Upgrade 기준
- **내 프로젝트에 적용하려면 추가 확인이 필요한 것**:
  - ca-skeleton 의 reverse proxy (Nginx) 가 `proxy_read_timeout` / `proxy_send_timeout` 을 WebSocket 에 맞게 설정했는지
  - WebSocket connection 수 per-user cap — DoS 방어 관련 (본 RFC 에 명시 없음)
  - Spring 의 `@EnableWebSocket` / STOMP / SockJS fallback 계층 채택 여부 결정

## 메모 / Notes

- `C5` 는 ca-skeleton 에서 WebSocket 도입 시 "reverse proxy 별도 설정 의무" claim 의 official-standard 근거
- `C2` 의 "HTTP polling 남용" 진술은 long-polling alternative 의 단점 비교에서 활용 가능
- HTTP/2 위 WebSocket (RFC 8441) 은 본 문서 범위 밖 — 별도 조사 필요 시 RFC 8441 참조

## Related / 관련

- 같은 주제 다른 raw 자료: [[raw/official-docs/whatwg-html-server-sent-events]] (SSE — 단방향 대안)
- 같은 주제 다른 raw 자료: [[raw/official-docs/rfc9112-http-1-1-chunked-transfer]] (HTTP chunked — 가장 단순한 스트리밍)
- 인용하는 branch: [[raw/branch-notes/feature-streaming-response-contract]]