4 ms·

First actually useful and technical answer I've seen in this thread. But... which use cases of HTTP need us timers? It's not like gmail or other bloated web ap

• romed 8y ago
  The timers are in TCP not HTTP. TCP only ACKs every other packet. If the stream pauses after an odd number of packets, the sender has to just wait for the receiver to perform a delayed ACK, for which there is a timer on both sides. The sender infers that the last packet has been lost if the ACK doesn't arrive after a while. The sender has a thing called the retransmission timeout (RTO) and the receiver's delayed ACK timeout (ATO) sets a lower bound on the RTO. Modern TCP stacks have a thing called the tail loss probe that just sends a retransmit early (before the RTO) if the stream has stopped at an odd boundary. This is a bit of a hack. All of these things affect client-observed latency since obviously the client can't proceed until it gets the last packet. On mobile this is pretty important because mobile networks have massive packet loss. Anyway, that's mobile. In the datacenter all of these timers are way too high, by several orders of magnitude. 1ms is an outrageously long RTO in a datacenter fabric but 200ms is the minimum RTO allowed by the TCP RFCs.