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

Messages in both directions

02

Once established, either endpoint can send a message without waiting for a new HTTP request.

Related RFCs and changes

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

DIAGRAM§ 1.2 ↗
RFC 6455 · § 1.2EXAMPLE
3 / 3
Messages in both directionsA single established channel carries an independent client text message, server update, and binary message.One connection, independent messagesApplication message examplesClientServertext: helloUTF-8text: updatebinary message01100101Binary bytes have application-defined meaning
03
Choose a message type for the application.

Binary content is delivered as bytes; its meaning comes from the application or negotiated subprotocol.

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

Two independent directions share one connection.

  • The base protocol carries text or binary messages over TCP.
  • Text messages must contain valid UTF-8 as a whole, even if split across frames.
  • WebSocket framing does not define your application message schema, delivery acknowledgments, or business-level replay behavior.
DETAILS

The illustration shows ordinary text messages. A TCP connection is an ordered byte stream; WebSocket provides message framing on top of it.

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 ↗