7 ms·

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 ke

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.

sennalen 2y ago
Connection migration sounds like a security nightmare
- AnthonyMouse 2y ago
  How is it any worse than session resumption from a different IP address?
lemagedurage 2y ago
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.
- TheRealPomax 2y ago
  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".
  - deleted 2y ago
    [deleted]
  - celsoazevedo 2y ago
    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.
    - TheRealPomax 2y ago
      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.
      - celsoazevedo 2y ago
        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.
        TheRealPomax 2y ago
        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.
- the8472 2y ago
  Isn't 5G supposed to solve the mobile latency issue?
  - nine_k 2y ago
    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.
    - the8472 2y ago
      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.
      - nine_k 2y ago
        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.
        joshstrange 2y ago
        Could you talk a little bit more about what changes you made on the back into accommodate that? That sounds interesting.
      - kiwijamo 2y ago
        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.
- motorest 2y ago
  > 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?
  - fragmede 2y ago
    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.
    - sublimefire 2y ago
      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?)
      - fragmede 2y ago
        > most of the web is non Google, Amazon or MSFT. maybe you can point out where that's what I said
    - kiwijamo 2y ago
      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.
- croes 2y ago
  And then the web app eats all that saved ms with ease.
- guappa 2y ago
  Does it really matter? The website is first going to download 5mb of js, then it's going to show 3 popups.
cyanmagenta 2y ago
> 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 https://github.com/lxin/quic
- eptcyka 2y ago
  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.
  - XorNot 2y ago
    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.
    - richardwhiuk 2y ago
      It's a good thing for a OS to provide, that doesn't mean it needs to be in the kernel.
    - kelnos 2y ago
      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/ 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.
xxs 2y ago
>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.
- eptcyka 2y ago
  But that will change, as more and more clients will rely on UDP on port 443.
  - AnthonyMouse 2y ago
    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.
    - eptcyka 2y ago
      Allegedly, some traffic is best split into multiple socket addresses to work around the smart middleboxes.
hubabuba44 2y ago
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.
jeroenhd 2y ago
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.
kelnos 2y ago
> 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.
plopz 2y ago
the big one is multiplayer games. udp is preferred and trying to work with webrtc is awful
AnthonyMouse 2y ago
> 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.

sennalen 2y ago

Connection migration sounds like a security nightmare

AnthonyMouse 2y ago
How is it any worse than session resumption from a different IP address?

lemagedurage 2y ago

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.

TheRealPomax 2y ago
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".
- deleted 2y ago
  [deleted]
- celsoazevedo 2y ago
  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.
  - TheRealPomax 2y ago
    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.
    - celsoazevedo 2y ago
      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.
      - TheRealPomax 2y ago
        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.
the8472 2y ago
Isn't 5G supposed to solve the mobile latency issue?
- nine_k 2y ago
  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.
  - the8472 2y ago
    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.
    - nine_k 2y ago
      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.
      - joshstrange 2y ago
        Could you talk a little bit more about what changes you made on the back into accommodate that? That sounds interesting.
    - kiwijamo 2y ago
      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.
motorest 2y ago
> 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?
- fragmede 2y ago
  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.
  - sublimefire 2y ago
    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?)
    - fragmede 2y ago
      > most of the web is non Google, Amazon or MSFT. maybe you can point out where that's what I said
  - kiwijamo 2y ago
    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.
croes 2y ago
And then the web app eats all that saved ms with ease.
guappa 2y ago
Does it really matter? The website is first going to download 5mb of js, then it's going to show 3 popups.

cyanmagenta 2y ago

> 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 https://github.com/lxin/quic

eptcyka 2y ago
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.
- XorNot 2y ago
  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.
  - richardwhiuk 2y ago
    It's a good thing for a OS to provide, that doesn't mean it needs to be in the kernel.
  - kelnos 2y ago
    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/ 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.

xxs 2y ago

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

eptcyka 2y ago
But that will change, as more and more clients will rely on UDP on port 443.
- AnthonyMouse 2y ago
  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.
  - eptcyka 2y ago
    Allegedly, some traffic is best split into multiple socket addresses to work around the smart middleboxes.

hubabuba44 2y ago

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.

jeroenhd 2y ago

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.

kelnos 2y ago

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

plopz 2y ago

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

AnthonyMouse 2y ago

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