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

231–240 of 504 posts

Re: HTTP/3 is everywhere but nowhere

#231

Post by thayne »

shermantanktop wrote: post #84
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.

.NET suffers from the long lasting reputational taint of Microsoft. It was seen as the sworn enemy of open source and Linux, and for good reason. Today’s MS is not what it was back then. But long memories are not a bad thing, really. If .NET suffers a bit from some unfair perception, perhaps that can remind MS and others what happens when you take an aggressively adversarial approach.

More than just that it came from MS.

For a long time, .NET was completely proprietary, and only ran on Windows.

Now it is open source and cross platform, but it is still fighting the momentum of being seen as Windows-only.

Re: HTTP/3 is everywhere but nowhere

#232

Post by mananaysiempre »

wizzwizz4 wrote: post #193
IgorPartola wrote: post #191

Earlier quoted context omitted.

But it doesn’t allow you to multiplex that connection (HTTP pipelining is broken and usually disabled). So depending on the app setup you could be losing quite a bit waiting on an API call while you could be loading a CSS file.

Your static and dynamic assets should be served from different domains anyway, to reduce the overhead of authentication headers / improve cache coherency. https://sstatic.net/ quotes a good explanation, apparently mirrored https://checkmyws.github.io/yslow-rules/ . (The original Yahoo Best Practices for Speeding Up Your Web Site article has been taken down.)

Why does saving on cookies outweigh having to go through an additional TCP slow start?

Re: HTTP/3 is everywhere but nowhere

#233

Post by TeMPOraL »

bheadmaster wrote: post #74
CharlieDigital wrote: post #61

Earlier quoted context omitted.

> Native AOT does not support cross-OS compilation > ...runtime-dependent and self-contained are fine This certainly reads like you moved the goal posts and recognized it.

Native AOT compilation is definitely not the same as self-contained package. With that logic, every Docker container could be considered AOT compiled static executable.

An image or a container could be, yes. It isn't, because Docker stuff is mostly distributed as Dockerfiles and docker-compose files, and those cause your system to download and install stuff, and that part is not like self-contained package.

Re: HTTP/3 is everywhere but nowhere

#234

Post by Varriount »

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…

I really have to agree with the "easier to debug" part. I one time had to debug a particularly nasty networking issue that was causing HTTP connections to just "stop" midway through sending data. Turned out to be a confusion mismatch between routers and allowed packet sizes. It would have been so much worse with a non-plaintext protocol.

Re: HTTP/3 is everywhere but nowhere

#235

Post by johnisgood »

ycombinatrix wrote: post #227
neonsunset wrote: post #210

Earlier quoted context omitted.

This link again? I'm baffled by insistent behavior like this. I think it is just alienating people and even if they move ecosystems, the negative impression will stay. If you engage in bad faith behavior in a technical discussion, can you be expected to conduct yourself acceptably in a professional setting? Unlikely. This is a discussion about HTTP/3 support of all things. Why does it happen only when someone leaves…

First time I've seen that link. What's bad faith about it? Don't know why you're bringing Rust into this.

Parent comment was edited, it no longer seems to include "Rust", difficult to follow. :P

Re: HTTP/3 is everywhere but nowhere

#236

Post by croes »

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.

And then the web app eats all that saved ms with ease.

Re: HTTP/3 is everywhere but nowhere

#237

Post by croes »

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.

So with HTTP/3 it’s just 9.9 sec

Re: HTTP/3 is everywhere but nowhere

#238

Post by xendo »

jsheard wrote: post #9

It's pretty glaring that nginx still doesn't have production-ready HTTP3 support despite being a semi-commercial product backed by a multi billion dollar corporation. F5 is asleep at the wheel.

Are there any viable nginx alternatives that support HTTP3 and are mature for prod workflows?

Re: HTTP/3 is everywhere but nowhere

#239

Post by neonsunset »

johnisgood wrote: post #235
ycombinatrix wrote: post #227

Earlier quoted context omitted.

First time I've seen that link. What's bad faith about it? Don't know why you're bringing Rust into this.

Parent comment was edited, it no longer seems to include "Rust", difficult to follow. :P

I edited it because it's not just my own experience of dealing with this. On twitter, I follow a couple Japanese developers from mainly gamedev scene and even they complain they started hearing more about "but it only works on windows" and "it's not open-source". Don't you find it strange that it should be the other way around the more years pass since .NET went OSS?

The link itself is also quite outdated and mainly consists of posts from Miguel de Icaza who's promoting Swift, arguably less OSS language. Take from that what you will.

Re: HTTP/3 is everywhere but nowhere

#240

Post by cogman10 »

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…

Totally agree. Most of the benefit of HTTP 2/3 comes from minimizing TCP connections between app->lb. Once you are past the lb the benefits are dubious at best.

Most application frameworks that I've dealt with have limited capabilities to handle concurrent requests, so it becomes a minor issue to have 100+ connections between the app and the lb.

On the flipside, apps talking to the LB can create all sorts of headaches if they have even modest sized pools. 20 TCP connections from 100 different apps and you are already looking at hard to handle TCP flooding.

Post reply on HN