views:

139

answers:

6

Is there any difference in network communication for HTTP GET and POST requests?

With GET, I understand that the entire request is sent in one go. With POST, I think the initial request is sent, and then a second request is sent which sends all the parameters.

For example, assume that the latency between server and client is 500ms. What would be the total time for a GET vs POST call?

+1  A: 

For a given piece of data, they will likely be very nearly the same. Here is what a GET request may look like:

GET /test?x=5&y=3&z=4 HTTP/1.1
Header1: value
Header2: value
...

Here is how the same would look as a POST:

POST /test HTTP/1.1
Header1: value
Header2: value
...

x=5&y=3&z=4

So it's the same amount of data. The real question is whether you want the user to be able to bookmark and return to the URL and see the same data again in the future. GETs are used for that, POSTs are used for requesting data be changed on the server, or for security reasons (don't use GET to submit a password, for example).

Jonathan
I would add that POST requests can be multipart, essentially uploading a lot more data to the server, like an image, for instance. POST requests are not so much more secure, however, since when intercepted, the password is still clear text.
Ioannis Karadimas
@Ioannis No more secure when over HTTP, but over HTTPS at least your password isn't shown in the address bar if you POST. I did not cover multipart because the question was only about latency of POST vs GET; if you were uploading enough to need multipart, GET would not be an option in the first place.
Jonathan
Also, a GET can include body data after the headers, the data is not required to be in the URL. This is not commonly used, though.
Remy Lebeau - TeamB
You are both quite correct.
Ioannis Karadimas
A: 

Its all about implementation on client side. In http specs there is no such condition. Time to send depends on amount of data. If you use POST only to replace GET it will be indistinguishably.

Artem
+6  A: 

The packets are all TCP packets, which carry the HTTP protocol, the request method doesn't change the network layer's response time.

It will change on request-to-request basis depending on the size of a request, but that's not determined by the request type.

You can send more data with post than get, but this doesn't mean they respond faster, it's a separate issue.

The speed at which the HTTP server can process and return a result is on the server you're using, and likely to be so negligible it's not worth mentioning.

The speed at which the result comes back from the server depends on what resource the HTTP server is processing, if it's calling a PHP file that takes time, then it's going to take time...

There isn't a clear difference in the packets... this is a GET request over SSL:

00907f8252f7001e4fe86a93080045000028
0bb2400080067380ac100167adc22064c51a
01bb66ccad148448d84850103f05bde90000

And this is a POST request over SSL:

00907f8252f7001e4fe86a93080045000028
0c0640008006732cac100167adc22064c511
01bbe538c0df8621dc6150104042248c0000

There isn't exactly a lot of involvement of whether the string inside the TCP packet is "GET" or "POST," the network looks at it, says "oh, you're TCP, Huh? Well, off you go then." It doesn't care.

Any delay outside of normal network traffic is soley due to processing on the sever level, or on the code it's working through.

Fixed a typo for you (at least, I think I did).
musicfreak
+1  A: 

Jonathan's answer is very elucidative. But let me go a little further on the spot where requests differ from each other.

All information flowing through internet goes through small packages. Let's say each package has a max capacity of 1KB (this is not the correct value, it's just for clarification on the mechanism, if you want real values about limits go search on RFC's).

OK, so we have a GET and a POST request. The packages are very similar as ilustrated by Jonathan. In that case, with a small amount of data, everything can be wrapped inside the 1KB package, thus there are no differentce on the network performance.

But what if the request needs to be huge? A few people know, but there is a max length for a GET request which may vary by server. Try ask any site.com/foo/a{200 times A}. It will return an invalid/bad request, instead of just a 404 not found.

So here is where POST takes place. If data amount is bigger than a certain value, POST allows the server to continue listing to that request and parse the values.

Also there is another underlying difference in the behavior that wasn't mentioned before. POST data is parsed within browser to the current document encoding before being sent to the server.

Dave
+1 informative details I didn't talk about in my answer
@user257493 Actually I replyed before you, but got an HTTP 500 error, when I finally recovered and sent, you've replyed already. This is why I didn't mentioned your answer (which is good) in mine. Well I think @frankadelic should have enough information from all of us as of now. cheers.
Dave
+5  A: 
vol7ron
I believe your answer resolves the spirit in which the question was asked, while mine is correct to describe the network layer. I would suggest this answer is more correct than mine if the OP wants to know about the fastest end-to-end and reduced load setup.
A: 

I tested this while monitoring in Wireshark.

I created a simple HTML form and toggled the method between GET and POST.

Consistently, I noticed that GET requests send one packet, while POST sends two. Even when the form data is very small, the POST data is always sent in the second packet.

This suggests to me that POST would be more impacted by latency.

frankadelic