RFC 8441 / START HERE
WebSockets over HTTP/2, before the details
WebSockets over HTTP/2. HTTP means Hypertext Transfer Protocol; WebSocket is a protocol name, not an acronym.
This RFC lets a client open a WebSocket, a two-way channel for application messages, on one stream within an HTTP/2 connection. A stream is an individually identified conversation sharing that connection.
The idea in one picture
Server enables the extension
Client opens one stream
WebSocket shares the connection
A simplified picture of the idea; the chapters explain the actual mechanisms.
Why it exists
The original WebSocket opening switches an entire HTTP/1.1 connection. HTTP/2 shares a connection across streams, so it needs an opted-in CONNECT handshake that changes just one stream.
A familiar example
A live chat can share an HTTP/2 connection with ordinary page requests. Both endpoints must support the extension; sharing does not supply login, remove WebSocket framing or make streams independent of TCP delivery.
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.
- Wait for server opt-inA server setting enables Extended CONNECT on new streams. A client must learn that support before using the extension.→
- Replace the opening handshakeExtended CONNECT names the WebSocket service and target URI; a successful response opens this stream for WebSocket traffic.→
- Carry WebSocket frames in DATAWebSocket frames remain WebSocket frames. Their bytes travel inside HTTP/2 DATA on the connected stream.→
- Close one stream, keep the connectionA WebSocket uses one HTTP/2 stream, while other streams can carry HTTP traffic or other WebSockets.→
- Cross a proxy and keep security checksA forward proxy still receives ordinary CONNECT. The protocol inside that tunnel determines the WebSocket opening handshake.→
This introduction explains RFC 8441 (2018). Read the original RFC ↗