What are the ramifications of making HTTP stateful?

Question

After working a bit with cookie related problems . Something struck me .

Why do we need to do all these gimmicks of maintaining cookies or session data ? Was wondering if this is so common why cant this be done by default by system ? I am lazy ...

But I remember that I don't do this job of maintaining session data in a number of places . For example SSH . When I do ssh I just do ssh and I am connected . I am not bothered of all these details like session . System takes care . Then why should I do these things in web sites .

Ya then opened college networking book by Forouzan . Started reading and found that http was a stateless protocol . Ssh is stateful . Ahh ...

Then why are we using http protocol . If not why not use some other protocol which is stateful .. Or why don't we change http to stateful . Are we loosing anything out of doing this ? Why is it not done ?

I searched at many places but could not get a solid convincing answer . But every one said this "To make http protocol simple " .

I cannot understand how this makes simple .I don't know the magnitude to which it is simplified by keeping http stateless ?

Can you direct me to some books which can explain this final question how much http is simplified by keeping it stateless ? If not Can you give an answer so easy to understand that even a 6 year child can understand .

Answer 1

AFAIK, the main reason is to reduce load on web servers. As it stands, when you make a HTTP connection, web server serves your request and then forgets about you, which allows it to free the resources. If HTTP was stateful, web servers would have to maintain (hundreds of) thousands simultaneous connections, which would require extremely large hardware resources.

Answer 2

It is worth noting that HTTP 1.0/1.1 (default in 1.1) has a Connection: Keep-Alive header that will keep the TCP socket open for subsequent requests. One could keep the socket open forever (at least until it is broken or closed, but not timed out) in theory, although they would need to be mindful of resource usage. Apache automatically closes the TCP connection, but with a custom server implementation this isn't a problem.

From Wikipedia: HTTP persistent connection:

Disadvantages:

For services where single documents are regularly requested (for example, image hosting websites), Keep-Alive can be massively detrimental to performance due to keeping unnecessary connections open for many seconds after the document was retrieved.

Due to increased complexity, persistent connections are more likely to expose software bugs in servers, clients and proxies.

However, it also states:

Advantages:

Lower CPU and memory usage (because fewer connections are open simultaneously).

Reduced network congestion (fewer TCP connections).

Reduced latency in subsequent requests (no handshaking).

These (dis)advantages have been recognized, which is why there's this thing called a WebSocket.

Answer 3

HTTP was originally intended for document access, where through HTML these documents could be linked to each other. You connect to the server, request a document, download it and the connection would be closed by the server.

I don't think sir Tim Berners-Lee foresaw the kind of applications built on top of HTTP we have nowadays, that's why there's being worked on WebSockets and HTTP 2.0, who try to mitigate some of the issues that rise from HTTP's stateless nature.