Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

HTTP/3 is everywhere but nowhere

httptoolkit.com

Post reply on HN
Print view View original

381–390 of 504 posts

Re: HTTP/3 is everywhere but nowhere

#381

Post by JoshTriplett »

frollogaston wrote: post #311
JoshTriplett wrote: post #296

Earlier quoted context omitted.

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

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 redundant checksum) were also a good idea.

It didn't require pushing SLAAC instead of DHCP.

It didn't require recommending (though fortunately not requiring) IPsec for all IPv6 stacks.

It didn't require changing the address syntax to use colons, causing pain for all protocols that used `IP:port` or similar.

It didn't require mandating link-local addresses for every interface.

It didn't require adding a mandatory address-collision-detection mechanism.

And I'm sure I'm forgetting a few.

Re: HTTP/3 is everywhere but nowhere

#382

Post by tsimionescu »

urban_alien wrote: post #226
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…

Ok, HTTP/3 is mobile centric. But why not fallback to HTTP/2 in all other cases?

HTTP/2 is still mostly implemented only over TLS, and that can mean significant and completely useless overhead if the server-LB connection is already encrypted using some VPN solution like WireGuard.

Re: HTTP/3 is everywhere but nowhere

#383

Post by kelseydh »

hu3 wrote: post #252
nolist_policy wrote: post #114

Earlier quoted context omitted.

I would say that .NET is the best example that Microsoft has not changed: https://isdotnetopen.com/

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.

They are criticising Microsoft closing access to .NET debugging tools: https://www.theverge.com/2021/10/22/22740701/microsoft-dotne...

Re: HTTP/3 is everywhere but nowhere

#385

Post by shmerl »

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 not suitable?

Re: HTTP/3 is everywhere but nowhere

#386

Post by eklitzke »

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…

This is vastly oversimplifying the problem, the difference between IPv4 and IPv6 is not just the format of the address. Different protocols have different features, which is why the sockaddr_in and sockaddr_in6 types don't just differ in the address field. Plus the vast majority of network programs are using higher level abstractions, for example even in C or C++ a lot of people would be using a network library like libevent or asio to handle a lot of these details (especially if you want to write code that easily works with TLS).

Re: HTTP/3 is everywhere but nowhere

#387

Post by karel-3d »

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

Re: HTTP/3 is everywhere but nowhere

#388

Post by lmm »

hypeatei wrote: post #24
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],…

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

It's not Windows only but it is Windows-first. Every few years I take a look but it still doesn't feel like a serious ecosystem for Linux development (in the same way that e.g. Perl might have a Windows release, but it doesn't feel really first-class). I can't think of a single .NET/C# program that people would typically run on Linux to even have the runtime installed, so no wonder people don't bother investigating the languages.

Re: HTTP/3 is everywhere but nowhere

#389

Post by karel-3d »

jauntywundrkind wrote: post #141

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…

I think the issue is the complexity? It pushes a lot of logic into userspace.

Re: HTTP/3 is everywhere but nowhere

#390

Post by lmm »

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…

I don't think many people use the builtin HttpClient these days. Apache httpclient would be the conservative standard, apparentyl it has some support for 2 but not 3: https://hc.apache.org/httpcomponents-client-5.4.x/index.html .
Post reply on HN