HTTP/3 is everywhere but nowhere • Hacker News Board

Re: HTTP/3 is everywhere but nowhere

#41

Post by echelon » Mon, Mar 17, 2025, 2:16 PM UTC

jchw wrote: post #29

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 up…

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.

Re: HTTP/3 is everywhere but nowhere

#42

Post by sethops1 » Mon, Mar 17, 2025, 2:16 PM UTC

jchw wrote: post #29

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 up…

> and even the h2 implementation feels like it still lacks some battle testing. I think that is a damn shame.

Citation needed.

Re: HTTP/3 is everywhere but nowhere

#43

Post by crazygringo » Mon, Mar 17, 2025, 2:16 PM UTC

troupo wrote: post #21

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,…

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?

Re: HTTP/3 is everywhere but nowhere

#44

Post by Macha » Mon, Mar 17, 2025, 2:17 PM UTC

inejge wrote: post #25

CharlieDigital wrote: post #2

> 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],…

> 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…

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...

Re: HTTP/3 is everywhere but nowhere

#45

Post by hylaride » Mon, Mar 17, 2025, 2:17 PM UTC

nchmy wrote: post #14

jimmydoe wrote: post #4

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.

Could you elaborate on why faster responses don't benefit you or your users?

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.

Re: HTTP/3 is everywhere but nowhere

#46

Post by kragen » Mon, Mar 17, 2025, 2:18 PM UTC

> 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.

Re: HTTP/3 is everywhere but nowhere

#47

Post by ralferoo » Mon, Mar 17, 2025, 2:21 PM UTC

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.

Re: HTTP/3 is everywhere but nowhere

#48

Post by FuriouslyAdrift » Mon, Mar 17, 2025, 2:21 PM UTC

elcritch wrote: post #19

kccqzy wrote: post #12

Earlier quoted context omitted.

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…

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.

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.

Re: HTTP/3 is everywhere but nowhere

#49

Post by nly » Mon, Mar 17, 2025, 2:22 PM UTC

ddulaney wrote: post #18

jcelerier wrote: post #7

Earlier quoted context omitted.

What prevents you from using a package manager linking statically with a recent libcurl ?

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 shippi…

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

Re: HTTP/3 is everywhere but nowhere

#50

Post by dadrian » Mon, Mar 17, 2025, 2:23 PM UTC

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.