RFC 6455 / ESTABLISH A CONNECTION

Opening handshake

The client requests WebSocket version 13. A valid switching response proves the server understood this handshake.

Related RFCs and changes

“Updates” changes part of an earlier RFC. “Obsoletes” replaces it. This list shows selected related documents.

DIAGRAM§ 4 ↗

RFC 6455 · § 4EXAMPLE

3 / 3

Enter the framed protocol.

Application data uses WebSocket frames after the opening handshake succeeds.

Protocol participantThreat or exceptionProtocol controlSimplified drawings · precise section references

WHAT CHANGED

RFC 6455 §4RFC 8441 §5

The later HTTP/2 bootstrap uses extended CONNECT with :protocol set to websocket. It replaces the HTTP/1.1 Upgrade and 101 exchange for that mapping; it does not define WebSocket version 14.

Read the updated RFC section ↗

KEY POINT

Validate the handshake before sending WebSocket data.

The HTTP/1.1 handshake uses GET, Upgrade: websocket, Connection: Upgrade, and Sec-WebSocket-Version: 13.
The server returns 101 and a Sec-WebSocket-Accept value derived from the client key and a fixed GUID; the client checks it.
Origin checks protect browser-based use, but Origin is not authentication for arbitrary non-browser clients. Use wss for TLS protection.

DETAILS

The key/accept exchange is a protocol check, not password authentication. Applications still need their own authorization policy. Subprotocols and extensions must be negotiated explicitly.

Read the RFC section ↗

Diagrams simplify the RFC. Read the linked sections for complete requirements.

Privacy

All chapters in this RFC