5 ms·

Those are pretty modest gains for a layer 4 change. It's going to be much harder to tool/debug this stuff. Is it expected that servers pretty much always suppor

Those are pretty modest gains for a layer 4 change. It's going to be much harder to tool/debug this stuff. Is it expected that servers pretty much always support all the HTTP protocols or is the goal to eventually replace the earlier forms?

ed25519FUUU 6y ago
Unless your web traffic represents single or double digits of worldwide web traffic, I don't see why anyone would bother.
- baggy_trough 6y ago
  You would bother if you wanted reduced latency for a better user experience.
  - leothecool 6y ago
    I don't disagree, but I still really really have a hard time caring about < 1ms of latency on a 50ms call. But, if I had to pay the electric bill on 2.5 million servers, I would definitely care about wasting resources sending extra packets.
    - throwaways885 6y ago
      That 1 ms translates to a much larger number in poor countries with everyone on 2G.
      - leothecool 6y ago
        I guess I'd have to see the metrics on it in production, but my intuition is that a 2% improvement to latency would be even less noticeable on low bandwidth connections where the download times are measured in whole seconds.
        baggy_trough 6y ago
        It's really the packet loss and TCP backoff that's a killer.
  - weego 6y ago
    Optimising at that granularity is also utterly at odds with everything that webdev has been doing for decades now. It's a micro optimisation that won't even register for your users, especially if you're reducing latency on 2mb of JS bundles
    - baggy_trough 6y ago
      Well those webdevs are terrible, but that doesn't mean everyone has to follow what they are doing.
  - ed25519FUUU 6y ago
    It would bother me if I had to debug an issue with QUIC for a website that never needed it in the first place.
  - kd913 6y ago
    If you wanted reduced latency, I think you would stick with HTTP/2 with onload on a Solarflare card. Until there is dedicated hardware NICs I think you would find HTTP/3 has worse latency. That is until dedicated NIC accelerators come out on the market.
    - baggy_trough 6y ago
      You're still stuck with TCP and its backoff algorithm in that case though.
- pokoleo 6y ago
  Just like minified JS, I expect people will run 3 in production, and 2 in development/etc environments.
- ehsankia 6y ago
  Well good thing it's optional and really only useful for a small subset of very large websites. I still serve my simple static unminified websites, but that doesn't mean minification and other optimizations have no reason to exist.
  - mobilemidget 6y ago
    Now you got my head all going, doing bad math.... As I simply wanted to write "That is not very 'green' of you" as in, compressed, minified, could be more efficient, better for the environment. But then I started thinking, is the saved traffic worth the compress (though once for static content) and decompress at all clients, increased cpu power, worth that trade off... And I guess I am not the first person to wonder about this, any people wanting to share a bookmark/url, tia (so I don't have to use google... ;) )
- mariusmarais 6y ago
  I don't think _you_ (nor I in my personal capacity) would, but your provider definitely should, and then you get the benefit. So if you're hosting via some accelerator like Cloudflare, AWS API Gateway, whatever Google has in this space, or app host like Heroku and friends, they'll happily do the work because they get the aggregate benefit. Your own site will become marginally faster or have happier roaming users, and so on, essentially for free. When you're developing a generic website, I don't think you should care about this. When you're self-hosting, you can decide if it might be worth it or not. It probably won't be worth the effort unless you're doing something really intricate or special, in which case you'll be really happy that you have the option.
ianswett 6y ago
In regards to the gains, these results are without 0-RTT, so I expect the gains with 0-RTT to be substantially larger. The numbers include total application latency, not just the latency introduced by the network, so the improvement to the network latency is larger. As such, applications that are more sensitive to network latency would show larger improvements. Thanks, Ian Disclosure: I authored the post
- StefanKarpinski 6y ago
  If I understand the benefits of HTTP/3 correctly, this post also doesn't address one of the major ones: seamless connection handoff during client mobility. Earlier HTTP versions are TCP-based, so if the IP address of a mobile client changes, e.g. because of moving from one cell tower to another or from wifi to/from cell, then the application layer has to notice the lost connection, create a new connection, and move whatever application-level context there is to the new connection. Not all applications do this, and even when they do, it's slow. If my understanding is correct, with HTTP/3 that's no longer necessary — the same HTTP/3 connection can migrate from one IP address to a different one. Another benefit that isn't measured in this post but has been mentioned elsewhere in the comments here is that the experience on flaky wireless connections (without changing IPs) should be much better. TCP was designed on the premise that packet loss almost never due to physical failure to transmit a packet, and almost always due to routers queues being full (i.e. network congestion). Wireless networks violate this assumption badly: physical-layer issues are the most likely cause of packet loss on a wireless connection. TCP reacts to wifi packet drops by backing off, assuming that some router is overloaded, but the routers are fine — it's just last hop signal that's bad. In those circumstances, the client should just try again instead of throttling the connection to nothing. Since HTTP/3 uses UDP, it can potentially handle dropped packets more appropriately.
  - nh2 6y ago
    On your first point, why is it necessary to switch IPs when switching between cell tower? Doesn't the cell ISP manage the IP anyway, thus making it easy to keep it from one tower to the next? On your second point, it's configurable how TCP reacts to packet loss. For example, wasn't BBR congestion control made to address exactly that case?
mike_d 6y ago
When networks realize they can't easily inspect it and shape it, we are going to end up in a world where anything UDP that isn't DNS will be blocked. TLS 1.3 and ESNI are already seeing blocking because middleboxes don't understand it.

ed25519FUUU 6y ago

Unless your web traffic represents single or double digits of worldwide web traffic, I don't see why anyone would bother.

baggy_trough 6y ago
You would bother if you wanted reduced latency for a better user experience.
- leothecool 6y ago
  I don't disagree, but I still really really have a hard time caring about < 1ms of latency on a 50ms call. But, if I had to pay the electric bill on 2.5 million servers, I would definitely care about wasting resources sending extra packets.
  - throwaways885 6y ago
    That 1 ms translates to a much larger number in poor countries with everyone on 2G.
    - leothecool 6y ago
      I guess I'd have to see the metrics on it in production, but my intuition is that a 2% improvement to latency would be even less noticeable on low bandwidth connections where the download times are measured in whole seconds.
      - baggy_trough 6y ago
        It's really the packet loss and TCP backoff that's a killer.
- weego 6y ago
  Optimising at that granularity is also utterly at odds with everything that webdev has been doing for decades now. It's a micro optimisation that won't even register for your users, especially if you're reducing latency on 2mb of JS bundles
  - baggy_trough 6y ago
    Well those webdevs are terrible, but that doesn't mean everyone has to follow what they are doing.
- ed25519FUUU 6y ago
  It would bother me if I had to debug an issue with QUIC for a website that never needed it in the first place.
- kd913 6y ago
  If you wanted reduced latency, I think you would stick with HTTP/2 with onload on a Solarflare card. Until there is dedicated hardware NICs I think you would find HTTP/3 has worse latency. That is until dedicated NIC accelerators come out on the market.
  - baggy_trough 6y ago
    You're still stuck with TCP and its backoff algorithm in that case though.
pokoleo 6y ago
Just like minified JS, I expect people will run 3 in production, and 2 in development/etc environments.
ehsankia 6y ago
Well good thing it's optional and really only useful for a small subset of very large websites. I still serve my simple static unminified websites, but that doesn't mean minification and other optimizations have no reason to exist.
- mobilemidget 6y ago
  Now you got my head all going, doing bad math.... As I simply wanted to write "That is not very 'green' of you" as in, compressed, minified, could be more efficient, better for the environment. But then I started thinking, is the saved traffic worth the compress (though once for static content) and decompress at all clients, increased cpu power, worth that trade off... And I guess I am not the first person to wonder about this, any people wanting to share a bookmark/url, tia (so I don't have to use google... ;) )
mariusmarais 6y ago
I don't think _you_ (nor I in my personal capacity) would, but your provider definitely should, and then you get the benefit. So if you're hosting via some accelerator like Cloudflare, AWS API Gateway, whatever Google has in this space, or app host like Heroku and friends, they'll happily do the work because they get the aggregate benefit. Your own site will become marginally faster or have happier roaming users, and so on, essentially for free. When you're developing a generic website, I don't think you should care about this. When you're self-hosting, you can decide if it might be worth it or not. It probably won't be worth the effort unless you're doing something really intricate or special, in which case you'll be really happy that you have the option.

ianswett 6y ago

In regards to the gains, these results are without 0-RTT, so I expect the gains with 0-RTT to be substantially larger. The numbers include total application latency, not just the latency introduced by the network, so the improvement to the network latency is larger. As such, applications that are more sensitive to network latency would show larger improvements. Thanks, Ian Disclosure: I authored the post

StefanKarpinski 6y ago
If I understand the benefits of HTTP/3 correctly, this post also doesn't address one of the major ones: seamless connection handoff during client mobility. Earlier HTTP versions are TCP-based, so if the IP address of a mobile client changes, e.g. because of moving from one cell tower to another or from wifi to/from cell, then the application layer has to notice the lost connection, create a new connection, and move whatever application-level context there is to the new connection. Not all applications do this, and even when they do, it's slow. If my understanding is correct, with HTTP/3 that's no longer necessary — the same HTTP/3 connection can migrate from one IP address to a different one. Another benefit that isn't measured in this post but has been mentioned elsewhere in the comments here is that the experience on flaky wireless connections (without changing IPs) should be much better. TCP was designed on the premise that packet loss almost never due to physical failure to transmit a packet, and almost always due to routers queues being full (i.e. network congestion). Wireless networks violate this assumption badly: physical-layer issues are the most likely cause of packet loss on a wireless connection. TCP reacts to wifi packet drops by backing off, assuming that some router is overloaded, but the routers are fine — it's just last hop signal that's bad. In those circumstances, the client should just try again instead of throttling the connection to nothing. Since HTTP/3 uses UDP, it can potentially handle dropped packets more appropriately.
- nh2 6y ago
  On your first point, why is it necessary to switch IPs when switching between cell tower? Doesn't the cell ISP manage the IP anyway, thus making it easy to keep it from one tower to the next? On your second point, it's configurable how TCP reacts to packet loss. For example, wasn't BBR congestion control made to address exactly that case?

mike_d 6y ago

When networks realize they can't easily inspect it and shape it, we are going to end up in a world where anything UDP that isn't DNS will be blocked. TLS 1.3 and ESNI are already seeing blocking because middleboxes don't understand it.