Como o HTTP se torna sem estado?

Diz-se que o HTTP é sem estado. Ou seja, ele não precisa armazenar informações para a transmissão de dados.

Mas o HTTP usa TCP, que é orientado ao estado.

Se for esse o caso, como o HTTP se torna sem estado?

O HTTP não se importa com - e é independente de - qualquer um dos protocolos de nível inferior usados ​​para se transportar, mesmo que ele próprio não tenha estado.

A tecnologia de transporte pode ser TCP, ou o antigo SPX da Novell, ou SCTP, ou qualquer outra coisa que você possa imaginar, e o HTTP continuará funcionando da mesma maneira. O HTTP requer um protocolo orientado a streaming ou conexão - e depende da resolução de URLs - mas não se importa com o que isso é feito.

Essa é uma das razões pelas quais o modelo em camadas ou a pilha de rede existe: A camada do aplicativo não precisa se preocupar com as camadas inferiores.

Só porque um protocolo de nível inferior é stateful não significa que nada em cima dele se torne stateful automaticamente ou seja necessário que ele seja stateful.

O próprio HTTP é sem estado. Isso significa que os aplicativos precisam implementar outra camada em cima do HTTP para estabelecer o estado. Isso geralmente é feito com cookies de sessão.

"HTTP é sem estado" significa que cada transação HTTP (par de solicitação-resposta) pode ser processada independentemente de qualquer estado do par de solicitação-resposta anterior.

Para transportar o par de solicitação-resposta específico, você precisa de um protocolo capaz de transportar blocos arbitrariamente grandes para lá e de volta arbitrariamente grandes, e para fazer isso em uma camada com tamanho de pacote limitado, o TCP deve ser stateful.

Mas além do limite da transação, não há estado. O cliente pode descartar a conexão e estabelecer uma nova para a próxima solicitação. De fato, essa era a única opção nas versões anteriores e ainda funcionaria assim se o cliente não incluir o Connection: keep-alivecabeçalho.

A próxima solicitação também pode ser facilmente tratada por um servidor diferente e o cliente nunca saberá, porque o servidor não precisa manter nenhum estado (a menos que o aplicativo adicione seu próprio estado no HTTP, geralmente na forma de sessão; as conseqüentes complicações no balanceamento de carga é sua punição por criar um protocolo stateful no HTTP). Isso é aproveitado no servidor ocupado com balanceamento de carga.

A natureza "sem estado" do HTTP significa que nessa camada, nenhuma informação de estado é criada ou usada.

Você pode ver isso em algumas instâncias, por exemplo, na autenticação HTTP, as credenciais são enviadas a cada solicitação e as conexões persistentes são realmente apenas uma otimização (ou seja, se eu enviar credenciais, o servidor as esquece após a solicitação, mesmo que saia a conexão aberta).

Por outro lado, os mecanismos de login baseados em cookies são stateful, mas não fazem parte do HTTP.

Você precisa entendê-lo como um conjunto de bonecas russas (ou caixas, se quiser), cada uma delas carregando outra, é assim que funciona: o TCP carrega o HTTP "dentro", mas não se importa com isso ou com seus recursos.

Para obter uma imagem completa, recomendo ler sobre o modelo OSI, pois ele fica mais claro.

O TCP fica algumas camadas abaixo do HTTP no modelo OSI, cada camada de fato corresponde a um protocolo diferente.

No nosso caso, o HTTP fica nas camadas de apresentação e aplicação e o TCP na camada de transporte. Ou, se você usar o modelo TCP / IP, os protocolos TCP e IP ficam na camada Link de rede e HTTP nas camadas de aplicativo e apresentação.