←back to thread

QUIC is not quick enough over fast internet

(arxiv.org)
306 points carlos-menezes | 1 comments | 19 Oct 24 21:04 UTC | HN request time: 0s | source
Show context
10000truths ◴[19 Oct 24 22:35 UTC] No.41891318[source]▶
TL;DR: Nothing that's inherent to QUIC itself, it's just that current QUIC implementations are CPU-bound because hardware GRO support has not yet matured in commodity NICs.

But throughput was never the compelling aspect of QUIC in the first place. It was always the reduced latency. A 1-RTT handshake including key/cert exchange is nothing to scoff at, and the 2-RTT request/response cycle that HTTP/3-over-QUIC offers means that I can load a blog page from a rinky-dink server on the other side of the world in < 500 ms. Look ma, no CDN!

replies(1): >>41891384 #
o11c ◴[19 Oct 24 22:48 UTC] No.41891384[source]▶
There's also the fact that TCP has an unfixable security flaw - any random middleware can inject data (without needing to block packets) and break the connection. TLS only can add Confidentiality and Integrity, it can do nothing about the missing Availability.
replies(2): >>41891453 #>>41891651 #
suprjami ◴[19 Oct 24 23:01 UTC] No.41891453[source]▶
What does that have to do with anything here? This post is about QUIC performance, not TCP packet injection.
replies(1): >>41891674 #
o11c ◴[19 Oct 24 23:35 UTC] No.41891674{3}[source]▶
"Accept worse performance in order to fix security problems" is a standard tradeoff.
replies(1): >>41892201 #
1. suprjami ◴[20 Oct 24 01:34 UTC] No.41892201{4}[source]▶
QUIC was invented to provide better performance for multiplexed HTTP/3 streams and the bufferbloat people love that it avoids middlebox protocol interference.

QUIC has never been about "worse performance" to avoid TCP packet injection.

Anybody who cares about TCP packet injection is using crypto (IPSec/Wireguard). If performant crypto is needed there are appliances which do it at wirespeed.