隨著IETF很快完成QUIC標準定稿，越來越多的企業(yè)和開發(fā)者投入到QUIC開發(fā)實現(xiàn)與部署中。阿里巴巴實現(xiàn)了XQUIC；B站、快手在2019年就公開了QUIC的應(yīng)用實踐；Akamai等CDN服務(wù)商則很早就開始擁抱QUIC，并提供相應(yīng)的支持。本文來自Facebook的工程博客，詳細介紹了Facebook是如何將其3/4的流量切換到QUIC上的。

Facebook正在使用QUIC取代互聯(lián)網(wǎng)幾十年來一直沿用的默認協(xié)議，這是我們最新的網(wǎng)絡(luò)協(xié)議優(yōu)化策略，同時也是最激進的一步，目的還是為了進一步提高我們的服務(wù)的用戶體驗。

今天，QUIC和HTTP/3在我們的互聯(lián)網(wǎng)通信中使用率超過75%（我們將QUIC和HTTP/3統(tǒng)稱為QUIC）。QUIC已經(jīng)顯著地改善多個指標，包括請求錯誤、尾延遲（Tail Latency）、響應(yīng)頭大小以及各種其他影響我們應(yīng)用程序用戶體驗相關(guān)的參數(shù)。 互聯(lián)網(wǎng)工程任務(wù)組（IETF）目前正在為QUIC和HTTP/3開發(fā)標準。

什么是QUIC和HTTP/3呢？

從廣義上講，QUIC替代了傳輸控制協(xié)議（TCP），后者是互聯(lián)網(wǎng)通信的主要協(xié)議之一。QUIC最初由谷歌公司內(nèi)部研發(fā)，稱為GoogleQUIC，或gQUIC，于2015年提交給IETF。從那之后，更廣大的IETF社區(qū)對其進行了重新設(shè)計與改進，形成了一個新的協(xié)議，也就是我們現(xiàn)在所說的QUIC。

HTTP/3是HTTP的新一代迭代，它是基于網(wǎng)絡(luò)的應(yīng)用程序和服務(wù)器之間通信的標準協(xié)議。綜合Facebook、谷歌和IETF社區(qū)數(shù)十年來在互聯(lián)網(wǎng)上運行協(xié)議獲得的最佳實踐經(jīng)驗和教訓，QUIC和HTTP/3共同代表了最新且最強大的以互聯(lián)網(wǎng)為中心的協(xié)議。

QUIC和HTTP/3整體優(yōu)于TCP和HTTP/2，后者則跑贏了TCP和HTTP/1.1。TCP和HTTP/2首先引入了流多路復(fù)用的概念，在同一進程中，允許單個網(wǎng)絡(luò)連接服務(wù)多個數(shù)據(jù)流。QUIC和HTTP / 3在此基礎(chǔ)上更進一步，通過避免TCP可怕的隊頭阻塞 （隊頭阻塞時，丟失的數(shù)據(jù)包發(fā)生阻塞同時導致連接上的所有流變慢），從而使得流真正獨立。 QUIC采用了最先進的丟失恢復(fù)技術(shù)，在惡劣的網(wǎng)絡(luò)條件下，這能使得它在大多數(shù)情況下性能跑贏TCP協(xié)議實現(xiàn)。TCP也容易僵化，因為防火墻等網(wǎng)絡(luò)中間件對數(shù)據(jù)包的格式做了假設(shè)，TCP協(xié)議很難進行升級，QUIC通過完全加密功能避免了這個問題，使得協(xié)議的可擴展性走向最佳，同時保證將來可以進行改進。QUIC還可以通過QLOG（一種專門為QUIC設(shè)計的基于JSON的跟蹤格式）來檢測、觀察和可視化展示傳輸行為。

以經(jīng)驗為導向的協(xié)議開發(fā)

Facebook開發(fā)了自己的QUIC實現(xiàn)，我們稱之為mvfst，以便在我們自己的系統(tǒng)上快速測試和部署QUIC。我們有編寫和部署自己的協(xié)議實現(xiàn)的經(jīng)驗，首先部署我們的HTTP客戶機/服務(wù)器庫Proxygen，緊接著是Zero協(xié)議，最后是Fizz（我們的TLS1.3實現(xiàn)）。

Facebook應(yīng)用程序運用Fizz和Proxygen通過Proxygen Mobile與服務(wù)器進行通信。我們還為TLS開發(fā)了一個名為delegated credentials的擴展程序，提供兩方面安全解決方案，一方面可用于保護TLS上的證書和DNS，另一方面也可用于加密和驗證TLS上的web流量。

從頭開始開發(fā)和部署新的傳輸協(xié)議

我們希望新協(xié)議能夠與現(xiàn)有的軟件無縫集成，并且?guī)椭鶩acebook的開發(fā)人員更高效地工作。作為一個試驗場，我們決定將QUIC部署在Facebook的相當一部分網(wǎng)絡(luò)流量上，尤其包括指向Facebook的公共代理流量在內(nèi)的內(nèi)部網(wǎng)絡(luò)流量。假如QUIC不能很好地處理內(nèi)部流量，我們便可以確定它在更廣闊的互聯(lián)網(wǎng)上效果也不會太好。

除開能暴露錯誤及其他有問題的行為之外，通過這種策略，我們可以設(shè)計一種方法，使我們的網(wǎng)絡(luò)負載均衡器對QUIC深度了解，并使得負載均衡器的零停機釋放得到保證。 有了這個堅實的基礎(chǔ)，我們開始向互聯(lián)網(wǎng)上的用戶部署QUIC?；趍vfst的設(shè)計，我們能夠?qū)UIC支持平穩(wěn)地集成到Proxygen Mobile中。

Facebook應(yīng)用程序

部署到Facebook應(yīng)用程序是我們在互聯(lián)網(wǎng)上使用QUIC的第一個目標。Facebook擁有成熟的基礎(chǔ)架構(gòu)，可以讓我們在向數(shù)十億人發(fā)布應(yīng)用程序之前，以有限的方式安全地推出應(yīng)用程序的更新。

我們從一個實驗入手，在Facebook應(yīng)用程序的動態(tài)GraphQL請求中啟用了QUIC。在這些請求的響應(yīng)中，沒有圖像和視頻之類的靜態(tài)內(nèi)容。 我們的測試表明，運用QUIC使得多個指標有所提升。Facebook用戶的請求錯誤率下降了6%，尾延遲下降了20%，響應(yīng)頭大小相較于HTTP/2縮小了5%。同時這也對其他指標產(chǎn)生了級聯(lián)效應(yīng)，可以說QUIC極大地提高了用戶的體驗。 然而，QUIC的應(yīng)用相較TCP也有倒退之處。最令人費解的是，盡管僅在動態(tài)請求時啟用QUIC，然而我們發(fā)現(xiàn)使用TCP下載的靜態(tài)內(nèi)容的錯誤率卻增加了。其根本原因是我們在將流量轉(zhuǎn)換到QUIC時遇到的一個常見問題：應(yīng)用程序的邏輯是，根據(jù)不同類型內(nèi)容的請求的速度和可靠性，切換請求的類型和數(shù)量以處理相應(yīng)的類型內(nèi)容。于是乎，改進一種請求類型可能會對其他類型產(chǎn)生糟糕的副作用。 再如，QUIC帶來的另一些麻煩，適應(yīng)應(yīng)用程序從服務(wù)器請求新靜態(tài)內(nèi)容的積極性的啟發(fā)式算法將隨著QUIC的使用而發(fā)生改變，當應(yīng)用程序發(fā)出一個請求時，比方說，當加載News Feed的文本內(nèi)容時，需要觀察這個請求耗時多久，然后再決定發(fā)出多少圖像/視頻請求。 我們發(fā)現(xiàn)啟發(fā)式算法策略可能對TCP比較有效，它是用任意閾值進行調(diào)整的。但是當我們切換到QUIC時，這些閾值變得不準確，應(yīng)用程序可能一次發(fā)送請求過多，最終導致News Feed的加載時間進一步加長。

擴大使用范圍

下一步是為Facebook應(yīng)用中的靜態(tài)內(nèi)容部署QUIC(如：圖片和視頻）。然而，在此之前，我們必須解決兩個重點問題：mvfst的CPU效率以及我們的主要擁塞控制實現(xiàn)的有效性與BBR。

到目前為止，mvfst的設(shè)計初衷是幫助開發(fā)人員靈活開發(fā)并跟上不斷變化的QUIC草案。與靜態(tài)請求相比，動態(tài)請求的響應(yīng)相對較小，它不需要占用大量的CPU，也不需要擁塞控制器來控制其進度。 為了解決這些問題，我們開發(fā)了性能測試工具，用以幫助我們評估CPU的使用情況并有效地運用擁塞控制器來管理網(wǎng)絡(luò)資源。 我們在負載均衡器中綜合使用了QUIC的負載測試和這些性能測試工具，取得了一些成果。一個重要的方向——例如——優(yōu)化我們調(diào)整UDP數(shù)據(jù)包的效率，以保證數(shù)據(jù)傳輸更加平滑。為了提高CPU的使用率，我們采用了不少技術(shù)，諸如使用通用分段延后處理（GSO）來一次高效地發(fā)送多個UDP包。我們還對處理未確認的QUIC數(shù)據(jù)使用的數(shù)據(jù)結(jié)構(gòu)和算法進行了優(yōu)化。

QUIC針對所有內(nèi)容

在為Facebook應(yīng)用程序中的所有內(nèi)容啟用QUIC之前，我們先與包括我們的視頻工程師在內(nèi)的幾個利益相關(guān)者展開合作。他們對重要的產(chǎn)品指標有著深刻的理解，能夠在我們啟用QUIC時幫助我們分析Facebook應(yīng)用程序中的實驗性結(jié)果。

實驗表明，QUIC對Facebook應(yīng)用中的視頻相關(guān)的指標有著革命性的影響。根據(jù)平臺的不同，體現(xiàn)出緩沖事件間隔耗時指標的平均重新緩沖時間（MTBR）總體上提高了22%。視頻請求的總體錯誤量減少了8%。視頻卡頓率降低了20％。 包括元指標在內(nèi)的其他幾個指標，考慮到各種因素，特別是異常情況，也得到了顯著改善。QUIC改善了視頻觀看體驗，對網(wǎng)絡(luò)條件相對較差的地區(qū)，尤其是新興市場，產(chǎn)生了巨大的影響。 然而，能達到這樣的成就，一路上也是困難重重。一如我們在動態(tài)內(nèi)容方面的經(jīng)歷，我們在應(yīng)用程序中發(fā)現(xiàn)了針對TCP行為進行調(diào)整的啟發(fā)式方法。例如，iOS和Android上的應(yīng)用程序有不同的機制來估計可用的下載帶寬。當使用QUIC時，這些估計器有時會高估可用帶寬，導致應(yīng)用程序播放的視頻質(zhì)量高于網(wǎng)絡(luò)所能支持的質(zhì)量，從而引起視頻卡頓。 我們還需要調(diào)整流控制參數(shù)并繼續(xù)迭代它。流控制限制了接收者期望從發(fā)送者那里緩存到的數(shù)據(jù)量。Facebook應(yīng)用程序?qū)TTP/2有一個靜態(tài)定義的流控制限制，該限制是針對TCP進行的隱藏式優(yōu)化，不過在QUIC中表現(xiàn)不太好。為了找到新的最優(yōu)流量控制值，我們需要進行一些實驗性迭代。

QUIC和TCP視頻加載時間之間的個體差異

Instagram及其他

即使是在Facebook這樣豐富復(fù)雜的應(yīng)用程序上，QUIC也被證明能夠有效改善人們在互聯(lián)網(wǎng)上的體驗。在未來，我們計劃繼續(xù)利用更多QUIC的已有功能，比如連接遷移和真正的0-RTT連接創(chuàng)建，并致力于改善擁塞控制和損失恢復(fù)。

我們也在Instagram中部署了QUIC，使用了與Facebook部署相同的策略——先在Instagram的一小部分流量上進行測試，然后進一步大規(guī)模使用。 如今，QUIC已經(jīng)部署到了Instagram的iOS和安卓版本上。Instagram的兩個版本的相關(guān)指標的優(yōu)化成果都達到甚至超越了我們先前在Facebook應(yīng)用程序上取得的收獲。 Facebook和Instagram的網(wǎng)頁版上也啟用了QUIC，隨著更多的web瀏覽器開始支持QUIC——如最近谷歌對Chrome和蘋果對Safari beta所做的改進——越來越多的用戶將從中受益。 除了Instagram之外，我們相信我們有能力將QUIC的優(yōu)勢帶到Facebook應(yīng)用家族中的所有應(yīng)用的每一次體驗中去，QUIC最終將不僅代表Facebook的大部分互聯(lián)網(wǎng)流量，而是代表Facebook的所有互聯(lián)網(wǎng)流量。 IETF有望在2021年某個時間點完成對QUIC協(xié)議的征求意見文檔（RFC）的定稿。到那時候，會有更多的網(wǎng)站、應(yīng)用程序和網(wǎng)絡(luò)庫提供通用的QUIC。在不久的將來，像QUIC這樣的新協(xié)議將是解鎖互聯(lián)網(wǎng)應(yīng)用創(chuàng)新的關(guān)鍵。對我們來說，QUIC則是一個起點，我們將繼續(xù)提升人們在Facebook上的用戶體驗。 在Facebook內(nèi)外，有太多的人共同努力促成了QUIC的成功部署。我們要感謝在過去幾年中參與IETF QUIC工作組的所有成員，感謝他們對QUIC不懈地探討與設(shè)計。IETF QUIC工作組由許多不同背景的成員組成，他們在相對較短的時間內(nèi)制定出了一項真正稱得上卓越的網(wǎng)絡(luò)協(xié)議。

責任編輯：lq