Another question was asked regarding the use of IP addresses to identify individual clients. I think I understand why an IP address is insufficient. But what about the socket, which has more information and, from what I understand, is stateful? Couldn't that be potentially used in lieu of a cookie?
A socket identifies a connection. Cookies are usually used to identify a user. If I open two browser tabs to SE.SE, I will have two connections and thus two sockets. But I want my settings to persist across both of them. (In fact, typically, a browser opens multiple sockets for one page in order to speed up page load time; I believe most browsers have a default maximum value between 4 and 10 sockets per page.)
And the opposite can happen as well: if I close my browser tab, another user on the machine may open a browser tab to SE.SE, and may get the same quadruple of (source_ip, source_port, target_ip, target_port), in which case, he will get all my settings.
TCP sockets are designed to be stateful so in general they are used to identify sessions. Protocols like SSH and ftp do exactly this.
HTTP is designed to be stateless and each connection is only associated with a resource to be downloaded. After a resource is downloaded the TCP socket that the HTTP request rides on is closed. The original reason for this was simplicity. But the side-effect is that HTTP servers running modern websites can handle far more users than socket based servers like SSH or ftp.
So sockets can't be used because HTTP will close the socket after downloading the web page.
Of course, saying HTTP will close the socket per resource is oversimplifying things because HTTP have features like pipelining and persistent connections that can download multiple resources per socket. But that's just optimisation. After everything have downloaded your browser will close the socket after some timeout.
HTTP was originally designed as a simple protocol for downloading HTML files. Old browsers can also download HTML files form other protocols like Gopher and ftp. As such, there was no reason for making HTTP stateful because HTML files are just simple text files.
Once web forms were introduced and HTML pages can send data back to the server web pages started to need sessions. Thus cookies were created to re-introduce state to a stateless protocol that is transmitted via a stateful transfer layer that is transmitted over a stateless network layer. So the full application layers are:
- Ethernet, Wifi etc. = stateless
- IP = stateless
- TCP = stateful
- HTTP = stateless
- HTTP + cookies = stateful