How does a WebSocket sender split one message across several frames, and what does each frame carry?

## The three-frame pattern A fragmented WebSocket message is a run of frames with a strict shape: | position | FIN | opcode | |---|---|---| | first frame | 0 | the message type: `%x1` text or `%x2` binary | | middle frames (zero or more) | 0 | `%x0` continuation | | final frame | 1 | `%x0` continuation | An **unfragmented** message is the degenerate case of the same rule: one frame with `FIN` set and a non-zero opcode. That is what almost all traffic looks like. Two consequences fall straight out of the table. First, the message's type appears **exactly once**, on the opening frame — a middle frame that repeated `%x1` would be starting a new message, not continuing one. Second, a continuation frame with nothing open is a protocol error: `%x0` refers to a message the previous frames began, and with no such message the receiver has nothing to attach it to. ## Why a sender fragments Fragmentation is permitted, not required, and a sender chooses it for concrete reasons: - **The total size is not known yet.** Each frame declares only its own length, so a sender producing output as it goes can start writing immediately instead of buffering the whole message to measure it. - **The payload is too large to hold at once.** A sender streaming a large blob out of storage can emit it in bounded pieces without ever holding all of it in memory. - **Something else needs the wire.** This is the operationally important one: a control frame may be sent **between** the frames of a fragmented message, but never inside a frame. Splitting a large payload creates the gaps where a liveness probe or a close can get out. A receiver cannot generally tell *why* a sender fragmented, and the boundaries carry no application meaning — they are a transport decision. ## Rules the sender must keep 1. **State the type once.** Only the first frame carries `%x1` or `%x2`; the rest carry `%x0`. 2. **Set FIN exactly once, on the last frame.** Until it arrives the message is open. 3. **Do not interleave two messages.** Fragments of one message must not be interleaved with fragments of another on the same connection unless a negotiated extension defines how, so a connection carries one data message at a time and a large one blocks the next. 4. **Deliver fragments in order.** They travel in the order the sender wrote them; the protocol adds no sequence number to reorder by, and none is needed over a single ordered connection. 5. **Never fragment a control frame.** A close, ping or pong is always a single frame with `FIN` set. ## A worked sequence A sign controller sends the text `Hello` as two frames instead of one: ```http 01 03 48 65 6c # FIN=0, opcode %x1 (text), 3 bytes: "Hel" 80 02 6c 6f # FIN=1, opcode %x0 (continuation), 2 bytes: "lo" ``` `0x01` is FIN clear with opcode `%x1`; `0x80` is FIN set with opcode `%x0`. Nothing on the wire says the message totals five bytes — that fact only exists once the receiver has seen the frame with `FIN` set. ## What this costs and what it buys Each extra frame costs another header — two bytes at minimum, four more if the frame is masked and large enough to need an extended length. Splitting a 4 MB payload into 64 KB pieces adds a few hundred bytes of framing in total, which is nothing; splitting a 200-byte payload into 20 pieces is pure waste. The real trade-off is not bytes but **occupancy**. A single enormous frame holds the connection for as long as it takes to write, and nothing else can be sent in the meantime, because the next frame's header can only start after the current frame's last payload byte. The same payload sent as fragments yields the wire between pieces. That is why a sender that must keep a liveness probe answerable, or must be able to close promptly, fragments its large payloads rather than sending them whole — the gaps are the entire benefit.