Why HTTP/3 is eating the world

Re:Why HTTP/3 is eating the world by ascar on Thursday October 05, 2023 @07:44AM (#37777349)

If I recall correctly in TCP a packet loss will cause a signifcant slowdown in the whole data stream since that packet needs to be retransmitted and you generally end up with a broken data stream until that happens (even tho TCP can continue to send more data in the meantime meaning it's more of a temporary hang than a block). Thus if you are sending multiple different data streams over the same TCP connection a packet loss will temporarily hang the processing of all data streams. A constrain that QUIC doesn't have.

[ Parent | on HN ]

Re:Why HTTP/3 is eating the world by dgb23 on Thursday October 05, 2023 @08:23AM (#37777667)

A somewhat decent analogy of thinking about TCP is a single lane queue with a security guy who's ordering people around and making sure the queue is orderly and doesn't overflow. He has pretty much no respect for families, groups or overall efficiency. He only cares about the queue itself.

[ Parent | on HN ]

Re:Why HTTP/3 is eating the world by pjc50 on Thursday October 05, 2023 @08:12AM (#37777594)

Not broken, but you end up with a hole in the TCP receive window while the packet is retransmitted.

How does QUIC manage its stream reassembly window sizes? I suppose it's easier since it's all in userland.

[ Parent | on HN ]

Re:Why HTTP/3 is eating the world by tsimionescu on Thursday October 05, 2023 @09:26AM (#37778320)

> I suppose it's easier since it's all in userland.

I doubt applications would provide more reliable information to the QUIC library than they would to the kernel.

The main difference as I understand it is that QUIC allows multiple separate TCP-like streams to exist on the same negotiated and encrypted connection. It's not fundamentally different from simply establishing multiple TLS over TCP connections with separate windows, it just allows you to establish the equivalent of multiple TLS + TCP connections with a single handshake.

[ Parent | on HN ]

Re:Why HTTP/3 is eating the world by adgjlsfhk1 on Thursday October 05, 2023 @09:58AM (#37778693)

The key point is that if I want to load a webpage that needs to download 100 different files, I don't care about the order of those 100 files, I just want them all to be downloaded in order. TCP makes you specify an order which means that if one packet gets lost, you have to wait for it. QUIC lets you say "here are the 100 things I want" which means that if you lose a packet, that only stops 1 of the things so the other 99 can continue asking for more packets.

[ Parent | on HN ]

Re:Why HTTP/3 is eating the world by syncsynchalt on Friday October 06, 2023 @04:07PM (#37795633)

QUIC improves on TCP stream windowing/reassembly in two ways:

- as noted by another commenter, you can send multiple streams in a single connection, so a lost packet for one stream does not necessarily affect others.

- QUIC sends ACK as a bitmap instead of a single number (TCP only sends the number of the highest continuous stream byte seen). Senders can see that one packet was lost, but that the packets following were successfully received. For long/fat pipes this prevents the sender from re-transmitting packets following the single lost packet.

[ Parent | on HN ]

Re:Why HTTP/3 is eating the world by culebron21 on Thursday October 05, 2023 @07:46AM (#37777370)

Yes, I just read about this, and it makes sense.

[ Parent | on HN ]