Frame-based与Stream-based协议含义及差异问询（WebSocket规范相关）

Hey there! Let me break down the difference between frame-based and stream-based protocols for you, using relatable examples to make it clear.

First, let's start with core definitions, then tie them back to WebSocket since that's what you're deep diving into.

Stream-based Protocols #

Think of a stream like a continuous pipe of bytes—there's no built-in "stop" or "start" marker to separate chunks of data. The sender pushes bytes out, and the receiver gets a continuous flow, with no inherent way to know where one message ends and the next begins.

Example: TCP (or HTTP/1.1) #

TCP is the classic stream-based protocol. Let's say you send two separate messages over TCP:

send("Hello, WebSocket!");
send("This is a stream test.");

The receiver might get these bytes all glued together:

"Hello, WebSocket!This is a stream test."

Or even split into random chunks like:

"Hello, WebSock"
"et!This is a stre"
"am test."

To make sense of this, the receiver has to use extra rules—like adding a special delimiter (e.g., a newline \n) between messages, or first sending the length of the message before the actual content. HTTP/1.1 does this with headers like Content-Length or chunked transfer encoding.

Frame-based Protocols #

Frame-based protocols package every piece of data into discrete, self-contained "frames." Each frame has a header that tells the receiver critical info:

• Where the frame starts and ends (its length)
• What type of data it is (e.g., text vs binary in WebSocket)
• Any other metadata needed to process the frame

The receiver doesn't have to guess where messages split—each frame is a complete, identifiable unit.

Example: WebSocket #

Going back to the WebSocket spec you quoted: the protocol uses frames specifically to avoid stream ambiguity and support different data types.

When you send a text message like "Hi there!" over WebSocket, it gets wrapped in a frame that looks something like this (simplified):

[Frame Type: Text (0x1)] [Length: 8] [Payload: "Hi there!"]

If you then send a binary image file, it goes into another frame:

[Frame Type: Binary (0x2)] [Length: 10240] [Payload: <image bytes>]

The receiver reads each frame's header first—immediately knowing if it's text or binary, how long the payload is, and exactly where the frame ends. No need for extra delimiters or length guessing; the frame itself defines the boundaries.

This is exactly why the WebSocket spec emphasizes minimal frame design: it's just enough to turn a stream (TCP, which WebSocket runs on top of) into a frame-based system, enabling clear separation of message types and reliable message delivery.

内容的提问来源于stack exchange，提问作者Rudziankoŭ