Live data from Hacker News

HTTP/3 is everywhere but nowhere

httptoolkit.com

411–420 of 504 posts

Re: HTTP/3 is everywhere but nowhere

#411

Earlier quoted context omitted.

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.

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.

I wonder if something like HTTP connection upgrade would have been possible with ipv6-ipv4, maybe something like imagine Machine 1 with ips 1.1.1.1 and 11::11 and machine 2 with ips 2.2.2.2 and 22::22.

When machine 2 receives a packet from 1.1.1.1 at 2.2.2.2 it sends a ipv6 ping-like packet to the ipv4-mapped address ::ffff:1.1.1.1 saying something like "hey you can also contact me at 22::22 and if machine 1 undertands then it can try to use the new address for the following packets.

I can see how it would be hard to secure this operation.

Re: HTTP/3 is everywhere but nowhere

#412
post #153

Earlier quoted context omitted.

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)

Surely most hardware / software that has had no support for IPv6 has been mostly phased out by now?

Not even Android has proper IPv6 support.

You cannot manually set an IPv6 address or gateway for a WiFi, it's forced DHCP only. All of this works for IPv4.

Re: HTTP/3 is everywhere but nowhere

#413

Earlier quoted context omitted.

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

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

Have you given C# a new try with Cursor and newer models?

There's a huge difference from Copilot in 2023, if that was your example.

Also, interesting you feel more productive on a language you don't even like than your "main" one.

Re: HTTP/3 is everywhere but nowhere

#414

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

HTTP3 is patch that unfucked some stupid design choices from HTTP2[1]

However IPv6 is perfectly suited to the datacentre. So long as you have properly infrastructure setup (ie properly functioning DNS) IPv6 is a godsend for simplifying medium scale infra.

In fact, if you want to get close to a million hosts, you need ipv6.

[1] Me and http/2 have beef, TCP multiplexing was always going to be a bad idea, but because idealism got in the way of testing

Re: HTTP/3 is everywhere but nowhere

#415
post #400

Earlier quoted context omitted.

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

C# is much closer in popularity to TypeScript/Python (the number 1s) than it is to Rust.

Re: HTTP/3 is everywhere but nowhere

#416

Earlier quoted context omitted.

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.

Isn't 5G supposed to solve the mobile latency issue?

> Isn't 5G supposed to solve the mobile latency issue?

Kinda.

So 5g is faster, but its still wireless, and shared spectrum. This means that the more people that use it, or the further they are away, the speed and bandwidth per client is adjusted.

(I'm not sure of the coding scheme for 5G, so take this with caution) For mobiles that are further away, or have a higher noise floor, the symbol rate (ie the number of radiowave "bits" that are being sent) is reduced so that there is a high chance they will be understood at the other end (Shannon's law, or something) Like in wifi, as the signal gets weaker, the headline connection speed drops from 100mb+ to 11.

In wifi, that tends to degrade the whole AP's performance, in 5G I'm not sure.

Either way, a bad connection will give you dropped packets.

Re: HTTP/3 is everywhere but nowhere

#417
post #151

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…

I think its more that HTTP/3 only really gives marginal gains for most people.

Just as python3 had almost nothing for programmer over python2, apart from print needing brackets. Sure it was technically better, and allowed for future gains, but in practice, for the end user, there was no real reason to adopt it.

For devs outside of FAANG, there is no real reason to learn how to setup and implement http3

Re: HTTP/3 is everywhere but nowhere

#418
post #342

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.

> whole point of a library like requests is to make networking requests.

The whole point of requests is to make HTTP requests easy. HTTPLib was/is an arse to use.

as HTTP3 is really not that widely adopted, and where it is, has fallbacks to 1.1 whats the point?

Plus the people who are keen on HTTP3 also seem to be keen on async, https://github.com/aiortc/aioquic/tree/main/examples which even though it isn't seems to be overly complex and difficult to use. Contrast that to r.get(url)....

Re: HTTP/3 is everywhere but nowhere

#419

Earlier quoted context omitted.

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…

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.

I would like you to explain specifically and concretely why you need this, without using any broad abstract ideas like "bots" or "fraud".

For example: "We were receiving 1000 spam and 100 legitimate comments per day even though we used hCaptcha on the comment form. When we disabled HTTP 1.1 on the comment endpoint, the spam stopped entirely, and we still received 95 legitimate comments per day." (in this scenario, I don't think it's necessary to further elaborate what counts as a "spam comment" if it's the usual type. If it's not the usual type then you will have to elaborate it.)

Re: HTTP/3 is everywhere but nowhere

#420

Earlier quoted context omitted.

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.

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…

> But it makes no overall difference to individual humans who are loading a web page or web app.

Navigating from my phone at 4g and my fiber connection has drastic differences.

Especially noticeable when on vacations or places with poor connections, TLS handshakes can take many, many, many, seconds..After the handshake and an established connection it's very different.

Post reply on HN