Hacker News Reader

Comment by ralferoo | Hacker News Reader

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.

Additionally, I'd posit that for most client applications, a few extra ms of latency on a request isn't really a big deal. Sure, I can imagine applications that might care, but I can't think of any applications I have (as a developer or as a user) where I'd trade to have more complexity on the networking layer for potentially saving a few ms per request, or more likely just on the first request.

View on HN

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 saved. But it makes no overall difference to individual humans who are loading a web page or web app.

There's a good argument to be made about wasting round trips and HTTP/3 adoption fixing that, but it's not grounded in the human experience, because the human experience isn't going to notice it and go "...did something change? everything feels so much faster now".

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.

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.

That was my point: 300ms sounds like a lot until, like me too, you're on a slow connection and those 300ms on the entire 10 second page load are utterly irrelevant. You were already expecting a several second load time, that 300ms is not something that even registers: the HTTP negotiation on a modern page is _not_ what you're noticing on a slow connection. You're noticing literally everything else taking forever instead.

3% speedup is still pretty good. (especially because with some of the awfulness, it's possible to get bottle-necked by multiple of these in which case it could be 6 or 9%)

omfg: YES! YES IT IS! But you won't notice it and so the argument that it improves the experience is nonsense because you as human WON'T NOTICE THOSE 3 OR EVEN 6%

It's good because it speeds up the overall response by a measurable degree, not because it makes the experience better. That only happens in conjunction with tons of other improvements, the big ones of which are completely unrelated to the protocol itself and are instead related to how the page is programmed.

How is everyone this bad are understanding that if someone claims A cannot be justified because of B, that does not mean that A cannot be justified. It's near-trivially justified in this case. This crowd really should know better.

In my experience almost every optimization is irrelevant for that exact reasoning.

Nearly all of my real world performance issues have come from a very small set of functionality running extremely poorly.

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 a ROI of decades. Or, the incentives can be misaligned leading to exploitation of personal information. For example, see chrome manifest v3.

It's okay to question whether we need it.

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 development, at the cost of burning people-centuries of your users' life in aggregate. And like with pollution, you usually can't pin the problem on anyone, as it's just a sum of great many parties each doing tiny damage.

>most software isn't doing much more than software did 20 years ago

This isn't exactly true, but some of the potential reasons are pretty bad. Software turning into an ad platform or otherwise spying on users has made numerous corporations wealthier than the gods at the expense of the user is probably one of the most common ones.

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

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.

> But it makes no overall difference to individual humans who are loading a web page or web app.

Navigating from my phone at 4g and my fiber connection has drastic differences.

Especially noticeable when on vacations or places with poor connections, TLS handshakes can take many, many, many, seconds..After the handshake and an established connection it's very different.

Isn't 5G supposed to solve the mobile latency issue?

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.

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

A lot of traffic still goes over 4G or even 3G in many countries. Most countries have only deployed 5G NSA (non-standalone) which means mobiles uses both 4G and 5G at the same time. Only a few networks in a few countries have deployed 5G SA (standalone) where mobiles use 5G only -- and even those few networks only deploy 5G SA in certain places e.g. selected CBDs. I live in the largest city in my country and I only get 4G still in my suburb and much of rest of my city is 5G NSA which means in most places phones stil use 4G for uplink and a mix of 4G and 5G for the downlink. Hence there is still a long way to go until most traffic (in both directions -- i.e. uplink AND downlink) is over 5G.

> Isn't 5G supposed to solve the mobile latency issue?

Kinda.

So 5g is faster, but its still wireless, and shared spectrum. This means that the more people that use it, or the further they are away, the speed and bandwidth per client is adjusted.

(I'm not sure of the coding scheme for 5G, so take this with caution) For mobiles that are further away, or have a higher noise floor, the symbol rate (ie the number of radiowave "bits" that are being sent) is reduced so that there is a high chance they will be understood at the other end (Shannon's law, or something) Like in wifi, as the signal gets weaker, the headline connection speed drops from 100mb+ to 11.

In wifi, that tends to degrade the whole AP's performance, in 5G I'm not sure.

Either way, a bad connection will give you dropped packets.

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

Most people still use Google, and so they're living the fast HTTP 3 life, switching off that to a slower protocol only when interacting with non-Google/Amazon/MSFT properties. If your product is a competitor, but slower/inaccessible users are going to bounce off your product and not even be able to tell you why.

Nonsense, most of the web is non Google, Amazon or MSFT. Much of the web apps already uses CDNs which will enable web3 and the browser will support it. Other parts like APIs will not benefit much it they hit the database/auth/etc. MSFT stuff is dead slow anyway, Amazon is out of date, Google is just ads (who uses their search anymore?)

> most of the web is non Google, Amazon or MSFT.

maybe you can point out where that's what I said

MSFT provides some of the slowest experiences I've had e.g. SharePoint, Teams, etc. Am laughing at the assumption that non-MSFT/etc properties are seen as slower when it is i fact MSFT that are the slowpokes. I haven't used Google much lately but they can be pretty poor too.

AWS are pretty good though. However it is notable I get good speeds and latency using S3 over HTTP/1.1 for backing up several hundreds gigs of data, so not sure if HTTP/3 makes any difference if it is already good enough without.

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.

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?

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 cacheable request that has to go through DNS and a slow-start stage because it’s to an unrelated domain, or a potentially(?) noncacheable one that can reuse the existing connection? On a fast Internet connection, the answer is nonobvious to me.

[1] https://www.rfc-editor.org/rfc/rfc9110.html#name-vary

[2] https://datatracker.ietf.org/doc/html/rfc6265#section-3

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.

> I routinely have concerns about lag on mobile. It sucks to have to wait for 10 seconds for a basic app to load.

That's a software architecture problem, not a transport layer problem.

Making the transport layer faster makes some architectures more performant. If you can simply swap out the transport layer that's a way easier optimization than rearchitecting an app that is correct but slow.

So with HTTP/3 it’s just 9.9 sec

Is HTTP the issue here though? Most of the time it seems to be more to do with the server taking ages to respond to queries. E.g. Facebook is equally poor on mobile as it is on my fibre-connected desktop (which I assume is using HTTP/3 as well) so I have my doubts that swapping HTTP versions will make a difference on mobile.

I did find it amusing how the author of the linked article says the megacorps are obsessed with improving performance (including the use of HTTP/3 to apparently help improve performance). In my experience the worst performing apps are those from the megacorps! I use Microsoft apps regularly at work and the performance is woeful even on a fibre connection using a HTTP/3 capable browser and/or their very own apps on their very own OS.

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

Does it really matter? The website is first going to download 5mb of js, then it's going to show 3 popups.

> I'd far rather have the OS provide a verified safe socket layer

There is work going on right now[1] to implement the QUIC protocol in the linux kernel, which gets used in userspace via standard socket() APIs like you would with TCP. Of course, who knows if it’ll ultimately get merged in.

[1] https://github.com/lxin/quic

Yea, but does the kernel then also do certificate validation for you? Will you pin certs via setsockopt? I think QUIC and TLS are wide enough attack surfaces to warrant isolation from the kernel.

The problem is that the situation where everyone rolls their own certificate stack is lunacy in this day and age. We need crypto everywhere, and it should be a lot easier to configure how you want: the kernel is a great place to surface the common interface for say "what certificates am I trusting today?"

The 10+ different ways you specify a custom CA is a problem I can't wait to see the back of.

It's a good thing for a OS to provide, that doesn't mean it needs to be in the kernel.

Putting cert parsing in (monolithic) kernels seems like a bad idea; cert parsing has a long history of security vulnerabilities, and you don't want that kind of mistake to crash your kernel, let alone lead to privilege escalation or a takeover of the kernel itself.

Regardless, your proposal suffers from the usual stuff about proliferating standards (https://xkcd.com/927/): a kernel interface will never get fully adopted by everyone, and then your "10+ ways" will become "11+ ways".

Meanwhile, all the major OSes have their own trust store, and yet some apps choose to do things in a different way. Putting this into the kernel isn't going to change that.

The kernel already does TLS, but the handshake happens in user-space.

> but does the kernel then also do certificate validation for you

No, the asymmetric cryptography is all done in userspace. Then, post-handshake, symmetric cryptography (e.g., AES) is done in-kernel. This is the same way it works with TCP if you’re using kTLS.

It will not.

Experiencing the internet at 2000ms latency every month or so thanks to dead spots along train tracks, the latency improvements quickly become noticeable.

HTTP/3 is terrible for fast connections (with download speeds on gigabit fiber notably capped) and great for bad ones (where latency + three way handshakes make the web unusable).

Perhaps there should be some kind of addon/setting for the browser to detect the quality of the network (doesn't it already for some JS API?) and dynamically enable/disable HTTP/3 for the best performance. I can live with it off 99% of the time, but those rare times I'm dropped to 2G speeds, it's a night and day difference.

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

Then you're trying to rely on the OS for this when it should actually be a dynamically linked third party library under some open source license.

Trying to get the OS to do it fails to one of two problems. Either each OS provides its own interface, and then every application has to be rewritten for each OS and developers don't want to deal with that so they go back to using a portable library, or the OS vendors all have to get together and agree on a standard interface, but then at least Microsoft refuses to participate and that doesn't happen either.

The real problem here is that mobile platforms fail to offer a package manager with the level of dependency management that has existed on Linux for decades. The way this should work is that you open Google Play and install whatever app that requires a QUIC library, it lists the QUIC library as a dependency, so the third party open source library gets installed and dynamically linked in the background, and the Play Store then updates the library (and therefore any apps that use it) automatically.

But what happens instead is that all the apps statically link the library and then end up using old insecure versions, because the store never bothered to implement proper library dependency management.

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

If the initial tcp 3 way handshake fails it can be quite a bit longer you would have to wait than a few ms. Depending on OS it is a second or more.

>saving a few ms per request, or more likely just on the first request.

That's not given, either as UDP is normally not prioritized under congestion.

But that will change, as more and more clients will rely on UDP on port 443.

It's also a poor congestion control practice to begin with. The main categories of UDP traffic are DNS, VoIP and VPNs. DNS is extremely latency sensitive -- the entirety of what happens next is waiting for the response -- so dropping DNS packets is a great way to make everything suck more than necessary. VoIP often uses some error correction and can tolerate some level of packet loss, but it's still a realtime protocol and purposely degrading it is likewise foolish.

And VPNs are carrying arbitrary traffic. You don't even know what it is. Assigning this anything less than "normal" priority is ridiculous.

In general middleboxes should stop trying to be smart. They will fail, will make things worse, and should embrace being as dumb and simple as possible. Don't try to identify traffic, just forward every packet you can and drop them at random when the pipe is full. The endpoints will figure it out.

Allegedly, some traffic is best split into multiple socket addresses to work around the smart middleboxes.

Connection migration sounds like a security nightmare

How is it any worse than session resumption from a different IP address?

the big one is multiplayer games. udp is preferred and trying to work with webrtc is awful

Reply on news.ycombinator.com