4 ms·

I hope I didn't miss this from the article but how do client and server "negotiate" which protocol to use?

by tobib 7y ago

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...
  - teddyh 7y ago
    That looks very interesting, but, like SRV records have been studiously ignored in the past, I doubt that Google, Cloudflare, etc al. will allow this to be the norm, since this would eliminate much of the value proposition which Cloudflare has, and also partially drain the moat which Google has constructed around itself.
    - tialaramex 7y ago
      Maybe take another glance at the "very interesting" draft? Those named authors are from Google and one of Cloudflare's competitors, Akamai. Of course you can imagine these are rogue actors off developing technology that's hostile to their employer's needs. But, like, Occam's razor. It seems simpler to assume that these outfits see improving the place where they make money (the web) as just good business.
      - teddyh 7y ago
        I’ll belive it when I see it. SRV has been around for ages, and the arguments given for not using SRV in HTTP/2, QUIC etc. have been weak and unconvincing, despite its obvious benefits.
    - amluto 7y ago
      I can’t fathom why CloudFlare world dislike this. To the contrary: > They also enable aliasing of apex domains, which is not possible with CNAME. That would help eliminate a major annoyance of using a CDN.
      - 7y ago

I hope I didn't miss this from the article but how do client and server "negotiate" which protocol to use?

by tobib 7y ago

I hope I didn't miss this from the article but how do client and server "negotiate" which protocol to use?

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...
- teddyh 7y ago
  That looks very interesting, but, like SRV records have been studiously ignored in the past, I doubt that Google, Cloudflare, etc al. will allow this to be the norm, since this would eliminate much of the value proposition which Cloudflare has, and also partially drain the moat which Google has constructed around itself.
  - tialaramex 7y ago
    Maybe take another glance at the "very interesting" draft? Those named authors are from Google and one of Cloudflare's competitors, Akamai. Of course you can imagine these are rogue actors off developing technology that's hostile to their employer's needs. But, like, Occam's razor. It seems simpler to assume that these outfits see improving the place where they make money (the web) as just good business.
    - teddyh 7y ago
      I’ll belive it when I see it. SRV has been around for ages, and the arguments given for not using SRV in HTTP/2, QUIC etc. have been weak and unconvincing, despite its obvious benefits.
  - amluto 7y ago
    I can’t fathom why CloudFlare world dislike this. To the contrary: > They also enable aliasing of apex domains, which is not possible with CNAME. That would help eliminate a major annoyance of using a CDN.
    - 7y ago