How does HTTP become stateless?

HTTP does not care about—and is independent of—any of the lower-level protocols used to transport itself, even though it is itself stateless.

The transport technology can be TCP, or Novell’s old SPX, or SCTP, or whatever else you can dream up, and HTTP will still work the same. HTTP does require a streaming or connection-oriented protocol—and depends on URLs being resolvable—but doesn’t care how that is accomplished.

This is one of the reasons why the layered model or network stack exists: The application layer does not need to concern itself with lower layers.

Just because a lower-level protocol is stateful doesn’t mean anything on top of it automatically becomes stateful or is required to be stateful.

HTTP itself is stateless. So that means applications have to implement another layer on top of HTTP to establish state. This is typically done with session cookies.

"HTTP is stateless" means that each HTTP transaction (request-response pair) can be processed independently of any state from previous request-response pair.

To transport the particular request-response pair you need a protocol that is able to carry arbitrarily large block there and arbitrarily large block back, and to do that over a layer with limited packet size, TCP has to be stateful.

But across transaction boundary, there is no state. The client can drop the connection and establish a new one for the next request. In fact that was the only option in the early versions and it still works like that if the client does not include the Connection: keep-alive header.

The next request can also easily be handled by different server and the client will never know, because the server does not need to maintain any state (unless the application adds its own state on top of HTTP, usually in form of session; the consequent complications in load-balancing is its punishment for building stateful protocol on HTTP). That is taken advantage of in load-balancing busy servers.

The "stateless" nature of HTTP means that on this layer, no state information is created or used.

You can see this in a few instances, for example in HTTP authentication, the credentials are sent with every request, and persistent connections are really just an optimization (i.e. if I send credentials, the server forgets these after the request, even if it leaves the connection open).

In contrast, cookie based login mechanisms are stateful, but not part of HTTP.

You have to understand it as a set of Russian dolls (or boxes if you want) each of them carrying another one inside, that's grossly how it works: TCP carries HTTP "inside" but it doesn't cares about it or it's features.

In order to get the whole picture I recommend reading about the OSI Model as it makes it clearer.

TCP sits a few layers below of HTTP in the OSI model, each layer does in fact correspond to a different protocol.

In our case HTTP sits in the presentation and application layers and TCP in the transport layer. Or if you use the TCP/IP Model both the TCP and the IP protocols sit in the Network Link layer and HTTP in the application and presentation layers.