Ich verstehe nicht ganz, ob ich http-Formulardaten vom Browser auf den Server poste. Muss das Protokoll noch einen Drei-Wege-Handshake (Syn-Ack-Daten) ausführen oder funktioniert es nur für GET-http-Anforderungen?
Ich verstehe nicht ganz, ob ich http-Formulardaten vom Browser auf den Server poste. Muss das Protokoll noch einen Drei-Wege-Handshake (Syn-Ack-Daten) ausführen oder funktioniert es nur für GET-http-Anforderungen?
Antworten:
Sowohl HTTP GET als auch HTTP POSTS verwenden TCP. Wenn Sie fragen, ob ein POST auch einen 3-Wege-TCP-Handshake (syn-synack-ack) erfordert, funktioniert er wie jede andere TCP-Verbindung. Der TCP-Handshake ist erforderlich, bevor ein Anwendungsprotokoll (z. B. HTTP) seine Arbeit aufnimmt.
Zu Ihrer Information, Ihr Drei-Wege-Handschlag ist falsch. es sollte "syn-synack-ack" sein
HINZUFÜGEN:
Wenn der Browser das QUIC- Protokoll (Quick UDP Internet Connections, ausgesprochen schnell. Vorgeschlagen von Google) für HTTP verwendet, kann ein 3-Wege-TCP-Handshake vermieden werden. Aber AFAIK wird in Chrome und Google unterstützt.
Die meisten Programme bevorzugen HTTP / 2, das immer noch TCP ist, aber mit vielen Funktionen eine dauerhafte Verbindung verwendet und dann einen 3-Wege-Handshake einmal für jeden Server-Server ausführt.
Wenn dieses Protokoll verwendet wird, kann 3-Wege-Hanshake durch jede Anforderung, einschließlich GET, vermieden werden.
Wenn Sie allgemein fragen, lautet die Antwort mit Sicherheit "Ja". Für jede HTTP-Methode (wie POST) ist eine TCP-Verbindung erforderlich. Die einzige Möglichkeit, eine TCP-Verbindung herzustellen, besteht in der Verwendung des Drei-Wege-Handshakes.
Wenn Sie jedoch in einem bestimmten Fall fragen, ob Sie möglicherweise Ihren eigenen Datenverkehr erfassen und den 3-Wege-Handshake nicht sehen, nachdem Sie Inhalte an eine Website gesendet haben, ist die Antwort etwas weniger einfach. Wir müssen einige HTTP-bezogene Konzepte diskutieren, bevor wir sie richtig beantworten können ...
In der ursprünglichen Version von HTTP1.0 musste für jedes Objekt, das Sie von einer Webseite angefordert haben, für jedes Objekt eine neue TCP-Verbindung hergestellt werden. Nehmen Sie die folgende vereinfachte Website, die Text und zwei Bilder enthält:
<HTML>
<HEAD>
<TITLE>My Title</TITLE>
</HEAD>
<BODY>
Stack Exchange Rules!
<IMG SRC="a.gif">
<IMG SRC="b.gif">
</BODY>
</HTML>
In herkömmlichem HTTP1.0 sind zum Laden dieser Website in Ihren Browser drei TCP-Verbindungen erforderlich (jede mit eigenem 3-Wege-Handshake und 4-Wege-Schließung).
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
Beachten Sie, dass oben 27 Pakete enthalten sind, um nur drei Elemente herunterzuladen: Die HTML-Seite selbst (index.html), image a.gif und image b.gif. (Es würde tatsächlich mehr als 27 Pakete geben, aber um vertikalen Platz zu sparen, habe ich nur die ACKs in den 3-Wege-Handshake und den 4-Wege-Verschluss aufgenommen und ACKs im Datenstrom weggelassen.)
Um die Effizienz von HTTP zu verbessern, wurde eine Funktion namens "Connection Keepalive" eingeführt, mit der HTTP dieselbe TCP-Verbindung wiederverwenden kann, um mehrere Objekte anzufordern. Die obige Übertragung würde auf Folgendes reduziert:
HTTP 1.1 mit 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
Beachten Sie, dass nur eine einzige TCP-Verbindung verwendet wurde, um alle drei Objekte anzufordern. Diesmal waren nur 13 Pakete erforderlich, eine große Verbesserung gegenüber den 27 Paketen von früher.
Die letzte Verbesserung von HTTP, die wir diskutieren müssen, ist eine Funktion namens Pipelining. Diese Funktion hat die Effizienz von HTTP weiter erhöht, indem der Client mehrere Optionen gleichzeitig anfordern kann, ohne auf den Empfang des zuvor angeforderten Objekts warten zu müssen. Lass mich dir zeigen:
HTTP1.1 mit Pipelining
--> SYN
SYN ACK <--
--> ACK
--> GET /index.html
--> GET /a.gif
--> GET /b.gif
<index.html> <--
<a.gif> <--
<b.gif> <--
--> FIN
ACK <--
FIN <--
--> ACK
Wir verwenden immer noch nur eine TCP-Verbindung und wir verwenden immer noch nur 9 Pakete. Wir müssen jedoch nicht auf die Round Trip Time (RTT) warten, die zwischen dem Client und dem Server zwischen dem Anfordern und Empfangen jedes Objekts benötigt wird. Wenn Sie eine Analogie benötigen, stellen Sie sich vor, Sie sind in einem Restaurant und benötigen Salz, Pfeffer und Ketchup. Ist es effizienter, Ihren Kellner / Ihre Kellnerin nach allen drei Artikeln gleichzeitig zu fragen oder nacheinander nach ihnen zu fragen und zu warten, bis sie zurückkommen, bevor Sie die nächste Anfrage stellen?
(Pipelining steht nicht in direktem Zusammenhang mit Ihrer Frage, wird jedoch häufig in Verbindung mit Keepalives und anderen HTTP-Effizienzfunktionen beschrieben. Aus Gründen der Vollständigkeit habe ich beschlossen, es in diese Antwort aufzunehmen.)
Jetzt können wir endlich auf Ihre Frage zurückkommen:
Ist für einen HTTP-POST ein TCP-Drei-Wege-Handshake erforderlich?
Wenn Sie eine Verbindung zu einem Webserver herstellen und eine Webseite mit der GET-Methode herunterladen und dieser Webserver die Verbindungsaufbewahrung unterstützt. Nachfolgende Anforderungen an diesen Webserver, einschließlich der POST-Methode, verwenden möglicherweise einfach die bereits vorhandene TCP-Verbindung wieder. Daher würde dieser bestimmte POST keinen neuen 3-Wege-Handshake erfordern, da die Daten in einer bereits vorhandenen TCP-Verbindung übertragen würden.
Connection Keepalive hat jedoch keine unendliche Dauer. Wenn Sie also nach dem Herunterladen der Webseite eine Weile gewartet haben, bevor Sie Ihren POST gesendet haben, wurde die ursprüngliche TCP-Verbindung möglicherweise bereits geschlossen. In diesem Fall müsste Ihr Browser eine neue TCP-Verbindung zum POST Ihrer Daten öffnen, was natürlich einen Start erforderlich machen würde mit dem 3-Wege-Handschlag.
Da viele Browser und Webserver unterschiedliche Timer verwenden, um zu ermitteln, wie lange die Funktion "Verbindungs-Keepalive" die Verbindung am Leben erhalten soll, kann ich Ihnen keine zuverlässigen Zahlen darüber geben, wie lange sie normalerweise benötigt.