¿Por qué no se pueden usar sockets para identificar a las personas en lugar de las cookies?

Se hizo otra pregunta sobre el uso de direcciones IP para identificar clientes individuales. Creo que entiendo por qué una dirección IP es insuficiente. Pero, ¿qué pasa con el zócalo, que tiene más información y, por lo que entiendo, tiene estado? ¿No podría usarse potencialmente en lugar de una cookie?

Un zócalo identifica una conexión . Las cookies se utilizan generalmente para identificar a un usuario . Si abro dos pestañas del navegador en SE.SE, tendré dos conexiones y, por lo tanto, dos sockets. Pero quiero que mi configuración persista en ambos. (De hecho, normalmente, un navegador abre múltiples sockets para una página para acelerar el tiempo de carga de la página; creo que la mayoría de los navegadores tienen un valor máximo predeterminado entre 4 y 10 sockets por página).

Y lo contrario también puede suceder: si cierro la pestaña de mi navegador, otro usuario en la máquina puede abrir una pestaña del navegador para SE.SE, y puede obtener el mismo cuádruple de (source_ip, source_port, target_ip, target_port), en cuyo caso , obtendrá todos mis ajustes.

Los sockets TCP están diseñados para tener estado, por lo que, en general, se utilizan para identificar sesiones. Los protocolos como SSH y ftp hacen exactamente esto.

HTTP está diseñado para no tener estado y cada conexión solo está asociada con un recurso para descargar. Después de descargar un recurso, se cierra el socket TCP en el que se basa la solicitud HTTP. La razón original de esto fue la simplicidad. Pero el efecto secundario es que los servidores HTTP que ejecutan sitios web modernos pueden manejar muchos más usuarios que los servidores basados ​​en sockets como SSH o ftp.

Por lo tanto, los sockets no se pueden usar porque HTTP cerrará el socket después de descargar la página web.

Por supuesto, decir que HTTP cerrará el socket por recurso es simplificar demasiado las cosas porque HTTP tiene características como canalización y conexiones persistentes que pueden descargar múltiples recursos por socket. Pero eso es solo optimización. Después de que todo se haya descargado, su navegador cerrará el socket después de un tiempo de espera.

HTTP fue originalmente diseñado como un protocolo simple para descargar archivos HTML. Los navegadores antiguos también pueden descargar archivos HTML de otros protocolos como Gopher y ftp. Como tal, no había razón para hacer HTTP con estado porque los archivos HTML son simples archivos de texto.

Una vez que se introdujeron los formularios web y las páginas HTML pueden enviar datos al servidor, las páginas web comenzaron a necesitar sesiones. Por lo tanto, las cookies se crearon para reintroducir el estado en un protocolo sin estado que se transmite a través de una capa de transferencia con estado que se transmite a través de una capa de red sin estado. Entonces, las capas de aplicación completas son:

• Ethernet, Wifi, etc. = sin estado
• IP = sin estado
• TCP = con estado
• HTTP = sin estado
• HTTP + cookies = con estado

En estos días tenemos websockets que pueden mantener un solo socket abierto desde su página web al servidor. Por lo tanto, con websockets puede volver a usar sockets para identificar a un usuario porque el websocket en sí mismo tiene estado. Pero en la mayoría de los casos aún necesitará una cookie para la página html principal que carga el javascript que inicia el websocket.