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.
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.
> 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.
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.
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.
