In che modo HTTP diventa apolide?

Si dice che HTTP sia apolide. Significato, non è necessario archiviare informazioni per la trasmissione di dati.

Ma HTTP utilizza TCP, che è orientato allo stato.

In tal caso, in che modo HTTP diventa apolide?

All'HTTP non interessa - ed è indipendente da - nessuno dei protocolli di livello inferiore usati per trasportare se stesso, anche se è esso stesso apolide.

La tecnologia di trasporto può essere TCP, o il vecchio SPX di Novell, o SCTP, o qualsiasi altra cosa tu possa immaginare, e HTTP continuerà a funzionare allo stesso modo. HTTP richiede un protocollo orientato allo streaming o orientato alla connessione e dipende dalla risoluzione degli URL, ma non importa come ciò venga realizzato.

Questo è uno dei motivi per cui esiste il modello a più livelli o lo stack di rete: il livello dell'applicazione non deve occuparsi di livelli inferiori.

Solo perché un protocollo di livello inferiore è stateful non significa che nulla in più diventi automaticamente stateful o sia necessario per essere stateful.

HTTP stesso è senza stato. Ciò significa che le applicazioni devono implementare un altro livello sopra HTTP per stabilire lo stato. Questo in genere viene fatto con i cookie di sessione.

"HTTP è senza stato" significa che ogni transazione HTTP (coppia richiesta-risposta) può essere elaborata indipendentemente da qualsiasi stato dalla precedente coppia richiesta-risposta.

Per trasportare la particolare coppia richiesta-risposta è necessario un protocollo in grado di trasportare lì blocchi arbitrariamente grandi e blocchi di dimensioni arbitrariamente grandi, e per farlo su un layer con dimensioni dei pacchetti limitate, TCP deve essere stateful.

Ma oltre il limite delle transazioni, non esiste uno stato. Il client può eliminare la connessione e stabilirne una nuova per la richiesta successiva. In effetti questa era l'unica opzione nelle prime versioni e funziona ancora così se il client non include l' Connection: keep-aliveintestazione.

La richiesta successiva può anche essere facilmente gestita da server diversi e il client non lo saprà mai, poiché il server non ha bisogno di mantenere alcuno stato (a meno che l'applicazione non aggiunga il proprio stato sopra HTTP, di solito in forma di sessione; le conseguenti complicazioni nel bilanciamento del carico è la sua punizione per la costruzione di protocollo con stato su HTTP). Ciò viene sfruttato nei server occupati con bilanciamento del carico.

La natura "senza stato" di HTTP significa che su questo livello non vengono create o utilizzate informazioni sullo stato.

Puoi vederlo in alcuni casi, ad esempio nell'autenticazione HTTP, le credenziali vengono inviate con ogni richiesta e le connessioni persistenti sono in realtà solo un'ottimizzazione (cioè se invio le credenziali, il server le dimentica dopo la richiesta, anche se lascia la connessione è aperta).

Al contrario, i meccanismi di accesso basati su cookie sono stateful, ma non fanno parte di HTTP.

Devi capirlo come un set di bambole russe (o scatole se vuoi) ognuna delle quali ne trasporta un'altra all'interno, ecco come funziona: TCP porta HTTP "dentro", ma non gliene importa o le sue caratteristiche.

Per ottenere il quadro completo, ti consiglio di leggere il Modello OSI in quanto lo rende più chiaro.

TCP si trova alcuni livelli al di sotto di HTTP nel modello OSI, ogni livello corrisponde infatti a un protocollo diverso.

Nel nostro caso HTTP si trova nei livelli di presentazione e applicazione e TCP nel livello di trasporto. Oppure se si utilizza il modello TCP / IP, entrambi i protocolli TCP e IP si trovano nel livello Network Link e HTTP nei livelli applicazione e presentazione.