Subprotocols, Extensions, and Compression

The raw WebSocket protocol only moves bytes. Two negotiation mechanisms let you layer meaning and efficiency on top: subprotocols and extensions.

A subprotocol is an agreed application-level message format, like a contract for what the bytes mean. Examples include wamp, mqtt, and graphql-ws.

The client lists desired subprotocols in a handshake header.

The server picks one subprotocol it supports and echoes it back. If none match, it omits the header and only the base protocol applies.

Pass an array of subprotocol names as the second argument when opening the socket.

An extension changes how frames are transmitted at the protocol level, transparent to your application logic. The most common is per-message compression.

Extensions are negotiated in the handshake too, via their own header.

permessage-deflate compresses each message with DEFLATE before sending. It cuts bandwidth for text-heavy payloads at the cost of CPU.

Compression wins for large, repetitive JSON or text. For tiny or already-compressed payloads (images, binary), it adds overhead without benefit and can be disabled.

Keep them straight:

• Subprotocol: meaning of the messages (application layer)
• Extension: how frames are transported (protocol layer)

Both are negotiated only during the handshake and cannot change afterward. Always verify ws.protocol client-side so your code parses messages with the agreed format.

Test your protocol knowledge.

You explored advanced WebSocket negotiation:

• Subprotocols agree on message format via Sec-WebSocket-Protocol
• Extensions change frame transport via Sec-WebSocket-Extensions
• permessage-deflate compresses text payloads
• Both are fixed at handshake time

You now understand the negotiation layer of WebSockets.