Stateless Is Not Short-Lived

HTTP is stateless, meaning the server treats each request on its own, with no memory of earlier ones built into the protocol. That says nothing about connections: one TCP connection can carry many requests in turn, and has done by default since HTTP/1.1. Statelessness is about what a request means, and connection reuse is about how it travels.

Picture a developer who reads that HTTP is stateless and concludes that every request opens a new TCP connection. They add a connection-per-request client to a service, measure the handshake cost and decide HTTP is slow.

The symptom. Treating "stateless" as "one connection per request", and either paying for needless handshakes or expecting a server to forget a client because a new connection was opened.

Why it happens. The two ideas sound alike. Early HTTP did close the connection after each response, and the word "stateless" stuck to that memory. HTTP/1.1 made persistent connections the default, and HTTP/2 goes further, carrying many requests on one connection at the same time.

What it costs. A client that opens a connection per request pays a TCP handshake, and a TLS one, on every call, and starts every response in slow start. Under load it also fills the machine with connections waiting in TIME_WAIT.

How state is added. Applications that need memory build it on top. A cookie is a header the server asks the client to send back with every later request; a token in the Authorization header does the same job for an API. The server reads it on each request, so any server behind a load balancer can answer, which is what statelessness buys.

What to do. Reuse connections with keep-alive or a client that pools them, and send identity with every request. Never rely on a connection to identify a user.