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

181–190 of 504 posts

Re: HTTP/3 is everywhere but nowhere

#181

Post by wizzwizz4 »

IgorPartola wrote: post #170
motorest wrote: post #143

Earlier quoted context omitted.

> A "few extra ms" is up to 3 roundtrips difference, that's easily noticeable by humans on cellular. That's a valid concern. That's the baseline already though, so everyone is already living with that without much in the way of a concern. It's a nice-to-have. The problem OP presents is what are the tradeoffs for that nice-to-have. Is security holes an acceptable tradeoff?

I routinely have concerns about lag on mobile. It sucks to have to wait for 10 seconds for a basic app to load. And that adds up over the many many users any given app or website has.

The problem with that is unlikely to be making HTTP connections. HTTP/1.1 already allows connections to be re-used.

Re: HTTP/3 is everywhere but nowhere

#183

Post by nine_k »

the8472 wrote: post #178
nine_k wrote: post #131

Earlier quoted context omitted.

The connection to your local tower can have a negligible latency. The connection all the way to the datacenter may take longer. Then, there is congestion sometimes, e.g. around large gatherings of people; it manifests as latency, too.

But from the tower onward it shouldn't be any different from fixed internet connections, except for the gatherings, I'll grant that one. So then (modern) mobile shouldn't be all that special.

At a previous job I had to specifically accommodate the backend API design to slow, large-latency 3G links which much of our East Asian audience had at the time. South Korea is one thing, Malaysia, quite another.

Re: HTTP/3 is everywhere but nowhere

#184

Post by JimDabell »

mixmastamyk wrote: post #147
JimDabell wrote: post #26

I’ve been using niquests with Python. It supports HTTP/3 and a bunch of other goodies. The Python ecosystem has been kind of stuck on the requests package due to inertia, but that library is basically dead now. I’d encourage Python developers to give niquests a try. You can use it as a drop-in replacement for requests then switch to the better async API when you need to. https://niquests.readthedocs.io/en/latest/ Tra…

requests dead? The reason given for not including it in the stdlib was so it could evolve more rapidly. Back then the protocol layer was handled/improved by urllib3.

It’s not evolving at all:

> Requests is in a perpetual feature freeze, only the BDFL can add or approve of new features. The maintainers believe that Requests is a feature-complete piece of software at this time.

> One of the most important skills to have while maintaining a largely-used open source project is learning the ability to say “no” to suggested changes, while keeping an open ear and mind.

> If you believe there is a feature missing, feel free to raise a feature request, but please do be aware that the overwhelming likelihood is that your feature request will not be accepted.

— https://requests.readthedocs.io/en/latest/dev/contributing/#...

Re: HTTP/3 is everywhere but nowhere

#185

Post by LinuxBender »

LinuxBender wrote: post #89
pas wrote: post #87

Earlier quoted context omitted.

https://nginx.org/en/CHANGES acquisition finished in 2019 there are quite a lot of features, but it's hard to say what constitutes a new module. (well, there's "Feature: the ngx_stream_set_module." so maybe yes?)

One would probably have to go through git logs [1] so I guess I should do that after getting some food in the belly to answer my own question. It's a big log. Interesting side note, appears all commits from Maxim stopped in January 2024. Must be all F5 now. [1] - https://github.com/nginx/nginx

16 commits from F5 from 2020 to 2025, nothing before that. Looks like they are bugfixes and enhancements. Perhaps someone else created the ngx_stream_set_module module prior to the acquisition.

Re: HTTP/3 is everywhere but nowhere

#186

Post by nine_k »

pas wrote: post #158
nine_k wrote: post #104

Earlier quoted context omitted.

What good is your IPv6, Mr Anderson, if your upstream provider and/or middleboxes along the way do not support it?

I'm happy to report that - to my utter amazement - my ISP's on-prem device does /64 prefix delegation to each (DHCPv6?) client.

Yes, right now every large provider does that, which is great. That was not the case when the first p2p networks were growing big (Napster, Gnutella, that kind of thing).

Re: HTTP/3 is everywhere but nowhere

#187

Post by LinuxBender »

FeistySkink wrote: post #119
LinuxBender wrote: post #89

Earlier quoted context omitted.

One would probably have to go through git logs [1] so I guess I should do that after getting some food in the belly to answer my own question. It's a big log. Interesting side note, appears all commits from Maxim stopped in January 2024. Must be all F5 now. [1] - https://github.com/nginx/nginx

Here's some background: https://arstechnica.com/information-technology/2024/02/nginx...

Ah yes, I vaguely recall the drama. Thankyou.

Re: HTTP/3 is everywhere but nowhere

#188

Post by kelnos »

ralferoo wrote: post #47

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

> a few extra ms of latency on a request

That's not what it is, though. The graph embedded in the article shows HTTP/3 delivering content 1.5x-2x faster than HTTP/2, with differences in the hundreds of ms.

Sure, that's not latency, but consider that HTTP/3 can do fewer round-trips. RTs are often what kill you.

Whether or not this is a good trade off for the negatives you mention is still arguable, but you seem to be unfairly minimizing HTTP/3's benefits.

Re: HTTP/3 is everywhere but nowhere

#189

Post by celsoazevedo »

TheRealPomax wrote: post #142
celsoazevedo wrote: post #116

Earlier quoted context omitted.

Almost every optimization is irrelevant if we apply the same reasoning to everything. Add all savings together and it does make a difference to real people using the web in the real world.

What a bizarre thing to say: not every optimization is imperceptable by humans (jpg, gzip, brotli, JS and CSS payload bundling and minification, etc. etc.) and not all sums of optimizations add up to "something significant in terms of human perception". HTTP/3 is a good optimization, and you can't sell it based on "it improves things for humans" because it doesn't. It improves things for machines, and given that esse…

For a long time all my internet connections were bad (slow, unstable or both). Compressing HTML/CSS/JS, avoiding JS unless absolutely needed, being careful with image sizes and formats, etc, helped a lot... so I guess this makes me biased.

Today I have fibre at home, but mobile networks are still patchy. I'm talking sub 1Mbps and high ping/jitter sometimes. So you can see why I think an "irrelevant" optimisation that removes 300ms from a page reload, no compression vs brotli/zstd, jpg vs avif, etc, are important for me, a human.

It's important to keep in mind that many users out there don't have a fast and low latency connections, at least not all the time. What takes 300ms to complete on our fast machine and fast WiFi at the office might take 1s on someone else's device and connection. It's harder to understand this if we only use fast connections/hardware though.

Re: HTTP/3 is everywhere but nowhere

#190

Post by hnlmorg »

CharlieDigital wrote: post #130
Svoka wrote: post #125

Earlier quoted context omitted.

Only Typescript is in-house. Others are acquisitions. Do you remember Embrace, extend, and extinguish times? https://en.wikipedia.org/wiki/Embrace,_extend,_and_extinguis...

Does the distinction matter?

In the case of GitHub, yeah. I don’t think a Microsoft source control “social network” would have taken off in the same way GitHub did.

In fact when Microsoft purchased GitHub, quite a few people did leave and close their account. But GitHub already had such a monumental market lead that the departures ended up being a drop in the ocean.

To be honest, I’m still waiting for the moment when Microsoft managed to fuck it all up like they did with Skype.

Post reply on HN