All, I'm excited to finally publicly share some of the work we've been doing on QUIC in recent years. You can read about it on the Facebook Engineering blog here <https://engineering.fb.com/networking-traffic/how-facebook-is-bringing-quic-to-billions/> .
The headline is that 75% of Facebook's Internet traffic is now QUIC and HTTP/3. In real terms this amounts to QUIC being fully enabled in the Facebook and Instagram mobile apps. We have had production traffic using QUIC on the Internet for over two years, but have dramatically increased the volume through 2020. We have been able to do this because QUIC has consistently shown significant empirical improvements over TCP. Importantly I'd like to stress that these aren't simply "performance" improvements, but rather measurable improvements to the application experience. A few things to note: - QUIC is enabled for all content in both apps, and is utilized for media upload as well. - The baseline HTTP for the apps is either HTTP/2 (for the Facebook app) or HTTP/1.1 (for Instagram). - The baseline transport server-side is vanilla Linux TCP + BBR with sensible TCP tuning. Our QUIC implementation doesn't diverge majorly from the drafts except for the use of BBR as the CCA. - Our TCP baseline uses TLS 1.3 and early_data, with the vast majority of connections resuming. - We are not currently using 0-RTT for QUIC. - We are not currently using connection migration. - We use a default UDP payload size of 1232 or 1252 depending on the IP version, and do not yet have our DPLPMTUD implementation enabled. - None of the quoted metrics include browser traffic, though we have had QUIC enabled on Facebook and Instagram web endpoints for about a year. As of today about 56% of Chrome stable traffic towards our servers is using QUIC, though we do not control the sampling so we cannot make very definitive statements about improvements. We believe several factors contribute to QUIC's significant advantage. A major factor which is often overlooked on paper is QUIC's ability to utilize modern loss recovery and congestion control undisturbed by the myriad middleboxes on Internet networks. The others we all like to mention in theory clearly play a role in practice as well. The linked post is targeted at a wide audience, so it naturally may leave people with questions. I'm happy to answer and provide more detail in this forum. I'd also like to thank everyone for your tireless efforts on this protocol over the last few years. You're a remarkable group of people and I hope this serves as one among many votes of confidence in QUIC as the future of Internet transports. Thanks, Matt Joras
