The majority of Facebook's traffic now uses QUIC and HTTP/3
engineering.fb.com
engineering.fb.com
So, if you give me $1000 dollars as your stake then:
- If you are wrong I get to keep the whole $1000
- If you are correct then I will give you $100 of your money back. (Leaving me with $900 of your money still hehe).
In other words what I am saying is, I think you are correct in what you said ;)
Like craps odds when betting on the don't side, where you win less than what you bet.
But it's important to point out that even with 1 for 10 odds, you still get your original stake back plus the extra 1.
Another thing where a full page refresh helps is towards getting consistency on whether HTTP/3 is available or not, because the client might make another HTTP/2 request instead and refresh the Alt-Svc information.
But I use HTTP/3 in Firefox Nightly and use Gmail and Google Docs all day long without major breakage these days.
Can't wait for http 4, 5 & 6 to be released next year so that a few companies can fight to steer the direction of the Web.
My understand is that HTTP/3 always means QUIC is used according to the standard. But that QUIC can be used for other protocols as well. FB's terminology seems to be backwards.
HTTP/3 implies IETF QUIC. IETF QUIC itself can be used for non-HTTP protocols, though, just like TCP can be used for protocols that aren't HTTP/2.
Maybe I can publish the virtual “WebSocketTransport” thing once I'm satisfied with it.
The output from the experiments was new standardization efforts at the IETF. Google's SPDY, which was a binary HTTP protocol over TLS, eventually resulted in HTTP/2 which there's a fair chance you use today.
The other idea, QUIC, is a much bigger lift. It replaces not just the HTTP protocol and TLS but the whole stack, even TCP. At the IETF this work was split into two pieces, the IETF's QUIC is just the TCP replacement, an encrypted connection-oriented reliable protocol. So the HTTP part of the problem is being standardised as HTTP/3
Google's QUIC "gQUiC" will be obsolete once the standardized protocol is finished. Right now a Chrome talking to e.g. GMail uses gQUIC, once the standards work is firmed up it'll speak HTTP/3 and then maybe a year later Google's sites will discontinue gQUIC because it's just maintenance effort with no residual value.
Of course an all new IP would be great, but the issue is it would take very long for all the soft and hardware to support it and UDP is simply there.
I would prefer for a new HTTP to go an all new way, leaving behind UDP and TCP and build something new. Then support fallback over HTTP1/2 until everything else caught up.
At least not one that works over the general Internet - controlled intra-organisation networks might possibly be able to do so, but very rarely.
There are too many broken machines on the Internet that assume all IP traffic is one of TCP, UDP and ICMP. And far too many are configured to screw up ICMP too.
So new protocols MUST use TCP or UDP as their base layer instead of raw IP.
So yes, QUIC uses UDP, but that should be considered an implementation detail. A hack for the lack of IP support on the Internet.
HTTP/3 uses QUIC like HTTP/1 and HTTP/2 use TCP + TLS, but QUIC is not limited to use by HTTP/3.
QUIC's development has been, basically, paused while HTTP/3 is finalised and then the IETF will pick up where it left off and work out how other higher-layer protocols will work using QUIC as the transport layer.
Having said that, I wish we could replace the "port" concept. With the size of address space IPV6 allows, 16 bits for ports is looking a bit small.
And for fancier protocols it doesn't matter anyway because they have their own concept of a connection identifier. WireGuard for example doesn't care at all, packets arrive and either they're authenticated or they aren't, it silently discards all packets that aren't authenticated, QUIC optionally has a connection ID that can survive changing the 4-tuple as far as I remember.
If you wish you did have more ports, the IPv6 address space makes it pretty cheap to just acquire more addresses on your network and use those, but I do not sense much appetite because people don't feel like they're short of ports.
You do see people spinning up more addresses to not need SNI or similar. If you have sixty virtual machines on one hardware box, having sixty IPv6 addresses, one per VM, means now the packets for VM #4 and VM #18 are separated on the wire, which might be convenient but that doesn't feel like it's due to running out of ports, it's just more convenient.
Without something to push UDP usage its possible we could end up with a TCP-only Internet that would make P2P connectivity more or less impossible.
Even if there's a new killer app that requires QUIC, I imagine an org backward enough to disallow UDP will just not care about that app.
Without UDP we have a purely "cloud-to-ground" Internet unless we can convince router/NAT makers to always include and always turn on UPnP/NAT-PMP. Not likely, and those protocols suck anyway.
For UDP, you just specify the destination IP and port, and send packets.
For TCP, new incoming SYNs to most (S)NAT addresses will just get dropped - especially CGNAT - making it impossible to communicate in that direction. If you're both in that situation (really common, actually), you just can't talk to each other.
For UDP, the packets will also get dropped on the receiver side. However, the act of sending the packet will often cause the originator's side's NAT to register that five-tuple (source and destination IP and port + UDP proto), which would allow the other side to reply. If both sides do this with the same IP/port pairs, then magically they can communicate - some of the time, at least. There's a lot more involved (for example, how do you know your own external IP address behind NAT?) - read up on STUN - https://en.wikipedia.org/wiki/STUN - for more details.
QUIC is designed to hide a lot from the network. But some network nodes use visibility into things like round-trip time, data-in-flight and packet loss for each flow, so they can adjust queuing parameters to optimise for each user. These measurements are easy to get from monitoring TCP, but not QUIC.
The designers of those network nodes may conclude that blocking QUIC (UDP on port 443) and forcing fallback to HTTP/2 over TCP results in better ability to optimise network flows than allowing QUIC to go ahead. All browsers race TCP against QUIC, so a network blocking QUIC shouldn't significantly slow performance compared with just HTTP/2.
If it's close, regardless of which way, you'll get beaten up for disabling HTTP/3, maybe that's unjust but that's how it is.
Kind of like how most big sites clamp TCP MSS at 1440 instead of 1460; there's too many PPPoE or IPIP tunneled links with broken path mtu, and too many clients without working/enabler path mtu blackhole detection to bother making a fuss about it. Just move on and cry on the inside.
[0]: https://docs.google.com/document/d/1RNHkx_VvKWyWg6Lr8SZ-saqs...
How does it compare to the February 2020 standard draft from IETF? [1] I was following the development of the Websocket protocol pretty closely when it happened and had to update my implementation[2] multiple times as the design kept changing. Did this also happen here, or was QUIC pretty much done and standardized straight from the Google design?
[1] https://tools.ietf.org/html/draft-ietf-quic-transport-27
Applications sitting behind a proxy wouldn't need to be updated. The core protocol semantics of HTTP are relatively unchanged between HTTP/1.1, HTTP/2, and HTTP/3.
[1] https://github.com/cloudflare/quiche
[2] https://www.nginx.com/blog/introducing-technology-preview-ng...
The high-level flow is pretty much:
1) Set up client connection/negotiate stuff (TLS, alpn, NPN, blah blah) 2) Process requests from that client connection 2.1) Decode request from client connection 2.2) Manipulate request (add/remove headers, ...) 2.3) Send request to server 2.3.1) If necessary, create a new connection to server (TLS, alpn, NPN, ...) 2.3.2) Encode request to server connection 2.4) Decode response from server connection 2.5) Manipulate response (add/remove headers, ...) 2.6) Encode response to client connection
You can talk totally different protocols from Internet-side client to the proxy, and from the proxy to the server - and multiple layers of proxies in between if you like. From an app point of view, there's essentially no difference. If you want to for some reason, you can use various headers to do attempt to indicate to the client to upgrade/downgrade to particular protocols, but most apps won't care about that.
Funny how people forgot that you actually can make (web)apps fast.
So, yeah of course you can always make something lightning fast.. but can you manage it, or even develop it properly in the first place?
Perhaps related to the const+let vs var bug the other day.
Chrome and FF also using more resources for Heavy JS (not as much as Safari) but maybe they just have better engines.
I loathe the over-js'd web.
It is amazingly fast(on desktop at least), behaves in all the right ways you would expect, you never lose you position anywhere, using back button always works properly, gracefully handles connection loss, and again, it's so fast and pleasurable to use. Too bad can't say the same for the content on the site.
I get notifications popping up but there's nothing there. Same thing with the messages jewel.
I'll get a notification about a reply to my comment, I'll go to the comment, like it, and then it will scroll me down to the same reply as a top level comment at the bottom of the post.
I've reported all the weirdness I've come across but nothing's changed since I was switched over a month ago.
https://chrome.google.com/webstore/detail/http-indicator/hgc...
performance.getEntriesByType("navigation")[0].nextHopProtocol
This one is not hard to audit but in current model should be done by each user.
javascript:alert(performance.getEntriesByType("navigation")[0].nextHopProtocol)HTTP/2 is a binary protocol over TCP. Requests are multiplexed. It’s normally better than HTTP/1, but in environments with higher packet loss rates (e.g. remote mobile networks) it can perform markedly worse than HTTP/1, because of TCP head-of-line blocking and the fact that the browser is now using only one connection.
HTTP/3 is a binary protocol over QUIC which is over UDP. Requests are multiplexed. If it works, it should be fairly uniformly better than both HTTP/1 and HTTP/2, because you can think of it as roughly HTTP/2 minus the bad parts of TCP. However, on a few networks (business networks typically, I think) it won’t work because they have firewalls that hate unknown UDP traffic.
(HTTP/3 is not actually just HTTP/2 over QUIC; HTTP/2’s header compression scheme HPACK is stateful in a way that depends on TCP’s sequential nature so that it couldn’t work over QUIC without completely reintroducing the head-of-line blocking problem, so it’s replaced with a variant that mitigates that problem substantially, called QPACK. But other than that, I think they’re roughly the same. Don’t quote me on that, though, it’s a few years since I read the specs and I’ve forgotten it all, not to mention that the specs have changed plenty in that time.)
I think this is a fair summary, but I don’t have any practical experience with HTTP/3, so I welcome any corrections.
HTTP/3 negotiation I’m not certain about. Its existence can be broadcast with an Alt-Svc header on an HTTP response, but that means that the browser won’t use HTTP/3 for the first request. I think that might be what browsers are doing now (rather than racing TCP and UDP). But I think the direction things are heading is to optionally advertise this stuff over DNS as well, which would allow browsers to go straight to HTTP/3 if the relevant DNS records say it’s OK to: https://blog.cloudflare.com/speeding-up-https-and-http-3-neg....
The HTTP/2 specification tells you how you could in principle do this, but no popular browsers implement it and so far as I know no popular servers do so either.
So in practice it's always ALPN, a modern browser specifies that it would prefer h2 and servers that speak HTTP/2 select that during TLS handshaking. As with SNI this means it is not secret yet (but it could be protected by Encrypted Client Hello)
Browsers did initially implement h2c (HTTP/2 cleartext), but before the dust had really settled, they decided “no, let’s use this opportunity to keep pushing people to adopt TLS” (if you want the performance improvements of HTTP/2, you have to go secure first) and so they ripped it out again. So h2c is much more an academic concept than a real-world thing.
Closely related is the general trend browser makers have agreed on to prefer to make new things only available in secure contexts, with https://w3c.github.io/webappsec-secure-contexts/ explaining and providing various rationale. There’s a genuine security aspect to it, but it’s also definitely about pushing people to do security properly. (“If you want to use this new feature, switch your site to HTTPS first.”)
Considering so much of the internet traffic is not text media was it necessary.
I feel there is a slight possibility of a Google optimisation for a problem they perceive. And then no one questions because brrr faster brrr.
But I'm conscious I might come across as a bit of a Luddite, but it's mostly musing.
QUIC is indeed built on top of UDP datagrams, much in the same way TCP is built (typically) on top of IP datagrams.
[1] https://github.com/quicwg/base-drafts/wiki/Implementations
But that's pretty irrelevant for most production deployments, as you'll almost certainly want to have some type of AWS ALB, nginx, Cloudflare etc. load balancer in front of your Node services.
As for HTTP/3 that’s a bit further down the line
Essentially, the core of standard HTTP requests and responses (method, path, headers, response code) is fairly unchanged since HTTP/1.0, and what's changed is how those requests/responses are encoded and carried.
More on our blog https://blog.cloudflare.com/http3-the-past-present-and-futur...
TLDR: we are a few years out from this being anything but experimental in node.
Generally the way this work goes, at first things change pretty violently, maybe it goes from let's have a 1 byte version number, ASN.1 OIDs for everything and some JSON, to actually it's always the five bytes 'QUICK' then a four byte version number, we're doing CORS instead of JSON, and no OIDs now it's all URNs, in like two weeks of git pulls and mailing list posts.
But after a while the drafts start to settle down. On some topics everybody is satisfied that there's a good argument for why we do this and not that, on others it's a coin toss and it's just easier not to change it than argue constantly. Do I like OIDs? Eh, they're better than URNs but I can live with either, so fine, have URNs if you insist.
QUIC has largely settled down. Google's systems for example will tell you they speak draft 29 of QUIC. Do they? Well, more or less. Maybe it's sort of draft 32 really. But drafts 29 and 32 are pretty similar, and draft 32 is going to Last Call now, if nobody raises any issues it's done.
Is it conceivable that somebody discovers a grave problem in QUIC and it has to be substantially revised? Yes. But it's not very likely. So it's easily possible that a draft 29 QUIC implementation like Google's (or Facebook's) will mostly interoperate with an actual QUIC standard next year after just some small tweaks to tell it this isn't a draft any more. Why wait?
HTTP/3 is a bit more than just do HTTP on QUIC, and it's slightly less finished than QUIC is, but it's also pretty stable and there's less that might change anyway.
Somebody has to try this stuff out, and at scale if we're to learn much more than "It might work" before it finishes that Last Call. Facebook, Google, Cloudflare, Mozilla, Netflix and so on are able to do that.
Nobody is trying to make v3 "look better." If you use v1, you can continue to use it for a very, very, very long time.
Check this - https://web.archive.org/web/20201021174206/https://engineeri...
> Facebook has a mature infrastructure that allows us to safely roll out changes to apps in a limited fashion before we release them to billions of people.
When you put it like that, the scale of it is scarily comprehensible.
Am I the only one bothered by that? I rarely use Facebook (I used it only when I had to, and never created by own profile, always some temporary ones), so maybe the content is king there, but the UI is very dated.
It is as if the whole Web 2.0 era forgot about it, all those icons on the left side.
The main part takes only like 30% of the screen estate.
On the other hand, reddit looks good, Google+ looked good. HN looks better.
Keep in mind also that https://nostalgia.wikipedia.org is what wikipedia looked like in the beginning of the 2000s, so i think you might just be misremembering how plain many sites were back then
Besides the dark theme, it is super crowded and feels like using a low-res phone on a 4k monitor—a step backwards.