Learning Question

Why is an open connection not enough to define how two applications communicate?

A connection lets bytes move between endpoints. It does not, by itself, say what those bytes mean, where messages begin or end, who is allowed to speak next, whether responses are cacheable, or whether the server can send updates without a new request.

Those meanings come from the application protocol.

Lower Capability, Higher Meaning

TCP provides a reliable ordered byte stream. That is a lower-layer capability:

bytes can flow in order between endpoints

HTTP adds request-response semantics:

client sends request
server sends response for that request

WebSocket adds a different message model after an HTTP Upgrade:

either side may send WebSocket messages over the upgraded connection

The same underlying idea of a persistent connection can support different application conversations.

The Common Confusion

The confusion often appears as:

TCP is bidirectional.
HTTP can keep a TCP connection open.
So why is WebSocket different?

The missing step is that transport capability is not protocol semantics. TCP can carry bytes both ways, but TCP does not define HTTP requests, HTTP responses, SSE events, WebSocket frames, or HLS media segments.

The application protocol defines the valid conversation pattern.

Why This Matters

If you diagnose only at the connection level, you may ask the wrong question.

For example:

  • A connection can be open while the HTTP response is already complete.
  • A server can keep one HTTP response body open without sending multiple completed responses.
  • A WebSocket connection can stay alive while the application still loses messages during reconnects.
  • Video playback can look continuous while the player is actually fetching many independent HTTP segment objects.

Core Mental Model

Always separate:

connection capability
-> can bytes move?
 
protocol semantics
-> what do the bytes mean?
 
application behavior
-> what state or action does the program attach to those messages?

This route is about the middle layer: how application protocols use lower connections to create different conversation shapes.