8 ms·

From a adoption perspective, how much is adopting HTTP/2 or /3 different from adopting a new IP "version" i.e. IPv6?

by tobib 7y ago

skybrian 7y ago
It's much easier, since it mostly affects browsers and websites, not ISPs and routers.
cesarb 7y ago
Much simpler. For IPv6, every hop in the path between the client and the server has to understand the new protocol. For HTTP/2 and HTTP/3, only the endpoints (the client and the server) have to understand the new protocol. And since they run on top of TCP (HTTP/2) or UDP (HTTP/3), not even the operating system on either endpoint has to understand the new protocol; only the client application (the browser) and the server application (the HTTP server daemon).
matsur 7y ago
It's much easier to get the adoption flywheel moving for new application and transport protocols than things farther down in the OSI stack. To get critical mass for HTTP/3 we'll need large server implementations (eg Cloudflare) and large client implementations (eg Chrome and Firefox) to build support and drive adoption. Which is what is happening! Contrast this to v6 adoption which requires software support _and_ support from hardware vendors, network operators, etc.
- throw0101a 7y ago
  > ... and transport protocols ... Are you referring to Layer 4 here? SCTP and DCCP may want to have a word with you. :)
  - dtech 7y ago
    Which we so successfully introduced that they needed a way to tunnel over UDP [1] and still have very niche support compared to TCP and UDP. [1] https://tools.ietf.org/html/rfc6951 https://tools.ietf.org/html/rfc6951
  - takeda 7y ago
    SCTP, DCCP are special case. Ideally those protocols supposed to be handled only by the endpoints, but over time the support of those protocols leaked to the network as well. Mainly because of wasteful allocation of IPv4 addresses we had to use NAT. A lot of that equipment makes other protocols impractical because they are not supporting them, even though initially they shouldn't have anything to do with them. I suppose HTTPs equivalent of that would be various http proxies, but in that case barely anyone uses them.
- tobib 7y ago
  I hope I didn't miss this from the article but how do client and server "negotiate" which protocol to use?
  - lucaspardue 7y ago
    We use HTTP Alternative Services (RFC 7838). This appears as a Alt-Svc response header that advertises the availability of HTTP/3 to a client. The client uses its local knowledge (and maybe other heuristics) to decide if it wants to change protocols.
  - tialaramex 7y ago
    Already in HTTP servers can send an "Alt-Svc" header which proposes a different way that clients might reach the same resources. So one thing that can happen goes in full like this: 1. User type http://example.com http://example.com into browser 1a. Browser does DNS lookup example.com AAAA or A -> 10.20.30.40 2. Browser connects to 10.20.30.40 TCP port 80 and speaks HTTP/1.1 over that port, announcing Host: example.com where it gets given a 301 redirect to https://example.com https://example.com (and HSTS pre-load would skip this step) 3. Browser connects to 10.20.30.40 TCP port 443, using SNI for example.com where it is offered an ALPN option h2 (meaning HTTP/2.0) and it takes that option and speaks HTTP/2.0 4. Browser receives Alt-svc: h3=":12345" which is an announcement that this same HTTPS service is available as HTTP/3 using UDP port 12345 from the same IP 5. Now for any future resources from https://example.com/ https://example.com/ the browser knows it could get them using HTTP/3 In future, maybe, perhaps, a new DNS record (only really practical via DPRIVE such as DoH since useless middleboxes will probably make this undeployable without) will do what the SRV record was trying to do, but this time focused on HTTP servers in particular. So with that record (again, not even a draft exists for this yet AFAIK): 1. User types http://example.com/ http://example.com/ into browser 1a. Browser uses DoH to ask HTTP-SERVICE DNS lookup example.com -> big pile of stuff about how to get this service. If the DNS lookup fails it tries asking for A or AAAA instead. 2. Browser intuits from the big pile of stuff to do QUIC to 10.20.30.40 UDP port 12345, and then speaks HTTP/3.
    - lucaspardue 7y ago
      Nice overview! There is a draft [1] that would support Alt-Svc in DNS. Lots to consider there but it is being presented to IETF. [1] - https://tools.ietf.org/html/draft-nygren-dnsop-svcb-httpssvc-00 https://tools.ietf.org/html/draft-nygren-dnsop-svcb-httpssvc...
- rumanator 7y ago
  > To get critical mass for HTTP/3 we'll need large server implementations (eg Cloudflare) and large client implementations (eg Chrome and Firefox) to build support and drive adoption. Which is what is happening! Isn't the critical path determined by the availability of web servers and client libraries? I get the importance of browsers, but I would guess that having HTTP/3 supported by projects such as Apache or nginx or curl is far more critical.
  - steveklabnik 7y ago
    It's a chicken and egg problem; without having clients, there's no reason for servers to support things, and without servers, there's no reason for clients to support things. It seems everyone recognizes this and so both clients and servers are getting implementations going to make sure this all goes smoothly.
    - rumanator 7y ago
      Nginx and Apache alone run about half of all active sites. That's pretty much the critical path to adoption. In fact, I'd argue that it would be impossible to adopt HTTP/3, or any other protocol, if those projects don't support it.
      - steveklabnik 7y ago
        Sure. I’m not saying that they aren’t valuable. I’m saying that they are, but clients are too.
        pdimitar 7y ago
        Are you guys working on a QUIC and HTTP/3 client/server in terms of future de-facto go-to crates for Rust? That would be amazing.
        steveklabnik 7y ago
        Cloudflare has made quiche, but I can't personally say that it's the go-to; I just haven't had direct experience enough. We'll just see how it all shakes out.
takeda 7y ago
Adopting IPv6 is much much harder. The problem with IPv6 is that it needs to be everywhere at once before it is useable, while protocol like http can be deployed incrementally and can coexist just fine with other protocols[1] [1] http://gumuskaya.com/images/tcp-ip.jpg http://gumuskaya.com/images/tcp-ip.jpg
sedachv 7y ago
As others have mentioned, moving HTTP versions is easier because it is at a higher protocol layer. But it is also an apples-to-oranges comparison, because the benefits of HTTP 2 or 3 over 1.1 are marginal compared to IPv6. The amount of benefit I got from going to IPv6 is so large in comparison to what HTTP 2 or 3 offers over 1.1, it is not in any way a fair comparison (and I am a pretty basic IPv6 user). A better comparison would be with TLS. Here again, I think new TLS versions offer benefits far above the marginal ones of HTTP 2 or 3 compared to 1.1.

From a adoption perspective, how much is adopting HTTP/2 or /3 different from adopting a new IP "version" i.e. IPv6?

by tobib 7y ago

From a adoption perspective, how much is adopting HTTP/2 or /3 different from adopting a new IP "version" i.e. IPv6?

skybrian 7y ago

It's much easier, since it mostly affects browsers and websites, not ISPs and routers.

cesarb 7y ago

Much simpler. For IPv6, every hop in the path between the client and the server has to understand the new protocol. For HTTP/2 and HTTP/3, only the endpoints (the client and the server) have to understand the new protocol. And since they run on top of TCP (HTTP/2) or UDP (HTTP/3), not even the operating system on either endpoint has to understand the new protocol; only the client application (the browser) and the server application (the HTTP server daemon).

matsur 7y ago

It's much easier to get the adoption flywheel moving for new application and transport protocols than things farther down in the OSI stack. To get critical mass for HTTP/3 we'll need large server implementations (eg Cloudflare) and large client implementations (eg Chrome and Firefox) to build support and drive adoption. Which is what is happening! Contrast this to v6 adoption which requires software support _and_ support from hardware vendors, network operators, etc.

throw0101a 7y ago
> ... and transport protocols ... Are you referring to Layer 4 here? SCTP and DCCP may want to have a word with you. :)
- dtech 7y ago
  Which we so successfully introduced that they needed a way to tunnel over UDP [1] and still have very niche support compared to TCP and UDP. [1] https://tools.ietf.org/html/rfc6951 https://tools.ietf.org/html/rfc6951
- takeda 7y ago
  SCTP, DCCP are special case. Ideally those protocols supposed to be handled only by the endpoints, but over time the support of those protocols leaked to the network as well. Mainly because of wasteful allocation of IPv4 addresses we had to use NAT. A lot of that equipment makes other protocols impractical because they are not supporting them, even though initially they shouldn't have anything to do with them. I suppose HTTPs equivalent of that would be various http proxies, but in that case barely anyone uses them.
tobib 7y ago
I hope I didn't miss this from the article but how do client and server "negotiate" which protocol to use?
- lucaspardue 7y ago
  We use HTTP Alternative Services (RFC 7838). This appears as a Alt-Svc response header that advertises the availability of HTTP/3 to a client. The client uses its local knowledge (and maybe other heuristics) to decide if it wants to change protocols.
- tialaramex 7y ago
  Already in HTTP servers can send an "Alt-Svc" header which proposes a different way that clients might reach the same resources. So one thing that can happen goes in full like this: 1. User type http://example.com http://example.com into browser 1a. Browser does DNS lookup example.com AAAA or A -> 10.20.30.40 2. Browser connects to 10.20.30.40 TCP port 80 and speaks HTTP/1.1 over that port, announcing Host: example.com where it gets given a 301 redirect to https://example.com https://example.com (and HSTS pre-load would skip this step) 3. Browser connects to 10.20.30.40 TCP port 443, using SNI for example.com where it is offered an ALPN option h2 (meaning HTTP/2.0) and it takes that option and speaks HTTP/2.0 4. Browser receives Alt-svc: h3=":12345" which is an announcement that this same HTTPS service is available as HTTP/3 using UDP port 12345 from the same IP 5. Now for any future resources from https://example.com/ https://example.com/ the browser knows it could get them using HTTP/3 In future, maybe, perhaps, a new DNS record (only really practical via DPRIVE such as DoH since useless middleboxes will probably make this undeployable without) will do what the SRV record was trying to do, but this time focused on HTTP servers in particular. So with that record (again, not even a draft exists for this yet AFAIK): 1. User types http://example.com/ http://example.com/ into browser 1a. Browser uses DoH to ask HTTP-SERVICE DNS lookup example.com -> big pile of stuff about how to get this service. If the DNS lookup fails it tries asking for A or AAAA instead. 2. Browser intuits from the big pile of stuff to do QUIC to 10.20.30.40 UDP port 12345, and then speaks HTTP/3.
  - lucaspardue 7y ago
    Nice overview! There is a draft [1] that would support Alt-Svc in DNS. Lots to consider there but it is being presented to IETF. [1] - https://tools.ietf.org/html/draft-nygren-dnsop-svcb-httpssvc-00 https://tools.ietf.org/html/draft-nygren-dnsop-svcb-httpssvc...
rumanator 7y ago
> To get critical mass for HTTP/3 we'll need large server implementations (eg Cloudflare) and large client implementations (eg Chrome and Firefox) to build support and drive adoption. Which is what is happening! Isn't the critical path determined by the availability of web servers and client libraries? I get the importance of browsers, but I would guess that having HTTP/3 supported by projects such as Apache or nginx or curl is far more critical.
- steveklabnik 7y ago
  It's a chicken and egg problem; without having clients, there's no reason for servers to support things, and without servers, there's no reason for clients to support things. It seems everyone recognizes this and so both clients and servers are getting implementations going to make sure this all goes smoothly.
  - rumanator 7y ago
    Nginx and Apache alone run about half of all active sites. That's pretty much the critical path to adoption. In fact, I'd argue that it would be impossible to adopt HTTP/3, or any other protocol, if those projects don't support it.
    - steveklabnik 7y ago
      Sure. I’m not saying that they aren’t valuable. I’m saying that they are, but clients are too.
      - pdimitar 7y ago
        Are you guys working on a QUIC and HTTP/3 client/server in terms of future de-facto go-to crates for Rust? That would be amazing.
        steveklabnik 7y ago
        Cloudflare has made quiche, but I can't personally say that it's the go-to; I just haven't had direct experience enough. We'll just see how it all shakes out.

takeda 7y ago

Adopting IPv6 is much much harder. The problem with IPv6 is that it needs to be everywhere at once before it is useable, while protocol like http can be deployed incrementally and can coexist just fine with other protocols[1] [1] http://gumuskaya.com/images/tcp-ip.jpg http://gumuskaya.com/images/tcp-ip.jpg

sedachv 7y ago

As others have mentioned, moving HTTP versions is easier because it is at a higher protocol layer. But it is also an apples-to-oranges comparison, because the benefits of HTTP 2 or 3 over 1.1 are marginal compared to IPv6. The amount of benefit I got from going to IPv6 is so large in comparison to what HTTP 2 or 3 offers over 1.1, it is not in any way a fair comparison (and I am a pretty basic IPv6 user). A better comparison would be with TLS. Here again, I think new TLS versions offer benefits far above the marginal ones of HTTP 2 or 3 compared to 1.1.