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

141–150 of 504 posts

Re: HTTP/3 is everywhere but nowhere

#141

Post by jauntywundrkind »

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 work has been done for Node & there's just no straightforward path forwards.

https://github.com/nodejs/node/issues/57281

Re: HTTP/3 is everywhere but nowhere

#142

Post by TheRealPomax »

celsoazevedo wrote: post #116
TheRealPomax wrote: post #101

Earlier quoted context omitted.

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…

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 essentially all internet traffic these days is handled by large scale machine systems, that's a perfectly sufficient reason for adoption.

Re: HTTP/3 is everywhere but nowhere

#143

Post by motorest »

lemagedurage wrote: post #71
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" 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.

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

Re: HTTP/3 is everywhere but nowhere

#144

Post by dismalaf »

victor106 wrote: post #27
hypeatei wrote: post #24

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.

Can .net produce cross platform libraries/executables like Go does? With Go I can develop on Mac and create executables for windows and Linux

Mono's been on Linux for like 20 years, maybe longer... C# is like Java, can run basically anywhere.

Re: HTTP/3 is everywhere but nowhere

#145

Post by pimterry »

dangoodmanUT wrote: post #123

It's been proven many times that in well-connected networks (e.g. datacenters) H2 is faster, often because all of the things that H3 improves on is now handled in the user context, which negates the overhead. The benefits only show in poorly connected networks (public internet), so that's pretty exclusively where it should be used - anything internet-facing.

Perhaps, but:

There's ongoing work exploring QUIC-in-kernel-space at https://github.com/lxin/quic, and more generally HTTP/3 will be increasingly optimized over time as it moves towards becoming the majority of HTTP traffic (a few years off, but looks likely eventually). There's no fundamental reason I'm aware of that HTTP/3 would be _inevitably_ slower than HTTP/2, it seems likely for now that it's largely implementation details.

There's plenty of internet-facing cases with average-at-best connectivity where HTTP/3 would be beneficial today, and isn't available (non-megacorp Android apps, CLI tools, IoT, desktop apps, etc). Even on the backend, it's very common to have connections between datacenters with significant latency (e.g. distributed CDN to central application server/database).

Re: HTTP/3 is everywhere but nowhere

#146

Post by upofadown »

The article talks about the advantages of HTTP/3 for IoT applications. I recently did an IoT application (weather station) where I actually ended up using HTTP/1.0. I only had to send a total of around 70 bytes every two minutes. If at the end of that two minutes I had an invalid or missing response there was nothing more to do other than record the result for a possible future reset. Once there was new data available the old data was irrelevant.

So I don't see how HTTP/3 would of helped there. Most IoT applications are not very sensitive to things like latency and what counts as reliability is very much dependent on the situation. A simple protocol is an advantage.

Re: HTTP/3 is everywhere but nowhere

#147

Post by mixmastamyk »

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.

Re: HTTP/3 is everywhere but nowhere

#149

Post by strongpigeon »

Svoka wrote: post #125
CharlieDigital wrote: post #109

Earlier quoted context omitted.

The ironic thing? GitHub, VS Code, and TypeScript are all Microsoft products.

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

VS code is mostly in house too. Sure, they don’t own Electron, but I was at MSFT when project Monaco (which became the basis for VS Code) was started and remember being very impressed by it back then

Re: HTTP/3 is everywhere but nowhere

#150

Post by grayhatter »

> And Fastly shared the major improvements in time-to-first-byte they're seeing in the real world:

What's time until last byte though?

Yeah, The metric that got you promoted is cool and all, but if my application works on files atomically, it's the time until last byte that has meaning to me.

I'm also gonna assume a bit more, and say it's also the byte where the service can start processing someone else's connection. So if http/3 increases the load on servers, with their CPU, instead of network hardware, with their ASIC, this would be a net loss as soon as you look at amount of complete requests per energy used. Instead of just looking at single session metrics.

I guess I should probably read the HTTP/3 spec now...

Post reply on HN