Non capisco bene se invio i dati del modulo http dal browser al server, il protocollo deve ancora eseguire l'handshake a tre vie (syn-ack-data) o funziona solo per le richieste GET http?
Non capisco bene se invio i dati del modulo http dal browser al server, il protocollo deve ancora eseguire l'handshake a tre vie (syn-ack-data) o funziona solo per le richieste GET http?
Risposte:
Sia HTTP GET che HTTP POSTS utilizzano TCP. Se stai chiedendo se un POST richiede anche un handshake TCP a 3 vie (syn-synack-ack), fa esattamente come qualsiasi altra connessione TCP. L'handshake TCP è necessario prima che qualsiasi protocollo applicativo (come HTTP) inizi a funzionare.
Cordiali saluti, la tua stretta di mano a tre vie non è corretta; dovrebbe essere "syn-synack-ack"
INSERISCI:
Se il browser utilizza il protocollo QUIC (Quick UDP Internet Connections, pronunciato rapidamente. Proposto da Google) per HTTP è possibile evitare l'handshake TCP a 3 vie. Ma AFAIK ha supportato in Chrome e Google.
La maggior parte dei software preferisce HTTP / 2, che è ancora TCP ma con molte funzionalità che utilizza la connessione persistente e l'handshake a 3 vie fatto una volta per ciascun server server.
Se si utilizzano questi protocolli, l'hanshake a 3 vie può essere evitato da qualsiasi richiesta, incluso GET.
Se stai chiedendo in senso generale, allora la risposta è sicuramente "sì", qualsiasi metodo HTTP (come POST) richiede una connessione TCP e l'unico modo per avviare una connessione TCP è utilizzare l'handshake a tre vie.
Se, tuttavia, stai chiedendo in un caso specifico, forse se stai acquisendo il tuo traffico e non vedi la stretta di mano a 3 vie dopo aver inviato il contenuto a un sito Web, la risposta è un po 'meno semplice. Dovremo discutere alcuni concetti relativi a HTTP prima di poter rispondere correttamente ...
Nella versione originale di HTTP1.0, ogni oggetto richiesto da una pagina Web richiedeva la formazione di una nuova connessione TCP per ciascun oggetto. Prendi il seguente sito Web semplicistico che include del testo e due immagini:
<HTML>
<HEAD>
<TITLE>My Title</TITLE>
</HEAD>
<BODY>
Stack Exchange Rules!
<IMG SRC="a.gif">
<IMG SRC="b.gif">
</BODY>
</HTML>
In HTTP1.0 tradizionale, per caricare questo sito Web nel browser sono necessarie tre connessioni TCP (ognuna con il proprio handshake a 3 vie e chiusura a 4 vie).
HTTP 1.0:
--> SYN
SYN ACK <--
--> ACK
--> GET /index.html
<index.html> <--
--> FIN
ACK <--
FIN <--
--> ACK
.
--> SYN
SYN ACK <--
--> ACK
--> GET /a.gif
<a.gif> <--
--> FIN
ACK <--
FIN <--
--> ACK
.
--> SYN
SYN ACK <--
--> ACK
--> GET /b.gif
<b.gif> <--
--> FIN
ACK <--
FIN <--
--> ACK
Nota che ci sono 27 pacchetti sopra, solo per scaricare tre elementi: la stessa pagina HTML (index.html), image a.gif e image b.gif. (in realtà ci sarebbero più di 27 pacchetti, ma per risparmiare spazio verticale, ho incluso solo gli ACK nella stretta di mano a 3 vie e nella chiusura a 4 vie e omesso gli ACK nel flusso di dati)
Per migliorare l'efficienza di HTTP, è stata introdotta una funzione chiamata "Keep Keepalive", che consente a HTTP di riutilizzare la stessa connessione TCP per richiedere più oggetti. Il trasferimento sopra riportato sarebbe ridotto a quanto segue:
HTTP 1.1 con Connection Keepalive
--> SYN
SYN ACK <--
--> ACK
--> GET /index.html
<index.html> <--
--> GET /a.gif
<a.gif> <--
--> GET /b.gif
<b.gif> <--
--> FIN
ACK <--
FIN <--
--> ACK
Si noti che è stata utilizzata una sola connessione TCP per richiedere tutti e tre gli oggetti. Questa volta, ci sono voluti solo 13 pacchetti, un notevole miglioramento rispetto ai 27 precedenti.
L'ultimo passaggio a HTTP che dobbiamo discutere è una funzione chiamata Pipelining. Questa funzionalità ha ulteriormente aumentato l'efficienza HTTP, rendendola in modo che il Cliente possa richiedere più opzioni contemporaneamente, senza aspettare di ricevere l'oggetto richiesto in precedenza. Lascia che ti mostri:
HTTP1.1 con Pipelining
--> SYN
SYN ACK <--
--> ACK
--> GET /index.html
--> GET /a.gif
--> GET /b.gif
<index.html> <--
<a.gif> <--
<b.gif> <--
--> FIN
ACK <--
FIN <--
--> ACK
Stiamo ancora usando solo una connessione TCP e stiamo ancora usando solo 9 pacchetti. Tuttavia, non dobbiamo attendere il Round Trip Time (RTT) che intercorre tra il client e il server tra la richiesta e la ricezione di ciascun oggetto. Se hai bisogno di un'analogia, immagina di essere in un ristorante e hai bisogno di sale, pepe e ketchup. È più efficiente chiedere al tuo cameriere / cameriera tutti e tre gli elementi contemporaneamente, oppure chiederli uno alla volta e attendere che tornino prima di effettuare la richiesta successiva?
(Il pipelining non è direttamente correlato alla tua domanda, ma è spesso descritto insieme a Keepalives e altre funzionalità di efficienza HTTP, quindi ho deciso di includerlo in questa risposta per completezza)
Ora possiamo finalmente tornare alla tua domanda:
È necessario un handshake a tre vie TCP per un POST HTTP?
Se si apre una connessione a un server Web e si scarica una pagina Web utilizzando il metodo GET e tale server Web supporta keepalive della connessione. Le richieste successive a quel server Web, incluso il metodo POST, potrebbero semplicemente riutilizzare la connessione TCP già esistente. Pertanto, quel particolare POST non richiederebbe una nuova stretta di mano a 3 vie, poiché i dati sarebbero trasferiti in una connessione TCP già esistente.
Connection Keepalive, tuttavia, non ha una durata infinita. Quindi, se dopo aver scaricato la pagina Web, hai atteso un po 'di tempo prima di inviare il tuo POST, la connessione TCP originale potrebbe essersi già chiusa e, in questo caso, il tuo browser dovrebbe aprire una nuova connessione TCP per inviare i tuoi dati, che ovviamente richiederebbe l'avvio con la stretta di mano a 3 vie.
Poiché molti browser e server web utilizzano timer diversi per quanto tempo desiderano che la loro funzione "keepalive di connessione" mantenga attive le connessioni, non sarei in grado di fornirti numeri affidabili per quanto tempo richiede in genere.