注明： 本文翻譯自The QUIC Transport Protocol: Design and Internet-Scale Deployment.
摘要
????基于我們的經(jīng)驗味抖，QUIC協(xié)議是一個加密的神郊、多路復(fù)用的躯畴、低延時的傳輸協(xié)議，它被設(shè)計用于提高HTTPS的傳輸效率進而使得快速部署和持續(xù)進化成為可能糖埋。 QUIC已經(jīng)在Google的成千上萬臺服務(wù)器上部署了，并且已經(jīng)用于為包括像Chrome和YouTube在內(nèi)的許多客戶端提供服務(wù)。 我們估計現(xiàn)在的網(wǎng)絡(luò)流量的7%是QUIC提供的磷蛹。我們想要敘述我們開發(fā)新的傳輸協(xié)議的動機、設(shè)計這個協(xié)議的原則和用于對QUIC進行迭代實驗的互聯(lián)網(wǎng)規(guī)南荆化處理味咳、性能的較大提升和我們?nèi)娌渴餛UIC的經(jīng)驗庇勃。我們還想分享從部署的過程中學習到的傳輸協(xié)議的設(shè)計和互聯(lián)網(wǎng)生態(tài)系統(tǒng)。
1. 簡介
????QUIC作為一個新的傳輸協(xié)議槽驶，有效的提高了HTTPS的傳輸效率并且可以快速部署和持續(xù)的進化责嚷。 QUIC替換了大多數(shù)傳統(tǒng)的HTTPS協(xié)議棧： HTTP/2，TLS 和TCP(如圖1)掂铐。 QUIC是基于UDP開發(fā)的一個用戶空間的協(xié)議罕拂。 在用戶空間實現(xiàn)該協(xié)議能夠像其他應(yīng)用程序那樣快速的部署并且能夠在應(yīng)用程序的更新過程中迭代。使用UDP能夠讓QUIC的包能夠穿過協(xié)議棧的中間層全陨。 QUIC是一個加密的傳輸協(xié)議： 數(shù)據(jù)包都進行了認證和加密爆班，可以防止被修改并且限制通過中間協(xié)議層限制協(xié)議的僵化。 QUIC通過使用服務(wù)端已知的證書來加密握手連接并且通過移除在多層網(wǎng)絡(luò)協(xié)議棧中的握手使得握手連接的延時最小化辱姨。QUIC通過使用輕量的數(shù)據(jù)結(jié)構(gòu)抽象和流的概念解決了隊頭阻塞的延遲問題柿菩。多個流在一個連接中能夠多路復(fù)用，使得一個包的丟失只會block當前流雨涛。
????在服務(wù)端側(cè)枢舶， 我們的經(jīng)驗來自在Google的前端服務(wù)器上部署QUIC， 這些服務(wù)器每天處理幾十億次的請求替久，這些請求來自各種瀏覽器和移動app上的廣泛的服務(wù)凉泄。在客戶端，我們已經(jīng)在Chrome侣肄、YouTube和安卓上的搜索app上部署了QUIC旧困。我們發(fā)現(xiàn)平均情況下，QUIC能夠減少Google搜索百分之8的延遲稼锅，減少移動用戶3.6%的延遲吼具，對于YouTube用戶，減少rebuffer操作的延遲矩距，桌面用戶能夠減少18%拗盒，移動用戶減少15.3%。 如圖2所示锥债， QUIC廣泛的部署了陡蝇，當前Google向外提供服務(wù)的服務(wù)器有大約30%已經(jīng)部署了QUIC， 整個互聯(lián)網(wǎng)大約有7%使用了QUIC哮肚。
????我們在2013年就啟動了一個QUIC的早期版本作為實驗登夫。 經(jīng)過對協(xié)議多次 的迭代并且跟蹤部署該協(xié)議超過三年的時間，組成了一個IETF的工作小組去將其標準化允趟。在我們的部署中恼策，QUIC是一個龐大的協(xié)議， 但是IETF的標準化工作將會將其模塊化為多個組成部分潮剪。 除了核心協(xié)議的劃分和指定工作涣楷， IETF的工作將會描述一個HTTP到QUIC的明確映射篡九，并分隔和替換QUIC基于最新的TLS 1.3的加密握手堤撵。 這篇文章描述了IETF之前的對QUIC協(xié)議的設(shè)計和部署工作晚凿。 QUIC協(xié)議的細節(jié)將會隨著IETF的工作的細化而改變补疑。 我們希望協(xié)議的核心設(shè)計和性能表現(xiàn)能夠保持原樣。
????在這篇文章中碳褒， 我們經(jīng)常穿插關(guān)于這個協(xié)議的討論以及在HTTPS協(xié)議棧中如何使用還有協(xié)議的具體實現(xiàn)折砸。在我們之前的工作經(jīng)驗中，這三點是相輔相成的骤视。 這篇文章試圖清晰的反映它們之間的關(guān)系鞍爱。
2. 動機： 為什么是QUIC？
????延時敏感的web服務(wù)的使用以及作為應(yīng)用程序平臺的web的快速增長专酗，促進了在降低延時方面的空前巨大的要求睹逃。 Web延時在提高用戶體驗中依然還是一個阻礙， tail latency依然是擴展web平臺的一個阻礙祷肯。 與此同時沉填，互聯(lián)網(wǎng)正在快速的從不安全的傳輸轉(zhuǎn)向安全傳輸， 這個轉(zhuǎn)變的過程中就增加了延時佑笋。舉一個通常的例子翼闹， 圖3展示了Google的安全傳輸怎樣在很短的一段時間內(nèi)喜劇般的增長，這全都歸功于Google的服務(wù)采用HTTPS的傳輸方式蒋纬。在傳輸機制方面降低延時的努力通沉攒快速進入了TLS/TCP生態(tài)系統(tǒng)的基本限制。
????協(xié)議保障： 盡管在TCP的簡單服務(wù)之下蜀备，新的傳輸協(xié)議已經(jīng)被指定來滿足應(yīng)用程序的進化要求关摇，但是它們沒有被廣泛部署。 當前的網(wǎng)絡(luò)架構(gòu)中的中間層意外的成為了關(guān)鍵的控制點： 防火墻處于安全的因素會傾向于阻止所有異常的訪問并且NAT協(xié)議會重寫傳輸協(xié)議的頭部碾阁，使得兩者都無法在不添加對它們明確支持的情況下允許來自新傳輸?shù)牧髁俊?任何包中的內(nèi)容都不會被從端到端的保護输虱， 例如TCP包的頭部，對于在協(xié)議棧的中間層中進行檢查和修改變得很公平脂凶。 因此宪睹， 由于middleboxes的固化，導致甚至只修改TCP協(xié)議也會面臨巨大的挑戰(zhàn)蚕钦。 對TCP的修改已經(jīng)達到了收益遞減的時點亭病， 現(xiàn)在簡單的協(xié)議修改也預(yù)計需要十年的時間來進行部署。
? ? 實現(xiàn)保障： 隨著互聯(lián)網(wǎng)的持續(xù)進化和各種對各種基礎(chǔ)設(shè)施的多種攻擊（包括傳輸?shù)牟糠郑?這樣就需要能夠快速的部署到客戶端嘶居。TCP協(xié)議是在操作系統(tǒng)的內(nèi)核中實現(xiàn)的命贴。 因此， TCP協(xié)議的修改需要升級操作系統(tǒng)。這種耦合限制了TCP修改的更新速率胸蛛。 操作系統(tǒng)的升級有著系統(tǒng)層面的影響并且升級的流水線和機制都需要非常的小心。 即使移動操作系統(tǒng)的普及率越來越高樱报，升級速度也越來越快葬项，但是相當大的用戶數(shù)量也會落戶幾年的時間。服務(wù)端操作系統(tǒng)的升級相對要快一個數(shù)量級迹蛤，但是也仍然需要耗費數(shù)月的時間民珍， 因為對OS的性能和穩(wěn)定性的高要求。 這個限制了部署和迭代的速度盗飒。
（上一段講了如果修改TCP協(xié)議來達到升級協(xié)議的目的嚷量，那就需要在每次修改協(xié)議的時候升級操作系統(tǒng)?）
????握手延遲： TCP和TLS的通用性繼續(xù)服務(wù)于互聯(lián)網(wǎng)的發(fā)展，但是隨著對HTTPS延遲要求的增長分層的代價也越來越明顯逆趣。在發(fā)送數(shù)據(jù)之前蝶溶，TCP連接至少會導致一個往返的延遲時間， 而TLS則需要再增加兩輪的延遲時間宣渗。隨著時間的推移抖所， 網(wǎng)絡(luò)的帶寬不斷增加。 大多數(shù)互聯(lián)網(wǎng)上的連接痕囱、大多數(shù)網(wǎng)絡(luò)上的交易田轧，只需要很短的傳輸過程，它們大多數(shù)都受到不必要的握手連接的影響鞍恢。
????隊頭阻塞延遲： 為了降低多個TCP連接的延遲和開銷傻粘， HTTP/1.1推薦限制客戶端到服務(wù)端的連接數(shù)量。 為了進一步的降低交易的延遲帮掉， HTTP/2多路復(fù)用多個對象并且推薦使用單個到服務(wù)器的TCP連接弦悉。然而，TCP的字節(jié)流抽象阻止了應(yīng)用程序控制傳輸過程中的幀旭寿，并且對應(yīng)用程序的幀征收了一個“延遲稅”警绩，因為這個應(yīng)用程序必須等待先前丟失幀的重新傳輸。
????通常盅称，部署web傳輸?shù)男薷男枰膚eb服務(wù)器和客戶端肩祥，對于服務(wù)端的傳輸協(xié)議棧，常常需要修改協(xié)議的中間層缩膝。 部署對這三個模塊的改動需要協(xié)調(diào)應(yīng)用程序開發(fā)者混狠，OS供應(yīng)商，middlebox供應(yīng)商和網(wǎng)絡(luò)運營商疾层。 QUIC加密傳輸頭部将饺，并且在UDP之上建立傳輸?shù)墓δ埽苊鈱?yīng)商和網(wǎng)絡(luò)運營商的依賴并且將傳輸過程中的控制權(quán)轉(zhuǎn)移到應(yīng)用程序之上。
3. QUIC 的設(shè)計與實現(xiàn)
????QUIC被設(shè)計來達到幾個目標予弧， 包括可部署刮吧、安全性、減少握手開銷和隊頭阻塞延時掖蛤。QUIC協(xié)議合并了它的加密和握手過程來減小連接建立過程中的往返次數(shù)杀捻。它通過為每個請求和響應(yīng)提供單個的stream流，實現(xiàn)了通過復(fù)用單個連接來處理所有的請求和響應(yīng)蚓庭，以便沒有其他響應(yīng)能夠阻斷這個響應(yīng)致讥。通過加密和認證數(shù)據(jù)包來避免被middleboxes篡改，并且避免協(xié)議的僵化器赞。 協(xié)議通過一下手段來提高丟包恢復(fù)能力垢袱，通過使用唯一的數(shù)據(jù)包編號來避免重傳二意性，通過使用明確的ACK信號來實現(xiàn)精確的RTT測量港柜。QUIC協(xié)議允許跨越IP地址改變來遷移連接请契，這是通過使用連接的ID來識別連接而不是IP/端口5元組。QUIC協(xié)議提供了流控制來限制在一個慢速的接收者上的流量潘懊，并且通過對每一個流使用流控制限制來確保單個流不會消耗接收者所有的buffer姚糊。我們的實現(xiàn)提供了一個模塊化的擁塞控制接口用于實驗各種控制器。 我們的客戶端和服務(wù)端在不增加延遲的情況下授舟，協(xié)商協(xié)議的使用救恨。 這個段落指明了QUIC中的設(shè)計和實現(xiàn)的細節(jié)。我們在這篇文章中不描述這種有線格式的細節(jié)释树，有興趣的朋友可以去查看IETF的相關(guān)文檔肠槽。
3.1 連接建立
????QUIC協(xié)議依賴于組合加密和傳輸過程中的握手來 創(chuàng)建一個安全的傳輸連接。 在成功連接的情況下奢啥， 客戶端緩存起來原始的信息秸仙。 在接下來與相同的服務(wù)器建立連接的過程中， 客戶端能夠在不增加額外RTT的情況下建立一個加密的連接桩盲，數(shù)據(jù)要發(fā)送的數(shù)據(jù)可以在握手的包中捎帶著發(fā)送過去寂纪，而不用等待服務(wù)器的回復(fù)。QUIC提供一個專用的可靠流（流在下文中定義）來執(zhí)行加密握手赌结。 本段落總結(jié)了QUIC的加密握手的機制捞蛋，還有QUIC是怎么實現(xiàn)0-RTT的連接建立過程。 如圖4所示柬姚。
????初始握手： 初始時拟杉， 客戶端客戶端沒有服務(wù)端的任何信息， 在握手之前量承， 客戶端發(fā)送一個初始的客戶端hello消息給到服務(wù)端搬设， 之后服務(wù)端會送一個REJ消息穴店。 REJ消息包含： 1.一個服務(wù)端的配置，這包括服務(wù)端的長期的迪菲-郝夫曼算法的公開值拿穴。 2.對服務(wù)器進行身份認證的證書鏈泣洞。 3. 使用證書鏈的葉子證書的私有key對服務(wù)端的簽名。4.一個源地址token：一個認證加密的區(qū)塊贞言，其中包含了客戶端的公開可見的IP地址和服務(wù)端的一個時間戳斜棚。客戶端在接下來的握手中發(fā)送這個token回到服務(wù)端该窗，驗證其IP地址的所有權(quán)。 一旦客戶端接收到服務(wù)端的配置蚤霞， 通過驗證證書鏈和簽名來認證這個配置酗失。 之后客戶端再發(fā)送一個complete CHLO， 其中包含了客戶端的暫存的迪菲-郝夫曼的公開值昧绣。
? ? 最終握手： 一個連接的所有key都是使用Diffie-Hellman算法來建立的规肴。 在發(fā)送一個complete CHLO之后， 客戶端就擁有了連接所需要的initial keys夜畴，這是因為這些key能夠通過服務(wù)端的長期Diffie-Hellman公開值以及客戶端自己暫存的Diffie-Hellman私有值拖刃。 這樣，客戶端就能馬上發(fā)送應(yīng)用程序的數(shù)據(jù)到服務(wù)端了贪绘。 實際上兑牡，要實現(xiàn)對于數(shù)據(jù)0-RTT的延遲，那么必須在服務(wù)端發(fā)送回復(fù)之前就將用initial keys加密好的數(shù)據(jù)發(fā)送出去税灌。
? ? 如果握手成功了均函， 服務(wù)端返回一個server hello（SHLO）消息。 這個消息用initial keys進行了加密菱涤， 并且含有服務(wù)端暫存的Diffie-Hellman的公開值苞也。
未完待續(xù)。粘秆。如迟。
