On Mon, 24 Jun 2024 at 16:16, Robin Marx <[email protected]> wrote:
> 1. Just because a CDN supports HTTP/3 does not mean it enables it (by > default) for all customers. For example, while Akamai (my current employer) > provides support, it is explicitly opt-in instead of opt-out for existing > customers, meaning we're probably at a much lower level of adoption than > what's conceptually possible. I can't speak for other CDNs/large providers, > but I imagine similar things happen there (e.g., only enable it by default > for free/small customers, but require manual action from larger entities, > which can be slow in the uptake). > You're right, and I suspect this is the single largest reason holding back adoption. > 2. Even if it's enabled, the alt-svc-based bootstrapping/discovery means > you'll still have plenty of HTTP/2 by design. And while Chrome and Firefox > pretty aggressively switch from H2 to H3 when discovered (even during a > page load), Safari/Apple (at least for a long time, not 100% sure what they > do not) kept using H2 for as long as possible, only switching to H3 when a > new connection was really needed. This will (probably) be improved by HTTPS > DNS records and alt-svc-bis, but those also have (current) deployment > issues IIUC. > I can see how this is a bootstrapping issue. But surely 99% of content fetches are towards a name that this user has visited before, so it *should* be negligible. Perhaps there is an issue with how long browsers remember Alt-svc or HTTPS information? Potentially this could be quite significant too. > 3. Even if the client tries HTTP/3, it will sometimes fail due to UDP rate > limiting/blackholing/firewalling/flukes or things like MTU nasties that > make HTTP/2 win the happy eyeballs race. I doubt this would contribute more > than single-digit percentages to the overall number, but still a factor (I > haven't seen recent numbers on this. Maybe Matt or Ian can comment, since > they track more detailed client-side info?) > I'm also guessing this is single-digit percentages, but if data shows otherwise then that would be something to work on. On Mon, 24 Jun 2024 at 16:30, Daniel Stenberg <[email protected]> wrote: > > The ecosystem situation is not making it easy to use QUIC. > Thanks Daniel. You neatly summarise it in the blog: "curl’s situation is symptomatic for a lot of other HTTP tools and libraries. HTTP/3 has been and continues to be a much tougher deployment journey than HTTP/2 was." Quite unfortunate that you have to poll OpenSSL due to an API shortcoming. On Mon, 24 Jun 2024 at 17:14, Nick Banks <[email protected]> wrote: > I've had https://github.com/microsoft/quicreach testing the top 5k > hostnames for a few years now, and it provides this dashboard: > https://microsoft.github.io/quicreach/. (Note, you can append ?count=2500 > to the URL to change the count of data points if you wish). While it's not > a huge change, it shows about a steady 10+ increase every month (for at > least the last year). We're almost at 1k hostnames supporting QUIC. > Thank Nick. I was initially puzzled how to interpret the data, but I see this is out of the 5,021 top names listed in https://github.com/microsoft/quicreach/blob/main/src/domains.hpp which is taken from the Majestic Million. So I think it's saying 20% of those sites have enabled H3 to their homepage. The growth shown in https://microsoft.github.io/quicreach/?count=1500 is remarkably linear. If this trend continues, we won't hit 50% until 2033. Chris
