3 ms·
From what I understand, QUIC is a lower level protocol near TCP and UDP which uses UDP as it's base for transport. Currently, HTTP/2 can multiplex streams, but
by jjice 6y ago
From what I understand, QUIC is a lower level protocol near TCP and UDP which uses UDP as it's base for transport. Currently, HTTP/2 can multiplex streams, but if one has an error, all must be stopped while TCP fixes it. In QUIC they use UDP, which doesn't do error checking, so QUIC implements the error checking itself. QUIC will handle the error checking while the UDP streams continue to deliver at the same time.
This is all based on my brief reading of the QUIC Wikipedia article, so take my knowledge with a grain of salt, but I think that my above summary fits.
Wikipedia at relevant anchor: https://en.wikipedia.org/wiki/QUIC#Background https://en.wikipedia.org/wiki/QUIC#Background
- jabart 6y agoError in this context is a missing packet causing a delay and a request for a retransmit blocking the TCP connection at the OS/Kernel while it waits for the missing packet before sending it to the application. UDP packets have checksums, its what network switches use to check before sending the packet on or dropping the packet. Other benefit is UDP doesn't have a window size (buffer). Which is part of the design when computers had ram measured in K instead of GB (Hey my buffer is full, stop). The chatty nature of TCP reduces download speeds across larger physical distances. Its why download managers spin up multiple threads to download part of a file to work around it.