I'm trying to get a first-order evaluation of how network latency / Round Trip Time (RTT) T, as characterized by ping time, will affect the duration of consecutive sequential POST requests over an https connection (assumed established, reused across requests, and using TLS v1.1 or better). I'm assuming large T (think 200 ms), and I'm primarily asking if T influences the POST duration with a multiplication factor of 1, or some higher integer.

The client waits for answer from a server before sending the next request. Requests and answers are small, and we can at first assume the MTU is not reached even with the encryption/MAC overhead. I'm willing to neglect processing delays by client and server, packet loss, and variations of routing delays.

I reason that for large T, the average POST time is about N * T for some small positive integer N; and hope that N = 1 ; is that positively certain (under the above assumptions)?

How does request and answer size increase that? What parameters mater, like TLS or TCP/IP.. options?

  • Did any answer help you? If so, you should accept the answer so that the question doesn't keep popping up forever, looking for an answer. Alternatively, you can provide your own answer and accept it. – Ron Maupin Aug 6 '17 at 22:29
  • @Ron Maupin: I'm still not seeing an answer that straightly states N=1 or at least N≪1.5. But that can be deduced from the lack of argument that N≥2 in the answer that I accepted, and is why I did so. – fgrieu Aug 7 '17 at 7:54

N will always be more than 1. It is impossible to accurately judge exactly how much more than 1, but here are some factors that will contribute to increasing the time between a Post request and an HTTP response:

I'm going to do this from the perspective of a single Post and a single HTTP response compared to a single Echo Request and a single Echo Reply. The time increase between 1 ICMP Exchange and HTTP Exchange verses 3 ICMP/HTTP Exchanges would be linear. Each exchange would be affected by each of factor belows.

1. There are more packets sent/received in the HTTP Post/Response

A ping 'sequence' is this:

01 Client --> Server ICMP Request
02 Client <-- Server ICMP Response.

Where as a HTTP Post/Response sequence would look like this:

01 Client --> Server HTTP Post
02 Client <-- Server TCP ACK
03 Client <-- Server HTTP Response

The Server doesn't need wait for the ACK (packet #2) to get to the client before sending the HTTP Response (packet #3). Both of those packets are sent directly one after the other. But either way, it is still a second packet that must be sent, so an increase to your value N.

2. Additional Crypto processing causes additional overhead

Even if the TCP Ack (packet #2 above) didn't need to be sent, the simple fact that the packets are secured with HTTPS is going to require both parties to validate the packet and decrypt the content before it gets passed to the HTTP interpreter.

Which is something the ICMP packet would not require. Hence, additional time added to N for the HTTP Request/Response.

3. HTTP packets might call for additional inspection by transient devices.

If this communication happens through a Firewall, it is likely the Firewall (or some sort of WAF/IPS) is performing additional processing/inspection/validation on the HTTP packets. In particular, since this a Post request.

This is less likely if it is HTTPS. But many transient firewalls can now decrypt HTTPS, inspect the underlying HTTP, and then re-encrypt the HTTPS before sending it on its way. Again, less likely, but not something we can dutifully rule out entirely.

Such inspection would not be necessary for simple ICMP packets. And not just because the packets themselves would more than likely be smaller. There is just less malicious intent that can exist with the far simpler ICMP protocol, as such more 'attention' is put in to deeper inspection of the HTTP/HTTPS.

4. An HTTP Post requires more processing by the server

Responding to an ICMP Response is (relatively) easy. At best, there is a little bit of data in the ICMP echo Payload to copy to the ICMP Response. Depending the content of the HTTP Post, there is more to consider.

Is there data entry validation? Does the content that is posted need to be processed and somehow included in the HTTP Response? Does it have to be processed 'as is', or does it require some analyzing before a useful HTTP Response can be produced?

There are literally endless possibilities for what sort of analyzing and/or data is presented in the Post. And this additional processing would also account for an increase to your N value.

I'm sure there are others, but those are the ones I could come up with thus far.

Edit: added #4


You can't compare times between packets (like ICMP) that only get as high as layer-3 to datagrams (like HTTP) that must endure processing all the way up to layer 7.

The difference is going to depend on the hosts on each end. The host processing is going to add a large, unpredictable overhead. You have no way of knowing the capabilities of the hosts, the applications that the hosts are using, and the host load.

Such a comparison is not valid since it will vary greatly based on the endpoints themselves which has nothing at all to do with the network.


Certainly, network latency plays a part, and a change in latency affects the total time, but what you get from a PING can't really be used in the calculation. The TCP nature of HTTP/HTTPS will vary the amount of data that can be transferred in a window. TCP, with its reliability algorithms, will multiply the latency, but it is not a constant multiple, varying during a transfer.

The nature of the layers higher than layer-3 will multiply the latency in ways that you can't completely predict, but you may be able to average them over a period of time if the data transferred is identically sized every time.

Not the answer you're looking for? Browse other questions tagged or ask your own question.