14 ms·
The majority of Facebook's traffic now uses QUIC and HTTP/3
- avinash 6y agoFor Chrome users, this open source extension will tell you what protocol the browser is using for each website being accessed: https://chrome.google.com/webstore/detail/http-indicator/hgcomhbcacfkpffiphlmnlhpppcjgmbl https://chrome.google.com/webstore/detail/http-indicator/hgc...
- r1ch 6y agoUnfortunately permissions to access everything on every website are way to broad for a niche extension like this. There's no guarantee it won't be sold to a malware developer in a month. If you want to use it, I suggest cloning the repo and loading it as an unpacked extension to avoid auto updates.
- kibwen 6y agoAlso be sure to audit it yourself beforehand if you're going to go that route; there's no use tilting against auto-updates if you haven't gone to the trouble of making sure that malicious code isn't already present.
- hunter2_ 6y agoThis is quite timely: https://chris.partridge.tech/2020/extensions-the-next-generation-of-malware/help-for-users/ https://chris.partridge.tech/2020/extensions-the-next-genera...
- sergeykish 6y agoEssentially it is performance.getEntriesByType("navigation")[0].nextHopProtocol and background task to update UI, plus a link to chrome://net-export/ This one is not hard to audit but in current model should be done by each user.
- deleted 6y ago[deleted]
- Siira 6y agoChrome's own developer tools can tell you this easily. Check out the network pane.
- mhoad 6y agoIs this down for anyone else?
- Santosh83 6y agoBy the way, even though it is not yet turned on by default, http3 support is present in Firefox and can be activated by toggling 'network.http.http3.enabled' in about:config to true. I have had it enabled for a few weeks and everything seems okay except that rarely I've noticed a few sites not loading the first time I visit them but needing a 'refresh', but I'm not sure if this is because of the new QUIC code or just another connection glitch.
- the-dude 6y agoWhere can I put my money on cache coherency?
- codetrotter 6y agoI’ll take that bet and I will give you a generous 1:10 bet odds ratio. 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 ;)
- jedberg 6y agoFYI, what you wanted to say was 1 for 10, not 1 to 10. 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.
- codetrotter 6y agoThanks for clarifying. Guess it's a good thing I never tried to enter the betting industry haha
- kortilla 6y agoYeah, nobody would ever place a bet if the best payout was less than what you put in...
- cblconfederate 6y agofacebook and porn are still driving tech forward
- Fumtumi 6y agoI would not name facebook close to something good like porn.
- 02020202 6y agohe probably meant scat since that pair with big tech the best
- ffpip 6y agoThanks. that's going in my quotes.txt file
- centimeter 6y agoThanks for the input, coomer.
- dagenix 6y ago> we refer to QUIC and HTTP/3 together as QUIC 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.
- microcolonel 6y agoI think they're talking about Google QUIC, which formed the basis for both IETF QUIC and HTTP/3; Facebook has been deploying Google QUIC for a long while now maybe, AFAIK. The people at fault here are probably the IETF lol.
- mjoras 6y agoWe never deployed Google QUIC. It was always IETF QUIC. Referring to them together as QUIC was just for expedience, since the main benefits came from the QUIC layer, not the HTTP layer. 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.
- microcolonel 6y agoThank you for the clarification. I'm sure you're looking forward to WebTransport+QUIC as well, I know I am. I'm already doing some little tweaks to our WebSocket RPC and bulk transfer layers to resemble WebTransport so it's an easy drop-in when the QUIC transport becomes available, or when there's a reasonable implementation of WebTransport+HTTP/3 (the other middle ground). Maybe I can publish the virtual “WebSocketTransport” thing once I'm satisfied with it.
- alexchamberlain 6y agoIt's rather frustrating when people do this; for the rest of the article, when saying QUIC do they mean theur terminology that is actually QUIC and HTTP/3 or do they mean QUIC the TCP alternative? They use both.
- 6y ago
- nt2h9uh238h 6y agoIs this possible with NodeJS + express already? I didn't see any package for that or config
- steelbrain 6y agoNode.js has builtin HttpV2 support but no v3 support IIRC. Which is not a deal breaker because any production app should already have a load balancer/proxy in front of it, which do have QUIC support.
- deleted 6y ago[deleted]
- Androider 6y agoNode.js v15.0 now has experimental QUIC support. For production usage, I wouldn't expect anything usable before the v16 LTS release in October 2021 (and it might still be feature flagged at that point). 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.
- Siira 6y agoCaddy does support http/3.
- jayflux 6y agoQUIC support has landed behind an experimental flag https://github.com/nodejs/node/issues/23064 https://github.com/nodejs/node/issues/23064 As for HTTP/3 that’s a bit further down the line
- cj 6y agoFor people running apps behind Cloudfront/Fastly/Cloudflare, is it similar to h2 where it can be enabled at the CDN level, or load balancer?
- 6y ago
- ldng 6y agoCould that explain this : the new UI, appart from being terrible, is often seeing slowdowns for me ?
- shadowgovt 6y agoPossibly, if something in your network is disallowing UDP traffic and the system has to fall back to HTTP over TCP.
- ldng 6y agooh, so it's fine to degrade HTTP v1 to make v3 look better ?
- room500 6y agoIt's acceptable to "degrade" a protocol that is only used as a fallback on broken networks if the new protocol is better for your use-case and is available to 99% of users. 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.
- dj_mc_merlin 6y agoBit offtopic and dumb but.. > 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.
- api 6y agoI am really happy Google and others are pushing QUIC, but for only one main reason: networks that disallow UDP will now be considered "broken." 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.
- Thaxll 6y agoWho disable UDP in 2020?
- nhooyr 6y agoSchools tend to have it blocked.
- deleted 6y ago[deleted]
- kelnos 6y agoI expect HTTP/2 and HTTP/1.1 will still be with us for decades; orgs that block UDP will be able to continue to do so, and the rare HTTP/3-only website will just be inaccessible. 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.
- H8crilA 6y ago"Science progresses one funeral at a time." https://en.m.wikipedia.org/wiki/Planck%27s_principle https://en.m.wikipedia.org/wiki/Planck%27s_principle
- chrismorgan 6y agoI expect HTTP/2 to disappear completely, to the point of browsers removing support for it probably even within a decade. Everything that works over HTTP/2 should work over HTTP/1.1, even if at a slight cost, and HTTP/3 should be uniformly superior to HTTP/2, except in those rare cases of UDP-blocking firewalls, which situation I expect to improve over time. Given the complexity and maintenance burden of the protocol and more importantly the upgrade mechanism, I think browsers will be happy to remove HTTP/2 in favour of the old reliable HTTP/1.1 (which is certainly not going anywhere) and HTTP/3 once they see very little using it any more, and absolutely nothing needing to use it.
- kwargs 6y agoMajority fb/chrome users are just telemetry and deserve to be data mined by big data corps and 3 letter organizations.
- chrismmay 6y agoWow. Now if they could just figure out why my news feed has said "Something Went Wrong" at the bottom for about the last year or so.
- darth_avocado 6y agoDamn I thought it was just me becauseI thought that the Facebook algorithm doesn't have content for me because I don't have friends.
- chrismmay 6y agoI don't think they test at all because... who cares? It's Facebook. You get what you pay for.
- harrygeez 6y agoI feel like I belong in the minority who like the new Facebook SPA. It loads shockingly fast on my computer, almost instantaneous even
- H8crilA 6y agoIt's almost like Windows 95! I click something and then it just happens, immediately! Funny how people forgot that you actually can make (web)apps fast.
- mrlala 6y agoBut being an SPA I'm sure it's a billion times more manageable for them to maintain instead of a javascript hack nightmare. 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?
- wrkronmiller 6y agoInteresting, it's very slow for me, and usually triggers warnings from Safari for excess resource consumption.
- sgt 6y agoI think it's extra slow in Safari, for some reason. Just like Google Maps is also slower in Safari than in Chrome. However, overall I would say Safari is the fastest browser out there, based on my own browsing habits. Also most memory efficient.
- krzyk 6y agoNice, can we now make Facebook look not like it was created in the early 2000? 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.
- meowtimemania 6y agoOn which platform is the ui outdated? IMO it looks pretty good
- mullingitover 6y agoSettings menus on desktop browsers look like they haven't been touched since the Windows XP era.
- krzyk 6y agoHere is my screenshot: https://imgur.com/17OxohL https://imgur.com/17OxohL 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.
- bawolff 6y agoWell i feel old now.... to me fb is one of those sites using tons of heavy ui that makes me yearn for older sites. Keep in mind also that https://nostalgia.wikipedia.org 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
- mixmastamyk 6y agoThey just updated it about a month ago. Besides the dark theme, it is super crowded and feels like using a low-res phone on a 4k monitor—a step backwards.
- SiVal 6y agoCan HTTP/3 be enabled in nginx now? Should it be? Is it a simple config change? I assume that would take care of serving static assets, but would reverse-proxied apps behind nginx also need to be upgraded to HTTP/3?
- mjoras 6y agoThere are several efforts to implement QUIC and HTTP/3 in nginx. Cloudflare has it deployed in production with quiche[1], and Nginx themselves are developing one[2]. 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 https://github.com/cloudflare/quiche [2] https://www.nginx.com/blog/introducing-technology-preview-nginx-support-for-quic-http-3/ https://www.nginx.com/blog/introducing-technology-preview-ng...
- nbm 6y agoPretty much any HTTP proxy supports talking a set of negotiated protocol versions/features with the client, and a potentially different set of protocol versions/features with the server behind it. 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.
- lawrenceyan 6y agoFor anyone interested, the original design doc for QUIC from 2013 [0]. Really good writeup, both in terms of engineering spec / architectural design. I recommend reading through if you have the time. [0]: https://docs.google.com/document/d/1RNHkx_VvKWyWg6Lr8SZ-saqsQx7rFV-ev2jRFUoVD34/edit https://docs.google.com/document/d/1RNHkx_VvKWyWg6Lr8SZ-saqs...
- thamer 6y agoLooks great, thanks for sharing! 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 https://tools.ietf.org/html/draft-ietf-quic-transport-27 [2] https://github.com/nicolasff/webdis#websockets https://github.com/nicolasff/webdis#websockets
- mjoras 6y agoThere's a lot of significant differences from the original Google QUIC design and what we currently have in the IETF drafts. They are very much wire-incompatible. That's why it took several years for the working group to get to a point where they were near-completion.
- jeffrogers 6y agoSo are the QUIC HTTP/3 Connection Migration IDs and end run around ad blockers and MAC spoofing, and other forms of anti-tracking measures? Long ago, I read these IDs are persistent across networks, etc.
- aronpye 6y agoIs QUIC implemented at the kernel level like TCP/UDP, or is it entirely userland? Is it encapsulated in UDP packets?
- mjoras 6y agoMost implementations[1] implement it in userland, but this is by no means a requirement. There is no implementation for the Linux kernel presently, but both msquic and F5's QUIC implementation can run in their respective kernels. 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 https://github.com/quicwg/base-drafts/wiki/Implementations
- aronpye 6y agoThanks for the info :)
- pabs3 6y agoCould QUIC also have been built on top of IP datagrams instead of UDP datagrams? Or does our crufty Internet mean only UDP and TCP are viable Internet protocols?
- tialaramex 6y agoIt is as you say. In theory you could build this as a new IP protocol next to TCP but in practice that would be blocked by default and can't be deployed.
- holidayacct 6y agoAm I reading the IETF status incorrectly or is HTTP/3 still i draft status? Why on earth are they implementing a protocol that is in draft status?
- mjoras 6y agoThis is how the IETF and protocol development works[1]. In fact, it is strongly encouraged for participants to implement and deploy drafts before they are finalized. Otherwise you risk finalizing something with a lot of deployment problems. [1]https://www.ietf.org/how/runningcode/ https://www.ietf.org/how/runningcode/
- wrycoder 6y agoFait accompli?
- tialaramex 6y agoYou are reading it correctly. This is a draft, and I presume Facebook's engineering team are confident that they have the resources (time/ money/ whatever) to stay reasonably up to date on any subsequent changes. 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.
- jrockway 6y agoWhy is the response time chart missing an x axis? What competitive advantage in the social networking space do they gain by not telling me their p99 request time?
- MichaelMoser123 6y agoI guess NAS (network access storage) would really benefit from QUIC; one could treat each file transfer as a separate session, so that a lost packet will not cause all the sessions to stall. Did any of the NAS protocols adopt QUIC already? Are they working on it?
- jdub 6y agoThere's been some interest among the Samba hackers, including some discussion with Microsoft. They seem quite excited about SMB-on-QUIC as an Internet-capable network filesystem protocol.
- mjoras 6y agoIndeed. I believe the latest Windows Insiders builds have SMB over QUIC support (via msquic). I think QUIC brings a lot potential to finally run network filesystem protocols on the Internet.
- hinkley 6y agorsync, please and thank you.
- BatteryMountain 6y agoCan anyone make a tidy article/post that outlines exactly how each protocol differs (v1 vs v2 vs v3) on the network level. Obviously most of us understand the high level differences but what does the mechanisms and payloads look like on lower levels. A side by side comparison would be great. Pro's & con's of each would be great. Would older hardware (say a 10 year old netgear router) be able to use v3 without pain?
- samoa42 6y agowas going to say "of course, why would the router care for layer4 proto" but then again, netgear is like a synonym for "unpredictable crappy middlebox".
- chrismorgan 6y agoHTTP/1 is a plain text protocol over TCP. Requests are sequential per connection. Browsers tend to use up to six connections at a time to work around this. 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.
- swyx 6y ago