It has to do with optimizations in TCP that can’t be done in QUIC. For example, the NIC can take multiple in order TCP packets and combine them together into a single very large TCP packet (64kb) and then the TCP stack needs to do a lot less processing. In QUIC, because the headers are encrypted end to end, the NIC can’t do anything unless you start sharing keys with the hardware.
Another problem is the fact that in TCP, TLS record sizes can be large, like 16kB, so you can amortize the cost of decryption setup. In QUIC, you have to decrypt and encrypt every single packet.
I suspect that this is going to be one of the big things in NVIDIA’s next generation datacenter SoCs. With the SmartNIC and CPU on the same package, they can decrypt QUIC packets in the NIC and put them in per-Realm encrypted memory.
We were working on enabling something similar at Microsoft before they decided that bullshit generators were more important than server performance and security.
I believe tcp has just been much more optimized over time, due to its historic popularity and usage.
Consider TCP Offload Engines, specifically TSO, GSO, and LRO.
Anyone know why HTTP/3 is so much more CPU-heavy?
It has to do with optimizations in TCP that can’t be done in QUIC. For example, the NIC can take multiple in order TCP packets and combine them together into a single very large TCP packet (64kb) and then the TCP stack needs to do a lot less processing. In QUIC, because the headers are encrypted end to end, the NIC can’t do anything unless you start sharing keys with the hardware. Another problem is the fact that in TCP, TLS record sizes can be large, like 16kB, so you can amortize the cost of decryption setup. In QUIC, you have to decrypt and encrypt every single packet.
I suspect that this is going to be one of the big things in NVIDIA’s next generation datacenter SoCs. With the SmartNIC and CPU on the same package, they can decrypt QUIC packets in the NIC and put them in per-Realm encrypted memory.
We were working on enabling something similar at Microsoft before they decided that bullshit generators were more important than server performance and security.
I believe tcp has just been much more optimized over time, due to its historic popularity and usage.
Consider TCP Offload Engines, specifically TSO, GSO, and LRO.
Could be that TCP is handled in the kernel and doesn’t count against user code. That would be my guess.
It isn’t just an accounting issue: QUIC gets half the bandwidth and half the requests per second.
I am hopeful that one day we will be able to collectively move on from OpenSSL.
It would be ironic if openssl’s weird choices with http/3 were the impetus for greater crypto library platform diversity.