I don't quite understand if i posting http form data from the browser to the server, does the protocol still need to make three-way handshake (syn-ack-data) or it only works for GET http requests?
Add a comment
|
3 Answers
Both HTTP GET and HTTP POSTS use TCP. If you are asking whether a POST also requires a 3-way TCP handshake (syn-synack-ack), it does just like any other TCP connection. The TCP handshake is required before any application protocol (such as HTTP) starts work.
FYI, your three-way handshake is incorrect; it should be "syn-synack-ack"
ADD:
If browser use QUIC (Quick UDP Internet Connections, pronounced quick. Proposed by Google) protocol for HTTP is possible to avoid 3-way TCP handshake. But AFAIK it supported in Chrome and Google.
Most software prefer HTTP/2 which still TCP but wit many features it use persistent connection then 3-way handshake done once for each server server.
If this protocols is used, 3-way hanshake can be avoided by any request, including GET.
If you are asking in a general sense, then the answer is most definitely "yes", any HTTP method (like POST) requires a TCP connection, and the only way to initiate a TCP connection is to use the three way handshake.
IF, however, you are asking in a specific case, maybe if you are capturing your own traffic and don't see the 3 way handshake after you submit content to a website, then the answer is a little less simple. We'll have to discuss a few HTTP related concepts before we can properly answer it...
In the original release of HTTP1.0, every object you requested from a webpage required a new TCP connection to be formed for each object. Take the following simplistic website that includes some text, and two images:
<HTML>
<HEAD>
<TITLE>My Title</TITLE>
</HEAD>
<BODY>
Stack Exchange Rules!
<IMG SRC="a.gif">
<IMG SRC="b.gif">
</BODY>
</HTML>
In traditional HTTP1.0, to load this website into your browser would require three TCP connections (each with their own 3-way handshake, and 4-way closure).
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
Note there are 27 packets above, just to download three items: The HTML page itself (index.html), image a.gif, and image b.gif. (there would actually be more than 27 packets, but to save vertical space, I only included the ACK's in the 3-way-handshake and the 4-way-closure, and omitted ACK's within the data stream)
To improve the efficiency of HTTP, a feature called "Connection Keepalive" was introduced, which allows HTTP to re-use the same TCP connection to request for multiple objects. The transfer above would be reduced to the following:
HTTP 1.1 with 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
Notice that only a single TCP connection was used to request all three objects. This time, it only took 13 packets, a large improvement from the 27 from earlier.
The last imrpovement to HTTP that we must discuss is a feature called Pipelining. This feature further increased HTTP's efficiency, by making it so the Client can requests multiple options at once, without waiting to receive the prior asked object. Let me show you:
HTTP1.1 with Pipelining
--> SYN
SYN ACK <--
--> ACK
--> GET /index.html
--> GET /a.gif
--> GET /b.gif
<index.html> <--
<a.gif> <--
<b.gif> <--
--> FIN
ACK <--
FIN <--
--> ACK
We're still only using one TCP connection, and we're still only using 9 packets. However, we don't have to wait the Round Trip Time (RTT) it takes between the Client and the Server in between asking for and receiving each object. If you need an analogy, imagine you're at a Restaurant, and you need Salt, Pepper, and Ketchup. Is it more efficient to ask your waiter/waitress for all three items at once, or to ask for them one at a time and wait for them to come back before making the next request?
(Pipelining isn't directly related to your question, but is often described in conjunction with Keepalives and other HTTP efficiency features, so I decided to include it in this answer for completeness)
Now we can finally come back to your question:
Is a TCP three-way handshake required for an HTTP POST?
If you open a connection to a web server and download a webpage using the GET method, and that webserver supports connection keepalive. Subsequent requests to that web server, including the POST method, might simply re-use the already existing TCP connection. Therefore, that particular POST would not require a new 3-way handshake, since the data would be transferred in an already existing TCP connection.
Connection Keepalive, however, does not have an infinite duration. So if after downloading the webpage, you waited a while before sending your POST, the original TCP connection may have already closed, and in this case, your browser would have to open a new TCP connection to POST your data, which would obviously require starting with the 3-way handshake.
Since many browsers and webservers use different timers for how long they want their "connection keepalive" feature to keep connections alive, I wouldn't be able to give you reliable numbers as to how long they typically last.
-
1This is a more complete answer. Thanks a lot. Definitely worth to be upvoted. Nov 22, 2016 at 18:56
-
1
-
Actually, three-way handshake is not the only way to open TCP connections. To mention the other ways, there are simultaneous connection open and split handshake at least.– juhistMar 5, 2017 at 13:04
-
1The world would be a better place if all the answer would be detailed like this one! Well done, very well explained.– dawezMay 24, 2018 at 20:53
-
1
Indeed. But anyways, there's still a way to make it more efficient — data can be put into SYN-SYNACK-ACK packets, although until the handshake's done, the data can't be used.
