Por que se diz que "HTTP é um protocolo sem estado"?

HTTP possui cookies HTTP. Os cookies permitem que o servidor rastreie o estado do usuário, o número de conexões, a última conexão etc.

O HTTP possui conexões persistentes (Keep-Alive), nas quais várias solicitações podem ser enviadas da mesma conexão TCP.

Mesmo que várias solicitações possam ser enviadas pela mesma conexão HTTP, o servidor não atribui nenhum significado especial à chegada pelo mesmo soquete. Isso é apenas uma questão de desempenho, destinada a minimizar o tempo / largura de banda que seria gasto restabelecendo uma conexão para cada solicitação.

No que diz respeito ao HTTP, todos eles ainda são solicitações separadas e devem conter informações suficientes por conta própria para atender à solicitação. Essa é a essência da "apatridia". As solicitações não serão associadas uma à outra, na ausência de algumas informações compartilhadas que o servidor conheça, que na maioria dos casos é um ID de sessão em um cookie.

Da Wikipedia :

HTTP é um protocolo sem estado. Um protocolo sem estado não exige que o servidor retenha informações ou status sobre cada usuário pela duração de várias solicitações.

Mas alguns aplicativos da web podem ter que rastrear o progresso do usuário de uma página para outra, por exemplo, quando um servidor da web é necessário para personalizar o conteúdo de uma página da web para um usuário. As soluções para esses casos incluem:

• o uso de cookies HTTP.
• sessões do lado do servidor,
• variáveis ​​ocultas (quando a página atual contém um formulário) e
• Regravação de URL usando parâmetros codificados em URI, por exemplo, /index.php?session_id=some_unique_session_code.

O que torna o protocolo sem estado é que o servidor não precisa rastrear o estado em várias solicitações, não que não possa fazê-lo se quiser. Isso simplifica o contrato entre cliente e servidor e, em muitos casos (por exemplo, fornecer dados estáticos em uma CDN), minimiza a quantidade de dados que precisam ser transferidos. Se os servidores precisassem manter o estado das visitas dos clientes, a estrutura de emissão e resposta a solicitações seria mais complexa. Como é, a simplicidade do modelo é uma de suas maiores características.

Como um protocolo sem estado não exige que o servidor mantenha informações ou status da sessão sobre cada parceiro de comunicação pela duração de várias solicitações.

HTTP é um protocolo sem estado, o que significa que a conexão entre o navegador e o servidor é perdida após o término da transação.

O HTTP é chamado stateless protocolporque cada solicitação é executada independentemente, sem nenhum conhecimento das solicitações que foram executadas antes, o que significa que, assim que a transação termina, a conexão entre o navegador e o servidor também é perdida.

O que torna o protocolo statelessé que, em seu design original, o HTTP é relativamente simples file transfer protocol:

1. faça uma solicitação para um arquivo nomeado por um URL,
2. obtenha o arquivo em resposta,
3. desconectar.

Não houve relacionamento mantido entre uma conexão e outra, mesmo do mesmo cliente. Isso simplifica o contrato entre cliente e servidor e, em muitos casos, minimiza a quantidade de dados que precisam ser transferidos.

Se o protocolo HTTP for fornecido como protocolo completo de Estado, a janela do navegador usará uma conexão única para se comunicar com o servidor da Web para várias solicitações fornecidas ao aplicativo da Web. Isso dará uma chance à janela do navegador para envolver as conexões entre a janela do navegador e os servidores da Web por um longo tempo e manter em estado inativo por um longo período de tempo. Isso pode criar a situação de atingir o máximo de conexões do servidor da web, mesmo que a maioria das conexões nos clientes esteja inativa.

O HTTP é sem conexão e este é um resultado direto de que o HTTP é um protocolo sem estado. O servidor e o cliente estão cientes apenas durante uma solicitação atual. Depois, os dois se esquecem. Devido a essa natureza do protocolo, nem o cliente nem o navegador podem reter informações entre diferentes solicitações nas páginas da web.

O que é apátrida ??

Depois que a solicitação é feita e a resposta é renderizada de volta ao cliente, a conexão será descartada ou encerrada. O servidor esquecerá tudo sobre o solicitante.

Por que apátridas ??

A web escolhe ir para o protocolo sem estado. Foi uma escolha genial, porque o objetivo original da web era permitir que documentos (páginas da web) fossem veiculados a um número extremamente grande. de pessoas que usam hardware muito básico para o servidor.

Manter uma conexão de longa execução teria sido extremamente intensivo em recursos.

Se a web fosse escolhida como protocolo de estado, a carga no servidor teria aumentado para manter a conexão do visitante.

HTTPé apátrida. TCPé stateful. Não existe o chamado HTTP connection, mas apenas HTTP requeste HTTP response. Não precisamos que nada seja mantido para fazer outro HTTP request. Um cabeçalho de conexão "keep-alive" significa TCPque será reutilizado pelas HTTPsolicitações e respostas subsequentes , em vez de desconectar e restabelecer a TCPconexão o tempo todo.

Acho que alguém escolheu um nome muito infeliz para o conceito STATELESS e é por isso que todo o mal-entendido é causado. Não se trata de armazenar qualquer tipo de recursos, mas do relacionamento entre o cliente e o servidor.

Cliente: Estou mantendo todos os recursos do meu lado e envio a "lista" de todos os itens importantes que precisam ser processados. Faça seu trabalho.

Servidor: Tudo bem ... deixe-me assumir a responsabilidade de filtrar o que é importante para fornecer a resposta adequada.

O que significa que o servidor é o "escravo" do cliente e deve esquecer seu "mestre" após cada solicitação. Na verdade, STATELESS refere-se apenas ao estado do servidor.

https://www.ics.uci.edu/~fielding/pubs/dissertation/rest_arch_style.htm#sec_5_1_3