Here’s a quick overview
- QUIC uses UDP. UDP isn’t slower by default, but its setup can make it slower compared to TCP.
- QUIC does much more of the processing on the user side rather than in the kernel or on the hardware.
- QUIC needs the application to perform way more socket reads and writes compared to http2.
- QUIC with UDP doesn’t take advantage of the offloading features that hardware usually offers for TCP. There are some offload features for UDP, but it seems QUIC doesn’t use them.
Overall, TCP is a streaming protocol that doesn’t keep message boundaries. This means that an application writing data has no direct way to control how those bytes become packets. A program might write 128 k, but the OS (or the hardware) handles breaking that down into 1500-byte packets. On the receiving side, it might provide a 128k buffer that can contain data from many 1500-byte packets. This setup lets the application and the kernel read and write data very efficiently using TCP. A lot of this work even gets offloaded to the hardware.
In TCP, acknowledgments are managed by the kernel, so they don’t interfere with the application’s reads and writes across the syscall.
Now with UDP, it keeps message boundaries, but it has no built-in acknowledgment system. So the typical way to use UDP is to read and write 1500 byte packets in user space, leading to many more syscalls compared to TCP just for bulk reads and writes. With QUIC, folder acknowledgments are also done by the application, which means more processing for it, rather than letting the kernel or hardware handle it.
All these factors mean that QUIC is often slower than http2 on computers that have fast internet connections like gigabit and above.
@Hadi
There are draft implementations of QUIC in the Linux kernel and ongoing talks about hardware offloading, like for encryption.
It’s a known issue, but one that seems likely to be solved soon.
Lyle said:
@Hadi
There are draft implementations of QUIC in the Linux kernel and ongoing talks about hardware offloading, like for encryption.
It’s a known issue, but one that seems likely to be solved soon.
I think all of this could be fixed by adding QUIC support to the kernel and network stack, so that when you use a QUIC library, it can smartly check if the system supports “native” QUIC or if it has to manually decode from UDP based on available functions.
@Wylie
I thought QUIC was meant to avoid needing to be implemented in the kernel and network stack?
Blake said:
@Wylie
I thought QUIC was meant to avoid needing to be implemented in the kernel and network stack?
Yes, it’s designed that way. But we can choose to handle it in the kernel and network stack for better performance.
For instance, if we used QUIC as a transport layer, your computer would not be able to use it without an update. Now an application can include its own QUIC version to use if the computer lacks native support (which applies to most computers until that kernel update is done).
@Wylie
Got it, that makes sense.
@Wylie
Today, it should also be feasible to run the entire network stack in userspace if you’re concerned about performance. That might be enough for many QUIC-related apps that really care about speed. It might be more crucial for middleware (which may also convert QUIC to other protocols) than for direct endpoints, though I’m not sure how much impact that would have.
@Hadi
I really don’t understand why Google pushed this protocol so hard, especially since SCTP has existed for years and does the same job.
Dexter said:
@Hadi
I really don’t understand why Google pushed this protocol so hard, especially since SCTP has existed for years and does the same job.
SCTP supporters unite! I’ve loved it since I first found out about it, what, two decades ago? Support for it is still lacking.
@Hadi
As far as I know, it’s an optional package in many Linux distros now. It officially supports being used within UDP, which allows it to run on systems that lack native support (mostly Windows). But if it were chosen as the next big protocol (since it can replace both TCP and UDP), it wouldn’t take long for all major OS to adopt it.
@Dexter
The real issue isn’t OS support, but middleboxes. Anything that isn’t TCP or UDP struggles to gain traction because firewalls will just block it. Even TLS 1.3 has to pretend it’s TLS 1.2 to get through. That’s also a major reason QUIC works to encrypt its metadata, so it can’t be read by firewalls while allowing future extensions.
You can watch this talk for more details.
@Stevie
SCTP supports running over UDP
Dexter said:
@Stevie
SCTP supports running over UDP
Even UDP is often restricted due to weird rules and old hardware that blocks too much.
Dexter said:
@Stevie
SCTP supports running over UDP
Even UDP is often restricted due to weird rules and old hardware that blocks too much.
Then HTTP/3 wouldn’t work either.
@Dexter
I know. And often it doesn’t.
@Stevie
I think Google linked encryption with QUIC to make sure governments couldn’t pressure to remove encryption later, essentially enforcing encryption everywhere. By building it into most basic web functions, it puts pressure on governments to allow it. That’s also why HTTP/3 needs TLS 1.3 to work.
@Lex
I believe it was more about avoiding protocol stagnation, rather than Google’s goodwill to stop spying.
Dexter said:
@Hadi
I really don’t understand why Google pushed this protocol so hard, especially since SCTP has existed for years and does the same job.
It has a separate protocol ID, which means firewalls and middleboxes usually just say no way, not happening.
@Addison
It also can encapsulate in UDP, so realistically, it works wherever UDP does.