top | item 44614173

(no title)

mikl | 7 months ago

How relevant is this now, if you have a modern server that supports HTTP/3?

HTTP/3 uses UDP rather than TCP, so TCP slow start should not apply at all.

discuss

order

gbuk2013|7 months ago

As per the article, QUIC (transport protocol underneath HTTP/3) uses slow start as well. https://datatracker.ietf.org/doc/id/draft-ietf-quic-recovery...

gsliepen|7 months ago

A lot of people don't realize that all these so-called issues with TCP, like slow-start, Nagle, window sizes and congestion algorithms, are not there because TCP was badly designed, but rather that these are inherent problems you get when you want to create any reliable stream protocol on top of an unreliable datagram one. The advantage of QUIC is that it can multiplex multiple reliable streams while using only a single congestion window, which is a bit more optimal than having multiple TCP sockets.

One other advantage of QUIC is that you avoid some latency from the three-way handshake that is used in almost any TCP implementation. Although technically you can already send data in the first SYN packet, the three-way handshake is necessary to avoid confusion in some edge cases (like a previous TCP connection using the same source and destination ports).

hulitu|7 months ago

> How relevant is this now

Very relevant. A lot of websites need 5 to 30 seconds or more to load.

throwaway019254|7 months ago

I have a suspicion that the 30 second loading time is not caused by TCP slow start.

ajross|7 months ago

Slow start is about saving small-integer-numbers of RTT times that the algorithm takes to ramp up to line speed. A 5-30 second load time is an order of magnitude off, and almost certainly due to simple asset size.