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

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

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

什么是QUIC和HTTP/3呢？

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

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

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

以經(jīng)驗(yàn)為導(dǎo)向的協(xié)議開(kāi)發(fā)

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

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

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

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

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

Facebook應(yīng)用程序

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

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

擴(kuò)大使用范圍

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

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

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

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

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

QUIC和TCP視頻加載時(shí)間之間的個(gè)體差異

Instagram及其他

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

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

責(zé)任編輯：lq