Full kudos to Caddy for being the first out the door with working HTTP/3 support.
Are there downsides to HTTP/3? When HTTP/2 came out there was discussions about why not to enable.
Are there downsides to HTTP/3? When HTTP/2 came out there was discussions about why not to enable.
Benefited from Lucas https://clemente.io/ ... full credit to him, and the various people who worked on the IETF test implementations that then became various production implementations.
I don't credit Caddy with this as they were downstream and just received the good work done. Not that Caddy is bad, but singling them out ignores those that did the hard work.
> Are there downsides to HTTP/3? When HTTP/2 came out there was discussions about why not to enable
1. HTTP/1 and HTTP/2 were natural rate limiters to your application... can your app cope when all requests arrive in a much shorter time window? The traffic pattern goes from somewhat smooth, to somewhat bursty and spikey. If your assets come from a dynamic endpoint or you have authorization on your endpoint that results in database lookups... you'll want to load test real world scenarios.
2. There are amplification potentials when you pass HTTP/3 through layers that map to HTTP/2 and HTTP/1 (the optimisations in the small payload to H3 are "undone" and amplify through H2 and H1 protocols)
3. HTTP/3 combined the transport protocol benefits and the HTTP protocol benefits with TLS benefits... all good, but it is harder for DDoS protection as proxies and middle boxes can no longer differentiate as easily the good traffic from the bad, and may not have visibility over what constitues good at all.
Largely though... worth enabling. And for a good while the last of my points is mitigated by disabling H3 as you'll degrade to H2 cleanly.
I'm also hesitant about HTTP/2 and 3 because of their complexity, but if you trust the systems and libraries underlying your server I don't see any problem in activating either. Just watch out with features like 0-RTT that can have a security impact and you should be fine.
The only downside with HTTP 2 & 3 is software support. If you are in Google, you probably already use it just because the load balancer supports it. With self hosted, you are dependent on whatever you are using adding support. I remember playing with SPDY way back on nginx for example. It wasn't that hard to get going and it made a difference for our mobile users (who are on shitty networks by default).
With anything self hosted, security is indeed a key concern; especially if you are using alpha versions of new functionality like this which is what you would be doing effectively.
https://news.ycombinator.com/item?id=27402222
As the article says, HTTP3 is pretty fast when there are high latencies/high loss scenarios. It will be interesting to see how it performs in a mobile setting. 4G and 5G networks have their own/specific optimizations that are different than a desktop world. eg. http keep alives were never respected, etc. (connections would be closed if there was no continuous activity). But, given the test, it 'should' be much faster than http 1.1
One think is for sure: HTTP 1.1 is going to still be used, even 100 years from now. It is like FM Radio, which is both good enough for most cases, and very simple and convenient at the same time.
I would suggest disabling HTTP/3 for the next 10 or so years and give everyone else the chance to burn through the exploits.