4 ms·

Can anyone make a tidy article/post that outlines exactly how each protocol differs (v1 vs v2 vs v3) on the network level. Obviously most of us understand the h

Can anyone make a tidy article/post that outlines exactly how each protocol differs (v1 vs v2 vs v3) on the network level. Obviously most of us understand the high level differences but what does the mechanisms and payloads look like on lower levels. A side by side comparison would be great. Pro's & con's of each would be great. Would older hardware (say a 10 year old netgear router) be able to use v3 without pain?

samoa42 6y ago
was going to say "of course, why would the router care for layer4 proto" but then again, netgear is like a synonym for "unpredictable crappy middlebox".
chrismorgan 6y ago
HTTP/1 is a plain text protocol over TCP. Requests are sequential per connection. Browsers tend to use up to six connections at a time to work around this. HTTP/2 is a binary protocol over TCP. Requests are multiplexed. It’s normally better than HTTP/1, but in environments with higher packet loss rates (e.g. remote mobile networks) it can perform markedly worse than HTTP/1, because of TCP head-of-line blocking and the fact that the browser is now using only one connection. HTTP/3 is a binary protocol over QUIC which is over UDP. Requests are multiplexed. If it works, it should be fairly uniformly better than both HTTP/1 and HTTP/2, because you can think of it as roughly HTTP/2 minus the bad parts of TCP. However, on a few networks (business networks typically, I think) it won’t work because they have firewalls that hate unknown UDP traffic. (HTTP/3 is not actually just HTTP/2 over QUIC; HTTP/2’s header compression scheme HPACK is stateful in a way that depends on TCP’s sequential nature so that it couldn’t work over QUIC without completely reintroducing the head-of-line blocking problem, so it’s replaced with a variant that mitigates that problem substantially, called QPACK. But other than that, I think they’re roughly the same. Don’t quote me on that, though, it’s a few years since I read the specs and I’ve forgotten it all, not to mention that the specs have changed plenty in that time.) I think this is a fair summary, but I don’t have any practical experience with HTTP/3, so I welcome any corrections.
- swyx 6y ago
  this was a remarkably concise summary, nicely done. one clarification/question I had was I think all connections start as http1 by default, then a request to upgrade to http2 is sent. does the same happen for http3? does it go from 1 to 3 or 1 to 2 to 3?
  - chrismorgan 6y ago
    HTTP/2 over cleartext uses an HTTP/1.1 Upgrade header field, yes, so that it’s an extra request. But HTTP/2 over TLS can use application-layer protocol negotiation (ALPN) so that the HTTP/2 negotiation piggybacks on the TLS handshake: the TLS ClientHello includes “I speak h2”, and the ServerHello response includes “OK, let’s do h2”. HTTP/3 negotiation I’m not certain about. Its existence can be broadcast with an Alt-Svc header on an HTTP response, but that means that the browser won’t use HTTP/3 for the first request. I think that might be what browsers are doing now (rather than racing TCP and UDP). But I think the direction things are heading is to optionally advertise this stuff over DNS as well, which would allow browsers to go straight to HTTP/3 if the relevant DNS records say it’s OK to: https://blog.cloudflare.com/speeding-up-https-and-http-3-negotiation-with-dns/ https://blog.cloudflare.com/speeding-up-https-and-http-3-neg....
    - swyx 6y ago
      you have a gift for explaining these things. thank you!
    - tialaramex 6y ago
      HTTP/2 without TLS is basically not a thing. The HTTP/2 specification tells you how you could in principle do this, but no popular browsers implement it and so far as I know no popular servers do so either. So in practice it's always ALPN, a modern browser specifies that it would prefer h2 and servers that speak HTTP/2 select that during TLS handshaking. As with SNI this means it is not secret yet (but it could be protected by Encrypted Client Hello)
      - 6y ago

samoa42 6y ago

was going to say "of course, why would the router care for layer4 proto" but then again, netgear is like a synonym for "unpredictable crappy middlebox".

chrismorgan 6y ago

HTTP/1 is a plain text protocol over TCP. Requests are sequential per connection. Browsers tend to use up to six connections at a time to work around this. HTTP/2 is a binary protocol over TCP. Requests are multiplexed. It’s normally better than HTTP/1, but in environments with higher packet loss rates (e.g. remote mobile networks) it can perform markedly worse than HTTP/1, because of TCP head-of-line blocking and the fact that the browser is now using only one connection. HTTP/3 is a binary protocol over QUIC which is over UDP. Requests are multiplexed. If it works, it should be fairly uniformly better than both HTTP/1 and HTTP/2, because you can think of it as roughly HTTP/2 minus the bad parts of TCP. However, on a few networks (business networks typically, I think) it won’t work because they have firewalls that hate unknown UDP traffic. (HTTP/3 is not actually just HTTP/2 over QUIC; HTTP/2’s header compression scheme HPACK is stateful in a way that depends on TCP’s sequential nature so that it couldn’t work over QUIC without completely reintroducing the head-of-line blocking problem, so it’s replaced with a variant that mitigates that problem substantially, called QPACK. But other than that, I think they’re roughly the same. Don’t quote me on that, though, it’s a few years since I read the specs and I’ve forgotten it all, not to mention that the specs have changed plenty in that time.) I think this is a fair summary, but I don’t have any practical experience with HTTP/3, so I welcome any corrections.

swyx 6y ago
this was a remarkably concise summary, nicely done. one clarification/question I had was I think all connections start as http1 by default, then a request to upgrade to http2 is sent. does the same happen for http3? does it go from 1 to 3 or 1 to 2 to 3?
- chrismorgan 6y ago
  HTTP/2 over cleartext uses an HTTP/1.1 Upgrade header field, yes, so that it’s an extra request. But HTTP/2 over TLS can use application-layer protocol negotiation (ALPN) so that the HTTP/2 negotiation piggybacks on the TLS handshake: the TLS ClientHello includes “I speak h2”, and the ServerHello response includes “OK, let’s do h2”. HTTP/3 negotiation I’m not certain about. Its existence can be broadcast with an Alt-Svc header on an HTTP response, but that means that the browser won’t use HTTP/3 for the first request. I think that might be what browsers are doing now (rather than racing TCP and UDP). But I think the direction things are heading is to optionally advertise this stuff over DNS as well, which would allow browsers to go straight to HTTP/3 if the relevant DNS records say it’s OK to: https://blog.cloudflare.com/speeding-up-https-and-http-3-negotiation-with-dns/ https://blog.cloudflare.com/speeding-up-https-and-http-3-neg....
  - swyx 6y ago
    you have a gift for explaining these things. thank you!
  - tialaramex 6y ago
    HTTP/2 without TLS is basically not a thing. The HTTP/2 specification tells you how you could in principle do this, but no popular browsers implement it and so far as I know no popular servers do so either. So in practice it's always ALPN, a modern browser specifies that it would prefer h2 and servers that speak HTTP/2 select that during TLS handshaking. As with SNI this means it is not secret yet (but it could be protected by Encrypted Client Hello)
    - 6y ago