It's strange to read this when you see articles like this[0] and see Lighthouse ranking better with it switched on. Nothing beats real world stats though. Could this be down to server/client implementation of HTTP2 or would you say its a fundamental implication of the design of the protocol?
Trying to make my sites load faster led me to experiment with QUIC and ultimately I didn't trust it enough to leave it on with the increase of complexity.
UDP is problematic because you can't recv() more than one packet at a time, so you get syscall limits that you could just ignore with a TCP-based protocol. There's a trick wasting lots of cores but it's bad for battery-powered devices. There's also iouring and af_xdp that look promising, but they aren't supported as widely as chrome.
HTTP2 I can't explain. HTTP2 should be better. I suspect it's probably an implementation bug because I can replicate lab performance and HTTP2 looks good to me in controlled tests.
I can always try turning it back on again in 6 months...
I don't know which site you're describing, but as a user living very far from major datacenters on an unstable and frequently slow network, HTTP[23] have been the best thing since sliced bread. How it looks in practice is getting hundreds of megabits/s when network is under low load (in the middle of the night, etc), but down to hundreds or even dozens of kilobytes/s in the evening. Sometimes with high packet loss. Always having pings of 100ms or higher (right now it's 120ms to the nearest google.com datacenter, 110ms to bing.com, 100ms to facebook.com, and 250ms to HN).
Back when HTTP2 was introduced and started becoming popular, I spent a few weekend hours on writing a short script to do a blind test of HTTP1.1 vs HTTP2 or some major sites where both were supported. H2 won every time, hands down. It was like comparing a 96kbit/s MP3 to a FLAC.
> UDP is problematic because you can't recv() more than one packet at a time
> but as a user living very far from major datacenters on an unstable and frequently slow network, HTTP[23] have been the best thing since sliced bread. How it looks in practice is getting hundreds of megabits/s when network is under low load ...
The surprise is that some users aren't able to access your site if you enable HTTP[23], and those that can will have worse latency on average.
There's a trick that I use to download large "files" -- I use content-range and multiple parallel fetch() calls. Because of the fast (lower latency) start of HTTP1.1 this outperforms H2 when you can get away with it. People who don't want to use JavaScript can use https://github.com/brunoborges/pcurl or something like it.
Cool. I don't think it helps H3 because the other end will just block anyway (because it's Linux only and the other side probably isn't Linux), and it seems to be a little slower than recvmsg() when there's only a small amount of traffic so I'm pretty sure it's not going to help me, but I'll keep poking around at it...
> It's strange to read this when you see articles like this[0] and see Lighthouse ranking better with it switched on.
I mean, Lighthouse is maintained by Google (IIRC), and I can believe they are going to give their own protocol bonus points.
> Could this be down to server/client implementation of HTTP2 or would you say its a fundamental implication of the design of the protocol?
For stable internet connections, you'll see http2 beat http3 around 95% of the time. It's the 95th+ percentile that really benefits from http3 on a stable connection.
If you have unstable connections, then http3 will win, hands down.
Trying to make my sites load faster led me to experiment with QUIC and ultimately I didn't trust it enough to leave it on with the increase of complexity.
[0]: https://kiwee.eu/blog/http-3-how-it-performs-compared-to-htt...