With my "Rust core team member" hat on, normally I'd want to see one good go-to library for an ecosystem. With my "I love web protocols" hat on, I want to see dozens of independent implementations. I wear hat #2 more than hat #1 when it comes to HTTP/3.
Nice catch! As you've noticed, we plan to keep tracking the new drafts as they come out. 22 was the current version at the time we drafted this post, and 23 is now live.
Not aware of benchmarks, but specification-wise I consider HTTP2 to be a regression.
Sure there are good things about it, and many great enhancements, but the larger mechanic of the protocol (the most important part really) has been significantly worsened. I'd rate them as follows:
HTTP3 > HTTP1.1 > HTTP2
QUIC is an amazing protocol, I have no complaints about it, and I'm very happy they decided to go with it for HTTP3. However the decision to make HTTP2 traffic go all through a single TCP socket is horrible, and makes the protocol very brittle under even the slightest network decay or packet loss. Any level of head-of-line blocking severely degrades the entire stream, even for unrelated requests.
Sure it CAN work better than HTTP1.1 under ideal network conditions, but any network degradation is severely amplified, to a point where even for traffic within a datacenter can amplify network distruption and cause an outage.
HTTP3 however is a refinement on those ideas, and gets pretty much everything right afaik.
Do you seriously expect Google and Cloudflate to make basic web development easier when they are making tons of money by "managing" its complexity for others? It's in their best interest to make hosting your own content or using smaller hosting providers absolute hell. Just like it's in Google's best interest to make browsers so complex that other browser devs just give up and Chrome derivatives become the only choice.
I'm predicting that eventually Google will start deranking HTTP 1.1 websites.
I have no idea how cookies are supposed to having an impact on hosting in Google's cloud vs your own hardware, or why Google would care about people where something like that is in any way significant.
>I have no idea how cookies are supposed to having an impact on hosting in Google's cloud vs your own hardware
You do not see how lack of built-in authentication increases complexity of implementing your own website as opposed to "outsourcing" stuff to Gmail, Google Docs and so on? You don't see the zillion "sign in with Google" buttons all over the web? You don't see how cookies are abused for tracking, which benefits Google orders of magnitude more than it would a smaller company?
Google, a multi-billion dollar corporation that owns most of the browser and search market share, a company that dictates the next transport-layer protocol we will use - this company struggles to design a session-handling mechanism that would out-compete an ugly hack that Netscape ductaped to HTTP in mid-90s.
The whole idea of HTTP and it's huge win over other server protocols was that it moved session support from the server to the client. You are talking nonsense here. cookies were needed for session persistency eventually.
TCP hardware acceleration is generally pretty minimal. The common features are checksum offload and segmentation offload. Checksum offload should generally work for UDP, and I believe that a good UDP implementation can get much of the benefit of segmentation offloading.
I'm not sure that follows. Higher CPU usage isn't undesirable because it slows things down (although it may), it prevents battery powered devices working efficiently. Plucking a figure from the air, if QUIC knocks 10% off the battery life of mobiles, that's a hard sell.
Network usage of CPU is tippically well bellow rounding error on a usual system. That's different if you are talking about a static assets CDN or if you are designing networking equipment, but for usual applications, no, it won't make a difference on the battery life of your mobile, page rendering will, not network.
Large percentage of mobile device power consumption is from radio use. Personal tests of phones in airplane mode and without airplane mode show even network keepalive consumes a fair amount of energy.
Sure but if HTTP/3 adds significant processor overhead compared to prior versions and the user isn't getting a noticeable benefit from this cost, they're not going to like it and it sort of seems like a pointless waste of effort.
I have an idea: maybe software engineers and tech managers could take a bit longer to do things, so that they don't have to rush to fix them later. Because it's exactly what HTTP/3 sounds: a rushed fix for the HTTP/2 screw up.
> Because it's exactly what HTTP/3 sounds: a rushed fix for the HTTP/2 screw up.
Wasn't Google already publishing and promoting QUIC before SPDY got adopted as the basis for HTTP/2? SPDY was more conservative because it didn't replace TCP, QUIC wasn't a fix for SPDY being broken, it was a concurrent and less conservative effort poo.
I think you should look into the histories of HTTP/2 and HTTP/3 before making such claims. These were both in development and deployment as proprietary protocols used by Google (in Chrome and other things) for nearly 10 years before being officially ratified.
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).
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.
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.
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:
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):
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.
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.
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.
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.
If clients could assist in load-balancing, it might be handy, but large web hosts would still need a lot of nodes, a lot of bandwidth, DoS mitigation and, ideally, a way to get clients to use a local point of presence. In other words, people would still want most of the services that CloudFlare provides.
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.)
Can the HTTP/1.1 server directly return the Alt-svc: h3 header? That way the entire HTTP/2 can be skipped, lower the bar of server implementation (maybe).
> 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.
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.
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.
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.
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]
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.
Are there any efforts to solve caching if encrypted counted? Currently all https traffic has to be handled by originating server directly. If there is a standard to verify document signature, clients could just cache the public key of originating website and use that to verify signature and decrypt the content.
This seems to be totally ignored and http2/3 seem to be solving the wrong problem.
Such efforts are contra-indicated by privacy concerns. You'd need to have everybody agree what we're happy to just let everyone see, then that goes in the cache, and anybody who wishes we didn't know that they've just looked at, say, the Wikipedia page for HIV regrets everybody else's decision at their leisure.
Anything you decide needs to be private doesn't benefit from this cache. So, maybe we can cache the little Y-combinator logo, but not anything anybody wrote? The Youtube help pages, but not any videos? It just doesn't seem like there's any plausible way this isn't either horribly invasive or largely useless or both.
You are right, but there are other cases like say distribution of common JS libraries. The way it is working currently is via CDN, even then the client could fetch the same object from different sources. Instead if you could describe the object as some sort of signed E-Tag, then the client can just reuse previously downloaded/authenticated/decrypted copy. Of course your actual bank statement should not be distributed this way.
For example, let's say site G, well known for fingerprinting and tracking, wants to estimate how long since you last visited site W recently. W uses modern software engineering recommended practices: CI/CD with several deploys a day, heavily minimised EMCAScript, various icons too.
When you visit any page on G, G serves you a page that uses 37 scripts (called "signals") of particular exact, minified versions, which G happens to know M has served on any particular day. The scripts are loaded in such a way that they don't really do anything.
From that, G can estimate when you visited W, and on what day.
This works so well that G starts adding invisible iframes or AJAX calls to signed copies of entire popular pages from W, and through that, works out exactly what you've been reading. It takes a while because people read different things, but guess by guess, they build up a profile of your W reading habits over time, and the more accurate the profile becomes, the better they are able to estimate what pages to check next.
They do this even though you don't visit G all that often, because G's page does its measurements continuously while the page is loaded. You try turning off JavaScript, but G's A/B test-driven AI helpfully evolves a clever workaround with nested iframes and meta-refresh, so it doesn't make much difference.
Eventually this is done in G's ServiceWorker so it trickles along in the background, and G keep the bandwidth usage low enough that you don't notice. Battery consumption is hardly affected because they run their probes at the same time as the ubiquitous mobile-server-to-client-notification service wakes up the radio. Which 99% of users have running all the time.
A kind of "web crawling", if you will, but crawling the client's history, crawling shared, signed ETags just by trying them.
I'm unsure what you mean; intermediaries can absolutely cache responses regardless of whether they are retrieved with HTTP or HTTPS. One great example of this is Cloudflare itself, acting as a CDN for backing systems which serve content to Cloudflare protected with HTTPS.
If you are talking about a separate, non-intermediary cache service, this is neither part of HTTPS or HTTP. While there are certainly third party implementations that work this way, there isn't a generalized approach out there to solve this. Instead you have things like software caching services specific to a particular vendor, or things like Google AMP.
I thought people wanting that used things such as HAProxy and https accelerators to deal with the encryption part before passing it onto caching and/or server apps.
> QUIC also combines the typical 3-way TCP handshake with TLS 1.3's handshake. Combining these steps means that encryption and authentication are provided by default, and also enables faster connection establishment. In other words, even when a new QUIC connection is required for the initial request in an HTTP session, the latency incurred before data starts flowing is lower than that of TCP with TLS.
It's kind of amazing seeing positive things from monopolies and evergreen updates. These institutions can roll out things fast. It's possible in hardware too-- remember Bell Labs in it's hayday?
82 comments
[ 4.8 ms ] story [ 149 ms ] threadWith my "Rust core team member" hat on, normally I'd want to see one good go-to library for an ecosystem. With my "I love web protocols" hat on, I want to see dozens of independent implementations. I wear hat #2 more than hat #1 when it comes to HTTP/3.
Sure there are good things about it, and many great enhancements, but the larger mechanic of the protocol (the most important part really) has been significantly worsened. I'd rate them as follows:
HTTP3 > HTTP1.1 > HTTP2
QUIC is an amazing protocol, I have no complaints about it, and I'm very happy they decided to go with it for HTTP3. However the decision to make HTTP2 traffic go all through a single TCP socket is horrible, and makes the protocol very brittle under even the slightest network decay or packet loss. Any level of head-of-line blocking severely degrades the entire stream, even for unrelated requests.
Sure it CAN work better than HTTP1.1 under ideal network conditions, but any network degradation is severely amplified, to a point where even for traffic within a datacenter can amplify network distruption and cause an outage.
HTTP3 however is a refinement on those ideas, and gets pretty much everything right afaik.
I'm predicting that eventually Google will start deranking HTTP 1.1 websites.
You do not see how lack of built-in authentication increases complexity of implementing your own website as opposed to "outsourcing" stuff to Gmail, Google Docs and so on? You don't see the zillion "sign in with Google" buttons all over the web? You don't see how cookies are abused for tracking, which benefits Google orders of magnitude more than it would a smaller company?
It's in no way easier than adding keycloak authentication for example, which is another (selfhosted) external authentication solution.
Social auth isnt there to make authentication easier for the website owner. He still has to do everything he'd have to do if he didn't use it.
It's there for the users, do they don't need to remember a bazillion passwords
Google, a multi-billion dollar corporation that owns most of the browser and search market share, a company that dictates the next transport-layer protocol we will use - this company struggles to design a session-handling mechanism that would out-compete an ugly hack that Netscape ductaped to HTTP in mid-90s.
[1] https://varnish-cache.org/docs/trunk/phk/http20.html#beating...
Cookies were a hack to add sessions on top of http.
[1] https://varnish-cache.org/docs/trunk/phk/http20.html#beating...
HTTP1/2 = TCP, which has dedicated hardware to offload major parts of the protocol overhead.
QUIC = UDP, but re-implements some features of TCP in software, leaving the CPU to handle things it didn't have to before.
I plan on purchasing the book as reviewed by this blog post: https://petewarden.com/2015/10/08/smartphone-energy-consumpt...
Wasn't Google already publishing and promoting QUIC before SPDY got adopted as the basis for HTTP/2? SPDY was more conservative because it didn't replace TCP, QUIC wasn't a fix for SPDY being broken, it was a concurrent and less conservative effort poo.
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.
Are you referring to Layer 4 here? SCTP and DCCP may want to have a word with you. :)
[1] https://tools.ietf.org/html/rfc6951
I suppose HTTPs equivalent of that would be various http proxies, but in that case barely anyone uses them.
The client uses its local knowledge (and maybe other heuristics) to decide if it wants to change protocols.
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.)
https://news.ycombinator.com/item?id=15906664#15908696
https://news.ycombinator.com/item?id=8549348#8550133
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.
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
Anything you decide needs to be private doesn't benefit from this cache. So, maybe we can cache the little Y-combinator logo, but not anything anybody wrote? The Youtube help pages, but not any videos? It just doesn't seem like there's any plausible way this isn't either horribly invasive or largely useless or both.
For example, let's say site G, well known for fingerprinting and tracking, wants to estimate how long since you last visited site W recently. W uses modern software engineering recommended practices: CI/CD with several deploys a day, heavily minimised EMCAScript, various icons too.
When you visit any page on G, G serves you a page that uses 37 scripts (called "signals") of particular exact, minified versions, which G happens to know M has served on any particular day. The scripts are loaded in such a way that they don't really do anything.
From that, G can estimate when you visited W, and on what day.
This works so well that G starts adding invisible iframes or AJAX calls to signed copies of entire popular pages from W, and through that, works out exactly what you've been reading. It takes a while because people read different things, but guess by guess, they build up a profile of your W reading habits over time, and the more accurate the profile becomes, the better they are able to estimate what pages to check next.
They do this even though you don't visit G all that often, because G's page does its measurements continuously while the page is loaded. You try turning off JavaScript, but G's A/B test-driven AI helpfully evolves a clever workaround with nested iframes and meta-refresh, so it doesn't make much difference.
Eventually this is done in G's ServiceWorker so it trickles along in the background, and G keep the bandwidth usage low enough that you don't notice. Battery consumption is hardly affected because they run their probes at the same time as the ubiquitous mobile-server-to-client-notification service wakes up the radio. Which 99% of users have running all the time.
A kind of "web crawling", if you will, but crawling the client's history, crawling shared, signed ETags just by trying them.
If you are talking about a separate, non-intermediary cache service, this is neither part of HTTPS or HTTP. While there are certainly third party implementations that work this way, there isn't a generalized approach out there to solve this. Instead you have things like software caching services specific to a particular vendor, or things like Google AMP.
https://www.shodan.io/search?query=http+Alt-svc+h3
> QUIC also combines the typical 3-way TCP handshake with TLS 1.3's handshake. Combining these steps means that encryption and authentication are provided by default, and also enables faster connection establishment. In other words, even when a new QUIC connection is required for the initial request in an HTTP session, the latency incurred before data starts flowing is lower than that of TCP with TLS.