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

361–370 of 504 posts

Re: HTTP/3 is everywhere but nowhere

#361

Post by motorest »

kstrauser wrote: post #301
frollogaston wrote: post #275

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

"It's not being used", except for nearly half of Google's traffic: https://www.google.com/intl/en/ipv6/statistics.html Disconnect your phone from Wi-Fi and visit https://ifconfig.co/ . If you're a Verizon customer, it's probably going to show you an IPv6 address. It's huge, right now, today.

> "It's not being used", except for nearly half of Google's traffic:

One of the world's largest ISPs, Vodafone, is yet to support IPv6.

What Google supports is irrelevant if your ISP can't handle the traffic.

Re: HTTP/3 is everywhere but nowhere

#362

Post by aboardRat4 »

zlagen wrote: post #148

shouldn't QUIC be supported at the operating system level similar to TCP? that way it could get adopted much easily in different languages

Not really. The whole point of quic is that it is built on top of plain old stupid udp, so it does _not_ require any OS level cooperation. The raison d etre of quic was to get rid of interacting with OS developers, convincing them, and patching some old ecomstations, and just "do what we want" in the process level.

Re: HTTP/3 is everywhere but nowhere

#363

Post by frollogaston »

kstrauser wrote: post #344
frollogaston wrote: post #305

Earlier quoted context omitted.

All that code using BSD sockets is rewritten by now to support v6, right? If so, that can't be the reason, cause v4 is still dominant. And btw, what I suggested would actually work without userspace code changes until you want to start subdividing the /32s. Cause v4 addresses would've still been valid in v6.

Where would you store the other 96 bits. In the body?

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 longer addresses like 1.1.1.1.2.

Re: HTTP/3 is everywhere but nowhere

#364

Post by realusername »

mlhpdx wrote: post #177
briandear wrote: post #134

Earlier quoted context omitted.

.NET ain’t hip because many of the shops that use it are dinosaurs in processes and culture.

And many are not. How many Python shops are living in the past? It’s the same problem everywhere.

I'd like this to be a lie but it's true, different languages have different cultures associated to them.

Re: HTTP/3 is everywhere but nowhere

#365

Post by aboardRat4 »

xxs wrote: post #70
llm_nerd wrote: post #64

Earlier quoted context omitted.

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…

>with 5% packet loss This is absolutely massive

I live in a third world country, and here we consider 5% to be VERY good.

Most if my servers have about 40-50% packet loss.

50% is just a half. So we naturally expect our 3000gbit links to turn into 1gbit links, but that's not how tcp works.

Re: HTTP/3 is everywhere but nowhere

#367

Post by hamandcheese »

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.

There isn't much need for many applications to know or care what IP protocol they are speaking, they are all just writing bytes to a TCP stream. I think the parent is saying that existing socket abstractions meant that these applications still had to be "upgraded" to support IPv6 whereas it could/should have been handled entirely by the OS with better socket APIs.

Re: HTTP/3 is everywhere but nowhere

#368

Post by antisthenes »

ezfe wrote: post #342
antisthenes wrote: post #207

Earlier quoted context omitted.

It takes a very special case of a person to complain about a feature-complete piece of software not evolving fast enough.

But it's not feature complete if it can't make modern networking requests when the whole point of a library like requests is to make networking requests.

If you can get the content of a web page using requests, then it works just fine.

Re: HTTP/3 is everywhere but nowhere

#369

Post by throwaway2037 »

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 network clients are now built on top of NettyIO. I can see an "incubator codec" here: https://github.com/netty/netty-incubator-codec-http3

Holy hell, this code is ridiculously complex: https://github.com/netty/netty-incubator-codec-http3/tree/ma...

I'm not hating on NettyIO here, but the protocol looks complex. Yet another reason why it is so slow to be deployed to more application frameworks.

Re: HTTP/3 is everywhere but nowhere

#370

Post by frollogaston »

gruez wrote: post #341
kstrauser wrote: post #324

Earlier quoted context omitted.

Fair. I bet that'll change soon though. My prediction is that it'll be a mobile-first game, like the next Pokemon Go sort of thing, that'll be IPv6-only.

Plenty of mobile users use wifi at home/work. Telling them to disable their ipv4-only wifi just to play your game is going to be a non-starter, especially when the cost of ipv4 address adds negligible cost to infrastructure. Is your CTO really going to massively increase user friction ("turn of your wifi to play!") just so try to save a few cents (comparatively speaking) on infra?

It could be in a country where people don't have home wifi.
Post reply on HN