4 ms·

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 ab

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.

ardit33 5y ago
We will know over time. HTTP/3 is fixing all shortcomings of HTTP/2, which was pretty flawed. It uses UDP though, and UDP itself can be blocked by many firewalls, and folks/companies have to update firewalls and routers for it to work properly. So, that's its major weakness (eg. some workplaces block all egress UDP packets). https://news.ycombinator.com/item?id=27402222 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.
- josefx 5y ago
  I can't wait for all the HTTP/3 -> HTTP/2 -> HTTP/1 tunneling and other exploits that will appear in all the rushed implementations. We already saw how that worked with HTTP/2 and people tried to rush OpenSSL into adopting an experimental implementation of QUIC while Google was still hashing out the spec. . I would suggest disabling HTTP/3 for the next 10 or so years and give everyone else the chance to burn through the exploits.
  - johncolanduoni 5y ago
    Thankfully HTTP/3 didn’t change request/header semantics much from HTTP/2, at least nowhere near the level of the HTTP/1 -> HTTP/2 changes.
- ithkuil 5y ago
  Do you have a link at hand describing the main shortcomings of http/2 (that http/3 fixes)?
Jleagle 5y ago
I am using it with traefik too.
jeroenhd 5y ago
I know of at least one ISP that plain blocks outgoing UDP/443 or at least messes with the packets, so I wouldn't rely on its availability. 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.
- jillesvangurp 5y ago
  It will likely just fallback to http on networks like that. Shitty ISPs and corporate networks are why we need fallbacks like that. I would suggest using a VPN if you are on such a network. 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.
francislavoie 5y ago
Caddy maintainer here - we still have it marked experimental, not turned on by default. There's still some bugs. The actual HTTP/3 implementation comes from https://github.com/lucas-clemente/quic-go https://github.com/lucas-clemente/quic-go which essentially just has one maintainer at the moment. I'm hoping the Go HTTP team throws some effort on HTTP/3 sooner rather than later.
buro9 5y ago
> Caddy Benefited from Lucas https://clemente.io/ 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.
- francislavoie 5y ago
  For sure, as a Caddy maintainer, all credit goes to the contributors of https://github.com/lucas-clemente/quic-go https://github.com/lucas-clemente/quic-go. Early on this was mostly Lucas Clemente, but Marten Seemann has been the primary maintainer for quite a while now, including the transition from QUIC to HTTP/3. https://github.com/lucas-clemente/quic-go/graphs/contributors https://github.com/lucas-clemente/quic-go/graphs/contributor...

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.

ardit33 5y ago

We will know over time. HTTP/3 is fixing all shortcomings of HTTP/2, which was pretty flawed. It uses UDP though, and UDP itself can be blocked by many firewalls, and folks/companies have to update firewalls and routers for it to work properly. So, that's its major weakness (eg. some workplaces block all egress UDP packets). https://news.ycombinator.com/item?id=27402222 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.

josefx 5y ago
I can't wait for all the HTTP/3 -> HTTP/2 -> HTTP/1 tunneling and other exploits that will appear in all the rushed implementations. We already saw how that worked with HTTP/2 and people tried to rush OpenSSL into adopting an experimental implementation of QUIC while Google was still hashing out the spec. . I would suggest disabling HTTP/3 for the next 10 or so years and give everyone else the chance to burn through the exploits.
- johncolanduoni 5y ago
  Thankfully HTTP/3 didn’t change request/header semantics much from HTTP/2, at least nowhere near the level of the HTTP/1 -> HTTP/2 changes.
ithkuil 5y ago
Do you have a link at hand describing the main shortcomings of http/2 (that http/3 fixes)?

Jleagle 5y ago

I am using it with traefik too.

jeroenhd 5y ago

I know of at least one ISP that plain blocks outgoing UDP/443 or at least messes with the packets, so I wouldn't rely on its availability. 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.

jillesvangurp 5y ago
It will likely just fallback to http on networks like that. Shitty ISPs and corporate networks are why we need fallbacks like that. I would suggest using a VPN if you are on such a network. 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.

francislavoie 5y ago

Caddy maintainer here - we still have it marked experimental, not turned on by default. There's still some bugs. The actual HTTP/3 implementation comes from https://github.com/lucas-clemente/quic-go https://github.com/lucas-clemente/quic-go which essentially just has one maintainer at the moment. I'm hoping the Go HTTP team throws some effort on HTTP/3 sooner rather than later.

buro9 5y ago

> Caddy Benefited from Lucas https://clemente.io/ 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.

francislavoie 5y ago
For sure, as a Caddy maintainer, all credit goes to the contributors of https://github.com/lucas-clemente/quic-go https://github.com/lucas-clemente/quic-go. Early on this was mostly Lucas Clemente, but Marten Seemann has been the primary maintainer for quite a while now, including the transition from QUIC to HTTP/3. https://github.com/lucas-clemente/quic-go/graphs/contributors https://github.com/lucas-clemente/quic-go/graphs/contributor...