Websocket frame-based

Question

I read from here that Websocket is a frame-based protocol instead of stream-based. But it also states Why are WebSockets frame-based and not stream-based? I don’t know and just like you, I’d love to learn more, so if you have an idea, feel free to add comments and resources in the responses below.
Can anyone explain what is the advantage of using frame-based protocol in Websocket?

Answer 1

Maybe this pre-existing answer will help provide some reference for the discussion.

By utilizing frames and having a massage based based protocol (vs. a stream based protocol) it makes it easier to write Web oriented applications.

Common actions, such as sending JSON data, become easier and don't require every application to implement a network-data buffering/caching layer for fragmented messages.

---

EDIT (answering comment)

The TCP/IP layer guarantees network packet delivery and ordering, but has no concept of data length - it's a streaming protocol and it promises that the stream will arrive in order, no more than that.

If any data arrives out of order, than the TCP/IP protocol layer will re-order the data. This may require an internal cache/buffer that will hold on to the existing data while waiting for the missing data.

In contrast, the WebSocket is message based and is aware of the message data length.

The WebSocket frames use a header with data length (total / partial) to allow the WebSocket protocol layer to concat all the data as a single unit, even when it's distributed across multiple TCP/IP packets or (even) WebSocket frames.

This requires the protocol layer to keep the data in an internal buffer until all the expected data in the message arrives. The WebSocket protocol will forward the message to the application only when the whole of it's data arrives.

This "holding on to data" in order to extract message "units" from the stream is the caching/buffering element I was referring to.