HTTP is said to be stateless. Meaning, it doesn’t need to store information for the transmission of data.

But HTTP uses TCP, which is state oriented.

If that's the case, how does HTTP becomes stateless?

  • 6
    How is this not a duplicate 5 years after Super User was launched? – Peter Mortensen Oct 13 '14 at 17:08
  • Because most of the dupes are on StackOverflow? I'm just guessing. – trysis Oct 13 '14 at 17:58
  • 8
    Just because it runs through cables (among others), doesn't make it an electric protocol either – Hagen von Eitzen Oct 13 '14 at 21:52

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.

  • 1
    Routing occurs at the tcp/ip level. – Fiasco Labs Oct 13 '14 at 3:46
  • 3
    This image explains it nicely. vichargrave.com/wp-content/uploads/2013/01/… – Giacomo1968 Oct 13 '14 at 4:32
  • 2
    Coincindentally, the fact that HTTP ignores statefullness of underlying connection (which almost always will be TCP) is one of the major performance shortfalls that various HTTP2 approaches are trying to address. – skolima Oct 13 '14 at 8:18
  • 2
    @Fiasco: Strictly speaking, routing occurs at the IP level. Routing is based on Internet Addresses, no information from the TCP layer is used in basic routing. – RedGrittyBrick Oct 13 '14 at 10:28
  • 1
    @skolima: on the other hand, statelessness is the reason why HTTP is the most scalable and reliable protocol in wide use. HTTP has always been explicitly designed for scalability rather than performance (yes, they're different thing), so if you think you need hard low latency than you are either using the wrong protocol or you are using the protocol incorrectly. While HTTP2 intends to improve performance, it does so in a way that remains true to statelessness. When used for what it's intended for, I had never seen statelessness being a bottleneck of a well designed HTTP application. – Lie Ryan Oct 13 '14 at 12:10

"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.

  • can also easily be handled by different server and the client will never know Though technically true, this is misleading as many web applications use sticky sessions, requiring a load balancer to route future requests from the same browsing session to the same server. From an HTTP perspective, sessions are irrelevant, but your last sentence sort of implies that the end-user experience will be unaffected, which would be false with sticky sessions. – Brandon Oct 13 '14 at 17:21
  • 1
    @Brandon: Such applications build a stateful protocol on top of HTTP and this is their punishment for it! – Jan Hudec Oct 13 '14 at 17:45
  • @Brandon: Lots of load balanced servers, such as gmail, don't send requests back to the same server. Instead the session is stored in a shared database that all the servers in the cluster can access. The state therefore is not handled by the server but by the database. – slebetman Oct 14 '14 at 7:25
  • @slebetman: Yeah, whatever. HTTP itself does not have such state, so for HTTP it's simple. If the application adds some state of it's own, it's its fight. – Jan Hudec Oct 14 '14 at 8:22
  • Right, I didn't say all. I said some. I personally prefer to avoid sticky sessions, and if possible, avoid sessions altogether. Nevertheless, software exists that doesn't live up to everybody's ideal. – Brandon Oct 14 '14 at 17:27

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.

  • 1
    The problem with the OSI model is that it's now theoretical (there were actual attempts to implement it, but they failed in the market due to their complexity). In reality, there are no layers between TCP and HTTP. Besides, the presentation layer would be HTML, not HTTP. – MSalters Oct 13 '14 at 11:26
  • In the TCP/IP model, TCP does not live in the network layer. It lives in the transport layer on top of IP, which is in the network later. The first google hit for "TCP model" demonstrates this: technet.microsoft.com/en-us/library/cc786900(v=ws.10).aspx – Brandon Oct 13 '14 at 17:24
  • @MSalters: Is TLS not a layer? – user1686 Oct 14 '14 at 6:45
  • 1
    @MSalters: You do realize that HTTPS is merely the name given by HTTP being tunneled by TLS? As such TLS is a layer under HTTP and on top of TCP and TLS/SSL+HTTP combo is called HTTPS. – slebetman Oct 14 '14 at 7:28
  • 1
    Also, there is another, new name for TLS/HTTP combo. If the TLS that carries the HTTP traffic implements virtual socket/stream multiplexing it's called SPDY (but the url in your browser is still HTTPS). – slebetman Oct 14 '14 at 7:29

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.