QUIC: Helping Internet Data Streams Share a Connection
A webpage can request text, pictures, and other resources at the same time. What happens when one part of the transfer encounters a delay? Internet transport protocols determine how data travels between applications and how a connection responds to losses. QUIC is a transport protocol designed to handle multiple streams within one connection while providing rules for reliable delivery.
Separate Streams in One Connection
RFC 9000, written by Jana Iyengar and Martin Thomson, specifies QUIC as a transport built over UDP. It describes streams that carry ordered sequences of bytes. Several streams can operate concurrently within a connection, subject to limits and flow control.
The specification explains that packet loss need not block progress on every stream. Streams containing the lost data wait for recovery, while other streams can continue. If one packet contains data from several streams, losing that packet can affect all of those particular streams.
A useful hypothetical comparison is a group project with several deliveries. If one package is delayed, the group can continue using material that has already arrived in other packages. That does not make the delayed package unimportant; it changes how much other work must wait for it.
Responding to Congestion
A connection cannot simply send unlimited amounts of data. RFC 9002, by Iyengar and Ian Swett, describes QUIC's loss detection and congestion control. It includes a controller that adjusts the amount of data permitted in flight and responds to losses or explicit signals of congestion.
The distinction between flow control and congestion control matters. The first concerns how much data a receiver can handle. The second concerns the network path's ability to carry traffic. A sender must account for both rather than assuming that one fast endpoint makes the entire journey fast.
Imagine several devices sharing a connection during a school event. A useful transport should respond to changing conditions, while the application still needs to decide which information matters most to its users. The protocol provides mechanisms; the app supplies the purpose of the transfer.
Measuring the Actual Experience
A new transport name is not a promise that every page will load faster. A meaningful comparison should examine the network conditions, application behavior, and implementation being tested. A protocol can address one source of waiting while other parts of a service still determine the overall delay.
For the event organizers, the relevant outcome might be whether a schedule remains usable as connections become unreliable. That practical test would say more than one ideal laboratory transfer.
Summary
QUIC organizes reliable transfers around multiple streams and defined responses to network congestion. Its design can let unaffected streams continue when other data is lost. The value of that flexibility depends on the application, the network path, and evidence about the experience users actually receive.
Works Cited
Iyengar, Jana, and Martin Thomson. “QUIC: A UDP-Based Multiplexed and Secure Transport.” May 2021. Accessed 10 Oct. 2026.
Iyengar, Jana, and Ian Swett. “QUIC Loss Detection and Congestion Control.” May 2021. Accessed 10 Oct. 2026.
Sedrubal. “Tcp-vs-quic-handshake.” Wikimedia Commons, 23 January 2022. Image. CC BY-SA 4.0. Accessed 10 Oct. 2026.
Published comparison of TCP and QUIC connection handshakes. Image: Sedrubal; CC BY-SA 4.0.