[vitus]

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?

[jsty]

Looks like Cloudflare quiche:

https://github.com/curl/curl/blob/0f4c19b66ad5c646ebc3c4268a...

[pclmulqdq]

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

[Matthias247]

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

[ndriscoll]

> 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. :-)

[secondcoming]

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