HTTP/3 is everywhere but nowhere • Hacker News Board

Re: HTTP/3 is everywhere but nowhere

#391

Post by frollogaston » Tue, Mar 18, 2025, 6:55 AM UTC

Dylan16807 wrote: post #373

frollogaston wrote: post #363

Earlier quoted context omitted.

Ipv6 packet format was needed either way, but only with the 32-bit address space at first (the other 92 bits set to 0). You simply tell your system to start using v6 instead, and everything else stays the same. No dual-stack. Next step would be upgrading all those parts like DNS, DHCP, etc to accept the 128-bit addrs, which again can be done in isolation. Then finally, ISPs or home routers can start handing out longe…

There are two ways for me to interpret "simply tell your system to start using v6". If it means upgrading every program, then your plan works but it's the same as how things work today. You're telling people to do a thing, and they aren't bothering. The "simple" step isn't simple at all. If it doesn't mean upgrading every program, then your rollout fails on the last step. You start handing out longer addresses and le…

It's the second one. But legacy programs did get upgraded, so I don't see why they wouldn't under this other plan. If anything, it's easier because you're only making the address field bigger and it's not a separate case. Some routers struggled with 128-bit addrs due to memory, and could've gotten away with like 48 or 64 bits if they're using DHCP.

Re: HTTP/3 is everywhere but nowhere

#392

Post by frollogaston » Tue, Mar 18, 2025, 7:01 AM UTC

JoshTriplett wrote: post #381

frollogaston wrote: post #311

Earlier quoted context omitted.

The main problem wasn't all the smaller features but one big one in particular that can't be split into smaller pieces, the new addressing scheme. They wanted to replace all the existing addresses, which meant replacing all the routes. Besides the difficulty of that by itself, it automatically meant that the v6 versions of DNS, DHCP, NAT, etc wouldn't support v4, rather it'd be a totally separate stack. There were al…

> Besides the difficulty of that by itself, it automatically meant that the v6 versions of DNS, DHCP, NAT, etc wouldn't support v4, rather it'd be a totally separate stack. Sure, "make the addresses bigger" would have required providing DHCPv6, DNS AAAA records, and various other protocol updates for protocols that embedded IP addresses. And making changes to the protocol header at the same time (e.g. removing the re…

Yeah. I didn't like any of those proposed changes, especially the colons. You also didn't mention how NAT6 isn't a thing by default.

Re: HTTP/3 is everywhere but nowhere

#393

Post by otabdeveloper4 » Tue, Mar 18, 2025, 7:15 AM UTC

koakuma-chan wrote: post #315

frollogaston wrote: post #277

Earlier quoted context omitted.

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.

No reason to choose HTTP/1.1 over HTTP/2.

Nobody needs HTTP/2. It's just Google doing embrace-extend-extinguish of public domain protocols.

Re: HTTP/3 is everywhere but nowhere

#394

Post by kortilla » Tue, Mar 18, 2025, 7:18 AM UTC

tsimionescu wrote: post #374

throwaway2037 wrote: post #359

Earlier quoted context omitted.

> results in hardcoding protocol details in application code Are you suggesting that this could have been implemented a different way? Example: IP could be negotiated to upgrade from v4 to v6? I am curious about your ideas.

I think in principle, an application didn't need to know the exact format of an IP address, even if connecting directly to an IP. A simple idea that could have made application code much more IP-agnostic would have been for SOCK_ADDR_IN to take the IP in string format, not as a four-byte value. That way, lots of application code would not need to even be recompiled to move from a 4 byte IPv4 address to a 16 byte IPv6…

Yeah, the big issue is that any code that took addresses from user input had to do validation to make sure addresses were valid, in allowed ranges, etc.

While the sockaddr struct allowed to to abstractly handle v4/v6 socket connections, there wasn’t a clean way to do all of that additional stuff and IP address logic leaked into all kinds of software where you wouldn’t first expect it.

Something as simple as a web app that needs to inspect proxy headers would even have it.

It also didn’t help that it became practice to explicitly not trust the addr resolution offered by the sockets API because it would do unexpected things like resolving something that looked like an integer to a uint32 and then a 4 byte V4 addr.

Re: HTTP/3 is everywhere but nowhere

#395

Post by charcircuit » Tue, Mar 18, 2025, 7:28 AM UTC

throwaway2037 wrote: post #359

p_l wrote: post #303

Earlier quoted context omitted.

Major reason for that is BSD Sockets and their leaky abstraction that results in hardcoding protocol details in application code. For a good decade a lot of software had to be slowly patched in every place that made a socket to add v6 support, and sometimes multiple times because getaddrinfo didn't reach everyone early enough.

> results in hardcoding protocol details in application code Are you suggesting that this could have been implemented a different way? Example: IP could be negotiated to upgrade from v4 to v6? I am curious about your ideas.

No, for example on Android and iOS the APIs for when you connect to a server the hostname is a string. This hostname can be either an ipv4 address, an ipv6 adress, or a domain. The BSD sockets API on the other hand forces each application to implement this themselves and a lot of them took the shortcut of only supporting ipv4.

It isn't about upgrading one protocol to another but about having the operating system abstract away the different protocols from the application.

Re: HTTP/3 is everywhere but nowhere

#396

Post by cyberax » Tue, Mar 18, 2025, 7:34 AM UTC

JoshTriplett wrote: post #381

frollogaston wrote: post #311

Earlier quoted context omitted.

The main problem wasn't all the smaller features but one big one in particular that can't be split into smaller pieces, the new addressing scheme. They wanted to replace all the existing addresses, which meant replacing all the routes. Besides the difficulty of that by itself, it automatically meant that the v6 versions of DNS, DHCP, NAT, etc wouldn't support v4, rather it'd be a totally separate stack. There were al…

> Besides the difficulty of that by itself, it automatically meant that the v6 versions of DNS, DHCP, NAT, etc wouldn't support v4, rather it'd be a totally separate stack. Sure, "make the addresses bigger" would have required providing DHCPv6, DNS AAAA records, and various other protocol updates for protocols that embedded IP addresses. And making changes to the protocol header at the same time (e.g. removing the re…

It didn't require removing ARP and inventing Neighbor Discovery that embeds the hardware addresses into the IP address.

It didn't require the Ruby Goldberg "on link" network mechanism.

It didn't require multicast instead of broadcasts for local network discovery.

It didn't require using DNS config (of all things) to specify V4/V6 priority.

It didn't require adding a "flow label" that is nobody to this day knows how to use properly.

The list of fails is ridiculous.

Re: HTTP/3 is everywhere but nowhere

#397

Post by skissane » Tue, Mar 18, 2025, 7:36 AM UTC

karel-3d wrote: post #387

djha-skin wrote: post #209

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

How is IPv6 mobile centric? It's from the 90s

The protocol isn’t but its deployment is - real-world deployment is predominantly mobile. That’s nothing to do with the inherent technical features of the protocol, it is a consequence of market history

Re: HTTP/3 is everywhere but nowhere

#398

Post by cyberax » Tue, Mar 18, 2025, 7:38 AM UTC

throwaway2037 wrote: post #359

p_l wrote: post #303

Earlier quoted context omitted.

Major reason for that is BSD Sockets and their leaky abstraction that results in hardcoding protocol details in application code. For a good decade a lot of software had to be slowly patched in every place that made a socket to add v6 support, and sometimes multiple times because getaddrinfo didn't reach everyone early enough.

> results in hardcoding protocol details in application code Are you suggesting that this could have been implemented a different way? Example: IP could be negotiated to upgrade from v4 to v6? I am curious about your ideas.

The simplest case would have been using a variant of Happy Eyeballs protocol.

Resolve the A and AAAA records, and try to connect to them at the same time. The first successful connection wins (maaaaybe with a slight bias for IPv6).

This would have required an API that uses the host name and folds the DNS resolution and connection into one call. Instead, the BSD socket API remained at the "network assembly" level with the `sockaddr_in/sockaddr_in6` structures used for address information.

Re: HTTP/3 is everywhere but nowhere

#399

Post by cyberax » Tue, Mar 18, 2025, 7:40 AM UTC

kstrauser wrote: post #328

einpoklum wrote: post #308

Earlier quoted context omitted.

> It removes tons of overhead and cruft Can you elaborate? Here, or with links? What kinds of overhead and cruft?

* The header is a fixed length. * You can't fragment packets. * The redundant checksum header was removed. * No more private addressing (unless you're a glutton for punishment). * No more NAT (see above). * Simpler routing. * Doesn't require DHCP. It benefits hugely from the lessons learned with IPv4.

> * No more private addressing (unless you're a glutton for punishment).

OK. So what happens if your ISP connection goes down? Your router will detect this and withdraw the ISP's prefix.

So now you can't print because your printer doesn't have an address. Good luck.

> * Doesn't require DHCP.

This turns out to be a problem, as you can't easily see what's going on in the network.

Re: HTTP/3 is everywhere but nowhere

#400

Post by oaiey » Tue, Mar 18, 2025, 7:48 AM UTC

throwaway2037 wrote: post #369

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

> sad that .NET and C# are not considered "major"... No need to be sad about that list. Java is also missing. There must be millions of enterprise programmers in the world using Java. I just checked the Java class HttpClient (a common JDK11+ HTTP client). It currently does not support HTTP/3, so add one more to the list! Ref: https://docs.oracle.com/en/java/javase/24/docs/api/java.net.... Also, most of the very best…

There is a very simple reason for not being on the list: It support HTTP/3 and the purpose of the post was to show the lack of support in common languages. .NET does not fit that list well.

And it is obviously only popular in the dark matter of Enterprise Software Development.