Pourquoi les sockets ne peuvent-ils pas être utilisés pour identifier des individus au lieu de cookies?

Une autre question a été posée concernant l'utilisation des adresses IP pour identifier les clients individuels. Je pense que je comprends pourquoi une adresse IP est insuffisante. Mais qu'en est-il de la socket, qui contient plus d'informations et, d'après ce que je comprends, est avec état? Cela ne pourrait-il pas être potentiellement utilisé à la place d'un cookie?

Une prise identifie une connexion . Les cookies sont généralement utilisés pour identifier un utilisateur . Si j'ouvre deux onglets de navigateur à SE.SE, j'aurai deux connexions et donc deux sockets. Mais je veux que mes paramètres persistent sur les deux. (En fait, généralement, un navigateur ouvre plusieurs sockets pour une page afin d'accélérer le temps de chargement des pages; je pense que la plupart des navigateurs ont une valeur maximale par défaut comprise entre 4 et 10 sockets par page.)

Et l'inverse peut également se produire: si je ferme l'onglet de mon navigateur, un autre utilisateur de la machine peut ouvrir un onglet de navigateur vers SE.SE et obtenir le même quadruple de (source_ip, source_port, target_ip, target_port), auquel cas , il obtiendra tous mes paramètres.

Les sockets TCP sont conçus pour être avec état, ils sont donc généralement utilisés pour identifier les sessions. Les protocoles comme SSH et ftp font exactement cela.

HTTP est conçu pour être sans état et chaque connexion n'est associée qu'à une ressource à télécharger. Une fois qu'une ressource est téléchargée, le socket TCP sur lequel la requête HTTP se déplace est fermé. La raison d'origine de cela était la simplicité. Mais l'effet secondaire est que les serveurs HTTP exécutant des sites Web modernes peuvent gérer beaucoup plus d'utilisateurs que les serveurs basés sur des sockets comme SSH ou ftp.

Les sockets ne peuvent donc pas être utilisés car HTTP fermera le socket après avoir téléchargé la page Web.

Bien sûr, dire que HTTP fermera le socket par ressource revient à simplifier les choses car HTTP a des fonctionnalités comme le pipelining et les connexions persistantes qui peuvent télécharger plusieurs ressources par socket. Mais ce n'est qu'une optimisation. Une fois tout téléchargé, votre navigateur fermera le socket après un certain délai.

HTTP a été initialement conçu comme un protocole simple pour télécharger des fichiers HTML. Les anciens navigateurs peuvent également télécharger des fichiers HTML à partir d'autres protocoles comme Gopher et ftp. En tant que tel, il n'y avait aucune raison de rendre HTTP avec état car les fichiers HTML ne sont que de simples fichiers texte.

Une fois que les formulaires Web ont été introduits et que les pages HTML peuvent renvoyer des données aux pages Web du serveur qui ont commencé à nécessiter des sessions. Ainsi, les cookies ont été créés pour réintroduire l'état dans un protocole sans état qui est transmis via une couche de transfert avec état qui est transmise sur une couche réseau sans état. Les couches d'application complètes sont donc:

• Ethernet, Wifi etc. = sans état
• IP = apatride
• TCP = avec état
• HTTP = sans état
• HTTP + cookies = avec état

De nos jours, nous avons des websockets qui peuvent garder un seul socket ouvert de votre page Web au serveur. Ainsi, avec les websockets, vous pouvez à nouveau utiliser des sockets pour identifier un utilisateur car le websocket en lui-même est avec état. Mais dans la plupart des cas, vous aurez toujours besoin d'un cookie pour la page HTML principale qui charge le javascript qui démarre le websocket.