Skip to content

Comment on Curl HTTP/3 Performance

Comments

It is promising to see that openssl-quic serial throughput is within 10-20% of more mature implementations such as quiche. (Which quiche, though? Is this Google's quiche, written in C++, or Cloudflare's quiche, written in Rust? It turns out that's approximately the only word that starts with "quic" that isn't a derivative of "quick".)

One of QUIC's weaknesses is that it's known to be much less CPU efficient, largely due to the lack of things like HW offload for TLS.

Also, the HTTP/1.1 numbers are a bit unfair since they do run 50 TCP connections against the server.

To emphasize this point: no modern browser will open 50 concurrent connections to the same server for 50 GET requests. You'll see connection pooling of, uh, 6 (at least for Chrome and Firefox), so the problems of head-of-line blocking that HTTP/2 and HTTP/3 attempt to solve would have manifested in more realistic benchmarks.

Some questions I have:

- What kind of CPU is in use? How much actual hw parallelism do you have in practice?

- Are these requests actually going over the network (even a LAN)? What's the MTU?

- How many trials went into each of these graphs? What are the error bars on these?

Hardware offload should be protocol-independent, but I suppose most network cards assume some stuff about TLS and aren't set up for QUIC?

NICs assume stuff for TCP (segmentation offload) that they can’t do for UDP, or can only do in a very limited fashion (GSO).

TLS offloads are very niche. There’s barely anyone using them in production, and the benchmarks are very likely without

To emphasize this point: no modern browser will open 50 concurrent connections to the same server for 50 GET requests.

They will. You just need to go bump that number in the settings. :-)

Browsers aren't the only things that connect to servers that speak HTTP.

AboutSource Built by g1lg1l

Hackerly is an independent reader for Hacker News, built on the public HN API. Not affiliated with Y Combinator.