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

151–160 of 504 posts

Re: HTTP/3 is everywhere but nowhere

#151

Post by xg15 »

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 "plaintext HTTP 1.1 only" world, because those are the abstractions that browser APIs and application servers still maintain. All the crazy stuff in between - encryption, CDNs, changing network protocols - are just as abstracted away as the different hops of an IP packet and might just as well not exist from the application perspective.

Re: HTTP/3 is everywhere but nowhere

#153

Post by pas »

giancarlostoro wrote: post #40

Reminds me of IPv6... When I was 17... (2007) and learned about it I was very hyped to see it become mainstream.. I still don't know why we go out of our way to only use IPv4 to this day. Its even older than when I discovered what IPv6 was.

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)

Re: HTTP/3 is everywhere but nowhere

#154

Post by nly »

progval wrote: post #124
nly wrote: post #49

Earlier quoted context omitted.

Exactly this. You don't want multiple versions of cURL loaded in to your process dynamically. You need to be in control of the final link if you're shipping a .a to other teams

That doesn't work if other teams want to apply their own cURL patches, or update as soon as upstream publishes new security fixes without waiting for you.

That's the point. We don't do that. You link to the system libcurl dynamically and everyone is told to do the same.

If you want to use a private curl as an implementation detail then the only safe way to do it is to ship a .so, make sure all the symbols are private and that symbol interposition is switched off.

If you ship a .a then the final link can always make symbols public again.

Re: HTTP/3 is everywhere but nowhere

#155

Post by CharlieDigital »

briandear wrote: post #138
CharlieDigital wrote: post #91

Earlier quoted context omitted.

You have to have some metrics from somewhere to be able to understand which languages are being used. SO is one data point, but there are certainly others.

GitHub is probably a better source. SO is self selecting for people asking questions about something, not actually using it. A “harder” thing might have more SO questions, so it isn’t representative of actual usage.

I posted above, but you can also see:

You get the same result from scraping job postings: https://www.devjobsscanner.com/blog/top-8-most-demanded-prog...

    1. JS/TS (note these two are collapsed)
    2. Python
    3. Java
    4. C#
Two datapoints, completely discrete, same result.

Re: HTTP/3 is everywhere but nowhere

#156

Post by charleslmunger »

TheRealPomax wrote: post #101
lemagedurage wrote: post #71

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…

Deploying QUIC led to substantial p95 and p99 latency improvements when I did it (admittedly a long time ago) in some widely used mobile apps. At first we had to correct our analysis for connection success rate because so many previously failing connections now succeeded slowly.

It's a material benefit over networks with packet loss and/or high latency. An individual human trying to accomplish something in an elevator, parking garage, or crowded venue will care about a connection being faster with a greater likelihood of success.

Re: HTTP/3 is everywhere but nowhere

#158

Post by pas »

nine_k wrote: post #104
pas wrote: post #98

Earlier quoted context omitted.

wanting p2p to work (without quixotic NAT hole-punching) is puristry?

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.

Re: HTTP/3 is everywhere but nowhere

#159

Post by dadrian »

lemagedurage wrote: post #76
dadrian wrote: post #50

It's not clear to me that HTTP/3 is relevant to anyone who isn't already using it. It's most useful for large-scale hosting providers and video. And these people have already adopted it, and don't necessarily use out-of-the-box web servers for their infrastructure.

Small websites gain from reducing roundtrips on connection too. Fast websites are nice

HTTP/2 already reduces roundtrips.

Re: HTTP/3 is everywhere but nowhere

#160

Post by mixmastamyk »

pas wrote: post #98
elcritch wrote: post #19

Earlier quoted context omitted.

IPv6 always seemed to me to be driven by a certain class of purist networking geeks. Then some corporations started getting on board like you said, but many couldn't care less.

wanting p2p to work (without quixotic NAT hole-punching) is puristry?

It already works. Sometimes the cure is worse than the disease.
Post reply on HN