Visual RFC.
ALL RFCs / RFC 6455
Read the RFC ↗
RFC 6455 / EXCHANGE MESSAGES

Fragments and control frames

04

A large message can be fragmented while Ping and Pong remain responsive between fragments.

Related RFCs and changes

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

DIAGRAM§ 5.4 ↗
RFC 6455 · § 5.4EXAMPLE
3 / 3
Fragments and control framesAn unfinished text message receives a Ping/Pong control exchange between fragments, then a final continuation completes the original text.Control between message fragmentsIllustrative message: Hellotext · FIN=0Helmessage incompletePing: 7Pong: 7continuation · FIN=1loAssembled text: HelloAppend the final continuation in order
03
Finish the original message.

The final continuation completes the text message in fragment order.

Protocol participantThreat or exceptionProtocol controlSimplified drawings · precise section references
KEY POINT

Keep control frames independent from message fragments.

  • A fragmented message begins with text/binary and FIN=0, continues with opcode 0, and ends with FIN=1.
  • Control frames cannot be fragmented and have at most 125 payload bytes. They may appear between message fragments.
  • A Ping normally requires a Pong response with the same application data, unless a Close was already received.
DETAILS

Without an extension defining it, fragments of different data messages are not interleaved. An unsolicited Pong is permitted and does not require a response.

Read the RFC section ↗

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

Privacy
All chapters in this RFC
  1. Opening handshake
  2. Messages in both directions
  3. Frame fields
  4. Fragments and control frames
  5. Client masking
  6. Closing the connection
RFC 9700 / CHAPTERS

Chapters

For full details, tables, algorithms, and exceptions, read the original RFC.

RFC status and corrections ↗