Keep-Alive, Multiplexing, and Connection Reuse

Learning Question

How can multiple HTTP exchanges use one underlying connection without becoming one message?

Connection reuse means a lower connection can carry more than one application exchange over time. Multiplexing means multiple logical exchanges can make progress over one lower connection. Neither one erases HTTP message boundaries.

Keep-Alive

With HTTP keep-alive, the same TCP connection can be reused for multiple request-response exchanges.

TCP connection opens
request 1 -> response 1
request 2 -> response 2
request 3 -> response 3
TCP connection closes later

The connection stays open, but each HTTP exchange remains a separate request and response.

This is different from WebSocket. Keep-alive does not turn one completed HTTP request into an unlimited sequence of future messages.

Multiplexing

HTTP/2 can carry multiple logical streams over one TCP connection. Frames include stream IDs, so the HTTP/2 layer can separate interleaved data.

TCP byte stream:
[stream 1 frame][stream 3 frame][stream 1 frame][stream 5 frame]
 
HTTP/2 layer:
stream 1 -> its request or response data
stream 3 -> its request or response data
stream 5 -> its request or response data

TCP still sees one ordered byte stream. HTTP/2 defines the frame and stream structure above it.

Head-of-Line Blocking

Because HTTP/2 runs over TCP, a missing earlier TCP byte range can delay later bytes from being delivered to the HTTP/2 parser, even if those later bytes belong to another HTTP/2 stream.

The lost unit is not “one HTTP request.” More precisely:

a missing TCP byte range blocks later bytes in the same TCP connection

HTTP/3 reduces this specific TCP-level issue by using QUIC streams rather than one TCP byte stream for all HTTP streams.

Core Mental Model

Connection reuse answers:

Can this lower connection carry more protocol work?

Multiplexing answers:

Can multiple logical protocol streams share the same lower connection?

Neither answer tells you the full conversation by itself. You still need the application protocol’s message boundaries and stream rules.