Notes on QUIC and HTTP/3 in practice
QUIC moves reliable transport into userspace and runs over UDP. The interesting consequence is not "faster" — it is that the congestion controller becomes something you can choose, tune, and replace without touching the kernel.
Why UDP gets blamed for the wrong thing
When a QUIC connection performs badly, the first suspect is usually "UDP is being throttled". Sometimes that is true; carrier-grade NAT and middleboxes do treat long-lived UDP flows differently. But far more often the problem is the congestion controller reacting to loss that TCP would have hidden behind retransmission.
On a path with 2% loss and 200ms RTT, the math is unforgiving. A loss-based controller cuts its window by half on every drop. With that much RTT, the window barely recovers before the next loss event. Throughput collapses even though the link is mostly idle.
What helps
- Loss-tolerant congestion control. BBR-style controllers estimate bandwidth from delivery rate instead of treating every drop as a signal to slow down.
- FEC and aggressive retransmission on links where loss is random rather than congestion-driven.
- Not multiplexing everything onto one connection when a single stalled stream would block the rest.
The fairness question
Aggressive controllers are effective precisely because they take more than their fair share when competing with loss-based flows. On a link you own, that is a tuning decision. On a shared one, it is rudeness with extra steps. Worth being honest about which situation you are in.
Practical takeaway
Measure loss and jitter before tuning anything. A path with 30% loss and 90ms jitter is not a configuration problem — no controller fixes a link that is genuinely dropping one packet in three. Tuning helps at the margins; the physics does not move.