RFC 6455 / START HERE
WebSocket, before the details
WebSocket
WebSocket lets a browser or another client keep a two-way message connection open with a server. Either side can send messages after setup.
The idea in one picture
A client opens a connection
Both sides can send messages
Updates arrive without polling
A simplified picture of the idea; the chapters explain the actual mechanisms.
Why it exists
Some applications need new information immediately instead of repeatedly asking whether anything changed.
A familiar example
A chat page receives a new message over an existing connection without refreshing the page.
Helpful background
You can start here without reading another RFC. If these ideas are unfamiliar, these short introductions may help.
What you’ll learn next
Begin with chapter one, or choose a topic.
- Opening handshakeThe client requests WebSocket version 13. A valid switching response proves the server understood this handshake.→
- Messages in both directionsOnce established, either endpoint can send a message without waiting for a new HTTP request.→
- Frame fieldsFIN, opcode, mask state, length, and optional masking key let the receiver interpret one frame.→
- Fragments and control framesA large message can be fragmented while Ping and Pong remain responsive between fragments.→
- Client maskingEach client frame uses a new unpredictable masking key, repeated across its payload bytes.→
- Closing the connectionClose frames coordinate shutdown before the underlying TCP connection is closed.→
This introduction explains RFC 6455 (2011). Read the original RFC ↗