Carry WebSocket frames in DATA
03WebSocket frames remain WebSocket frames. Their bytes travel inside HTTP/2 DATA on the connected stream.
The receiver joins the byte stream, reads the four-byte key and XORs the five masked payload bytes to recover Hello. HTTP/2 delivery does not eliminate WebSocket parsing.
Source for this drawing: RFC 8441 · Read RFC section 5 ↗
New to this? Start hereA quick picture + helpful background
A message needs an address.
Think of a packet as a small addressed envelope. Devices pass it onward; transport protocols decide what delivery promises an application gets.
Helpful first, if these ideas are unfamiliar
These pictures are analogies to help you learn. The linked RFC explains the actual rules.
Terms in this drawing
- DATA
- An HTTP/2 frame type carrying stream-associated bytes, subject to flow control.
- Mask
- A four-byte key XORed with client WebSocket payload bytes.
- FIN
- A WebSocket flag marking the final frame of a message; unrelated to HTTP/2 END_STREAM.
Related RFCs and changes
“Updates” changes part of an earlier RFC. “Obsoletes” replaces it. This list shows selected related documents.
HTTP/2 boundaries do not replace WebSocket framing.
- Treat the successfully connected HTTP/2 stream like the TCP byte connection used by RFC6455. Its DATA carries the traditional WebSocket protocol.
- Client frames MUST be masked under the retained RFC6455 rules, even with TLS. A fresh unpredictable masking key is required per frame; the public Hello vector is a worked example, not a reusable key.
- HTTP/2 DATA boundaries need not match WebSocket frame boundaries. The 11-byte example is split into 5 and 6 data bytes; HTTP/2 frame headers and optional padding are not shown.
Supporting RFC6455§§5.1,5.3,5.7 and10.3 define framing and masking; RFC9113§6.1 defines DATA. The mask hides an application’s choice of wire bytes from intermediaries; it is not encryption or authentication. This example has FIN=1, text opcode=1, a five-byte payload and no negotiated extensions.
Read the RFC section ↗