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


170

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.


3
Outra área em que não vejo "apátrida" está na Autorização - particularmente na Proxy-Authorization. Parece que é estável durante a negociação. Para autenticação NTLM, o cliente precisa lembrar o tipo de autenticação por proxy e o servidor precisa ser monitorado, pois há uma sequência para os tipos de mensagem NTLM. Portanto, não tenho certeza de entender as respostas.
Lindsay Morsillo

1
Agora devo adicionar HTTP / 1.1? Porque acho que o HTTP / 2 tem estado.
José Nobile

4
HTTP / 2 é estável. HTTP 1 é sem estado. Adições posteriores destinadas ao HTTP 1, como cookies, adicionaram estado. Essas adições não fazem parte da especificação HTTP 1 "principal". É por isso que o HTTP 1 é considerado um protocolo sem estado, embora na prática não seja. O HTTP / 2, por outro lado, foi projetado com componentes com estado incorporados. Não foram necessárias adições para satisfazer o requisito de ser rotulado como "com estado".
Zamicol 12/04

Respostas:


130

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.


1
O que acontece quando o servidor se lembra de uma sessão (no lado do servidor) e personaliza a experiência do usuário de acordo com ela?
NurShomik

3
@NurShomik: consulte stackoverflow.com/a/3521393/319403 para obter uma explicação de como as sessões normalmente funcionam.
cHao 09/02

12
@ Andrew: HTTP não é "construído em" TCP, eo estado do TCP não é HTTP. Os dois são protocolos totalmente separados em diferentes camadas da pilha. Você poderia servir HTTP sobre pipes nomeados, se quisesse, ou mesmo enviando arquivos, se tivesse masoquistas suficientes para concordar em fazê-lo, e funcionaria precisamente porque o HTTP é independente de protocolo de transporte. Nesse nível, são apenas solicitações e respostas. Isso torna o próprio HTTP sem estado, independentemente de qual estado possa ser usado / mantido / exigido por protocolos de nível inferior ou superior.
Chao

@cHao Ok, eu admito. Se definirmos apatridia como "não necessariamente precisa ter um estado para operar" (consulte a resposta do dimo414 abaixo listando opções de estado no HTTP citadas na Wikipedia) e se visualizarmos cada protocolo estritamente por si só e não com base nas camadas abaixo dele , sim, posso concordar que o HTTP é "sem estado".
Andrew

101

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.


21

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.


2
Mas, o HTTP pode salvar informações no servidor, usando cookies. HTTP com keep-alive não fecha a conexão em cada solicitação.
José Nobile


18
Salvar informações no servidor não significa que a conexão esteja ativa constantemente.
srijan

1
@srijan Bem, não. Assim? Ninguém estava reivindicando o contrário.
Mark Amery

10

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.


3

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.


1
O HTTP já tem manutenção, isso significa que o servidor não fecha a conexão e o cliente pode fazer muitos pedidos na mesma conexão.
José Nobile

3

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.


1

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.


1

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.


0

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

Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.