[HN Gopher] HTTP/3 is everywhere but nowhere
___________________________________________________________________
HTTP/3 is everywhere but nowhere
Author : doener
Score : 288 points
Date : 2025-03-14 07:02 UTC (3 days ago)
(HTM) web link (httptoolkit.com)
(TXT) w3m dump (httptoolkit.com)
| CharlieDigital wrote:
| > 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/networ...
|
| [1] https://github.com/microsoft/msquic
|
| [2] https://learn.microsoft.com/en-
| us/dotnet/fundamentals/networ...
|
| [3] https://learn.microsoft.com/en-
| us/dotnet/fundamentals/networ...
| hypeatei wrote:
| > 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 wrote:
| 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 wrote:
| 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-a...
| pjc50 wrote:
| Are you sure? 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 ; runtime-
| dependent and self-contained are fine)
| CharlieDigital wrote:
| > 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 wrote:
| 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.
| TeMPOraL wrote:
| An image or a container could be, yes. It isn't, because
| Docker stuff is mostly distributed as Dockerfiles and
| docker-compose files, and those cause your system to
| download and install stuff, and _that_ part is not like
| self-contained package.
| chronogram wrote:
| The original question did ask about creating executables
| like Go, which means a single file you can run as is, so
| it was fair to mention AOT. For servers etc you usually
| don't want the AOT version, so then it doesn't matter
| which platform you develop on, but it's not always just
| like Go when you want to ship little applications.
| CharlieDigital wrote:
| The context of the thread is HTTP/3 servers; would it not
| make sense to take the comment in that context? Original
| article mentions that browsers (the client side) already
| supports HTTP/3 with the application server ecosystem
| being the missing piece.
| pjc50 wrote:
| More that there are at least three different ways to
| deploy things in dotnet, and only AOT is directly
| equivalent to Go executables. I like dotnet and use it at
| work but this is a nuisance limitation for us.
| neonsunset wrote:
| I don't know why we're trying anymore.
|
| You're not going to convince someone who is looking for a
| way to make something _not_ work however minor it is and
| not the other way around.
| homebrewer wrote:
| If your code does not rely on native libraries, or you're
| fine with shipping multiple copies for different operating
| systems, a single build works everywhere with dotnet
| installed.
|
| Or you can cross-compile and run without having dotnet on
| the target system, I do it from Linux to all three
| platforms all the time, it's pretty seamless. The
| application can be packaged into a single binary (similar
| to Go), or as a bunch of files which you can then then
| package up into a zip file.
| actionfromafar wrote:
| How do you cross compile from linux to macos?
| orphea wrote:
| dotnet publish -r osx-x64 --self-contained
|
| https://learn.microsoft.com/en-
| us/dotnet/core/deploying/#pub...
| mlhpdx wrote:
| Just like for windows or Linux, in other words. The
| dotnet tooling is amazingly friction and ceremony free
| these days.
| neonsunset wrote:
| JIT deployments do not care where they get built on. AOT
| deployments do because they use OS-provided linker to
| produce the final binary, much like C++ and Rust do
| (unless you use PublishAotCross nuget package which uses
| Zig toolchain to allow you to build Linux binaries from
| under Windows, I'm sure if someone's interested it could
| be extended further)
|
| Also, if you want to have just a single binary, you want
| to do 'dotnet publish /p:PublishSingleFile=true
| /p:PublishTrimmed=true' instead. Self-contained build
| means it just ships everything needed to run in a folder
| without merging the assembly files or without trimming
| unreachable code and standard library components.
| artimaeis wrote:
| I'm a dabbler in Go, far from an expert. But I'm not
| familiar with a capability to use, say, native MacOS
| platform libraries from a go app that I'm compiling in
| Windows/Linux without using a VM of some sort to compile
| it. If that's possible I'd love to learn more.
| hnlmorg wrote:
| If you're calling against shared libraries using cgo then
| things are a little more tricky, but still doable.
|
| But if it's native Go code, then cross platform compiling
| is just an a few environmental variables
| GOOS=darwin GOARCH=arm64
| dismalaf wrote:
| Mono's been on Linux for like 20 years, maybe longer... C#
| is like Java, can run basically anywhere.
| parineum wrote:
| 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.
| briandear wrote:
| .NET ain't hip because many of the shops that use it are
| dinosaurs in processes and culture.
| mlhpdx wrote:
| And many are not. How many Python shops are living in the
| past? It's the same problem everywhere.
| shermantanktop wrote:
| .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 wrote:
| They may be much less Linux-hostile today, but are still
| plenty user-hostile. Not to mention their lackadaisical
| security record.
| cebert wrote:
| Can you please highlight some examples of .NET's
| lackadaisical security record? I'm curious for my own
| awareness.
| mixmastamyk wrote:
| Microsoft's. Consult your favorite search engine.
| CharlieDigital wrote:
| The ironic thing? GitHub, VS Code, and TypeScript are all
| Microsoft products.
| Svoka wrote:
| Only Typescript is in-house. Others are acquisitions. Do
| you remember Embrace, extend, and extinguish times?
|
| https://en.wikipedia.org/wiki/Embrace,_extend,_and_exting
| uis...
| CharlieDigital wrote:
| Does the distinction matter?
| hnlmorg wrote:
| In the case of GitHub, yeah. I don't think a Microsoft
| source control "social network" would have taken off in
| the same way GitHub did.
|
| In fact when Microsoft purchased GitHub, quite a few
| people did leave and close their account. But GitHub
| already had such a monumental market lead that the
| departures ended up being a drop in the ocean.
|
| To be honest, I'm still waiting for the moment when
| Microsoft managed to fuck it all up like they did with
| Skype.
| LtWorf wrote:
| I've left later on, when they started to impose 2FA and
| decided to scan all my code to train their AI.
| strongpigeon wrote:
| VS code is mostly in house too. Sure, they don't own
| Electron, but I was at MSFT when project Monaco (which
| became the basis for VS Code) was started and remember
| being very impressed by it back then
| bitwize wrote:
| They own Electron now...
| foobarchu wrote:
| Text editors and IDEs come and go, there is very little
| commitment to using one.
|
| If you write a project in C#, you've committed to it and
| it's ecosystem. Getting out of there when MS makes a
| choice you don't agree with is going to be near
| impossible.
| ZeWaka wrote:
| Eh, these days there's a lot of investment in the VSCode
| extension ecosystem.
| mb7733 wrote:
| From whom was VSCode acquired?
| Navarr wrote:
| GitHub was purchased, which is a bit different.
|
| TypeScript though I had no idea about! Good for them!
| CharlieDigital wrote:
| > GitHub was purchased, which is a bit different.
|
| Why is that different? The purchase was 7 years ago (?)
| at this point.
|
| Do we make an exemption for SharePoint because it, too,
| is an extension of FrontPage acquired via Vermeer?[0]
|
| At what point does it lose its exemption from "Hate All
| Things Microsoft"? 10 years? 20 years?
|
| [0] https://en.wikipedia.org/wiki/Microsoft_FrontPage
| varjag wrote:
| Github looks and works mostly indistinguishable from how
| it was 7 years ago.
| CharlieDigital wrote:
| So you are of the belief that Microsoft has not had any
| effect on GitHub _over the last 7 years_? Interesting.
| Navarr wrote:
| The difference here is that we didn't select to use a
| Microsoft product, a produce we used became Microsoft.
|
| It only matters in the context of it being "ironic" that
| it is used and favored in the coding community.
| hbn wrote:
| The exceptions prove the rule.
|
| In my head, when I think Microsoft I think about the
| stress and anger I feel using Windows, and the OS-level
| notification I got apropos of nothing a few minutes ago
| trying to sell me an Xbox Game Pass subscription. The
| fear of what is going to break in the next forced update.
| For months now I haven't been able to do a task as simple
| as take a screenshot on my PC because seemingly the flash
| effect it plays gets caught in the image and the
| resulting screenshot has all the colors blown out, so
| it's mostly white.
|
| So yes, this does color my opinion of how many ecosystems
| of theirs I want to tie myself too (minimal)
| Zardoz84 wrote:
| You mean that Microsoft BOUGHT GitHub , like they did
| with Skype and many other things.
| varjag wrote:
| Skype that they ran into the ground despite it being
| their best messaging product, and are shutting it down in
| May.
| Zambyte wrote:
| Why is that ironic? Only one of those are Free Software
| nolist_policy wrote:
| I would say that .NET is the best example that Microsoft
| has not changed: https://isdotnetopen.com/
| neonsunset wrote:
| This link again?
|
| I'm baffled by insistent behavior like this. I think it
| is just alienating people and even if they move
| ecosystems, the negative impression will stay.
|
| If you engage in bad faith behavior in a technical
| discussion, can you be expected to conduct yourself
| acceptably in a professional setting? Unlikely.
|
| This is a discussion about HTTP/3 support of all things.
| Why does it happen only when someone leaves a briefly
| positive note on C#? I don't know any other language
| (besides PHP, to an extent) that gets the same amount of
| hate.
| ycombinatrix wrote:
| First time I've seen that link. What's bad faith about
| it? Don't know why you're bringing Rust into this.
| johnisgood wrote:
| Parent comment was edited, it no longer seems to include
| "Rust", difficult to follow. :P
| neonsunset wrote:
| I edited it because it's not just my own experience of
| dealing with this. On twitter, I follow a couple Japanese
| developers from mainly gamedev scene and even they
| complain they started hearing more about "but it only
| works on windows" and "it's not open-source". Don't you
| find it strange that it should be the other way around
| the more years pass since .NET went OSS?
|
| The link itself is also quite outdated and mainly
| consists of posts from Miguel de Icaza who's promoting
| Swift, arguably less OSS language. Take from that what
| you will.
| johnisgood wrote:
| I assumed .NET is Windows-only and proprietary, too, but
| it has to do with me not having done enough research, so
| if it is not the case anymore, the blame is on me.
| CharlieDigital wrote:
| Hey, I just want to commend you for amending your
| perspective (even if a little). There's a lot of
| intellectual hoop jumping in this thread with respect to
| Microsoft.
| int_19h wrote:
| You forgot to mention that Miguel de Icaza was probably
| the single biggest .NET fanboy for literally _decades_
| before throwing in the towel. The fact that a person like
| this ended up being alienated tells volumes.
|
| I should also add that the general public only saw the
| tip of the iceberg in this entire episode. Miguel spent a
| lot of time and effort internally trying to right the
| .NET ship, gradually escalating through management until
| he finally gave up.
| neonsunset wrote:
| I don't doubt this but the criticism has to be rooted in
| facts and the current state of affairs, and you have to
| consider conflict of interest. It's not too different to
| what you can read here. No one ever talks about whether
| C# offers good cohesive experience when solving a
| specific task, or what are the pros and cons of its build
| system, or how a typical .NET team looks like in a
| particular region. No.
|
| Instead, the complaints you will read here are about what
| the authors _think_ .NET's problems are without ever
| verifying if any of that is true in hopes of making
| swipes for god knows what reason, because posting
| something accurate requires knowledge on the subject and
| the results of a cursory search usually do not support
| cheap arguments.
|
| (and I see this as an embarrassment because you can learn
| a lot from doing research instead of repeating the same
| tired phrases you heard elsewhere)
| CharlieDigital wrote:
| .NET after .NET Framework is just terrible branding by
| Microsoft.
|
| Call it TypeScript++ or just `dot`; rebrand it Microsoft!
| Look at this thread full of misunderstandings and
| confusion around modern .NET!
| neonsunset wrote:
| I don't think we can survive another rename haha. It
| doesn't seem to have helped PHP either. But we could use
| a newer .NET language with better lambda lowering,
| dependent types, HM type inference, structs as the
| default data type, improved lifetime analysis and
| different tradeoffs w.r.t now that we're going to have
| zero-cost-ish non-suspending async calls.
| hu3 wrote:
| These are handful of handpicked twitter posts that are
| almost 3 years old, including the page itself.
|
| https://github.com/ghuntley/isdotnetopen
|
| The website doesn't even explain what they mean by open.
|
| Nor they explain why they think .NET is not open source.
| eptcyka wrote:
| Isn't `vsdbg` still distributed with an incredibly
| restrictive license? Doesn't sound all too open to me.
|
| Further, the twitter posts themselves are still relevant
| I believe. If someone took over my repo, I'd remember it
| 3 years later.
| neonsunset wrote:
| VSCodium uses NetCoreDbg. There are community snippets to
| make the same work for Cursor, NeoVim, etc.
|
| So far, there was little demand to write another debugger
| integration (because, really, the debugger core is
| implemented in the runtime itself - what vsdbg,
| NetCoreDbg and Rider all primarily do is consume the
| runtime API).
| lll-o-lll wrote:
| Yes, it is annoying. You can run VS Code on a PI and have
| an amazing Rust environment, or Zig, or any language.
| Except for .Net. Why MS? What is the benefit to your
| business to make .net suck without your closed sourced
| bits?
| thayne wrote:
| More than just that it came from MS.
|
| For a long time, .NET was completely proprietary, and only
| ran on Windows.
|
| Now it is open source and cross platform, but it is still
| fighting the momentum of being seen as Windows-only.
| mleo wrote:
| I haven't developed with .NET in a dozen years, let alone
| since it went cross platform, but I at least know it is
| capable of being cross platform. It amazes me how many
| developers I speak to that still assume .NET is Windows
| only.
| redeeman wrote:
| except if you want to use for example
| system.windows.forms, then "oh well different teams
| maintain that, nobody made it for linux!!!" "the core is
| open!!!"
|
| they clearly WANT applications written in .net not to be
| cross platform
| ziml77 wrote:
| It's not about different teams, it's that
| System.Windows.Forms is exactly what the namespace says.
| It's Windows Forms. It's a fairly thin wrapper over the
| Windows API. It's never going to be adapted to be cross-
| platform and isn't really something they've put any
| development work into for many years at this point.
|
| If you want a cross platform UI, use WPF with Avalonia.
| Or if you want something entirely from Microsoft
| themselves, there's MAUI as an option.
| lll-o-lll wrote:
| JS is the only true cross-platform UI; sadly.
| arccy wrote:
| It wasn't good enough for the typescript rewrite...
| bjoli wrote:
| Mostly because they didnt consider the AOT compilation
| mature enough.
| int_19h wrote:
| 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 wrote:
| > 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.
| shepherdjerred wrote:
| Why would I use C# over any other language though?
| CharlieDigital wrote:
| It's very productive and kinda nice.
|
| Especially for big backend APIs: https://typescript-is-
| like-csharp.chrlschn.dev/
| jayd16 wrote:
| 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.
| hu3 wrote:
| LINQ alone is unmatched.
| CharlieDigital wrote:
| 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-top...
| OkGoDoIt wrote:
| 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.
| inejge wrote:
| > _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 wrote:
| 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-
| ht...
|
| https://docs.python.org/3/library/http.server.html#module-
| ht...
| xpressvideoz wrote:
| > 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 wrote:
| > 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-
| 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
| 0x457 wrote:
| I never understood SO as a measurement tool for anything,
| but people that can't read docs.
| CharlieDigital wrote:
| 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.
| briandear wrote:
| GitHub is probably a better source. SO is self selecting
| for people asking questions about something, not actually
| using it. A "harder" thing might have more SO questions,
| so it isn't representative of actual usage.
| CharlieDigital wrote:
| I posted above, but you can also see:
|
| You get the same result from scraping job postings:
| 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 datapoints, completely discrete, same result.
| 0x457 wrote:
| It tells me which languages have people asking questions
| about them. That metric is useful only if it's normalized
| around how many people are using that language, but we
| don't have that metric.
| bheadmaster wrote:
| > StackOverflow survey[0] shows C# (27.1%) right behind
| Java (30.3%)
|
| Can we rule out sample bias here? After all, Jon Skeet [0]
| is an important part of the Stack Overflow's C# community.
|
| It might just be the case that C# and Java developers use
| Stack Overflow more than users of other languages.
|
| [0] https://toggl.com/blog/save-princess-8-programming-
| languages
| CharlieDigital wrote:
| You get the same result from scraping job postings:
| https://www.devjobsscanner.com/blog/top-8-most-demanded-
| prog... 1. JS/TS (note these two are
| collapsed) 2. Python 3. Java 4.
| C#
|
| So now you have two data points that align and are
| completely independent measuring two different things
| (one self reported, one based on employer job postings).
|
| I'd say it's consistent and reliable?
|
| It's not like people use StackOverflow _because it 's
| written in C#_; people use StackOverflow because Google
| points us there.
| Teckla wrote:
| _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)._
|
| I don't understand this reasoning at all, and I'm hoping
| you can shed some light on it.
|
| As far as I know, C# supports static methods. Thus, using
| OO in C# would not have been required, would it?
|
| I feel like I'm missing something here.
| Kipters wrote:
| That wouldn't feel very idiomatic - you can do it but
| would feel wrong
| briandear wrote:
| I've never filled out a stack overflow survey. I wouldn't
| say Stack Overflow is statistically representative what's
| being used -- it's statistically representative of people
| that use Stack Overlow. 10 years ago SO was my go-to. Now,
| I barely notice it -- it seems very outdated in many
| respects.
| kevinmershon wrote:
| It's pretty true from recent experience. I've recently
| started rewriting a C# based desktop/window stream tool
| because of how weak the support is across the board for C#.
| Microsoft abandoned WinRTC, Sipsorcery is one guy and is
| missing VP9 HEVC and AV1 support. And for fancier stuff like
| using computer shaders for color space conversion, SharpDX is
| constantly referenced by chatgpt and MS docs, yet it's
| archived and unmaintained as well. I ended up using media
| streams VideoFrame class but it and two other classes
| required to interact with it have unpreventable thread and
| memory leaks built into the WinRT implementations themselves
| 4+ years ago. Good times.
|
| All of the above was easy to implement in Rust
| kragen wrote:
| This is an interesting point I hadn't thought of when I saw
| the announcement of the new TypeScript compiler. It might be
| overstating the case to say that C# is indeed a minor
| language, but it's thought-provoking that it wasn't
| Microsoft's automatic choice here, the way it is for some
| all-Microsoft in-house IT shops.
| CharlieDigital wrote:
| Microsoft themselves ship on a variety of platforms.
|
| It's more about right tool for the right job.
|
| Good example is Azure CLI; it's Python. Microsoft is also a
| big contributor in the Python scene[0]
|
| I don't think it's surprising at all that they didn't use
| C# to write a compiler for TS.
|
| They have internal champions for Rust[1]
|
| I'd say Microsoft is possibly one of the most diverse shops
| when it comes to tech selection.
|
| [0] https://devblogs.microsoft.com/python/supporting-the-
| python-...
|
| [1]
| https://www.theregister.com/2022/09/20/rust_microsoft_c/
| troupo wrote:
| It's not thought-provoking if you care to spend 5 minutes
| and read/listen to the reasons they provided.
| jabart wrote:
| The interviews with the Typescript dev doing the rewrite will
| tell you why. Switching their compiler to Go was a quick
| transition since Go matched their current JS build. The dev
| also wanted to use go, and use functional programming. It
| would have required more work to switch from functional to
| OOP style that C# has. Dev also didn't want to learn F#.
| Nothing about C#, just a personal decision with the least
| amount of work to get to a beta.
| jayd16 wrote:
| Go folks are going to be holding up this Typescript decision
| for years, aren't they...
| qingcharles wrote:
| 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/s...
| bullen wrote:
| 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 wrote:
| 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 wrote:
| Could you elaborate on why faster responses don't benefit you
| or your users?
| hylaride wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| I subscribe for that
| vrnvu wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| What prevents you from using a package manager linking
| statically with a recent libcurl ?
| ddulaney wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| 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.
| ddulaney wrote:
| There's also a sort-of informal "standard library" of C
| libraries that have super-stable ABI's that we can
| generally assume are either present on the system or easy
| to install. Zlib is another one that comes immediately to
| mind, but there are others as well.
| jsheard wrote:
| 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 wrote:
| Out of curiosity have F5 added any new modules since they
| acquired Nginx?
| pas wrote:
| 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 wrote:
| 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
| FeistySkink wrote:
| Here's some background:
|
| https://arstechnica.com/information-
| technology/2024/02/nginx...
| LinuxBender wrote:
| Ah yes, I vaguely recall the drama. Thankyou.
| LinuxBender wrote:
| 16 commits from F5 from 2020 to 2025, nothing before
| that. Looks like they are bugfixes and enhancements.
| Perhaps someone else created the ngx_stream_set_module
| module prior to the acquisition.
| xendo wrote:
| Are there any viable nginx alternatives that support HTTP3 and
| are mature for prod workflows?
| artyom wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| 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.
| Sesse__ wrote:
| What do you mean? IPv6 PI is common and easy to get;
| there's no big difference between IPv4 and IPv6 there.
| FuriouslyAdrift wrote:
| I've gone through dozens of applications for a PI block
| and all been turned down. Heard the same from most of the
| networking people I know of. One even had their company
| become a LIR just so they could lock down a block.
|
| Outside of Europe I don't know anyone not FAANG sized
| that managed to get it done in the last few years.
|
| In my dealings with small to medium sized biz, I usually
| go the SDWAN route to aggregate and balance in IPv4 space
| instead as it is MUCH easier to get it done from an ISP.
| pas wrote:
| wanting p2p to work (without quixotic NAT hole-punching) is
| puristry?
| nine_k wrote:
| What good is your IPv6, Mr Anderson, if your upstream
| provider and/or middleboxes along the way do not support
| it?
| pas wrote:
| I'm happy to report that - to my utter amazement - my
| ISP's on-prem device does /64 prefix delegation to each
| (DHCPv6?) client.
| nine_k wrote:
| Yes, right now every large provider does that, which is
| great. That was not the case when the first p2p networks
| were growing big (Napster, Gnutella, that kind of thing).
| preisschild wrote:
| Can you request a bigger delegation? a single /64 is very
| limiting, since that effectively limits you to 1 subnet
| (so no extra guest / IoT subnet)
| mixmastamyk wrote:
| It already works. Sometimes the cure is worse than the
| disease.
| nine_k wrote:
| The exhaustion of IPv4 address pool was easy to predict
| even in 2000, just by extrapolation of the growth curve.
|
| Then came IP telephony backbone and the mobile internet,
| topped up with the cloud, and the need became acute. For
| the large corporations involved, at least.
| kccqzy wrote:
| Oh many purist networking geeks joined large corporations
| so that these corporations began to push IPv6 in a
| direction set by the geeks. They understood that as
| independent geeks they have essentially no say in the
| evolution of IPv6. My favorite example here is Android
| refusing to support stateful DHCPv6; it's clear that it's
| being pushed by purist networking geeks inside Google.
| jsheard wrote:
| Nginx (F5) and Go (Google) are hardly scrappy open source
| projects with limited resources. The former is semi-commercial,
| you can _pay_ for Nginx and still not have stable HTTP3
| support. Google was one of the main drivers of the HTTP3 spec
| and has supported it both in Chromium and on their own cloud
| for years, but for whatever reason they haven 't put the same
| effort into Go's stdlib.
| arccy wrote:
| It's in progress: quic is in testing in
| http://pkg.go.dev/golang.org/x/net/quic and http3 is being
| implemented https://github.com/golang/go/issues/70914
|
| Since Go has strong backwards compatibility guarantees,
| they're unlikely to commit to APIs that may need to change in
| the standard library.
| Orygin wrote:
| The backwards compatibility guarantees are for the language
| and not the standard library. They won't make breaking
| changes nilly willy but it can and has happened for the
| std.
| FuriouslyAdrift wrote:
| I'd go with HAProxy over Nginx any day. It far more robust
| and more capable. They've had QUIC & HTTP/3 since 2022.
| hylaride wrote:
| 99% of the benefit of HTTP/3 is on distributed web serving
| where clients are connecting to multiple remote ends on a web
| page (which lets be honest, is mostly used for serving ads
| faster).
|
| Why would the open source community prioritize this?
| surajrmal wrote:
| The open source community is full of companies who make money
| from things like ads.
| hylaride wrote:
| Yes, but they've likely already optimized any code that's
| part of their ad networks to support http/3 anyways.
| They're not necessarily going to lose sleep if other
| components doesn't support it.
| not_a_bot_4sho wrote:
| > see IPv6
|
| "We'll get to IPv6 after we finish IPv5"
| gexla wrote:
| 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 wrote:
| > 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 wrote:
| 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
| crazygringo wrote:
| 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 wrote:
| 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.
| crazygringo wrote:
| Of course it's alarming. But _what 's the alternative?_
|
| > _Something like 1% of HTTP hits pose some risk of spam
| or fraud_
|
| It doesn't matter if it's a tiny _percentage_ of requests
| that are spam /fraud. The only thing that matters is the
| _absolute_ amount, and that 's massive.
|
| > _Static file serving is very difficult to DDoS_
|
| No it's not, and most pages aren't particularly static.
| They're hitting all sorts of databases and caches and
| stores.
|
| > _generally the DoS actor has to pay more than the
| victim website_
|
| No, generally the DDoS actor pays very little, because
| they're using bots infecting other people's devices. The
| bandwidth is free because it's stolen.
|
| > _be weighing "a thousand signals" to decide which
| version of the truth_
|
| Nobody said anything about "truth". You're either blocked
| or you're not. Page content isn't changing.
|
| Yes, spam and fraud and abuse prevention does require
| weighing a thousand signals. It always has. It sucks, but
| the world is an adversarial place, and the internet
| wasn't designed with that in mind.
| immibis wrote:
| Can you explain more specifically the threats faced by
| your website? Please help us understand what attacks you
| are currently facing. Are you currently getting DDoSed?
| Did the DDoSer stop DDoSing when you blocked HTTP 1.1?
| Did your credit card chargebacks drop by 50%?
|
| ---
|
| According to other commenters the main use case for
| HTTP/3 is ads serving. Should I assume your project is an
| ad server? I could disable HTTP/3 in my browser to block
| ads. You see that this is a bit silly, right?
| crazygringo wrote:
| I'm sorry, are you really questioning whether these
| threats exist? Or whether not using HTTP/3 is one
| potential signal of being a bot (out of _many_ ), since
| tools like cURL don't support HTTP/3?
|
| The two other commenters are wrong, ads are not the main
| use case at all. And disabling HTTP/3 won't block ads,
| not even the tiniest bit. It appears you are getting a
| lot of misinformation.
| progmetaldev wrote:
| When it comes specifically to Cloudflare, it does not have to
| be this way. A site operator can choose to set their own
| rules for triggering CAPTCHAs, it's just that most don't
| actually bother to learn about the product they're using.
|
| I use Cloudflare through my employer because I deal with
| clients that aren't willing to spend a few hundred dollars a
| month on hosting. In order to keep up with sales of new
| websites for these clients (where the real money lies), I
| need to keep hosting costs down, while also providing high-
| availability and security. Bot traffic is a real problem, and
| while I would love to not require using Cloudflare in favor
| of other technologies to keep a site running quickly and
| securely, I just can't find another solution near a similar
| price point. I've already tweaked the CMS I use to actually
| run with less than the minimum recommended requirements, so
| would have to take a more hostile action towards my clients
| to keep them at the same cost (such as using a less powerful
| CMS, or setting expiration headers far in the future - which
| doesn't help with bots).
|
| If anyone has suggestions, I'd be open to them, but working
| for a small business I don't have the luxury to not run with
| Cloudflare (or a similar service if one exists). I have
| worked with this CMS since 2013, and have gone into the
| internals of the code to try and find every way to reduce
| memory and CPU usage so I don't need to depend on other
| services, but I don't see too many returns anymore.
|
| I am all for internet privacy, and don't like where things
| are going, but also do work for lots of small businesses
| including charities and "mom and pop" shops that can't afford
| extra server resources. In no way do I use Cloudflare to
| erode user privacy or trust, but can understand others
| looking at it that way. If I had the option to pick my
| clients and their budgets, it wouldn't be an issue.
| LinuxBender wrote:
| I've been doing that on my hobby sites ever since all the
| popular browsers supported HTTP/2.0 [1] if
| ($server_protocol != HTTP/2.0) { return 444; }
|
| It knocks out a lot of bots. I am thankful that most bots are
| poorly maintained and most botters are just skiddies that could
| not maintain the code if they wanted to.
|
| [1] -
| https://nginx.org/en/docs/http/ngx_http_rewrite_module.html#...
| jiehong wrote:
| 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 wrote:
| 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 wrote:
| 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
|
| --- end quote ---
|
| And if you believe the discussion here
| https://news.ycombinator.com/item?id=25970258 it increased the
| load on the server unless you can "spend years optimizing it".
| crazygringo wrote:
| 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 wrote:
| Google's needs are not most people's needs, "wrong" for them
| is different than "wrong" for general users.
| crazygringo wrote:
| 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 wrote:
| 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.
| xxs wrote:
| >with 5% packet loss
|
| This is absolutely massive
| crazygringo wrote:
| Clearly you have never taken the subway, or stood on a
| particular street corner with bad reception.
|
| Quite frequently I'd _love_ to have just 5% packet loss.
| llm_nerd wrote:
| It is bad packet loss, but is the sort of situations that
| people often find themselves in. Congestion, bad
| connections (which is a lot of mobile scenarios), satellite
| comms, and the like and it's a reality.
|
| It's interesting how people often say HTTP/3 only benefits
| the megas like Google. A few years back I worked on a data
| centric system (fund administration) where we had a single
| centralized server cluster serving high value users across
| the globe. Because of the integration and real-time nature
| of the data, it wasn't possible to replicate to servers
| around the world, nor was local (relative to the user)
| caching of much value at all.
|
| QUIC (which became HTTP/3) proved a significant improvement
| for users of the system. Users in the UK, Singapore,
| Australia, Germany, California, and so on, were all using a
| system in Toronto basically transparently, with great
| usability. That it was continents away suddenly didn't
| matter.
| troupo wrote:
| > 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.
|
| And yet it's somehow being pushed as a be-all solve-all
| replacement despite this:
|
| --- start quote ---
|
| We experimentally demonstrate that QUIC's performance
| degradation affects not only bulk file transfers but also
| other applications including video content delivery and web
| browsing, despite their intermittent traffic patterns. QUIC
| incurs a video bitrate reduction of up to 9.8% compared to
| HTTP/2 when delivering DASH (Sodagar, 2011) video chunks over
| high-speed Ethernet and 5G. Again, such QoE degradation only
| exhibits when the underlying bandwidth is sufficiently high.
| For example, the impact is hidden over 4G but unleashed over
| 5G. QUIC's page load time (PLT) is 3.0% longer than HTTP/2's,
| averaged across 100 representative websites, with a long tail
| of page load time gaps over 50%.
|
| --- end quote ---
|
| Latency is all good ... until latency isn't the only thing
| affecting the performance
|
| > 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.
|
| Indeed, why not claim something that article never claimed
| and then claim moral superiority for yourself. Nowhere in the
| article do authors claim to have servers 0ms from each other
| with 0 packet loss.
|
| Additionally, if your performance degrades even in these
| ideal conditions, what does this promise for non-ideal
| conditions?
| llm_nerd wrote:
| >And yet it's somehow being pushed as a be-all solve-all
| replacement
|
| But _it isn 't_ a be-all solve-all replacement. The whole
| point of HTTP/3 is that you can still use HTTP/2 all you
| want in your build-outs, and it uses as appropriate. If
| large file, many packet, high speed sustained performance
| is your thing and you've got problems with HTTP/3, deploy
| it on an HTTP/2 server. Go nuts. Positively nothing will go
| awry. Everything will be fine.
|
| You're arguing a strawman.
|
| >Additionally, if your performance degrades even in these
| ideal conditions, what does this promise for non-ideal
| conditions?
|
| This is an absolutely _nonsensical_ statement. HTTP /3 is
| quite literally _built_ for situations where you have many
| small requests, often in suboptimal situations. The average
| web user interacting with an average web page over
| something other than their local ethernet connection,
| exchanging tens of thousands of back and forths for
| different resources and navigations and posts. Screeching,
| with moral superiority I might add, that if it pins the CPU
| using their oddball no-name server -- oh, and where they
| bizarrely forced the HTTP /3 server to use HTTP/2
| congestion control because that made the results funner --
| with their client machine with a CPU 1/4 the performance of
| _my smartphone_ , downloading a many GB file, isn't the big
| win you seem to think it is.
| troupo wrote:
| > If large file, many packet, high speed sustained
| performance is your thing and you've got problems with
| HTTP/3, deploy it on an HTTP/2 server.
|
| Ah yes. Basically back to some links I discussed. Oh,
| it's amazing _but_ you have to be careful what you
| deploy, and when, and you have to switch between HTTP /2
| and HTTP/3 for some unspecified criteria which may or may
| not be better in one or another while the article we're
| in comments to decries "why oh why so few implement
| HTTP/3"
|
| > HTTP/3 is quite literally built for situations where
| you have many small requests, often in suboptimal
| situations.
|
| That is what Google markets it as, for sure.
|
| The rest of that sentence I could not parse.
| llm_nerd wrote:
| >That is what Google markets it as, for sure.
|
| Can you point me to this Google "marketing"?
|
| Google doesn't particularly _care_ if you use HTTP /3.
| They don't even build it into the tools they build like
| Go or Dart, at least not in a timely manner. There was a
| passing bit of technical notes for RFCs and as they added
| it in Chromium, but otherwise they've been remarkably
| silent about it.
|
| Yet they moved trillions of web requests to HTTP/3. Maybe
| they really don't know what they're doing. Cloudflare
| also clearly hasn't the slightest, right? Fools!
|
| >while the article we're in comments to decries
|
| HTTP/3 is complex to implement. Very complex. It's pretty
| simple to understand why it hasn't seen wide
| implementation in every random tool. And for many people
| HTTP/2 is fine, especially as you're probably just going
| to drop Cloudflare (which has HTTP/3) with caching in
| front of it anyways.
| JimDabell wrote:
| 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/
|
| 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 wrote:
| 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 wrote:
| 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
| /#...
| antisthenes wrote:
| It takes a very special case of a person to complain about
| a feature-complete piece of software not evolving fast
| enough.
| jchw wrote:
| 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 wrote:
| 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 wrote:
| > and even the h2 implementation feels like it still lacks some
| battle testing. I think that is a damn shame.
|
| Citation needed.
| jchw wrote:
| 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 wrote:
| Why not Traefik?
| jchw wrote:
| Good question! I have nothing against Traefik. I just haven't
| used it as much, whereas with Envoy I've both used it and
| contributed to it a little bit too.
| sheerun wrote:
| Coordinate efforts for more of most of popular programming
| languages, then switch from experimental in synchrony
| theandrewbailey wrote:
| 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://haproxy.debian.net/
|
| https://www.haproxy.com/blog/announcing-haproxy-2-6
|
| Live example: https://theandrewbailey.com/
| AlienRobot wrote:
| Cool, let me see if I can block HTTP/1.1 on Cloudflare to get rid
| of bot traffic.
| giancarlostoro wrote:
| 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 wrote:
| 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 wrote:
| Surely most hardware / software that has had no support for
| IPv6 has been mostly phased out by now?
| kragen wrote:
| > _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 wrote:
| 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.
| lemagedurage wrote:
| 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 wrote:
| 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".
| celsoazevedo wrote:
| Almost every optimization is irrelevant if we apply the
| same reasoning to everything. Add all savings together and
| it does make a difference to real people using the web in
| the real world.
| TheRealPomax wrote:
| What a bizarre thing to say: not every optimization is
| imperceptable by humans (jpg, gzip, brotli, JS and CSS
| payload bundling and minification, etc. etc.) and not all
| sums of optimizations add up to "something significant in
| terms of human perception".
|
| HTTP/3 is a good optimization, and you can't sell it
| based on "it improves things for humans" because it
| doesn't. It improves things for machines, and given that
| essentially all internet traffic these days is handled by
| large scale machine systems, that's a perfectly
| sufficient reason for adoption.
| celsoazevedo wrote:
| For a long time all my internet connections were bad
| (slow, unstable or both). Compressing HTML/CSS/JS,
| avoiding JS unless absolutely needed, being careful with
| image sizes and formats, etc, helped a lot... so I guess
| this makes me biased.
|
| Today I have fibre at home, but mobile networks are still
| patchy. I'm talking sub 1Mbps and high ping/jitter
| sometimes. So you can see why I think an "irrelevant"
| optimisation that removes 300ms from a page reload, no
| compression vs brotli/zstd, jpg vs avif, etc, are
| important for me, a human.
|
| It's important to keep in mind that many users out there
| don't have a fast and low latency connections, at least
| not all the time. What takes 300ms to complete on our
| fast machine and fast WiFi at the office might take 1s on
| someone else's device and connection. It's harder to
| understand this if we only use fast connections/hardware
| though.
| TheRealPomax wrote:
| That was my point: 300ms sounds like a lot until, like me
| too, you're on a slow connection and those 300ms on the
| entire 10 second page load are utterly irrelevant. You
| were already expecting a several second load time, that
| 300ms is not something that even registers: the HTTP
| negotiation on a modern page is _not_ what you're
| noticing on a slow connection. You're noticing literally
| everything else taking forever instead.
| SkyPuncher wrote:
| In my experience almost every optimization is irrelevant
| for that exact reasoning.
|
| Nearly all of my real world performance issues have come
| from a very small set of functionality running extremely
| poorly.
| waynesonfire wrote:
| Google operates at such a scale that tiny increases of
| performances allows them to support a team of engineers
| and saves money on the bottom line.
|
| For example, Google hires 10 engineers, they deploy
| HTTP/3, it saves 0.5% cpu usage, Google saves a million
| dollars and covers the salary of the said 10 engineers.
|
| For the vast majority of society, the savings don't
| matter. Perhaps even deploying it is a net-negative with
| a ROI of decades. Or, the incentives can be misaligned
| leading to exploitation of personal information. For
| example, see chrome manifest v3.
|
| It's okay to question whether we need it.
| TeMPOraL wrote:
| It absolutely matters. Machines are orders of magnitude
| faster than they were 20 years ago; most software isn't
| doing much more than software did 20 years ago. And no,
| collaborative editing isn't be-all, end-all, nor does it
| explain where all that performance is lost.
|
| Many optimizations have bad ROI because users' lives are
| an externality for the industry. It's Good and
| Professional to save some people-weeks in development, at
| the cost of burning people-centuries of your users' life
| in aggregate. And like with pollution, you usually can't
| pin the problem on anyone, as it's just a sum of great
| many parties each doing tiny damage.
| charleslmunger wrote:
| Deploying QUIC led to substantial p95 and p99 latency
| improvements when I did it (admittedly a long time ago) in
| some widely used mobile apps. At first we had to correct
| our analysis for connection success rate because so many
| previously failing connections now succeeded slowly.
|
| It's a material benefit over networks with packet loss
| and/or high latency. An individual human trying to
| accomplish something in an elevator, parking garage, or
| crowded venue will care about a connection being faster
| with a greater likelihood of success.
| the8472 wrote:
| Isn't 5G supposed to solve the mobile latency issue?
| nine_k wrote:
| The connection to your local tower can have a negligible
| latency. The connection all the way to the datacenter may
| take longer. Then, there is congestion sometimes, e.g.
| around large gatherings of people; it manifests as latency,
| too.
| the8472 wrote:
| But from the tower onward it shouldn't be any different
| from fixed internet connections, except for the
| gatherings, I'll grant that one.
|
| So then (modern) mobile shouldn't be all that special.
| nine_k wrote:
| At a previous job I had to specifically accommodate the
| backend API design to slow, large-latency 3G links which
| much of our East Asian audience had at the time. South
| Korea is one thing, Malaysia, quite another.
| motorest wrote:
| > A "few extra ms" is up to 3 roundtrips difference, that's
| easily noticeable by humans on cellular.
|
| That's a valid concern. That's the baseline already though,
| so everyone is already living with that without much in the
| way of a concern. It's a nice-to-have.
|
| The problem OP presents is what are the tradeoffs for that
| nice-to-have. Is security holes an acceptable tradeoff?
| fragmede wrote:
| Most people still use Google, and so they're living the
| fast HTTP 3 life, switching off that to a slower protocol
| only when interacting with non-Google/Amazon/MSFT
| properties. If your product is a competitor, but
| slower/inaccessible users are going to bounce off your
| product and not even be able to tell you why.
| sublimefire wrote:
| Nonsense, most of the web is non Google, Amazon or MSFT.
| Much of the web apps already uses CDNs which will enable
| web3 and the browser will support it. Other parts like
| APIs will not benefit much it they hit the
| database/auth/etc. MSFT stuff is dead slow anyway, Amazon
| is out of date, Google is just ads (who uses their search
| anymore?)
| fragmede wrote:
| > most of the web is non Google, Amazon or MSFT.
|
| maybe you can point out where that's what I said
| IgorPartola wrote:
| I routinely have concerns about lag on mobile. It sucks to
| have to wait for 10 seconds for a basic app to load. And
| that adds up over the many many users any given app or
| website has.
| wizzwizz4 wrote:
| The problem with _that_ is unlikely to be making HTTP
| connections. HTTP /1.1 already allows connections to be
| re-used.
| IgorPartola wrote:
| But it doesn't allow you to multiplex that connection
| (HTTP pipelining is broken and usually disabled). So
| depending on the app setup you could be losing quite a
| bit waiting on an API call while you could be loading a
| CSS file.
| wizzwizz4 wrote:
| Your static and dynamic assets should be served from
| different domains anyway, to reduce the overhead of
| authentication headers / improve cache coherency.
| https://sstatic.net/ quotes a good explanation,
| apparently mirrored https://checkmyws.github.io/yslow-
| rules/. (The original Yahoo _Best Practices for Speeding
| Up Your Web Site_ article has been taken down.)
| mananaysiempre wrote:
| Why does saving on cookies outweigh having to go through
| an additional TCP slow start?
| motorest wrote:
| > I routinely have concerns about lag on mobile. It sucks
| to have to wait for 10 seconds for a basic app to load.
|
| That's a software architecture problem, not a transport
| layer problem.
| lukeschlather wrote:
| Making the transport layer faster makes some
| architectures more performant. If you can simply swap out
| the transport layer that's a way easier optimization than
| rearchitecting an app that is correct but slow.
| croes wrote:
| So with HTTP/3 it's just 9.9 sec
| croes wrote:
| And then the web app eats all that saved ms with ease.
| cyanmagenta wrote:
| > I'd far rather have the OS provide a verified safe socket
| layer
|
| There is work going on right now[1] to implement the QUIC
| protocol in the linux kernel, which gets used in userspace via
| standard socket() APIs like you would with TCP. Of course, who
| knows if it'll ultimately get merged in.
|
| [1] https://github.com/lxin/quic
| eptcyka wrote:
| Yea, but does the kernel then also do certificate validation
| for you? Will you pin certs via setsockopt? I think QUIC and
| TLS are wide enough attack surfaces to warrant isolation from
| the kernel.
| XorNot wrote:
| The problem is that the situation where everyone rolls
| their own certificate stack is lunacy in this day and age.
| We need crypto everywhere, and it _should_ be a lot easier
| to configure how you want: the kernel is a great place to
| surface the common interface for say "what certificates am
| I trusting today?"
|
| The 10+ different ways you specify a custom CA is a problem
| I can't wait to see the back of.
| richardwhiuk wrote:
| It's a good thing for a OS to provide, that doesn't mean
| it needs to be in the kernel.
| kelnos wrote:
| Putting cert parsing in (monolithic) kernels seems like a
| bad idea; cert parsing has a long history of security
| vulnerabilities, and you don't want that kind of mistake
| to crash your kernel, let alone lead to privilege
| escalation or a takeover of the kernel itself.
|
| Regardless, your proposal suffers from the usual stuff
| about proliferating standards (https://xkcd.com/927/): a
| kernel interface will never get fully adopted by
| everyone, and then your "10+ ways" will become "11+
| ways".
|
| Meanwhile, all the major OSes have their own trust store,
| and yet some apps choose to do things in a different way.
| Putting this into the kernel isn't going to change that.
| SahAssar wrote:
| The kernel already does TLS, but the handshake happens in
| user-space.
| cyanmagenta wrote:
| > but does the kernel then also do certificate validation
| for you
|
| No, the asymmetric cryptography is all done in userspace.
| Then, post-handshake, symmetric cryptography (e.g., AES) is
| done in-kernel. This is the same way it works with TCP if
| you're using kTLS.
| xxs wrote:
| >saving a few ms per request, or more likely just on the first
| request.
|
| That's not given, either as UDP is normally not prioritized
| under congestion.
| eptcyka wrote:
| But that will change, as more and more clients will rely on
| UDP on port 443.
| AnthonyMouse wrote:
| It's also a poor congestion control practice to begin with.
| The main categories of UDP traffic are DNS, VoIP and VPNs.
| DNS is _extremely_ latency sensitive -- the entirety of
| what happens next is waiting for the response -- so
| dropping DNS packets is a great way to make everything suck
| more than necessary. VoIP often uses some error correction
| and can tolerate some level of packet loss, but it 's still
| a realtime protocol and purposely degrading it is likewise
| foolish.
|
| And VPNs are carrying arbitrary traffic. You don't even
| know what it is. Assigning this anything less than "normal"
| priority is ridiculous.
|
| In general middleboxes should stop trying to be smart. They
| _will_ fail, _will_ make things worse, and should embrace
| being as dumb and simple as possible. Don 't try to
| identify traffic, just forward every packet you can and
| drop them at random when the pipe is full. The endpoints
| will figure it out.
| eptcyka wrote:
| Allegedly, some traffic is best split into multiple
| socket addresses to work around the _smart_ middleboxes.
| hubabuba44 wrote:
| If the initial tcp 3 way handshake fails it can be quite a bit
| longer you would have to wait than a few ms. Depending on OS it
| is a second or more.
| sennalen wrote:
| Connection migration sounds like a security nightmare
| AnthonyMouse wrote:
| How is it any worse than session resumption from a different
| IP address?
| jeroenhd wrote:
| Experiencing the internet at 2000ms latency every month or so
| thanks to dead spots along train tracks, the latency
| improvements quickly become noticeable.
|
| HTTP/3 is terrible for fast connections (with download speeds
| on gigabit fiber notably capped) and great for bad ones (where
| latency + three way handshakes make the web unusable).
|
| Perhaps there should be some kind of addon/setting for the
| browser to detect the quality of the network (doesn't it
| already for some JS API?) and dynamically enable/disable HTTP/3
| for the best performance. I can live with it off 99% of the
| time, but those rare times I'm dropped to 2G speeds, it's a
| night and day difference.
| kelnos wrote:
| > _a few extra ms of latency on a request_
|
| That's not what it is, though. The graph embedded in the
| article shows HTTP/3 delivering content 1.5x-2x faster than
| HTTP/2, with differences in the hundreds of ms.
|
| Sure, that's not latency, but consider that HTTP/3 can do fewer
| round-trips. RTs are often what kill you.
|
| Whether or not this is a good trade off for the negatives you
| mention is still arguable, but you seem to be unfairly
| minimizing HTTP/3's benefits.
| plopz wrote:
| the big one is multiplayer games. udp is preferred and trying
| to work with webrtc is awful
| AnthonyMouse wrote:
| > 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.
|
| Then you're trying to rely on the OS for this when it should
| actually be a dynamically linked _third party_ library under
| some open source license.
|
| Trying to get the OS to do it fails to one of two problems.
| Either each OS provides its own interface, and then every
| application has to be rewritten for each OS and developers
| don't want to deal with that so they go back to using a
| portable library, or the OS vendors all have to get together
| and agree on a standard interface, but then at least Microsoft
| refuses to participate and that doesn't happen either.
|
| The real problem here is that mobile platforms fail to offer a
| package manager with the level of dependency management that
| has existed on Linux for decades. The way this _should_ work is
| that you open Google Play and install whatever app that
| requires a QUIC library, it lists the QUIC library as a
| dependency, so the third party open source library gets
| installed and dynamically linked in the background, and the
| Play Store then updates the library (and therefore any apps
| that use it) automatically.
|
| But what happens instead is that all the apps statically link
| the library and then end up using old insecure versions,
| because the store never bothered to implement proper library
| dependency management.
| dadrian wrote:
| 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 wrote:
| Small websites gain from reducing roundtrips on connection too.
| Fast websites are nice
| dadrian wrote:
| HTTP/2 already reduces roundtrips.
| charleslmunger wrote:
| At the cost of head-of-line blocking - one dropped TCP
| packet delays all HTTP/2 streams.
| dadrian wrote:
| Yes, but head-of-line blocking is a different thing than
| round trips.
| charleslmunger wrote:
| 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.
| lieuwex wrote:
| HTTP/3 even more so due to QUIC's shorter handshake
| process.
| fiatjaf wrote:
| 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.
| jillesvangurp wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| I don't think I'd call Caddy "widely used" it is used, but
| nowhere near nginx, apache, haproxy, squid, etc.
| lemagedurage wrote:
| 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 wrote:
| 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 wrote:
| 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)
| lokar wrote:
| I think they mean these intercepting firewall/proxies that many
| big companies use to spy on their employees don't work (yet)
| InfiniteRand wrote:
| 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 wrote:
| > neither QUIC nor HTTP/3 are included in the standard libraries
| of any major languages
|
| Like dotnet?
| globnomulous wrote:
| Just pointing this out in case it's helpful: there's tons of
| great discussion of this topic elsewhere in the thread!
| dangoodmanUT wrote:
| 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 wrote:
| Perhaps, but:
|
| There's ongoing work exploring QUIC-in-kernel-space at
| 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 wrote:
| 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 wrote:
| 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 wrote:
| 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
| jauntywundrkind wrote:
| 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
| sureIy wrote:
| I'd love to see that OpenSSL fork drama on the main page of HN.
| Do you know where this was discussed?
| billywhizz wrote:
| 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-...
| upofadown wrote:
| 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.
| zlagen wrote:
| shouldn't QUIC be supported at the operating system level similar
| to TCP? that way it could get adopted much easily in different
| languages
| grayhatter wrote:
| > 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 wrote:
| 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 wrote:
| > because those are the abstractions that browser APIs and
| application servers still maintain
|
| Because semantics are the same for every version.
| skybrian wrote:
| I'm wondering why switching Node from OpenSSL to BoringSSL is
| considered hard? Is the JavaScript API exposing too many
| implementation details?
| jrpelkonen wrote:
| 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 wrote:
| Bun uses BoringSSL. Bun is mostly compatible with Node.
| Havoc wrote:
| 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 wrote:
| > 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 wrote:
| 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.
| samueloph wrote:
| HTTP/3 is enabled in the curl package on Debian:
|
| https://samueloph.dev/blog/debian-curl-now-supports-http3/
| zokier wrote:
| 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 wrote:
| > 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 wrote:
| 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 wrote:
| 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 wrote:
| 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.
| JoshTriplett wrote:
| > 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.
|
| Exactly. I would love to have seen the world in which
| that happened, and where all the other parts of IPv6 were
| _independently_ proposed (and likely many of them
| rejected as unwanted).
| cowsandmilk wrote:
| For those building on AWS with VPC per service and using
| PrivateLink for connections between services, the whole IP
| conflict problem just evaporates. Admittedly, you're paying
| some premiums to Amazon for that convenience.
| aoeusnth1 wrote:
| What kind of overhead? I'm curious if there's data about this
| because I hadn't heard that 1.1 was better for the data center.
| Karrot_Kream wrote:
| QUIC/HTTP3 relies on TLS. If you already have some encrypted
| transport, like an Istio/Envoy service mesh with mutual TLS,
| or Zerotier/Tailscale/Wireguard style encrypted overlay
| network, then there are no benefits to using HTTP3. Moreover
| native crypto libraries tend do a better job handling
| encryption anyway so rather than wasting cycles doing crypto
| in Go or Node it makes more sense to let the service mesh or
| the overlay handle encryption and let your app just respond
| to clear requests.
| urban_alien wrote:
| Ok, HTTP/3 is mobile centric. But why not fallback to HTTP/2 in
| all other cases?
| jallmann wrote:
| http/1 traffic is a lot easier to inspect
| Varriount wrote:
| I really have to agree with the "easier to debug" part. I one
| time had to debug a particularly nasty networking issue that
| was causing HTTP connections to just "stop" midway through
| sending data. Turned out to be a confusion mismatch between
| routers and allowed packet sizes. It would have been _so_ much
| worse with a non-plaintext protocol.
| cogman10 wrote:
| Totally agree. Most of the benefit of HTTP 2/3 comes from
| minimizing TCP connections between app->lb. Once you are past
| the lb the benefits are dubious at best.
|
| Most application frameworks that I've dealt with have limited
| capabilities to handle concurrent requests, so it becomes a
| minor issue to have 100+ connections between the app and the
| lb.
|
| On the flipside, apps talking to the LB can create all sorts of
| headaches if they have even modest sized pools. 20 TCP
| connections from 100 different apps and you are already looking
| at hard to handle TCP flooding.
| frollogaston wrote:
| Speaking of gRPC, it's unfortunate that they went all-in on
| HTTP/2. Should have made it work over HTTP/1.1. I know others
| made it work, but it wasn't first-party. Maybe it could've been
| more popular than JSON-over-HTTP by now.
| fweimer wrote:
| 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 wrote:
| HAProxy supports HTTP/3. Should be mentioned.
| tristor wrote:
| 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 wrote:
| 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 wrote:
| There's also s2n-quic.
| williamDafoe wrote:
| 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 ....
| raggi wrote:
| 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_.
___________________________________________________________________
(page generated 2025-03-17 23:00 UTC)