17

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?

  • 18
    The socket is statefull, but http don't keep the connection open after you have downloaded the webpage. It closes about 15 seconds after the entire webpage is downloaded. this is the entire reason you need cookies to keep state – MTilsted Mar 26 '17 at 22:09
  • 41
    A socket isn't a piece of data. You can't send it about. Your question doesn't make sense. – user207421 Mar 27 '17 at 1:14
  • 8
    It's like asking why you can't use verbs instead of nouns... – Mehrdad Mar 27 '17 at 3:00
  • 2
    @EJP: I answered under the assumption that the OP means the (source_ip, source_port, target_ip, target_port) quadruple instead of the socket object. But your interpretation makes sense, too. – Jörg W Mittag Mar 27 '17 at 3:49
  • You could try and mimic the way firebase works to manage state or user identity without cookies or session. – JeffO Mar 27 '17 at 14:27
64

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.

  • It's worth noting that with http2 (and http pipelining) that you probably won't have two sockets open to SE. Your browser will re-use the same socket. You'd need to have different browsers running. – Matthew Steeples Mar 27 '17 at 8:29
  • 3
    A trivial local check indicates that Chrome does keep one socket open per tab - probably because they're sandboxed and it doesn't want to share state between them - but each tab's socket seems to be persistent and requests are probably pipelined within that tab. – Useless Mar 27 '17 at 9:55
  • 1
    It's also worth noting that you don't know what's going on at the back end either. Many load balancers will terminate a users connection and then open their own to the back end servers meaning that you may have multiple users sharing a single socket. – Dan Mar 27 '17 at 9:57
  • @Useless IIRC SE does use either WebSockets or long-polling (fallback) to fetch updates (new questions, edits, etc.) in case you're testing here. Other sites might behave differently - there's not much point keeping a socket open indefinitely on a static site. – Bob Mar 27 '17 at 15:22
  • True, it took me a few tries to find a genuinely-static site to check. For that, Chrome opens multiple sockets per tab, and still doesn't reuse them between tabs, but does close them once the tab has finished loading. They're easily visible though because they spend so long in TIME_WAIT. – Useless Mar 27 '17 at 15:33
20

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

These days we have websockets that can keep a single open socket from your web page to the server. So with websockets you can again use sockets to identify a user because the websocket by itself is stateful. But in most cases you will still need a cookie for the main html page that loads the javascript that starts the websocket.

  • 4
    "HTTP servers running modern websites can handle far more users than socket based servers like SSH or ftp" [citation needed] – el.pescado Mar 27 '17 at 5:37
  • 6
    @el.pescado: It's just logical. Since socket based servers keep a live connection therefore socket based servers are limited to the maximum number of file descriptors you can open (and on some OSes sockets compete with hard disk for file descriptors). If you don't need to keep connection alive then your limit is just bandwidth. Note that the bandwidth limit is the same weather you keep a connection alive or not. Modern HTTP servers can handle millions of requests per second. If they need to keep those millions of sockets up while you read a webpage the server would die – slebetman Mar 27 '17 at 7:07
  • 6
    +1 for "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". That's beautiful – dirkk Mar 27 '17 at 13:03
  • I liked this answer. It cuts right to the core of the issue. – Jim W Mar 27 '17 at 15:31
  • @slebetman HTTP servers are socket-based. All of them are. By definition. And cookies do not make HTTP servers stateful. In fact by definition they are not, which is why the cookies are transferred by the client every time. – Miles Rout Mar 28 '17 at 21:44

Your Answer

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