Facebook現在大部分流量都使用QUIC和HTTP/3

什麼是QUIC和HTTP / 3？
從廣義上講，QUIC替代了傳輸控制協議（TCP），後者是Internet通訊的主要協議之一。QUIC最初由Google內部開發，稱為Google QUIC或gQUIC，並於2015年提交給IETF。此後，IETF社群對其進行了重新設計和改進，形成了我們現在稱為QUIC的新協議。HTTP / 3是 HTTP的下一個迭代，HTTP是基於Web的應用程式和伺服器的標準協議。QUIC和HTTP / 3共同代表了以網際網路為中心的協議中最新，最先進的技術，並結合了我們，Google和IETF社群透過在網際網路上執行協議而學到的數十年的最佳實踐和經驗教訓。
QUIC和HTTP / 3通常勝過TCP和HTTP / 2，而後者又勝過TCP和HTTP / 1.1。TCP和HTTP / 2首先引入了在稱為流多路複用的過程中允許單個網路連線支援多個資料流的概念。QUIC和HTTP / 3進一步邁出了這一步，它透過避免TCP可怕的行阻塞（使丟失的資料包阻塞並使連線上的所有流變慢）而使流真正獨立，從而使流真正獨立。
QUIC採用最先進的丟失恢復功能，因此在惡劣的網路條件下，它的效能比大多數TCP實現要好。TCP也容易僵化，協議難以升級，因為防火牆等網路中間盒對資料包的格式進行了假設。QUIC透過完全加密來避免此問題，使協議可擴充套件性成為頭等公民，並保證將來可以進行改進。QUIC還允許透過QLOG（一種專門為QUIC設計的基於JSON的跟蹤格式）來檢測，觀察和視覺化傳輸行為的新方法。
 

以經驗為中心的協議開發
我們開發了自己的稱為mvfst的QUIC實現，以便在我們自己的系統上快速測試和部署QUIC。我們擁有編寫和部署自己的協議實現的歷史，首先使用我們的HTTP客戶端/伺服器庫Proxygen，然後使用Zero協議，然後使用TLS 1.3實現Fizz。Facebook應用程式利用Fizz和Proxygen透過Proxygen Mobile與我們的伺服器進行通訊。我們還為TLS開發了兩種安全解決方案，即稱為委託憑據的擴充套件，用於保護TLS上的證書和DNS，以透過TLS加密和認證網路流量。
 

從頭開始開發和部署新的傳輸協議
我們希望新協議能夠與現有軟體無縫整合，並允許我們的開發人員快速工作。作為一個試驗場，我們決定將QUIC部署在Facebook網路流量的很大一部分上，特別是內部網路流量，其中包括到Facebook的代理公共流量。如果QUIC對於內部流量來說效果不佳，我們知道在較大的網際網路上也可能效果不佳。
除了消除錯誤和其他有問題的行為外，該策略還讓我們設計了一種方法，該方法可使我們的網路負載平衡器對QUIC有深刻的瞭解，並保持負載平衡器的零停機時間釋放保證。
有了這個堅實的基礎，我們便開始向網際網路上的人們部署QUIC。由於mvfst的設計，我們能夠將QUIC支援平穩地整合到Proxygen Mobile中。
 

Facebook應用
Facebook應用程式是我們在網際網路上使用QUIC的第一個目標。Facebook擁有成熟的基礎架構，使我們能夠以有限的方式安全地釋出對應用程式的更改，然後再將其釋出給數十億人。我們從一個實驗開始，在該實驗中，我們為Facebook應用程式中的動態GraphQL請求啟用了QUIC 。這些請求在響應中沒有靜態內容，例如影像和影片。
我們的測試表明，QUIC在幾個指標上提供了改進。與HTTP / 2相比，Facebook上的人們的請求錯誤減少了6％，尾部等待時間減少了20％，響應頭大小減少了5％。這也對其他指標產生了級聯影響，表明QUIC大大提高了人們的體驗。
但是，存在迴歸。最令人困惑的是，儘管僅對動態請求啟用了QUIC，但我們發現使用TCP下載的靜態內容的錯誤率有所增加。根本原因是當我們將流量轉換為QUIC時遇到的一個常見主題：應用程式邏輯正在根據對其他型別內容的請求的速度和可靠性來更改對某些型別內容的請求的型別和數量。因此，改進一種請求可能會對其他請求產生不利影響。
例如，一種啟發式方法可以適應應用程式向伺服器請求新靜態內容的積極程度，從而以QUIC產生問題的方式進行調整。當應用發出請求（例如，載入新聞訂閱源的文字內容）時，它會等待檢視該請求花費的時間，然後確定從那裡發出多少影像/影片請求。我們發現啟發式方法已使用任意閾值進行了調整，這對於TCP來說可能效果很好。但是，當我們切換到QUIC時，這些閾值是不準確的，並且該應用嘗試一次請求太多，最終導致新聞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上表現不佳。我們花了一些實驗迭代才能找到新的最佳流量控制值。

 

Instagram
QUIC在Facebook應用程式上的效能證明了其改善人們在網際網路上的體驗的能力，即使在像Facebook這樣豐富而複雜的應用程式上也是如此。將來，我們計劃繼續利用QUIC的更多現有功能，例如連線遷移和真正的0-RTT連線建立，並投資改善擁塞控制和丟失恢復。
我們也使用與Facebook部署相同的策略，將QUIC部署到Instagram應用程式上-對Instagram流量的一小部分進行測試，然後進行擴充套件。如今，QUIC已部署在iOS的Instagram和Android的Instagram上。Instagram的兩個版本都具有與Facebook應用程式相當或更好的指標。網路上的Facebook和Instagram也啟用了QUIC，因此，隨著越來越多的網路瀏覽器啟用對QUIC的支援，就像Google最近針對Chrome所做的和Apple針對Safari beta所做的那樣，更多的人將從中受益。除Instagram外，我們相信我們可以將QUIC的優勢帶入我們應用程式系列的每一種體驗中，而QUIC最終不僅代表了Facebook的網際網路流量的絕大部分，而且還代表了整個網際網路流量的全部。 
IETF有望在2021年某個時候最終完成QUIC協議，作為徵求意見（RFC）檔案。一旦發生這種情況，更多的網站，應用程式和網路庫將開始提供通用的QUIC。在不久的將來，像QUIC這樣的新協議對於解鎖創新的網際網路應用將至關重要。對於我們來說，QUIC是一個起點，我們可以從此起點繼續增強人們的Facebook體驗。