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

Facebook正在使用QUIC取代互聯網幾十年來一直沿用的默認協議，這是我們最新的網絡協議優化策略，同時也是最激進的一步，目的還是為了進一步提高我們的服務的用戶體驗。

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

什么是QUIC和HTTP/3呢？

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

HTTP/3是HTTP的新一代迭代，它是基于網絡的應用程序和服務器之間通信的標準協議。綜合Facebook、谷歌和IETF社區數十年來在互聯網上運行協議獲得的最佳實踐經驗和教訓，QUIC和HTTP/3共同代表了最新且最強大的以互聯網為中心的協議。

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

以經驗為導向的協議開發

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

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

從頭開始開發和部署新的傳輸協議

我們希望新協議能夠與現有的軟件無縫集成，并且幫助Facebook的開發人員更高效地工作。作為一個試驗場，我們決定將QUIC部署在Facebook的相當一部分網絡流量上，尤其包括指向Facebook的公共代理流量在內的內部網絡流量。假如QUIC不能很好地處理內部流量，我們便可以確定它在更廣闊的互聯網上效果也不會太好。

除開能暴露錯誤及其他有問題的行為之外，通過這種策略，我們可以設計一種方法，使我們的網絡負載均衡器對QUIC深度了解，并使得負載均衡器的零停機釋放得到保證。 有了這個堅實的基礎，我們開始向互聯網上的用戶部署QUIC。基于mvfst的設計，我們能夠將QUIC支持平穩地集成到Proxygen Mobile中。

Facebook應用程序

部署到Facebook應用程序是我們在互聯網上使用QUIC的第一個目標。Facebook擁有成熟的基礎架構，可以讓我們在向數十億人發布應用程序之前，以有限的方式安全地推出應用程序的更新。

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

擴大使用范圍

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

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

QUIC針對所有內容

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

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

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

Instagram及其他

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

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

責任編輯：lq