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

481–490 of 504 posts

Re: HTTP/3 is everywhere but nowhere

#481

Post by djha-skin »

kstrauser wrote: post #328
einpoklum wrote: post #308

Earlier quoted context omitted.

> It removes tons of overhead and cruft Can you elaborate? Here, or with links? What kinds of overhead and cruft?

* The header is a fixed length. * You can't fragment packets. * The redundant checksum header was removed. * No more private addressing (unless you're a glutton for punishment). * No more NAT (see above). * Simpler routing. * Doesn't require DHCP. It benefits hugely from the lessons learned with IPv4.

* First three points matter more on bad connections, but are less of a problem on good ones.

* Private addressing is a feature, not a bug, in the datacenter.

* NAT is a feature, not a bug, in the datacenter.

* Simpler routing matters more on bad connections, but is less of a problem on good ones.

* DHCP is a feature, not a bug, in the datacenter.

Overall, it adds features that I don't need in my datacenter, and takes away others that I do and now need to add back. Like I said: it's great outside the datacenter, not so great inside it.

Re: HTTP/3 is everywhere but nowhere

#482

Post by djha-skin »

raggi wrote: post #299
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…

HTTP/3 is not a mobile centric technology. Yes there was a lot of discussion of packet pacing and it's implications for mobile in early presentations on QUIC but that's not the same as "centric", that's one application of the behavior. Improved congestion control, reduced control plane cost and removal of head of line blocking behaviors have significant value in data center networks as well. How often do you work wit…

I will acknowledge that truly massive datacenter deployments can and do use these technologies to good effect, but I haven't worked at any of these kinds of places in the last fifteen years and I suspect many (most?) of my colleagues haven't either. Anything smaller than a /8, they usually don't add much and just get in the way more often than not.

Re: HTTP/3 is everywhere but nowhere

#483

Post by djha-skin »

jiggawatts wrote: post #339
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…

> pass back HTTP 1.1 ... to the backing service. Sure, but now you've lost some of the benefits of HTTP/3, such as the header compression and less head-of-line blocking. To some degree the load balancer can solve this by using multiple parallel HTTP 1.1 streams, but in practice I've seen pretty bad results in many common scenarios.

No one cares about those "benefits" _on a gigabit line_. The head of your line is not blocked at such speeds, believe you me. Same thing with compression. Like, why. Other than to make it harder to debug?

Re: HTTP/3 is everywhere but nowhere

#484

Post by jiggawatts »

djha-skin wrote: post #483
jiggawatts wrote: post #339

Earlier quoted context omitted.

> pass back HTTP 1.1 ... to the backing service. Sure, but now you've lost some of the benefits of HTTP/3, such as the header compression and less head-of-line blocking. To some degree the load balancer can solve this by using multiple parallel HTTP 1.1 streams, but in practice I've seen pretty bad results in many common scenarios.

No one cares about those "benefits" _on a gigabit line_. The head of your line is not blocked at such speeds, believe you me. Same thing with compression. Like, why. Other than to make it harder to debug?

I had head-of-line-blocking issues recently on a 10 Gbps data centre link!

HTTP client packages often use a small, fixed number of connections per domain. So if you have two servers talking to each other and there's slow requests mixed in with short RPCs, the latter can sit in a queue for tens of seconds.

Re: HTTP/3 is everywhere but nowhere

#485

Post by motorest »

kstrauser wrote: post #438
motorest wrote: post #361

Earlier quoted context omitted.

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

True, but irrelevant to my point. Whether a particular ISP supports doesn’t matter: it is being widely used by the rest of the world, to the point that it’s half of Google’s traffic.

> True, but irrelevant to my point.

Vodafone's network is reported to handle around 20% of the world's traffic. It's not a random ISP. It's network does not support IPv6. It is how a big chunk of all internet users experience the internet. Claiming it doesn't matter in a discussion over IPv6 adoption rate is ludicrous.

Re: HTTP/3 is everywhere but nowhere

#486

Post by LtWorf »

neonsunset wrote: post #474
LtWorf wrote: post #466

Earlier quoted context omitted.

> Took you long enough. Yeah I do have a life. I advice you to get one as well. > Launching a new process can be as easy as `Process.Start(path, args);`. -_-' Same exact problem. Letting every single process do their own escaping of the arguments. A proper portable API would have an array of strings for the arguments, to map execve(). That's how on windows every program does its own escaping and there's lots of progr…

Look, it is very difficult to hold a conversation with someone who responds with "you're just a fanboy, it's 5!" to "2 + 2 equals 4". On the off chance you are making an intentionally inflammatory reply - you could also ask normally. Let me try one last time (and now I vaguely remember having similar conversation here before). On Ubuntu: sudo apt install dotnet9 On RHEL (8 or 9): sudo dnf install dotnet-sdk-9.0 On Al…

All these words and you lost the original part where the APIs are windows oriented?

Re: HTTP/3 is everywhere but nowhere

#487

Post by johnisgood »

CharlieDigital wrote: post #280
johnisgood wrote: post #243

Earlier quoted context omitted.

I assumed .NET is Windows-only and proprietary, too, but it has to do with me not having done enough research, so if it is not the case anymore, the blame is on me.

Hey, I just want to commend you for amending your perspective (even if a little). There's a lot of intellectual hoop jumping in this thread with respect to Microsoft.

One has to know what they don't know, or at least consider the possibility that they might not know the whole story. I did not know the whole story, but I do now, thanks to earlier comments with regarding to .NET!

Re: HTTP/3 is everywhere but nowhere

#488

Post by wizzwizz4 »

mananaysiempre wrote: post #449
wizzwizz4 wrote: post #434

Earlier quoted context omitted.

Consider HTTP semantics. If there are cookies in the request, and those cookies change, it has to be re-requested every time. If there are no cookies, the request can remain semantically compatible, so the browser's internal caching proxy can just return the cached version. There are other advantages: the article elaborates.

Per the official HTTP semantics[1,2], what you say is not true: the only header that’s (effectively) always part of Vary is Authorization, the rest are at the origin server’s discretion; so don’t set Vary: Cookie on responses corresponding to static assets and you’re golden. The article only says that some (all?) browsers will disregard this and count Cookie there as well. Even still, the question is, what’s worse: a…

Oh, would that anyone heeded the official HTTP semantics. (Web browsers barely let you make requests other than GET and POST! It's ridiculous.)

On a fast internet connection, the answer doesn't matter because the internet connection is fast. On a slow internet connection, cacheable requests are better.

Re: HTTP/3 is everywhere but nowhere

#489

Post by joshstrange »

nine_k wrote: post #183
the8472 wrote: post #178

Earlier quoted context omitted.

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.

Could you talk a little bit more about what changes you made on the back into accommodate that? That sounds interesting.

Re: HTTP/3 is everywhere but nowhere

#490

Post by joshstrange »

TeMPOraL wrote: post #244
waynesonfire wrote: post #197

Earlier quoted context omitted.

Google operates at such a scale that tiny increases of performances allows them to support a team of engineers and saves money on the bottom line. For example, Google hires 10 engineers, they deploy HTTP/3, it saves 0.5% cpu usage, Google saves a million dollars and covers the salary of the said 10 engineers. For the vast majority of society, the savings don't matter. Perhaps even deploying it is a net-negative with…

It absolutely matters. Machines are orders of magnitude faster than they were 20 years ago; most software isn't doing much more than software did 20 years ago. And no, collaborative editing isn't be-all, end-all, nor does it explain where all that performance is lost. Many optimizations have bad ROI because users' lives are an externality for the industry. It's Good and Professional to save some people-weeks in devel…

> Machines are orders of magnitude faster than they were 20 years ago; most software isn't doing much more than software did 20 years ago.

That seems like an absurd statement to the point I wonder if I’m missing something.

Post reply on HN