在12月初舉行的CoNEXT 2018 EPIQ研討會(huì)上來(lái)自Facebook的Subodh Iyengar詳細(xì)介紹了Facebook如何在其基礎(chǔ)設(shè)施中使用IETF-QUIC，并且通過(guò)Android和iOS設(shè)備上的Facebook應(yīng)用程序在移動(dòng)客戶端上進(jìn)行實(shí)驗(yàn)。本文來(lái)自QUIC-Tracker的博客，LiveVideoStack進(jìn)行了翻譯。

文 / QUIC-Tracker

譯/ 元寶

原文?

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

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

主題演講：大規(guī)模快速移動(dòng)

在Facebook上部署IETF QUIC的經(jīng)驗(yàn)（Subodh Iyengar - Facebook）

經(jīng)過(guò)兩位主持人約爾格·奧特(Jorg Ott，慕尼黑TU)和拉爾斯·埃格特(Lars Eggert, NetApp)簡(jiǎn)短的介紹，當(dāng)天的第一位主講人是來(lái)自Facebook的Subodh Iyengar。鑒于宣布了一個(gè)有趣的標(biāo)題，但沒(méi)有摘要，這個(gè)主題演講將成為研討會(huì)的一個(gè)很好的起點(diǎn)。在大約一個(gè)小時(shí)內(nèi)，主講人詳細(xì)介紹了Facebook如何在其基礎(chǔ)設(shè)施中使用IETF-QUIC，以及如何通過(guò)Android和iOS設(shè)備上的Facebook應(yīng)用程序在移動(dòng)客戶端上進(jìn)行實(shí)驗(yàn)的。

主講人概述了有關(guān)使用QUIC代替TCP的幾個(gè)要求。

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

• 能夠始終如一地連接路由到應(yīng)用程序服務(wù)器。

• 能夠使用QUIC進(jìn)行連接，但回退到TCP不會(huì)影響延遲。

• 能夠檢測(cè)QUIC并獲取日志以分析性能問(wèn)題。

QUIC中的零停機(jī)重啟

基于Proxygen的 Facebook代理會(huì)不斷重新啟動(dòng)以更新其軟件。理想情況下，在更新期間不應(yīng)關(guān)閉現(xiàn)有的連接。在代理更新期間建立新連接時(shí)也不會(huì)發(fā)生停機(jī)。為了實(shí)現(xiàn)這一點(diǎn)，將服務(wù)器ID編碼到所選服務(wù)器的ConnectionID中。一個(gè)位就足以區(qū)分舊服務(wù)器和新服務(wù)器。新代理實(shí)例使用此位來(lái)區(qū)分新的傳入連接與現(xiàn)有連接。這些現(xiàn)有連接是UDP封裝的，并路由到舊實(shí)例。

?

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

QUIC數(shù)據(jù)包的穩(wěn)定路由

在部署的初始階段，Facebook工程師注意到使用QUIC的連接超時(shí)率很高。他們首先懷疑是死連接導(dǎo)致的，但由于他們沒(méi)有實(shí)現(xiàn)無(wú)狀態(tài)重置機(jī)制，他們選擇這樣做是為了保證每個(gè)對(duì)等端的連接狀態(tài)視圖是同步的。他們發(fā)現(xiàn)他們無(wú)法將這些重置發(fā)送到正確的連接，這表明存在數(shù)據(jù)包路由問(wèn)題。為了調(diào)試此問(wèn)題，他們?cè)俅卫梅?wù)器選擇的ConnectionID，并保留了第二部分來(lái)指示服務(wù)器主機(jī)ID。現(xiàn)在，每個(gè)服務(wù)器都能夠記錄到達(dá)錯(cuò)誤目的地的數(shù)據(jù)包。

在實(shí)現(xiàn)了對(duì)Facebook的L3負(fù)載均衡器katran中的服務(wù)器主機(jī)ID的支持后，他們觀察到錯(cuò)誤路由數(shù)據(jù)包的數(shù)量降至0。請(qǐng)求延遲降低了15％，表明此問(wèn)題影響了相當(dāng)多的連接。主講人指出，他們打算在實(shí)現(xiàn)多路徑和任播QUIC等期貨功能時(shí)使用這個(gè)ID。

匯集連接

他們首先分析了允許UDP連接的網(wǎng)絡(luò)數(shù)量。在25000家運(yùn)營(yíng)商中，大約有4000家沒(méi)有使用QUIC。主講人表示，這些攜帶者沒(méi)有統(tǒng)計(jì)學(xué)意義，但他沒(méi)有提供更準(zhǔn)確的數(shù)字。他們的團(tuán)隊(duì)聯(lián)系了他們中的一些人，詢問(wèn)關(guān)于這個(gè)堵塞的問(wèn)題。他們報(bào)告稱，一些運(yùn)營(yíng)商故意將UDP屏蔽在眾所周知的使用之外，例如DNS。其他一些人意外阻止了它。

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

賽車算法的第二個(gè)版本進(jìn)行了實(shí)驗(yàn)。在TCP連接的開(kāi)始處添加了100ms的任意延遲，但沒(méi)有觀察到QUIC使用率的改善。建立連接的客戶端是移動(dòng)設(shè)備，他們懷疑無(wú)線電喚醒延遲會(huì)影響他們的結(jié)果。在QUIC連接開(kāi)始時(shí)，再次觀察到更高的隨機(jī)損失，它們可能歸因于中間盒。

他們的第三個(gè)版本的算法更復(fù)雜，但將QUIC利用率提高到93％。首先，如果QUIC失去競(jìng)爭(zhēng)，則刪除TCP延遲，如果QUIC獲勝，則在后續(xù)連接上添加TCP延遲。其次，當(dāng)TCP獲勝時(shí)，QUIC不再被取消，如果建立了連接，則通過(guò)QUIC發(fā)送新請(qǐng)求。

在結(jié)束這一節(jié)時(shí)，演示者展示了他們?cè)趨R集TCP和QUIC連接時(shí)使用的0-RTT數(shù)據(jù)。他們選擇了保守的方法，即如果TCP + TLS 1.3 0-RTT成功，則取消通過(guò)QUIC發(fā)送的請(qǐng)求。在QUIC上失敗的請(qǐng)求將在TCP上重播。

在生產(chǎn)中調(diào)試QUIC

就其可能的操作數(shù)量而言，QUIC是一個(gè)復(fù)雜的協(xié)議。回答為什么在Y時(shí)刻發(fā)送X幀的問(wèn)題？因此，在觀察其行為時(shí)至關(guān)重要。為了解決這個(gè)問(wèn)題，主講人介紹了Facebook的QUIC跟蹤格式，它記錄了實(shí)現(xiàn)的內(nèi)部狀態(tài)。它允許它們?cè)\斷連接生命周期中發(fā)生的幾個(gè)事件，例如擁塞窗口阻塞和丟失恢復(fù)持續(xù)時(shí)間。

他們發(fā)現(xiàn)恢復(fù)的ACK閾值，例如觸發(fā)快速重傳，在其使用情況下的大部分時(shí)間是不夠的，因?yàn)樵诮邮盏阶銐虻臄?shù)據(jù)包以觸發(fā)它之前可能需要幾個(gè)RTT。他們還發(fā)現(xiàn)大多數(shù)時(shí)候HTTP連接都處于空閑的狀態(tài)。

結(jié)果

主題演講的最后一部分是關(guān)于性能結(jié)果的。主持人首先介紹了他們的實(shí)驗(yàn)裝置。

Facebook的QUIC實(shí)現(xiàn)mvfst是通過(guò)Facebook應(yīng)用程序和他們的proxygen服務(wù)器部署在移動(dòng)客戶端上的。他們實(shí)施了草案-09，主講人指出該草案相當(dāng)穩(wěn)定，可以追溯到2018年1月。在進(jìn)行實(shí)驗(yàn)時(shí)使用了Cubic擁塞控制器，我假設(shè)它在TCP和QUIC中都有，但我的注釋中缺少這方面的內(nèi)容。他們專注于API風(fēng)格的請(qǐng)求和響應(yīng)，而不是完整的HTML頁(yè)面和資產(chǎn)。請(qǐng)求大小介于247字節(jié)和13 KB之間，而響應(yīng)大小則包含64字節(jié)和500 KB。

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

只顯示了相對(duì)數(shù)字，沒(méi)有給出絕對(duì)數(shù)字。主講人解釋說(shuō)，他不允許分享這些數(shù)字，但他保證這些數(shù)字在實(shí)踐中具有重要意義。他在總結(jié)主題時(shí)解釋說(shuō)，雖然使用早期版本的QUIC和HTTP/1.1的這些初始結(jié)果是有前途的，但是還有很多實(shí)驗(yàn)需要進(jìn)行。如本主題所述，大規(guī)模使用QUIC還需要對(duì)基礎(chǔ)設(shè)施進(jìn)行重大更改。

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

問(wèn)答環(huán)節(jié)

觀眾提出的第一個(gè)問(wèn)題涉及到mvfst在TCP方面的公平性，以及如何負(fù)責(zé)大規(guī)模部署QUIC。主講人解釋說(shuō)他們沒(méi)有詳細(xì)查看。總體而言，他們沒(méi)有觀察到與擁堵和公平相關(guān)的問(wèn)題，因?yàn)橥ㄟ^(guò)QUIC交換的數(shù)據(jù)相對(duì)較小。主講人指出，很多連接不會(huì)退出慢啟動(dòng)，因?yàn)樗鼈兊臅r(shí)間非常短。

觀眾還提出了一個(gè)關(guān)于CPU性能的問(wèn)題。他解釋說(shuō)，他們沒(méi)有調(diào)查移動(dòng)客戶端對(duì)電池壽命的影響，但他們觀察到整體CPU使用率有所增加，部分原因是sendmsg調(diào)用。

下一個(gè)問(wèn)題涉及在客戶端代理通信之外在其主干網(wǎng)內(nèi)使用QUIC，以及他們?cè)趦烧咧g觀察到的兩者之間的差異。主講人解釋說(shuō)，他們沒(méi)有觀察到主干網(wǎng)CPU使用率的差異。他指出，損失率接近于0，并且連接經(jīng)常在主干網(wǎng)中重復(fù)使用。

一個(gè)關(guān)于mvfst可用性的簡(jiǎn)短問(wèn)題被提出，主講人宣布客戶端和服務(wù)器最終都將是開(kāi)源的。

觀眾席上的一個(gè)人對(duì)他們使用ConnectionID領(lǐng)域表示擔(dān)憂，他指出這是濫用，并且鼓勵(lì)了分層違規(guī)。主講人評(píng)論說(shuō)，IP層正在開(kāi)展一些工作來(lái)應(yīng)對(duì)這些問(wèn)題。他指出，ConnectionID除了數(shù)據(jù)包路由之外，它還可以用于其他目的。

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

致謝

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

精品文章推薦

技術(shù)干貨：

• RTMP之后，SRT與QUIC

• 跨國(guó)實(shí)時(shí)網(wǎng)絡(luò)調(diào)度系統(tǒng)設(shè)計(jì)

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

• 基于HLS格式的低延時(shí)互動(dòng)直播技術(shù)

• Demuxed：編解碼器和壓縮的未來(lái)

• UDP成為低延時(shí)流媒體關(guān)鍵 選SRT還是QUIC？

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

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

總結(jié)

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

如果覺(jué)得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。