4 ms·
As I understood it: QUIC, or more accurately HTTP/3 over QUIC, is optimised for consumer web browser, mainly mobile devices over lossy network. That is not (onl
by quietbritishjim 4y ago
As I understood it: QUIC, or more accurately HTTP/3 over QUIC, is optimised for consumer web browser, mainly mobile devices over lossy network. That is not (only) Google's use case at all.
If you're loading several images over the same HTTP2/TCP connection and you miss a packet of one then you have to get later packets resent for all of them. Even if the delayed packet does eventually arrive without needing to be resent, it still has the effect of holding up all the other streams. With HTTP3/QUIC, a missed or delayed packet does still affect the stream it's from within that connection (still a pity) but at least the other streams carry on unaffected.
This problem in TCP is called head-of-line blocking:
https://en.wikipedia.org/wiki/Head-of-line_blocking https://en.wikipedia.org/wiki/Head-of-line_blocking
- Animats 4y agoEven if the delayed packet does eventually arrive without needing to be resent, it still has the effect of holding up all the other streams. Only if you're multiplexing multiple streams inside one TCP connection. Multiple TCP connections will not affect each other.
- quietbritishjim 4y agoYes, that is exactly what HTTP allows: multiple data streams over a single TCP connection. In general, that's a good thing: if you have a page with dozens of small files (icon images, CSS, JS fragments, etc.) then you don't want to instantiate a new TCP connection for every one. Browsers typically have multiple HTTP connections open as a compromise so that you don't need a new TCP connection for every file but don't have the head of line problem so severely. But it's not as good as fixing the underlying problem.