Perché si dice che "HTTP è un protocollo senza stato"?


170

HTTP ha i cookie HTTP. I cookie consentono al server di tracciare lo stato dell'utente, il numero di connessioni, l'ultima connessione, ecc.

HTTP ha connessioni permanenti (Keep-Alive) in cui è possibile inviare più richieste dalla stessa connessione TCP.


3
Un'altra area in cui non vedo "apolidia" è in Autorizzazione - in particolare l'autorizzazione proxy. Sembra che sia stato durante la negoziazione. Per l'autenticazione NTLM, il client deve ricordare il tipo di autenticazione proxy e il server deve essere stateful poiché esiste una sequenza per i tipi di messaggi NTLM. Quindi non sono sicuro di aver capito le risposte.
Lindsay Morsillo,

1
Ora dovrei aggiungere HTTP / 1.1? Perché penso che HTTP / 2 abbia stato.
Jose Nobile,

4
HTTP / 2 è stateful. HTTP 1 è senza stato. Aggiunte successive intese per HTTP 1, come i cookie, stato aggiunto. Tali aggiunte non fanno parte della specifica "core" HTTP 1. Ecco perché si dice che HTTP 1 sia un protocollo senza stato, sebbene in pratica non lo sia. HTTP / 2 invece è stato progettato con componenti stateful integrati. Non sono state richieste aggiunte per soddisfare il requisito di essere etichettati "stateful".
Zamicol,

Risposte:


130

Anche se più richieste possono essere inviate sulla stessa connessione HTTP, il server non attribuisce alcun significato speciale al loro arrivo sullo stesso socket. Questa è solo una cosa di prestazione, intesa a minimizzare il tempo / larghezza di banda che altrimenti verrebbe speso per ristabilire una connessione per ogni richiesta.

Per quanto riguarda l'HTTP, sono ancora richieste separate e devono contenere informazioni sufficienti per soddisfare la richiesta. Questa è l'essenza dell '"apolidia". Le richieste non saranno associate tra loro in assenza di alcune informazioni condivise di cui il server è a conoscenza, che nella maggior parte dei casi è un ID di sessione in un cookie.


1
Cosa succede quando il server ricorda una sessione (lato server) e personalizza l'esperienza utente in base ad essa?
NurShomik

3
@NurShomik: Vedere stackoverflow.com/a/3521393/319403~~V~~singular~~3rd per una spiegazione di come le sessioni di lavoro in genere.
cHao,

12
@Andrew: HTTP non è "costruito su" TCP e lo stato di TCP non è HTTP. I due sono protocolli completamente separati a diversi livelli nello stack. Potresti servire HTTP su pipe nominate se lo desideri, o anche inviando file in giro, se hai abbastanza masochisti per accettarlo, e funzionerebbe proprio perché HTTP è indipendente dal protocollo di trasporto. A quel livello, sono solo richieste e risposte. Ciò rende lo stesso HTTP senza stato, indipendentemente dallo stato che può essere utilizzato / mantenuto / richiesto dai protocolli di livello inferiore o superiore.
cHao,

@cHao Ok, lo ammetto. Se definiamo l'apolidia come "non necessariamente necessario avere uno stato per operare" (vedi la risposta di dimo414 sotto le opzioni di elenco per lo stato all'interno di HTTP citate da Wikipedia), e se consideriamo ogni protocollo rigorosamente da solo e non basato sui livelli sottostanti , quindi sì, posso essere d'accordo sul fatto che HTTP è "apolide".
Andrew,

101

Da Wikipedia :

HTTP è un protocollo senza stato. Un protocollo senza stato non richiede al server di conservare informazioni o stato su ciascun utente per la durata di più richieste.

Tuttavia, alcune applicazioni Web potrebbero dover tenere traccia dei progressi dell'utente da una pagina all'altra, ad esempio quando è richiesto un server Web per personalizzare il contenuto di una pagina Web per un utente. Le soluzioni per questi casi includono:

  • l'uso di cookie HTTP.
  • sessioni lato server,
  • variabili nascoste (quando la pagina corrente contiene un modulo) e
  • Riscrittura URL utilizzando parametri codificati URI, ad esempio /index.php?session_id=some_unique_session_code.

Ciò che rende il protocollo senza stato è che il server non è tenuto a tracciare lo stato su più richieste, non che non possa farlo se lo desidera. Ciò semplifica il contratto tra client e server e, in molti casi (ad esempio, fornendo dati statici su una rete CDN), riduce al minimo la quantità di dati che devono essere trasferiti. Se ai server fosse richiesto di mantenere lo stato delle visite dei clienti, la struttura di emissione e risposta alle richieste sarebbe più complessa. Così com'è, la semplicità del modello è una delle sue più grandi caratteristiche.


21

Perché un protocollo senza stato non richiede al server di conservare le informazioni o lo stato della sessione su ciascun partner di comunicazione per la durata di più richieste.

HTTP è un protocollo senza stato, il che significa che la connessione tra il browser e il server viene persa al termine della transazione.


2
Tuttavia, HTTP può salvare informazioni nel server, utilizzando i cookie. HTTP con keep-alive non chiude la connessione su ogni richiesta.
Jose Nobile,


18
Il salvataggio delle informazioni sul server non significa che la connessione sia costantemente attiva.
srijan,

1
@srijan Bene, no. Così? Nessuno pretendeva diversamente.
Mark Amery,

10

HTTP viene chiamato come stateless protocolperché ogni richiesta viene eseguita in modo indipendente, senza alcuna conoscenza delle richieste che sono state eseguite prima di essa, il che significa che una volta terminata la transazione viene persa anche la connessione tra il browser e il server.

Ciò che rende il protocollo statelessè che nella sua progettazione originale, HTTP è relativamente semplice file transfer protocol:

  1. effettuare una richiesta per un file denominato da un URL,
  2. ottenere il file in risposta,
  3. disconnessione.

Non è stata mantenuta alcuna relazione tra una connessione e l'altra, anche dallo stesso client. Ciò semplifica il contratto tra client e server e, in molti casi, riduce al minimo la quantità di dati che devono essere trasferiti.


3

Se il protocollo HTTP viene fornito come protocollo completo Stato, la finestra del browser utilizza una singola connessione per comunicare con il server Web per richieste multiple fornite all'applicazione Web. Ciò consente alla finestra del browser di impegnare le connessioni tra la finestra del browser e i server Web per lungo tempo e di mantenere in stato di inattività per lungo tempo. Ciò può creare la situazione per raggiungere le connessioni massime del server Web anche se la maggior parte delle connessioni nei client sono inattive.


1
HTTP ha già keep-alive, questo significa che il server non chiude la connessione e il client può effettuare molte richieste sulla stessa connessione.
Jose Nobile,

3

HTTP è senza connessione e questo è un risultato diretto che HTTP è un protocollo senza stato. Il server e il client si conoscono solo durante una richiesta corrente. Successivamente, entrambi si dimenticano l'uno dell'altro. A causa di questa natura del protocollo, né il client né il browser sono in grado di conservare informazioni tra richieste diverse tra le pagine Web.


1

Che cos'è apolide ??

Una volta effettuata la richiesta e restituita la risposta al client, la connessione verrà interrotta o interrotta. Il server dimenticherà tutto sul richiedente.

Perché apolide ??

Il web sceglie di scegliere il protocollo stateless. È stata una scelta geniale perché l'obiettivo originale del Web era quello di consentire ai documenti (pagine Web) di essere serviti a un numero estremamente elevato. di persone che utilizzano hardware di base per il server.

Il mantenimento di una connessione a lungo termine sarebbe stato estremamente dispendioso in termini di risorse.

Se al web fosse stato scelto il protocollo stateful, il carico sul server sarebbe stato aumentato per mantenere la connessione del visitatore.


1

HTTPè apolide. TCPè di stato. Non esiste un cosiddetto HTTP connection, ma solo HTTP requeste HTTP response. Non abbiamo bisogno di nulla da mantenere per crearne un altro HTTP request. Un'intestazione di connessione "keep-alive" significa TCPche verrà riutilizzato dalle HTTPrichieste e risposte successive , anziché disconnettere e ristabilire la TCPconnessione in ogni momento.


0

Penso che qualcuno abbia scelto un nome molto sfortunato per il concetto STATELESS ed è per questo che l'intero malinteso è causato. Non si tratta di archiviare alcun tipo di risorsa, ma piuttosto della relazione tra client e server.

Cliente: Sto mantenendo tutte le risorse dalla mia parte e ti invio la "lista" di tutti gli elementi importanti che devono essere elaborati. Fai il tuo lavoro.

Server: Va bene ... lasciami assumermi la responsabilità di filtrare ciò che è importante per darti la risposta corretta.

Ciò significa che il server è lo "schiavo" del client e deve dimenticare il suo "master" dopo ogni richiesta. In realtà, STATELESS si riferisce solo allo stato del server.

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

Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.