5 ms·

No head-of-line blocking is a pretty significant improvement.

coddle-hark 6y ago
Yes, but in reality you don’t want your page to load until all above the fold assets are loaded anyway. We went through this a couple of years ago with increasingly complicated techniques to avoid the dreaded “flash of unstyled content”. Head-of-line blocking is only a problem if you’re multiplexing connections. Just open one TCP socket per request and you’ll never have head of line blocking. There are issues with opening multiple TCP sockets of course (mainly Slow Start) but these aren’t insurmountable.
- TravelPiglet 6y ago
  You do want to download multiple assets like images in parallel over the same connection since you can’t open that many connections per domain.
  - coddle-hark 6y ago
    That’s not a fundamental limitation of TCP though. You can theoretically open 4294967296 sockets between two machines (with one IP address per machine) and a beefy machine can handle >1M concurrent connections. They’ve already proposed adding HTTPS and SVCB DNS records for performance, it would be easy enough to implement a ICANTAKEIT record that lets the browser know it’s OK to open as many sockets as it needs.
    - CydeWeys 6y ago
      It's a bigger lift than just switching from TCP to QUIC though. And there's other reasons you wouldn't want to use as many connections as you have assets to download; each connection has startup overhead.
      - coddle-hark 6y ago
        N connections have the same startup overhead as a single connection though, since they’re made in parallel.
        a1369209993 6y ago
        A single (TCP) connection has a single SYN and SYN-ACK packet of startup overhead. N connections have N SYN packets and N SYN-ACKs. That might still not be very much overhead, but it is more.
        coddle-hark 6y ago
        You’re right, of course, there’s a (teeny tiny) cost for the handshakes but what I meant was that the performance overhead will be zero.
        CydeWeys 6y ago
        The performance overhead will not be zero. You're spending more computational power and memory opening up and maintaining a larger number of connections, and you're sending more packets and bits over the network in total because each additional connection has non-zero overhead.
        gravypod 6y ago
        > (teeny tiny) cost for the handshakes What happens when your ping time is >500ms? > was that the performance overhead will be zero I think QUIC is motivated by Google's expansion into developing markets (China, India, etc). These areas are primarily mobile markets that would like to consume the same content we do. What might sound like small overhead (SYN->SYN-ACK) actually takes half a second. If your performance is measured in this way than N connections times half a second is a long time. And, on mobile networks, sometimes your TCP connection will drop even if there's still data being sent back and forth (some times you can see latency spikes up to 3sec on really bad networks which causes most software to timeout since it thinks no data came in because of head-of-line blocking). It's a truely miserable experience that QUIC or HTTP/3 can easily solve. Imagine how slow an `apt update && apt upgrade` is and how much of that overhead can be dropped by connecting to 1 mirror a single time and bulk requesting 10 to 100 file transfers. This allows you to maximize your network throughput. Think instead of how slow this would be if you opened 10 to 100 connections each of which might take 500ms per startup. In the worst case that's a 500ms penalty versus a 5 second penalty.
- gravypod 6y ago
  There are many things that use HTTP that are not web browsers. Things like S3, for example, can make use of no head of line blocking by allowing multiple file transfers, multiple pagination requests, etc. Even APIs can benefit from this by using bidirectional streaming. Games can now also be built over a REST-like API using separate channels for different priority messages: movement, world state, chat, etc. Since you don't need to worry about blocking you get way better performance. Almost every game engine networking component essentially implements TCP-over-UDP just to get application level control over these functions.
  - coddle-hark 6y ago
    You can do all of that, except for the application level control, by just opening multiple TCP sockets. QUIC is just basically TCP over UDP in that it shares the same semantics (guaranteed, in order delivery of a bidirectional data stream with congestion control). Sure, game engines don’t always want all those attributes - guaranteed delivery, for example - and will implement their own thing over UDP that makes more sense for them. QUIC is just as bad as TCP for those use cases though!
    - gravypod 6y ago
      The benefit is that you can open up as many channels within a connection as you want so you obtain the same abilities as you'd normally implement in a game engine.
      - coddle-hark 6y ago
        No, you wouldn’t. You can’t turn off retransmissions in QUIC, for instance.

Yes, but in reality you don’t want your page to load until all above the fold assets are loaded anyway. We went through this a couple of years ago with increasingly complicated techniques to avoid the dreaded “flash of unstyled content”. Head-of-line blocking is only a problem if you’re multiplexing connections. Just open one TCP socket per request and you’ll never have head of line blocking. There are issues with opening multiple TCP sockets of course (mainly Slow Start) but these aren’t insurmountable.

TravelPiglet 6y ago
You do want to download multiple assets like images in parallel over the same connection since you can’t open that many connections per domain.
- coddle-hark 6y ago
  That’s not a fundamental limitation of TCP though. You can theoretically open 4294967296 sockets between two machines (with one IP address per machine) and a beefy machine can handle >1M concurrent connections. They’ve already proposed adding HTTPS and SVCB DNS records for performance, it would be easy enough to implement a ICANTAKEIT record that lets the browser know it’s OK to open as many sockets as it needs.
  - CydeWeys 6y ago
    It's a bigger lift than just switching from TCP to QUIC though. And there's other reasons you wouldn't want to use as many connections as you have assets to download; each connection has startup overhead.
    - coddle-hark 6y ago
      N connections have the same startup overhead as a single connection though, since they’re made in parallel.
      - a1369209993 6y ago
        A single (TCP) connection has a single SYN and SYN-ACK packet of startup overhead. N connections have N SYN packets and N SYN-ACKs. That might still not be very much overhead, but it is more.
        coddle-hark 6y ago
        You’re right, of course, there’s a (teeny tiny) cost for the handshakes but what I meant was that the performance overhead will be zero.
        CydeWeys 6y ago
        The performance overhead will not be zero. You're spending more computational power and memory opening up and maintaining a larger number of connections, and you're sending more packets and bits over the network in total because each additional connection has non-zero overhead.
        gravypod 6y ago
        > (teeny tiny) cost for the handshakes What happens when your ping time is >500ms? > was that the performance overhead will be zero I think QUIC is motivated by Google's expansion into developing markets (China, India, etc). These areas are primarily mobile markets that would like to consume the same content we do. What might sound like small overhead (SYN->SYN-ACK) actually takes half a second. If your performance is measured in this way than N connections times half a second is a long time. And, on mobile networks, sometimes your TCP connection will drop even if there's still data being sent back and forth (some times you can see latency spikes up to 3sec on really bad networks which causes most software to timeout since it thinks no data came in because of head-of-line blocking). It's a truely miserable experience that QUIC or HTTP/3 can easily solve. Imagine how slow an `apt update && apt upgrade` is and how much of that overhead can be dropped by connecting to 1 mirror a single time and bulk requesting 10 to 100 file transfers. This allows you to maximize your network throughput. Think instead of how slow this would be if you opened 10 to 100 connections each of which might take 500ms per startup. In the worst case that's a 500ms penalty versus a 5 second penalty.
gravypod 6y ago
There are many things that use HTTP that are not web browsers. Things like S3, for example, can make use of no head of line blocking by allowing multiple file transfers, multiple pagination requests, etc. Even APIs can benefit from this by using bidirectional streaming. Games can now also be built over a REST-like API using separate channels for different priority messages: movement, world state, chat, etc. Since you don't need to worry about blocking you get way better performance. Almost every game engine networking component essentially implements TCP-over-UDP just to get application level control over these functions.
- coddle-hark 6y ago
  You can do all of that, except for the application level control, by just opening multiple TCP sockets. QUIC is just basically TCP over UDP in that it shares the same semantics (guaranteed, in order delivery of a bidirectional data stream with congestion control). Sure, game engines don’t always want all those attributes - guaranteed delivery, for example - and will implement their own thing over UDP that makes more sense for them. QUIC is just as bad as TCP for those use cases though!
  - gravypod 6y ago
    The benefit is that you can open up as many channels within a connection as you want so you obtain the same abilities as you'd normally implement in a game engine.
    - coddle-hark 6y ago
      No, you wouldn’t. You can’t turn off retransmissions in QUIC, for instance.