5 ms·

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 mas

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

by matsur 7y ago

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.