15 ms·

HTTP/3 is everywhere but nowhere

• CharlieDigital 2y ago
  > At the same time, neither QUIC nor HTTP/3 are included in the standard libraries of any major languages including Node.js, Go, Rust, Python or Ruby. .NET actually looking like it has decent support for any teams that are interested[0] (side note: sad that .NET and C# are not considered "major"...). There is an open source C library that they've published that seems rather far along[1] Support for Windows, Linux[2], and Mac[3] (the latter two with some caveats). Overall, I think for most dev teams that are not building networking focused products/platforms, HTTP/3 is probably way down the stack of optimizations and things that they want to think about, especially if the libraries available have edge cases and are too early for production. Who wants to debug issues with low-level protocol implementations when there are features to ship, releases to stabilize, and defects to fix? [0] https://learn.microsoft.com/en-us/dotnet/fundamentals/networking/quic/quic-overview https://learn.microsoft.com/en-us/dotnet/fundamentals/networ... [1] https://github.com/microsoft/msquic https://github.com/microsoft/msquic [2] https://learn.microsoft.com/en-us/dotnet/fundamentals/networking/quic/quic-overview#macos https://learn.microsoft.com/en-us/dotnet/fundamentals/networ... [3] https://learn.microsoft.com/en-us/dotnet/fundamentals/networking/quic/quic-overview#macos https://learn.microsoft.com/en-us/dotnet/fundamentals/networ...
  • hypeatei 2y ago
    > side note: sad that .NET and C# are not considered "major I've said it before on here, but the tech community severely underrates .NET today. It's not Windows only (and hasn't been for ~8 years) plus C# is a very nice language. F# is also an option for people who like functional languages. I'd highly recommend giving it a try if you haven't already.
    • victor106 2y ago
      Can .net produce cross platform libraries/executables like Go does? With Go I can develop on Mac and create executables for windows and Linux
      • CharlieDigital 2y ago
        Yes, it can. I work on .NET and work on Mac (hate the OS, but the hardware and battery life are way better). Last startup, we shipped AWS t4g Arm64 and GCP x64 Linux containers. A few devs started on Windows (because of their preferred platform), but we all ended up on M1 MacBook Pros using a mix of Rider and VS Code. Common misconception between old .NET Framework and new .NET # (e.g. .NET 9) (MS terrible naming). C#/.NET has been capable of cross platform binaries for close to a decade? I have a bit more info here: https://typescript-is-like-csharp.chrlschn.dev/pages/intro-and-motivation.html#common-myths https://typescript-is-like-csharp.chrlschn.dev/pages/intro-a...
        • pjc50 2y ago
          Are you sure? https://learn.microsoft.com/en-us/dotnet/core/deploying/native-aot/cross-compile https://learn.microsoft.com/en-us/dotnet/core/deploying/nati... "Since there's no standardized way to obtain native macOS SDK for use on Windows/Linux, or Windows SDK for use on Linux/macOS, or a Linux SDK for use on Windows/macOS, Native AOT does not support cross-OS compilation. Cross-OS compilation with Native AOT requires some form of emulation, like a virtual machine or Windows WSL." Now, you don't have to actually use AOT, the other deployment options are actually much easier to cross-build, but true cross build AOT is still not supported. (this comment is correct: https://news.ycombinator.com/item?id=43388962 https://news.ycombinator.com/item?id=43388962 ; runtime-dependent and self-contained are fine)
          • CharlieDigital 2y ago
            > Native AOT does not support cross-OS compilation > ...runtime-dependent and self-contained are fine This certainly reads like you moved the goal posts and recognized it.
            • bheadmaster 2y ago
              Native AOT compilation is definitely not the same as self-contained package. With that logic, every Docker container could be considered AOT compiled static executable.
    • parineum 2y ago
      They also severely underrate it's actual usage. For a non "major" language, there sure are a lot of jobs out there. .NET ain't hip.
      • deleted 2y ago
        [deleted]
      • briandear 2y ago
        .NET ain’t hip because many of the shops that use it are dinosaurs in processes and culture.
        • mlhpdx 2y ago
          And many are not. How many Python shops are living in the past? It’s the same problem everywhere.
          • realusername 2y ago
            I'd like this to be a lie but it's true, different languages have different cultures associated to them.
    • shermantanktop 2y ago
      .NET suffers from the long lasting reputational taint of Microsoft. It was seen as the sworn enemy of open source and Linux, and for good reason. Today’s MS is not what it was back then. But long memories are not a bad thing, really. If .NET suffers a bit from some unfair perception, perhaps that can remind MS and others what happens when you take an aggressively adversarial approach.
      • mixmastamyk 2y ago
        They may be much less Linux-hostile today, but are still plenty user-hostile. Not to mention their lackadaisical security record.
        • cebert 2y ago
          Can you please highlight some examples of .NET’s lackadaisical security record? I’m curious for my own awareness.
          • mixmastamyk 2y ago
            Microsoft's. Consult your favorite search engine.
            • CharlieDigital 2y ago
              You might be interested in GitHub's State of the Octoverse report from 2020 that had a section dedicated to security of popular languages, active open source projects on GH with those languages, and the package managers for those platforms. https://octoverse.github.com/2020/ https://octoverse.github.com/2020/
              • mixmastamyk 2y ago
                Microsoft's security record. Not one package manager. https://arstechnica.com/security/2024/01/microsoft-network-breached-through-password-spraying-by-russian-state-hackers/ https://arstechnica.com/security/2024/01/microsoft-network-b...
    • arccy 2y ago
      It wasn't good enough for the typescript rewrite...
      • bjoli 2y ago
        Mostly because they didnt consider the AOT compilation mature enough.
        • int_19h 2y ago
          Actually, the reason why they went with Go rather than C# is because they wanted to port the existing code as much as possible rather than rewriting from scratch. And it turns out that TS is syntactically and semantically much closer to Go, so you can often convert the former to the latter mechanically.
          • CharlieDigital 2y ago
            > And it turns out that TS is syntactically and semantically much closer to Go, so you can often convert the former to the latter mechanically. Are there examples of this? I ask because I've been working on a Nest.js backend in TS and it's remarkably similar to C# .NET Web APIs (controllers, classes, DI). Really curious to see the translation from TS to Go.
            • neonsunset 2y ago
              TSC codebase is quite unlike regular TypeScript code you will see out there. So it is about specific way TSC is written in being the easiest to port to Go rather than the TS language as a whole. There's a screenshot comparing the two side-by-side, IIRC it was showcased on the video of the talk (if someone has a timestamp - please post).
              • CharlieDigital 2y ago
                Got it; thanks for the tip!
    • shepherdjerred 2y ago
      Why would I use C# over any other language though?
      • CharlieDigital 2y ago
        It's very productive and kinda nice. Especially for big backend APIs: https://typescript-is-like-csharp.chrlschn.dev/ https://typescript-is-like-csharp.chrlschn.dev/
      • jayd16 2y ago
        C# has a strong high level feature set and lower level tools to keep performance up. The language itself is well designed and consistent. Its able to mix functional and OO features without being dogmatic, leading to better dev-x over all. ASP is actually very good these days and feels cleaner than Spring Boot. There's less choice but the available choices are good. It has arguably the best gRPC implementation. It's just a nice experience over all.
        • deleted 2y ago
          [deleted]
      • hu3 2y ago
        LINQ alone is unmatched.
        • CharlieDigital 2y ago
          Addendum: having `Expression`[0] type representing the expression tree is a really killer feature. I've been doing a writeup comparing how ORMs work in TypeScript vs ORMs in .NET and one thing that is magical is that having the `Expression` type enables a much more functional and fluent experience with ORMs. [0] https://learn.microsoft.com/en-us/dotnet/csharp/advanced-topics/expression-trees/ https://learn.microsoft.com/en-us/dotnet/csharp/advanced-top...
          • fireant 2y ago
    • OkGoDoIt 2y ago
      I’ve been a .Net developer since it launched, but recently I find myself using it less and less. I’m so much more productive with LLM assistance and they aren’t very good at C#. (Seriously, I thought AI coding was all exaggeration until I switched to Python and realized what the hype was all about, these language models are just so much more optimized for python) Plus now Microsoft is being a bully when it comes to Cursor and the other VS Code forks, and won’t let the .net extensions work. I jumped through a lot of hoops but they keep finding ways to break it. I don’t want an adversarial relationship with my development stack. I miss C# and I really don’t like Python as a language, but I don’t see myself doing a lot more C# in the future if these trends continue.
      • epolanski 2y ago
        Have you given C# a new try with Cursor and newer models? There's a huge difference from Copilot in 2023, if that was your example. Also, interesting you feel more productive on a language you don't even like than your "main" one.
      • seunosewa 2y ago
        You can use VS Code and cursor at the same time. One to code and the other to compile the code. That's how I build for Android. I generate code in Cursor/Windsurf then I compile and deploy using Android Studio.
    • lmm 2y ago
      It's not Windows only but it is Windows-first. Every few years I take a look but it still doesn't feel like a serious ecosystem for Linux development (in the same way that e.g. Perl might have a Windows release, but it doesn't feel really first-class). I can't think of a single .NET/C# program that people would typically run on Linux to even have the runtime installed, so no wonder people don't bother investigating the languages.
      • CharlieDigital 2y ago
        Definitely not Windows-first. Last startup we built our entire backend in .NET and C#. Every dev ended up using MacBooks. We shipped to AWS t4g Arm64 Linux targets. This mis-perception is so irrational and not based on any facts.
        • LtWorf 2y ago
          Just because .NET is what you know best, doesn't necessarily mean it's the best in all use cases. You're seeming like the node developers trying to push js everywhere because it's all they know. It's not a very rational approach I think.
          • CharlieDigital 2y ago
            I don't think I've ever said it was good for all use cases and probably said to the contrary. I write it very explicitly here[0]: > Should you use C# for web front-ends? > > We're only considering backends here; I do not think that .NET-based front-ends (e.g. Blazor) are competitive in all use cases. We are in a thread about...backend application servers. Most of my side projects are TS/JS and run serverless Node.js functions on the BE[1]. I don't choose favorites; I choose the right one for the job. [0] https://typescript-is-like-csharp.chrlschn.dev/pages/intro-and-motivation.html#a-bit-of-background https://typescript-is-like-csharp.chrlschn.dev/pages/intro-a... [1] https://github.com/CharlieDigital/coderev https://github.com/CharlieDigital/coderev
            • LtWorf 2y ago
  • inejge 2y ago
    > At the same time, neither QUIC nor HTTP/3 are included in the standard libraries of any major languages including Node.js, Go, Rust, Python or Ruby. .NET omission notwithstanding, one of the languages in the list is not like the others: Rust has a deliberately minimal standard library and doesn't include HTTP at all. I don't follow Rust HTTP/3 efforts closely, but there are at least two actively developed libraries: quiche and quinn.
    • Macha 2y ago
      The official Python stance on using the standard library HTTP client is also "are you sure?" and their stance on using the standard library HTTP server is "don't". https://docs.python.org/3/library/http.client.html#module-http.client https://docs.python.org/3/library/http.client.html#module-ht... https://docs.python.org/3/library/http.server.html#module-http.server https://docs.python.org/3/library/http.server.html#module-ht...
  • xpressvideoz 2y ago
    > side note: sad that .NET and C# are not considered "major"... Even Microsoft does not use C# for their new projects. See the new TypeScript compiler that is being rewritten in Go. So I think it is safe to say C# is indeed a minor language.
    • CharlieDigital 2y ago
      > So I think it is safe to say C# is indeed a minor language That's not really the case; StackOverflow survey[0] shows C# (27.1%) right behind Java (30.3%) and well ahead of Go (13.5%), Rust (12.6%), Kotlin (9.4%), Ruby (5.2%), and Scala (2.6%). If we exclude HTML/CSS, Bash/Shell, and SQL, C# would be #5 in actual languages used over the past year by devs in this survey. You get the same result from scraping job postings: https://www.devjobsscanner.com/blog/top-8-most-demanded-programming-languages/ https://www.devjobsscanner.com/blog/top-8-most-demanded-prog... 1. JS/TS (note these two are collapsed) 2. Python 3. Java 4. C# Two completely separate sources with the same output... > See the new TypeScript compiler that is being rewritten in Go If they had started from scratch, Anders mentioned the considerations would be different. But because they had an existing body of code that was not class based, it would be more of a re-write (C#) versus a refactor (Go). A lot of folks read the headline without actually reading Anders' comments and reasoning. C# is good for many things -- in particular application backends, game engines (both Godot and Unity) -- and not optimal for other things -- like serverless functions. Each language has a place and Go and Python are certainly better for CLI tools, for example. [0] https://survey.stackoverflow.co/2024/technology https://survey.stackoverflow.co/2024/technology
      • 0x457 2y ago
        I never understood SO as a measurement tool for anything, but people that can't read docs.
        • CharlieDigital 2y ago
          You have to have some metrics from somewhere to be able to understand which languages are being used. SO is one data point, but there are certainly others.
  • qingcharles 2y ago
    Indeed. And I would think you can use Microsoft's free reverse proxy, YARP, in front of an app (on any platform) that doesn't natively support HTTP/3? https://learn.microsoft.com/en-us/aspnet/core/fundamentals/servers/yarp/http3?view=aspnetcore-9.0 https://learn.microsoft.com/en-us/aspnet/core/fundamentals/s...
  • o11c 2y ago
    Until the dotnet packages are shipped in every major Linux distro's default repositories (it's okay if it's a 5-year-old version), we can't call C# a major language. But apparently there aren't enough people willing to actually do the work.
  • ycombinatrix 2y ago
    Kind of misleading - Rust stdlib doesn't include HTTP 1 or 2 either
  • throwaway2037 2y ago
    > sad that .NET and C# are not considered "major"... No need to be sad about that list. Java is also missing. There must be millions of enterprise programmers in the world using Java. I just checked the Java class HttpClient (a common JDK11+ HTTP client). It currently does not support HTTP/3, so add one more to the list! Ref: https://docs.oracle.com/en/java/javase/24/docs/api/java.net.http/java/net/http/HttpClient.Version.html https://docs.oracle.com/en/java/javase/24/docs/api/java.net.... Also, most of the very best network clients are now built on top of NettyIO. I can see an "incubator codec" here: https://github.com/netty/netty-incubator-codec-http3 https://github.com/netty/netty-incubator-codec-http3 Holy hell, this code is ridiculously complex: https://github.com/netty/netty-incubator-codec-http3/tree/main/src/main/java/io/netty/incubator/codec/http3 https://github.com/netty/netty-incubator-codec-http3/tree/ma... I'm not hating on NettyIO here, but the protocol looks complex. Yet another reason why it is so slow to be deployed to more application frameworks.
    • lmm 2y ago
      I don't think many people use the builtin HttpClient these days. Apache httpclient would be the conservative standard, apparentyl it has some support for 2 but not 3: https://hc.apache.org/httpcomponents-client-5.4.x/index.html https://hc.apache.org/httpcomponents-client-5.4.x/index.html .
    • oaiey 2y ago
      There is a very simple reason for not being on the list: It support HTTP/3 and the purpose of the post was to show the lack of support in common languages. .NET does not fit that list well. And it is obviously only popular in the dark matter of Enterprise Software Development.
      • epolanski 2y ago
        C# is much closer in popularity to TypeScript/Python (the number 1s) than it is to Rust.
        • oaiey 2y ago
• bullen 2y ago
  For bidirectional 2 TCP sockets and HTTP/1.1 Comet-Stream works fine. Fighting HTTP/1.1 for money is going to fail unless you invent something fundamentally better.
• jimmydoe 2y ago
  as an indie web master, some percentage improvement on ttfb brings zero benefit to me and my users, but requiring or recommending it to users only help big tech.
  • nchmy 2y ago
    Could you elaborate on why faster responses don't benefit you or your users?
    • hylaride 2y ago
      Because the faster response is negligible when you're an indie web host that can serve content over a single connection with reasonable speed. Where HTTP/3 really "shines" is when you connect to a web site that then has dozens of connections to other hosts (internal or external)...which is facebook/google/ad companies. HTTP/3 speeds up that kind of content by reducing connection startup times to all of them, which can be compounded.
      • arccy 2y ago
        but it doesn't help for different external connections, each one needs a new connection. it's good for multiple resources from the same host, maybe you have a lot of images on your photo blog or something
        • hylaride 2y ago
          http3 has enhancements that speed up initial handshakes for new connections (QUIC essentially is UDP plus combining TLS and a native reliability layer to replace separate initial SYNs for them separately). So when you go to a page with tons of ads/trackers/javascript libraries, you're not left waiting as long for the ads to serve while browser reaches out to all those components and does separate TCP, TLS, and HTTP connections. But users of most other websites won't see a ton of noticable benefits unless they have facebook/netflix/google levels of traffic. And at that point, you're either highly focused on the end user component code or you've outsourced it to a CDN that'll do the http3 for you anyways.
• jbosh 2y ago
  How much does http/3 help for server to server traffic? Seems like larger websites can use a CDN or load balancer to do termination and then use http 1.1 to the back end. Is that good enough with large pipes and a high number of connections?
  • davidkwast 2y ago
    I subscribe for that
  • vrnvu 2y ago
    QUIC was not designed for server-to-server. In that use case, you’ll [1]likely experience poor performance due to higher CPU usage (since QUIC is a user-space protocol without TCP optimizations at the kernel/NIC level) and lower throughput. [1]This is based on public benchmarks, try searching for `TCP vs QUIC`
  • omcnoe 2y ago
    The primary benefits of QUIC apply in scenarios where you have some packet loss, and are multiplexing multiple independent "transactions" (DB queries, HTTP req's, gRPC calls etc.) over a single connection. Multiplexing is very common but unless you are at megacorp scale (or operating a cloud hosting platform) packetloss within your own wired network infrastructure isn't a super common issue. Compared to say packetloss to mobile clients on bad networks where QUIC can really provide a significantly improved experience.
• nly 2y ago
  My recent projects in C++ are just using cURL, but given some of the versions of cURL I have to support are 10 years old it isn't being turned on anytime soon. Even the latest deployments on Rocky 9 are using a 4 year old version of cURL When you're writing libraries distributed as binaries for other teams you can't just statically link whatever you want willy nilly.
  • jcelerier 2y ago
    What prevents you from using a package manager linking statically with a recent libcurl ?
    • ddulaney 2y ago
      I’m not OP, but at $WORK we sell a C++ library. We want to make it as easy as possible for clients to integrate it into their existing binaries. We need to be able to integrate with CMake, Meson, vcxproj, and hand-written Makefiles. We’re not the only vendor: if another vendor is using a specific cURL version, you better hope we work with it too, otherwise integration is almost impossible. You could imagine us shipping our library as a DLL/.so and static-linking libcurl, but that comes with a bunch of its own problems.
      • nly 2y ago
        Exactly this. You don't want multiple versions of cURL loaded in to your process dynamically. You need to be in control of the final link if you're shipping a .a to other teams
        • progval 2y ago
          That doesn't work if other teams want to apply their own cURL patches, or update as soon as upstream publishes new security fixes without waiting for you.
          • nly 2y ago
            That's the point. We don't do that. You link to the system libcurl dynamically and everyone is told to do the same. If you want to use a private curl as an implementation detail then the only safe way to do it is to ship a .so, make sure all the symbols are private and that symbol interposition is switched off. If you ship a .a then the final link can always make symbols public again.
• jsheard 2y ago
  It's pretty glaring that nginx still doesn't have production-ready HTTP3 support despite being a semi-commercial product backed by a multi billion dollar corporation. F5 is asleep at the wheel.
  • LinuxBender 2y ago
    Out of curiosity have F5 added any new modules since they acquired Nginx?
    • pas 2y ago
      https://nginx.org/en/CHANGES https://nginx.org/en/CHANGES acquisition finished in 2019 there are quite a lot of features, but it's hard to say what constitutes a new module. (well, there's "Feature: the ngx_stream_set_module." so maybe yes?)
      • LinuxBender 2y ago
        One would probably have to go through git logs [1] so I guess I should do that after getting some food in the belly to answer my own question. It's a big log. Interesting side note, appears all commits from Maxim stopped in January 2024. Must be all F5 now. [1] - https://github.com/nginx/nginx https://github.com/nginx/nginx
        • FeistySkink 2y ago
          Here's some background: https://arstechnica.com/information-technology/2024/02/nginx-key-developer-starts-a-freenginx-fork-after-dispute-with-parent-firm/ https://arstechnica.com/information-technology/2024/02/nginx...
          • LinuxBender 2y ago
            Ah yes, I vaguely recall the drama. Thankyou.
        • 2y ago
• artyom 2y ago
  Every single project mentioned in the article is to some extent either open source and/or community driven. So nobody considered HTTP/3 interesting enough to rush and add support for it very quickly. It'll get there, but fast? I don't think so, see IPv6. Also, nobody considered HTTP/3 worth enough of paying for maintainers to add support for it.
  • kccqzy 2y ago
    The comparison with IPv6 is interesting. IPv6 isn't mainly driven by open source or community. It is driven by the needs of large corporations, including both ISPs and tech companies. ISPs like T-mobile wanting to run an IPv6-only backbone network, and tech companies like Apple forcing every app in the App Store to work in IPv6-only mode (DNS64+NAT64). New operating system levels features for IPv6 are often proposed by big tech companies and then implemented eagerly by them; see for example DHCP option 108. In a sense the need for IPv6 is driven by corporates just like that for HTTP/3.
    • vlovich123 2y ago
      Ummm… Google invented QUIC and pushed it into Chrome and shuttled it through IETF to be ratified as a standard. Some of the large OSS projects are maintained by large companies (eg quiche is by Cloudflare) and Microsoft has MsQuic which you can link against directly or just use the kernel mode version built into the OS directly since Windows 11. The need for QUIC is actually even more driven by corporates since IPv6 was a very small comparative pain point compared to better reaching customers with large latency network connections.
    • elcritch 2y ago
      IPv6 always seemed to me to be driven by a certain class of purist networking geeks. Then some corporations started getting on board like you said, but many couldn't care less.
      • FuriouslyAdrift 2y ago
        The largest use of IPv6 is in mobile (cell) networks. When they effectively killed IP block mobility (provider independent netblocks), they (the standards bodies) effectively killed it's adoption everywhere else. I work in the networking space and outside of dealing with certain European subsidiaries, we don't use IPv6 anywhere. It's a pain to use and the IPv6 stacks on equipment (routers, firewalls, etc) are no where near the quality, affordability, and reliability of their IPv4 stacks.
• gexla 2y ago
  Isn't this just going to get resolved within one year when programmers aren't needed and AI will create all the needed libraries? </sarcasm>
• confirmr 2y ago
  > You'll start to see lack of HTTP/3 support used as a signal to trigger captchas & CDN blocks, like as TLS fingerprinting is already today. HTTP/3 support could very quickly & easily become a way to detect many non-browser clients, cutting long-tail clients off from the modern web entirely. That explains it. I've seen this when using 3 year old browsers on retail web sites recently. A few cloud providers think I’m a bot.
  • userbinator 2y ago
    It's horrible that the Internet is slowly becoming a locked-down ecosystem. Everyone should turn off HTTP/3 in protest of this. https://news.ycombinator.com/item?id=43329320 https://news.ycombinator.com/item?id=43329320
    • crazygringo 2y ago
      What exactly are sites supposed to do to prevent being the targets of DDoS, spam, fraud, aggressive bots, and other abuse? And it's not "locked down", it's usually just a CAPTCHA as long as you're not coming from an abusive IP range like might happen with a VPN. Also there are a thousand other signals besides HTTP/3. It's not going to make a difference.
      • kragen 2y ago
        The normalization of CAPTCHAs for simply reading what ought to be public information strikes me as very alarming, as does characterizing essential privacy and anti-censorship measures like VPNs as "abusive". Something like 1% of HTTP hits pose some risk of spam or fraud, those where somebody is trying to post a message or a transaction or something. The other 99% are just requesting a static HTML document or JPEG (or its moral equivalent with unwarranted and untrustworthy dynamic content injected). Static file serving is very difficult to DDoS, even without a caching CDN like Fastly. There is still a potentially large bandwidth cost, but generally the DoS actor has to pay more than the victim website, making it relatively unappealing. Should web sites really be weighing "a thousand signals" to decide which version of the truth to present a given user with? That sounds dystopian to me.
• jiehong 2y ago
  Caddy does support http 3 in production now, and so can be used as a reverse proxy. The http client libraries almost everywhere do lack support, though.
  • ddon 2y ago
    We switched to Caddy in multiple projects and really happy with it... Certificate generation feels like magic and http3 works great as well. Config files are much smaller and easier to read as well!
• troupo 2y ago
  A lot of the article is the same marketing spiel that Google has been using to promote QUIC (and then HTTP/3) At best those amazeballs advantages are applicable only at Google's scale, and have very little impact anywhere else. Worse, still, --- start quote --- We find that over fast Internet, the UDP+QUIC+HTTP/3 stack suffers a data rate reduction of up to 45.2% compared to the TCP+TLS+HTTP/2 counterpart. Moreover, the performance gap between QUIC and HTTP/2 grows as the underlying bandwidth increases. https://arxiv.org/abs/2310.09423 https://arxiv.org/abs/2310.09423 --- end quote --- And if you believe the discussion here https://news.ycombinator.com/item?id=25970258 https://news.ycombinator.com/item?id=25970258 it increased the load on the server unless you can "spend years optimizing it".
  • crazygringo 2y ago
    Have those findings been independently confirmed? Has Google said anything? Is it dependent on certain e.g. server-side factors? Did Google "get this wrong" or was this intentional? E.g. is it by far a net positive to be faster on slow internet where the difference is perceivable, than to be slower on fast internet because it's still lightning-fast even when it's slower?
    • nyrikki 2y ago
      Google's needs are not most people's needs, "wrong" for them is different than "wrong" for general users.
      • crazygringo 2y ago
        I don't know what you mean. In this particular instance, the point is to speed up page loads. In this particular case, speed increases are most people's needs.
  • llm_nerd 2y ago
    The benefits of QUIC / HTTP/3 have been extremely well defined as- -higher latency connections. -packet loss under multiplexing scenarios / suboptimal connections (e.g. mobile). These are the situations where it shines and runs away from HTTP/2. And this has been the promised advantage from the outset, and is literally the problem it is designed to solve. Given that the linked paper mentions the word latency once in an irrelevant context, I think that's telling. Of course there is no advantage -- and in fact is an expected disadvantage -- when your client and server are 0ms from each other with 0% packet loss. Now put them 100ms from each other with 5% packet loss/reordering/retransmission and multiplexing.
• JimDabell 2y ago
  I’ve been using niquests with Python. It supports HTTP/3 and a bunch of other goodies. The Python ecosystem has been kind of stuck on the requests package due to inertia, but that library is basically dead now. I’d encourage Python developers to give niquests a try. You can use it as a drop-in replacement for requests then switch to the better async API when you need to. https://niquests.readthedocs.io/en/latest/ https://niquests.readthedocs.io/en/latest/ Traditionally these types of things are developed outside the stdlib for Python. I’m not sure why they draw the line where they do between urllib vs niquests, but it does sometimes feel like the batteries-included nature of Python is a little neglected in some areas. A good HTTP library seems like it belongs in the stdlib.
  • mixmastamyk 2y ago
    requests dead? The reason given for not including it in the stdlib was so it could evolve more rapidly. Back then the protocol layer was handled/improved by urllib3.
    • JimDabell 2y ago
      It’s not evolving at all: > Requests is in a perpetual feature freeze, only the BDFL can add or approve of new features. The maintainers believe that Requests is a feature-complete piece of software at this time. > One of the most important skills to have while maintaining a largely-used open source project is learning the ability to say “no” to suggested changes, while keeping an open ear and mind. > If you believe there is a feature missing, feel free to raise a feature request, but please do be aware that the overwhelming likelihood is that your feature request will not be accepted. — https://requests.readthedocs.io/en/latest/dev/contributing/#feature-requests https://requests.readthedocs.io/en/latest/dev/contributing/#...
      • antisthenes 2y ago
        It takes a very special case of a person to complain about a feature-complete piece of software not evolving fast enough.
• jchw 2y ago
  If you are looking for a reverse proxy with good HTTP/3 support, I recommend Envoy. Configuring it is a bit of a chore, but it feels like it was engineered from first principles to be the best possible HTTP/2 and 3 reverse proxy. The architecture for HTTP is entirely based around the h2 protocol, unlike NGINX which splits requests into various phases and struggles to support things like bidirectional streaming and upstream h2. (One down side is that it really is a reverse proxy; no static file serving or anything like that. But if you know what you need it can be great.) I do hope to see more QUIC and HTTP/3 support, but to be honest, even h2 support in many cases sucks pretty hard. The Go HTTP interface is still pretty much HTTP/1 oriented and really needs a rehaul, and even the h2 implementation feels like it still lacks some battle testing. I think that is a damn shame.
  • echelon 2y ago
    Envoy is so much more. We used it for gRPC, service discovery, health checking, dynamic failover, and so much of our at-scale service topology at my last place.
  • sethops1 2y ago
    > and even the h2 implementation feels like it still lacks some battle testing. I think that is a damn shame. Citation needed.
    • jchw 2y ago
      I've run into production bugs with Go HTTP/2 at multiple different jobs. They are now fixed, but I'm personally not confident that those were the last ones. I could look them up and link them if you're actually curious, but I'm not sure that will be convincing, you can obviously link to bug reports for anything and claim it's unstable, I can only speak of my personal experience.
  • INTPenis 2y ago
    Why not Traefik?
    • 2y ago
• fiatjaf 2y ago
  Google invents something and uses its huge market share and power to force everybody to use their thing, shaming and threatening those who don't. Amazing outcome.
• sheerun 2y ago
  Coordinate efforts for more of most of popular programming languages, then switch from experimental in synchrony
• theandrewbailey 2y ago
  I'm using HAProxy on my 1 machine homelab. I'm not convinced that HTTP/3 a big improvement over HTTP/2, but for me, HTTP/3 was as easy as upgrading and adjusting the config file a little bit. From my perspective, the seeming lack of HTTP/3 support noted in this article is not a big problem. That said, I'm dying to get official 0-rtt support. https://www.haproxy.org/ https://www.haproxy.org/ https://haproxy.debian.net/ https://haproxy.debian.net/ https://www.haproxy.com/blog/announcing-haproxy-2-6 https://www.haproxy.com/blog/announcing-haproxy-2-6 Live example: https://theandrewbailey.com/ https://theandrewbailey.com/
• AlienRobot 2y ago
  Cool, let me see if I can block HTTP/1.1 on Cloudflare to get rid of bot traffic.
• giancarlostoro 2y ago
  Reminds me of IPv6... When I was 17... (2007) and learned about it I was very hyped to see it become mainstream.. I still don't know why we go out of our way to only use IPv4 to this day. Its even older than when I discovered what IPv6 was.
  • pas 2y ago
    lot of people do use IPv6 but what turned out to be a big problem (not enough IP addresses for clients) was solved by CGNAT and a simple market (for servers) of course it's important to understand that it was cheaper to deploy thousands of CGNAT boxes than to upgrade the whole Internet (and corresponding software)
    • giancarlostoro 2y ago
      Surely most hardware / software that has had no support for IPv6 has been mostly phased out by now?
      • jeroenhd 2y ago
        It seems cheap consumer ISP hardware works absolutely fine these days, but prosumer/small business devices sometimes still have trouble with hardware acceleration. You can sometimes get that acceleration when you flash OpenWRT so the problem seems to be a lack of effort from companies that should do better. Also, IoT crap tends to disable IPv6 (for saving a few kilobytes of ROM I think) but that stuff is better off locked behind six levels of NAT anyway.
      • nh2 2y ago
        Not even Android has proper IPv6 support. You cannot manually set an IPv6 address or gateway for a WiFi, it's forced DHCP only. All of this works for IPv4.
• kragen 2y ago
  > We've developed a totally new version of HTTP, and we're on track to migrate more than 1/3 of web traffic to it already! This is astonishing progress. It's astonishing change. You could have used the same argument to show that any dismaying historical development was "astonishing progress". From my point of view HTTP/3 looks like an advantage for hyperscalers but no benefit to regular users using small-scale websites. That's progress toward a future I don't want to arrive.
• ralferoo 2y ago
  For me, I think the biggest issue with large scale deployment of HTTP 3 is that it increases the surface area of potentially vulnerable code that needs to be kept patched and maintained. I'd far rather have the OS provide a verified safe socket layer, and a dynamically linked SSL library, that can be easily updated without any of the application layer needing to worry about security bugs in the networking layer. Additionally, I'd posit that for most client applications, a few extra ms of latency on a request isn't really a big deal. Sure, I can imagine applications that might care, but I can't think of any applications I have (as a developer or as a user) where I'd trade to have more complexity on the networking layer for potentially saving a few ms per request, or more likely just on the first request.
  • sennalen 2y ago
    Connection migration sounds like a security nightmare
    • AnthonyMouse 2y ago
      How is it any worse than session resumption from a different IP address?
  • lemagedurage 2y ago
    A "few extra ms" is up to 3 roundtrips difference, that's easily noticeable by humans on cellular. For all the CPU optimisations we're doing, cutting out a 50ms roundtrip for establishing a HTTP connection feels like a great area to optimize performance.
    • TheRealPomax 2y ago
      And yet, compared to the time you're waiting for that mast head jpeg to load, plus an even bigger "react app bundle", also completely irrelevant. HTTP/3 makes a meaningful difference for machines that need to work with HTTP endpoints, which is what Google needed it for: it will save them (and any other web based system similar to theirs) tons of time and bandwidth, which at their scale directly translates to dollars saved. But it makes no overall difference to individual humans who are loading a web page or web app. There's a good argument to be made about wasting round trips and HTTP/3 adoption fixing that, but it's not grounded in the human experience, because the human experience isn't going to notice it and go "...did something change? everything feels so much faster now".
• dadrian 2y ago
  It's not clear to me that HTTP/3 is relevant to anyone who isn't already using it. It's most useful for large-scale hosting providers and video. And these people have already adopted it, and don't necessarily use out-of-the-box web servers for their infrastructure.
  • lemagedurage 2y ago
    Small websites gain from reducing roundtrips on connection too. Fast websites are nice
    • dadrian 2y ago
      HTTP/2 already reduces roundtrips.
      • charleslmunger 2y ago
        At the cost of head-of-line blocking - one dropped TCP packet delays all HTTP/2 streams.
        • dadrian 2y ago
          Yes, but head-of-line blocking is a different thing than round trips.
          • charleslmunger 2y ago
            A dropped packet requires a retransmit which is effectively a round trip. Introducing shared fate by bundling many requests into a single TCP connection results in more requests being delayed by round trips per dropped packet.
          • hnaccountme 2y ago
            Isn't head of line blocking a problem with the design of web servers?
      • 2y ago
• jillesvangurp 2y ago
  My observation is that anything based on public cloud providers using their load balancers is basically using HTTP3 out of the box. This benefits people that use browsers that support this (essentially all browser and mobile browsers). And since it falls back to plain HTTP 1.1, there are no downsides for others. Sites that use their own apache/nginx/whatever servers are not benefiting from this and need to do work. And this is of course not helped by the fact that http3 support in many servers is indeed still lacking. Which at this point should be a strong hint to maybe start considering something more modern/up to date. Http clients used for API calls between servers that maybe use pipelining and connection reuse, benefit less from using HTTP3. So, fixing http clients to support http3 is less urgent. Though there probably are some good reasons to support this anyway. Likewise there is little benefit in ensuring communication between microservices in e.g. Kubernetes happens over http3.
• mintflow 2y ago
  it's quite shocking to know that http/3 is still not gain enough opensource libraries support. Maybe really some users does not care more about it,as a developper I'd rather not taking much overhead to maintain a server that support http/3.
  • xxs 2y ago
    The sheer truth is the prime user for the protocol is ads serving, for common case (API calls with some keep-alive) it's an effective downgrade to even http1.1.
• huijzer 2y ago
  Very interesting. The article states that > Really it's hard to point to any popular open-source tools that fully support HTTP/3: rollout has barely even started. But isn’t Caddy a widely used reverse proxy with HTTP/3 support? Or what features are missing?
  • dubcanada 2y ago
    I don't think I'd call Caddy "widely used" it is used, but nowhere near nginx, apache, haproxy, squid, etc.
    • lemagedurage 2y ago
      Make sense. Nowadays, for a new project, I would like to use Caddy where I would otherwise use Apache or nginx, but I would be even more inclined to use a cloud provider's load balancer.
• aboardRat4 2y ago
  TLS termination is still not working for HTTP/3, I think. The nicest feature of HTTP/3 is that it is UDP based, and thus does not allow so much interception by the malicious ISPs.
  • pas 2y ago
    can you please elaborate on what do you mean? TLS termination as in HTTP/3 on a reverse proxy? nginx's implementation works. (but for me it caused a strange performance degradation with Seafile)
    • aboardRat4 2y ago
      How exactly does it work? By terminating an udp stream and fetching the backend data using http 2.0? This might be enough for static web and such, but in a "new web" you'd want to use all those nice features of http/3 which have no direct equivalent in http/2, like multiplexing udp streams for video and such. And if you forward the udp stream itself, what do you do with the certificate? Use a selfsigned one with no expiration date and add a custom CA? Seems laborious.
  • lokar 2y ago
    I think they mean these intercepting firewall/proxies that many big companies use to spy on their employees don’t work (yet)
  • jeroenhd 2y ago
    The people whose ISPs are spying on them, won't be able to use HTTP/3 anyway. It's not hard to figure out if a packet is HTTP/3 and when you drop all HTTP/3 packets your browser will usually just use something that does make it through.
    • aboardRat4 2y ago
      Well, http/3 so far works in China and Russia, because, presumably, many enough required services are using it so that blocking indiscriminately is not practical.
• InfiniteRand 2y ago
  Here’s the question, are the benefits worth the increase in complexity, or rather are they worth more than other features that could be worthwhile for libraries to support. For the hyperscale web sure, but for the long tail web that is very unclear.
• mlhpdx 2y ago
  > neither QUIC nor HTTP/3 are included in the standard libraries of any major languages Like dotnet?
  • globnomulous 2y ago
    Just pointing this out in case it's helpful: there's tons of great discussion of this topic elsewhere in the thread!
• dangoodmanUT 2y ago
  It's been proven many times that in well-connected networks (e.g. datacenters) H2 is faster, often because all of the things that H3 improves on is now handled in the user context, which negates the overhead. The benefits only show in poorly connected networks (public internet), so that's pretty exclusively where it should be used - anything internet-facing.
  • pimterry 2y ago
    Perhaps, but: There's ongoing work exploring QUIC-in-kernel-space at https://github.com/lxin/quic https://github.com/lxin/quic, and more generally HTTP/3 will be increasingly optimized over time as it moves towards becoming the majority of HTTP traffic (a few years off, but looks likely eventually). There's no fundamental reason I'm aware of that HTTP/3 would be _inevitably_ slower than HTTP/2, it seems likely for now that it's largely implementation details. There's plenty of internet-facing cases with average-at-best connectivity where HTTP/3 would be beneficial today, and isn't available (non-megacorp Android apps, CLI tools, IoT, desktop apps, etc). Even on the backend, it's very common to have connections between datacenters with significant latency (e.g. distributed CDN to central application server/database).
• ajross 2y ago
  I think a lot of this is missing the point. The features HTTP/3 provides are features of value to datacenter and large scale deployment. Most sites deploying off-the-shelf solutions like nginx or whatever don't care. Most behind-the-reverse-proxy services don't care. So Cloudflare cares about HTTP/3, but their customers mostly don't, except the biggest ones. Use the tool for the job. If a single-threaded Python server running HTTP/1.1 works for your IT app, then use that. HTTP/3 has nothing to offer you.
• goeiedaggoeie 2y ago
  As an Akamai user I already serve all my DASH traffic (video) over http3. Akamai itself return to origin only supports http 1.1 LL-HLS forces me use HTTP2. The problem here is Akamai really in only supporting HTTP1.1 to the origin. Cloudfare I think only supports HTTP2 to origin. Does Fastly yet support QUIC to origin? Does Cloudfront, I could only find information about it supporting QUIC the last mile. Maybe more CDN support will drive web server support.
• fresh_broccoli 2y ago
  The slow adoption of QUIC is the result of OpenSSL's refusal to expose the primitives needed by QUIC implementations that already existed in the wild. Instead, they decided to build their own NIH QUIC stack, which after all these years is still not complete. Fortunately, this recently changed and OpenSSL 3.5 will finally provide an API for third party QUIC stacks.[1] It works differently than all the other existing implementations, as it's push-based instead of pull-based. It remains to be seen what it means for the ecosystem. [1] - https://github.com/openssl/openssl/pull/26683 https://github.com/openssl/openssl/pull/26683
• jauntywundrkind 2y ago
  There's some cool stuff & capabilities here. Its surprising to me that uptake has been so slow. Node.js just posted an update on the state of QUIC, which underlies http3 & has had some work over the years. They're struggling with openssl being slow to get adequate API support going. There's efforts that have working books for quic, but the prospect of switching is somewhat onerous. Really unfortunate; so much of this work has been done for Node & there's just no straightforward path forwards. https://github.com/nodejs/node/issues/57281 https://github.com/nodejs/node/issues/57281
  • sureIy 2y ago
    I'd love to see that OpenSSL fork drama on the main page of HN. Do you know where this was discussed?
    • billywhizz 2y ago
      there's a pretty good summary of things with links from daniel stenberg - the curl guy - here : https://daniel.haxx.se/blog/2021/10/25/the-quic-api-openssl-will-not-provide/ https://daniel.haxx.se/blog/2021/10/25/the-quic-api-openssl-...
  • karel-3d 2y ago
    I think the issue is the complexity? It pushes a lot of logic into userspace.
• upofadown 2y ago
  The article talks about the advantages of HTTP/3 for IoT applications. I recently did an IoT application (weather station) where I actually ended up using HTTP/1.0. I only had to send a total of around 70 bytes every two minutes. If at the end of that two minutes I had an invalid or missing response there was nothing more to do other than record the result for a possible future reset. Once there was new data available the old data was irrelevant. So I don't see how HTTP/3 would of helped there. Most IoT applications are not very sensitive to things like latency and what counts as reliability is very much dependent on the situation. A simple protocol is an advantage.
  • aboardRat4 2y ago
    >Most IoT applications are not very sensitive to things like latency and what counts as reliability is very much dependent on the situation. IoT is not about latency. IoT is about devices being behind a NAT which does not allow inbound connections. With UDP-based HTTP/3 it is possible to do "udp hole punching".
    • upofadown 2y ago
      >With UDP-based HTTP/3 it is possible to do "udp hole punching". That works reliably with all the various types of NAT?
      • aboardRat4 2y ago
        For some definition of "reliably". In the sense that nothing is really reliable in the presence of state-level adversaries censuring traffic, malicious ISPs, and crappy hardware. In general I have been more successful with QUIC hole punching than with ipv6. But having a standard and relatively broadly implemented way to make reliable "TCP-like" streams over UDP is a great thing regardless.
• zlagen 2y ago
  shouldn't QUIC be supported at the operating system level similar to TCP? that way it could get adopted much easily in different languages
  • aboardRat4 2y ago
    Not really. The whole point of quic is that it is built on top of plain old stupid udp, so it does _not_ require any OS level cooperation. The raison d etre of quic was to get rid of interacting with OS developers, convincing them, and patching some old ecomstations, and just "do what we want" in the process level.
• grayhatter 2y ago
  > And Fastly shared the major improvements in time-to-first-byte they're seeing in the real world: What's time until last byte though? Yeah, The metric that got you promoted is cool and all, but if my application works on files atomically, it's the time until last byte that has meaning to me. I'm also gonna assume a bit more, and say it's also the byte where the service can start processing someone else's connection. So if http/3 increases the load on servers, with their CPU, instead of network hardware, with their ASIC, this would be a net loss as soon as you look at amount of complete requests per energy used. Instead of just looking at single session metrics. I guess I should probably read the HTTP/3 spec now...
• xg15 2y ago
  I feel another way to look at it is that there is a growing divide between the "fronted/backend developer" view of an application and the "ops/networking" view - or put differently, HTTP2 and HTTP3 are not really "application layer" protocols anymore, they're more on the level of TCP and TLS and are perceived as such. As far as developers are concerned, we still live, have always lived and will always be living in a "plaintext HTTP 1.1 only" world, because those are the abstractions that browser APIs and application servers still maintain. All the crazy stuff in between - encryption, CDNs, changing network protocols - are just as abstracted away as the different hops of an IP packet and might just as well not exist from the application perspective.
  • koakuma-chan 2y ago
    > because those are the abstractions that browser APIs and application servers still maintain Because semantics are the same for every version.
  • KaiserPro 2y ago
    I think its more that HTTP/3 only really gives marginal gains for most people. Just as python3 had almost nothing for programmer over python2, apart from print needing brackets. Sure it was technically better, and allowed for future gains, but in practice, for the end user, there was no real reason to adopt it. For devs outside of FAANG, there is no real reason to learn how to setup and implement http3
    • ratorx 2y ago
      I’d go even further and say that HTTP/3 gives almost no gains for the average person using a high speed wired or wireless internet connection at a fixed location (or changing locations infrequently). However, for high latency mobile connections while roaming and continuously using the internet, it’s quite an optimisation. I wouldn’t expect even the vast majority of devs in FAANG to care. It should purely be an infrastructural change that has no impact on application semantics.
• skybrian 2y ago
  I’m wondering why switching Node from OpenSSL to BoringSSL is considered hard? Is the JavaScript API exposing too many implementation details?
  • jrpelkonen 2y ago
    I have no specific knowledge about this case, but I would guess one major reason is that BoringSSL does not provide any API or ABI stability guarantees.
  • koakuma-chan 2y ago
    Bun uses BoringSSL. Bun is mostly compatible with Node.
• Havoc 2y ago
  Openssl choice here remind me of torvalds and his „don’t break user space“ refrain. They may have gone with a technically cleaner solution but it’s causing chaos downstream
• RKFADU_UOFCCLEL 2y ago
  > At the same time, neither QUIC nor HTTP/3 are included in the standard libraries of any major languages including Node.js, Go, Rust, Python or Ruby. Curl recently gained supportopens in a new tab but it's experimental and disabled in most distributions. That doesn't matter too much, since a certain "security" company is doing deep packet inspection and blocking anything that isn't Firefox, Chrome, or Safari.
  • gkbrk 2y ago
    It's not even doing that right. I regularly see the same page blocked in Firefox while not being blocked in Chrome, on the same IP and device. Basically if your browser provides even a tiny bit of privacy, Cloudflare blocks it randomly.
    • deleted 2y ago
      [deleted]
    • RKFADU_UOFCCLEL 2y ago
      Yep, 90's security is *in* again.
• samueloph 2y ago
  HTTP/3 is enabled in the curl package on Debian: https://samueloph.dev/blog/debian-curl-now-supports-http3/ https://samueloph.dev/blog/debian-curl-now-supports-http3/
• zokier 2y ago
  While this article is about H3, I think there is wider issue at play; in general I think the gap of availble tools (/libraries/etc) between these faang megacorps and your average dev has grown very wide. Googles internal tooling maybe is the most famed, I'm sure some xooglers can tell more. This is very sad to see after seeing the massive democratization of sw development in the 00s-10s. I'm concerned about what the impact of having this two classes of developers will have on the community and ecosystem. I suppose this h3 phenomenon is one consequence.
• djha-skin 2y ago
  > Really it's hard to point to any popular open-source tools that fully support HTTP/3: rollout has barely even started. > This seems contradictory. What's going on? IT administrators and DevOps engineers such as myself typically terminate HTTP/3 connections at the load balancer, terminate SSL, then pass back HTTP 1.1 (_maybe_ 2 if the service is GRPC or GraphQL) to the backing service. This is way easier to administer and debug, and is supported by most reverse proxies. As such, there's not much need for HTTP/3 in server side languages like Golang and Python, as HTTP/1.1 is almost always available (and faster and easier to debug!) in the datacenter anyways. HTTP/3 and IPv6 are mobile centric technologies that are not well suited for the datacenter. They really shine on ephemeral spotty connections, but add a lot of overhead in a scenario where most connections between machines are static, gigabit, low-latency connections.
  • kstrauser 2y ago
    I'm not an expert on HTTP/3, but vehemently disagree about IPv6. It removes tons of overhead and cruft, making it delightful for datacenter work. That, and basically guaranteeing you don't have to deal with the company you just acquired having deployed their accounts with the same 10/16 subnet your own company uses.
    • cogman10 2y ago
      The problem I keep running into is that IPv6 support in common infrastructure is somewhat lacking. It's always a headache to learn that some container orchestration system doesn't support IPv6. Or an http client. Or a DNS resolver. Or whatever. Not to mention the supreme annoyance I have that, to this day, my ISP still does not have IPv6 addressing available.
      • frollogaston 2y ago
        Yep, it's tragic because it all stems from unforced differences vs ipv4. The design was reasonable, but with perfect hindsight, it needed to be different. They needed to keep the existing /32s and just make the address field bigger, despite the disadvantages. "Everywhere but nowhere" is sorta how I'd describe ipv6. Most hardware and lower-level software supports it, so obviously it wasn't impossible to support a new protocol, but it's not being used.
• fweimer 2y ago
  A lot of programming interfaces do not even keep alive HTTP/1.1 connections across requests because they do not have means to manage the hidden state. Transparent and meaningful upgrades to HTTP/3 on the library side only appear difficult.
• owenthejumper 2y ago
  HAProxy supports HTTP/3. Should be mentioned.
• tristor 2y ago
  HTTP/3 adoption will explode as soon as its provided in `libcurl` with default compile options when combined with OpenSSL and not a moment before. As soon as this happens there will be a bunch of clients that speak HTTP/3 if available, and then there will be effort to build it into servers. Right now there's no critical mass, and the most commonly used most-reference implementation of an HTTP client doesn't support HTTP/3 in any standardized way.
• LoganDark 2y ago
  I am still super disappointed about HTTP/3 in Rust. AFAICT there was a working HTTP/3 implementation in Rust over 6 years ago, but they (quinn crate) then literally yanked their entire version history from Cargo in order to wait for h3 which proceeded to take about three years (minus three days...) to even show up. I don't know the status of h3 today but that whole thing made me incredibly upset at the time. That having happened also makes me get annoyed again every time someone points out that Rust still doesn't have a very good HTTP/3 implementation, because I get reminded of the implementation from over 6 years ago that practically got retconned out of existence for this. (I guess though that quiche has been an option if you like to write Rust like it's C.)
  • koakuma-chan 2y ago
    There's also s2n-quic.
• williamDafoe 2y ago
  The most popular internet protocols are 100% text. This fact is indisputable. I doubt that the guys at google even know this, or know why ....
  • aboardRat4 2y ago
    Not really. Most of internet traffic now is video.
• raggi 2y ago
  Everyone loves to tout TTFB numbers for quic, but there's very little widespread reporting on throughput, particularly analyzed for a large number / wide breadth of real world customers. This matters because for a lot of operating systems, UDP buffers are still tuned to nearly 1990s levels, and are insufficient to overcome BDP challenges. For CDNs / edge deployment systems such as Cloudflare/Fastly, this may not be "statistically relevant" for their customers, in that they're close to "statistically most" of their customers, however for users in locations where these organizations do not have anywhere near such a good presence (APAC, the islands, etc), their experiences are getting _far worse_.
• francasso 2y ago
  I'm not an expert, so it's likely there are many things I don't get, but I wanted to have "UDP in the browser" for a project, and after looking at quic/http3/web transport I'm depressed by the complexity of it all
• superkuh 2y ago
  HTTP/3 isn't really HTTP. It's a protocol designed to deliver javascript applications to a browser. It's not even TCP. It's UDP and then a CA TLS only layer of QUIC on top of that. It is entirely designed for large corporate use cases the the detriment of anything else.
• kelseydh 2y ago
  I'm curious if any Ruby gems support HTTP/3? A quick google search found me nothing.
• hnaccountme 2y ago
  Isn't head of line blocking a problem with the design of web servers?
• f_devd 2y ago
  > At the same time, neither QUIC nor HTTP/3 are included in the standard libraries of any major languages including Node.js, Go, Rust, Python or Ruby. I'm not sure why it would be in the Rust std, Rust std doesn't even have HTTP/1 or TLS, it's not supposed to support any network layer higher than what's provided by the OS.