3 ms·
This is especially true since HTTP/2 uses TCP, and TCP is designed to interpret flaky wifi or cellular connections as congestion and become unusably slow. It's
by anonymoushn 6y ago
This is especially true since HTTP/2 uses TCP, and TCP is designed to interpret flaky wifi or cellular connections as congestion and become unusably slow. It's a fairly common situation in which you don't want to pay for additional round trips.
- cma 6y agoIsn't that handled with layer 2 retransmissions now?
- yaantc 6y agoPartially. There are local (L2) and fast re-transmit with ARQ [1] and HARQ [2] (at least in cellular, which I know, but I guess Wifi likely has both too), and it can help hide some packet loss to the upper layers. But this still creates added delay, which is seen by TCP as more RTT jitter, with a bad impact on performance. Also, if the link degrades really badly TCP will definitely see more congestion and loss. So yes, the L2 will do all it can do hides wireless issues to the upper layers. But it cannot make miracles and wireless is still a challenging medium for end-to-end congestion control. There's still work at the TCP (or let's say end-to-end congestion control layer, with QUIC) to improve things, see BBRv2 for example. It's an active area, and any new generation tends to push the current state of the art. [1] https://en.wikipedia.org/wiki/Automatic_repeat_request https://en.wikipedia.org/wiki/Automatic_repeat_request [2] https://en.wikipedia.org/wiki/Hybrid_automatic_repeat_request https://en.wikipedia.org/wiki/Hybrid_automatic_repeat_reques...