From a adoption perspective, how much is adopting HTTP/2 or /3 different from adopting a new IP "version" i.e. IPv6?
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.
1. User type 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 (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/ 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/ 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.
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...
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.
> They also enable aliasing of apex domains, which is not possible with CNAME.
That would help eliminate a major annoyance of using a CDN.
> a lot of nodes,
Not that many, say three or four servers at most should IMHO be fine for the vast majority.
> a lot of bandwidth,
If your service gets popular enough that you need that much bandwidth, you can then very likely get enough funds to get adequate bandwidth. (Either by commercializing or by donations.)
> DoS mitigation
If you have four servers on four different networks, how hard would someone have to DoS them all before all four give out? And, maybe at least one of those four servers are placed on an ISP which is actually somewhat competent in helping you to filter out DoS traffic? Cloudflare doesn’t have some secret magic sauce, you know.
> and, ideally, a way to get clients to use a local point of presence.
That’s technically true, but only if you are desperate for your latency enough to merit such needs. But you probably aren’t. You are, most likely, much more served by optimizing your server caching and HTML page code than you would be by trying to claw a few extra milliseconds out of the network itself.
If you are desperate to get a few extra milliseconds, and already have a dead-simple homepage, and are enormously popular enough to merit it, then you are Google, and you can solve this problem by means not available to mere mortals.
I have written before in more detail why Google et al. probably doesn’t want SRV records: (In short, SRV solves problems for other people which Google have already solved for themselves, and Google would like to keep their moat.)
The client uses its local knowledge (and maybe other heuristics) to decide if it wants to change protocols.
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.
It seems everyone recognizes this and so both clients and servers are getting implementations going to make sure this all goes smoothly.
Are you referring to Layer 4 here? SCTP and DCCP may want to have a word with you. :)
I suppose HTTPs equivalent of that would be various http proxies, but in that case barely anyone uses them.
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]