在12月初舉行的CoNEXT 2018 EPIQ研討會上來自Facebook的Subodh Iyengar詳細介紹了Facebook如何在其基礎設施中使用IETF-QUIC，并且通過Android和iOS設備上的Facebook應用程序在移動客戶端上進行實驗。本文來自QUIC-Tracker的博客，LiveVideoStack進行了翻譯。

文 / QUIC-Tracker

譯/ 元寶

原文?

https://quic-tracker.info.ucl.ac.be/blog/epiq-2018/2018/12/10/epiq-2018-keynote-facebook.html

在12月的第一周，第一屆QUIC的演變，性能和互操作性研討會在克里特島Heraklion的CoNEXT 2018上舉行。我們展示了我們的論文，觀察了QUIC實現的演變，并與參加研討會的研究人員和工程師進行了討論。在這一系列的博客文章中，我們報告了研討會每個會議的摘要以及我們做的一些筆記。

主題演講：大規?？焖僖苿?/span>

在Facebook上部署IETF QUIC的經驗（Subodh Iyengar - Facebook）

經過兩位主持人約爾格·奧特(Jorg Ott，慕尼黑TU)和拉爾斯·埃格特(Lars Eggert, NetApp)簡短的介紹，當天的第一位主講人是來自Facebook的Subodh Iyengar。鑒于宣布了一個有趣的標題，但沒有摘要，這個主題演講將成為研討會的一個很好的起點。在大約一個小時內，主講人詳細介紹了Facebook如何在其基礎設施中使用IETF-QUIC，以及如何通過Android和iOS設備上的Facebook應用程序在移動客戶端上進行實驗的。

主講人概述了有關使用QUIC代替TCP的幾個要求。

• 能夠在不中斷連接的情況下更新其代理。

• 能夠始終如一地連接路由到應用程序服務器。

• 能夠使用QUIC進行連接，但回退到TCP不會影響延遲。

• 能夠檢測QUIC并獲取日志以分析性能問題。

QUIC中的零停機重啟

基于Proxygen的 Facebook代理會不斷重新啟動以更新其軟件。理想情況下，在更新期間不應關閉現有的連接。在代理更新期間建立新連接時也不會發生停機。為了實現這一點，將服務器ID編碼到所選服務器的ConnectionID中。一個位就足以區分舊服務器和新服務器。新代理實例使用此位來區分新的傳入連接與現有連接。這些現有連接是UDP封裝的，并路由到舊實例。

?

一旦所有舊連接終止，代理更新就完成了。此操作大約需要15分鐘。

QUIC數據包的穩定路由

在部署的初始階段，Facebook工程師注意到使用QUIC的連接超時率很高。他們首先懷疑是死連接導致的，但由于他們沒有實現無狀態重置機制，他們選擇這樣做是為了保證每個對等端的連接狀態視圖是同步的。他們發現他們無法將這些重置發送到正確的連接，這表明存在數據包路由問題。為了調試此問題，他們再次利用服務器選擇的ConnectionID，并保留了第二部分來指示服務器主機ID?，F在，每個服務器都能夠記錄到達錯誤目的地的數據包。

在實現了對Facebook的L3負載均衡器katran中的服務器主機ID的支持后，他們觀察到錯誤路由數據包的數量降至0。請求延遲降低了15％，表明此問題影響了相當多的連接。主講人指出，他們打算在實現多路徑和任播QUIC等期貨功能時使用這個ID。

匯集連接

他們首先分析了允許UDP連接的網絡數量。在25000家運營商中，大約有4000家沒有使用QUIC。主講人表示，這些攜帶者沒有統計學意義，但他沒有提供更準確的數字。他們的團隊聯系了他們中的一些人，詢問關于這個堵塞的問題。他們報告稱，一些運營商故意將UDP屏蔽在眾所周知的使用之外，例如DNS。其他一些人意外阻止了它。

鑒于這種觀察，他們選擇競爭QUIC和TCP，以便在回退到TCP的情況下，延遲不會受到影響。他們使用TCP和TLS 1.3 0-RTT與QUIC進行比較，因此兩者都需要相同數量的RTT才能建立連接。他們一開始采取了一種幼稚的方法，即同時啟動展位，一旦獲勝就取消另一個展位。使用這種方法，他們報告了QUIC的70％使用率。主講人指出了概率損失和TCP中間件加速可能是導致這個結果的原因。

賽車算法的第二個版本進行了實驗。在TCP連接的開始處添加了100ms的任意延遲，但沒有觀察到QUIC使用率的改善。建立連接的客戶端是移動設備，他們懷疑無線電喚醒延遲會影響他們的結果。在QUIC連接開始時，再次觀察到更高的隨機損失，它們可能歸因于中間盒。

他們的第三個版本的算法更復雜，但將QUIC利用率提高到93％。首先，如果QUIC失去競爭，則刪除TCP延遲，如果QUIC獲勝，則在后續連接上添加TCP延遲。其次，當TCP獲勝時，QUIC不再被取消，如果建立了連接，則通過QUIC發送新請求。

在結束這一節時，演示者展示了他們在匯集TCP和QUIC連接時使用的0-RTT數據。他們選擇了保守的方法，即如果TCP + TLS 1.3 0-RTT成功，則取消通過QUIC發送的請求。在QUIC上失敗的請求將在TCP上重播。

在生產中調試QUIC

就其可能的操作數量而言，QUIC是一個復雜的協議?；卮馂槭裁丛赮時刻發送X幀的問題？因此，在觀察其行為時至關重要。為了解決這個問題，主講人介紹了Facebook的QUIC跟蹤格式，它記錄了實現的內部狀態。它允許它們診斷連接生命周期中發生的幾個事件，例如擁塞窗口阻塞和丟失恢復持續時間。

他們發現恢復的ACK閾值，例如觸發快速重傳，在其使用情況下的大部分時間是不夠的，因為在接收到足夠的數據包以觸發它之前可能需要幾個RTT。他們還發現大多數時候HTTP連接都處于空閑的狀態。

結果

主題演講的最后一部分是關于性能結果的。主持人首先介紹了他們的實驗裝置。

Facebook的QUIC實現mvfst是通過Facebook應用程序和他們的proxygen服務器部署在移動客戶端上的。他們實施了草案-09，主講人指出該草案相當穩定，可以追溯到2018年1月。在進行實驗時使用了Cubic擁塞控制器，我假設它在TCP和QUIC中都有，但我的注釋中缺少這方面的內容。他們專注于API風格的請求和響應，而不是完整的HTML頁面和資產。請求大小介于247字節和13 KB之間，而響應大小則包含64字節和500 KB。

結果顯示，第75個百分位數的延遲減少了6％，第90個百分位數減少了10％，第99個百分位數減少了23％。在隔離后續請求(即在連接生命的后期發送的請求)的性能結果時觀察到這些百分比的延遲降低分別為1%、5%和15%。主講人注意到，在隔離RTT小于500ms的連接時，延遲也有類似的降低。

只顯示了相對數字，沒有給出絕對數字。主講人解釋說，他不允許分享這些數字，但他保證這些數字在實踐中具有重要意義。他在總結主題時解釋說，雖然使用早期版本的QUIC和HTTP/1.1的這些初始結果是有前途的，但是還有很多實驗需要進行。如本主題所述，大規模使用QUIC還需要對基礎設施進行重大更改。

最后，主講人展望了一些未來的工作，例如將mvfst更新為最新的QUIC規范草案，添加HTTP / 3和0-RTT支持。他們的團隊還將探索新的用例，例如實時視頻的部分可靠性和低延遲視頻傳輸。

問答環節

觀眾提出的第一個問題涉及到mvfst在TCP方面的公平性，以及如何負責大規模部署QUIC。主講人解釋說他們沒有詳細查看?？傮w而言，他們沒有觀察到與擁堵和公平相關的問題，因為通過QUIC交換的數據相對較小。主講人指出，很多連接不會退出慢啟動，因為它們的時間非常短。

觀眾還提出了一個關于CPU性能的問題。他解釋說，他們沒有調查移動客戶端對電池壽命的影響，但他們觀察到整體CPU使用率有所增加，部分原因是sendmsg調用。

下一個問題涉及在客戶端代理通信之外在其主干網內使用QUIC，以及他們在兩者之間觀察到的兩者之間的差異。主講人解釋說，他們沒有觀察到主干網CPU使用率的差異。他指出，損失率接近于0，并且連接經常在主干網中重復使用。

一個關于mvfst可用性的簡短問題被提出，主講人宣布客戶端和服務器最終都將是開源的。

觀眾席上的一個人對他們使用ConnectionID領域表示擔憂，他指出這是濫用，并且鼓勵了分層違規。主講人評論說，IP層正在開展一些工作來應對這些問題。他指出，ConnectionID除了數據包路由之外，它還可以用于其他目的。

最后一個問題是關于主干內外的QUIC如何共存。主講人介紹了邊緣代理終止與客戶端的QUIC連接，并在主干中建立新的連接的方法。

致謝

我要感謝Fran?oisMichel在本文中提供的照片，Quentin De Coninck在研討會上做的筆記，以及Robin Marx做的筆記。

精品文章推薦

技術干貨：

• RTMP之后，SRT與QUIC

• 跨國實時網絡調度系統設計

• 自建及商用CDN之間的多維度比較

• 基于HLS格式的低延時互動直播技術

• Demuxed：編解碼器和壓縮的未來

• UDP成為低延時流媒體關鍵 選SRT還是QUIC？

• 下一代低延時直播CDN：HLS、RTMP 與UDP +WebRTC

• 《周四橄欖球之夜》流媒體視頻拆解：Twitch VS Amazon Prime

總結

以上是生活随笔為你收集整理的CoNEXT 2018：在Facebook上部署IETF QUIC的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。