Por que os soquetes não podem ser usados ​​para identificar indivíduos em vez de cookies?

Outra pergunta foi feita sobre o uso de endereços IP para identificar clientes individuais. Acho que entendo por que um endereço IP é insuficiente. Mas e o soquete, que tem mais informações e, pelo que entendi, é stateful? Isso não poderia ser potencialmente usado no lugar de um cookie?

Um soquete identifica uma conexão . Os cookies geralmente são usados ​​para identificar um usuário . Se eu abrir duas guias do navegador no SE.SE, terei duas conexões e, portanto, dois soquetes. Mas quero que minhas configurações persistam nos dois. (De fato, normalmente, um navegador abre vários soquetes para uma página para acelerar o tempo de carregamento da página; acredito que a maioria dos navegadores tem um valor máximo padrão entre 4 e 10 soquetes por página.)

E o contrário também pode acontecer: se eu fechar a guia do navegador, outro usuário na máquina poderá abrir uma guia do navegador para o SE.SE e obter o mesmo quádruplo de (source_ip, source_port, target_ip, target_port), nesse caso , ele receberá todas as minhas configurações.

Os soquetes TCP são projetados para serem com estado, de modo que geralmente são usados ​​para identificar sessões. Protocolos como SSH e ftp fazem exatamente isso.

O HTTP foi projetado para ser sem estado e cada conexão é associada apenas a um recurso a ser baixado. Após o download de um recurso, o soquete TCP em que a solicitação HTTP é acionada é fechado. A razão original para isso foi a simplicidade. Mas o efeito colateral é que os servidores HTTP executando sites modernos podem lidar com muito mais usuários do que servidores baseados em soquete, como SSH ou ftp.

Portanto, os soquetes não podem ser usados ​​porque o HTTP fechará o soquete após o download da página da web.

Obviamente, dizer que o HTTP fechará o soquete por recurso é muito simplificador, porque o HTTP tem recursos como pipelining e conexões persistentes que podem baixar vários recursos por soquete. Mas isso é apenas otimização. Depois que tudo tiver baixado, seu navegador fechará o soquete após algum tempo limite.

O HTTP foi originalmente projetado como um protocolo simples para baixar arquivos HTML. Navegadores antigos também podem baixar arquivos HTML de outros protocolos, como Gopher e ftp. Como tal, não havia razão para tornar o HTTP com estado, porque os arquivos HTML são apenas arquivos de texto simples.

Depois que os formulários da web foram introduzidos e as páginas HTML podem enviar dados de volta para o servidor, as páginas da web começaram a precisar de sessões. Assim, os cookies foram criados para reintroduzir o estado em um protocolo sem estado que é transmitido por meio de uma camada de transferência com estado que é transmitida por uma camada de rede sem estado. Portanto, as camadas completas do aplicativo são:

• Ethernet, Wifi etc. = sem estado
• IP = sem estado
• TCP = com estado
• HTTP = sem estado
• HTTP + cookies = com estado

Atualmente, temos websockets que podem manter um único soquete aberto da sua página da web para o servidor. Portanto, com os websockets, você pode novamente usar sockets para identificar um usuário, porque o websocket por si só é estável. Mas na maioria dos casos, você ainda precisará de um cookie para a página html principal que carrega o javascript que inicia o websocket.