01 引言

QUIC 協(xié)議從傳輸層面相較 TCP 的幾點(diǎn)優(yōu)勢(shì)：

• 0-RTT 建連QUIC 協(xié)議基于 UDP，本身無(wú)需握手，并且其使用 Diffie-Hellman 或者 ECC 算法，只在 1-RTT 就完成對(duì)等秘鑰的協(xié)商。QUIC 協(xié)議的 0-RTT 建連使用 TLS1.3，通過(guò) early_data 完成加密數(shù)據(jù)透?jìng)鳌?/li>
• 多路復(fù)用/無(wú)對(duì)頭阻塞相比于 HTTP/2 的多路復(fù)用，QUIC 不會(huì)受到隊(duì)頭阻塞的影響，各個(gè)流更獨(dú)立，多路復(fù)用的效果也更好。

• 連接遷移與 TC P 用四元組標(biāo)識(shí)一個(gè)唯一連接不同，QUIC 使用一個(gè) 64 位的 ConnectionID 來(lái)標(biāo)識(shí)連接，基于這個(gè)特點(diǎn)，QUIC 的使用連接遷移機(jī)制，在四元組發(fā)生變化時(shí)（比如客戶(hù)端從 WIFI 切換到蜂窩移動(dòng)網(wǎng)絡(luò)），嘗試“保留”先前的連接，從而維持?jǐn)?shù)據(jù)傳輸不中斷。

• 可定制的擁塞控制QUIC 協(xié)議沒(méi)有定義擁 塞控制算法的使用，這部分實(shí)現(xiàn)在應(yīng)用層，方便開(kāi)發(fā)者自行優(yōu)化迭代。

02 QUIC 協(xié)議從協(xié)議層面相較 TCP 的幾點(diǎn)差別

• Separate Packet Number SpacesQUIC 協(xié)議定義了 4 種不同的加密級(jí)別，各種加密級(jí)別使用不同包序列號(hào)空間。
• Monotonically Increasing Packet Numbers相同包序列號(hào)空間中的包序列號(hào)單調(diào)遞增，避免了重傳歧義。 QUIC 協(xié)議的包序列號(hào)空間只標(biāo)識(shí)傳輸順序，數(shù)據(jù)包內(nèi)容的順序則用 STR EAM 幀當(dāng)中的偏移（offset）來(lái)標(biāo)識(shí)。
• Clearer Loss Epoch當(dāng)一個(gè) QUIC 包被申明為丟失，QUIC 開(kāi)啟一段丟失檢測(cè)的周期，在此之后發(fā)送的任何一個(gè) QUIC 包被確認(rèn)則刷新檢測(cè)周期的時(shí)間。 與 TCP 不同，TCP 會(huì)一直等待序列號(hào)空間中的空白被填滿(mǎn)盡管有可能在傳輸過(guò)程中相同數(shù)據(jù)包發(fā)生了多次丟失。 這樣做的意義在于：QUIC 可以更精確地在每個(gè)往返時(shí)間（RTT）內(nèi)去更新?lián)砣翱诘拇笮　?/span>
• No Reneging不能食言。一旦一個(gè)包被對(duì)端確認(rèn)，則改包不能再被申明為丟失。這樣的設(shè)定大大簡(jiǎn)化了雙端傳輸協(xié)議的設(shè)計(jì)，也減小了發(fā)送端的內(nèi)存壓力。
• More ACK Ranges相比 TCP 的 SACK 只能確認(rèn)三個(gè)段（范圍），QUIC 協(xié)議的 ACK 幀支持更多的段（范圍）確認(rèn)。 在高丟包場(chǎng)景下，加快了重傳恢復(fù)的速度，避免零散的范圍確認(rèn)導(dǎo)致的傳輸中斷。
• Explicit Correction For Delayed AcknowledgementsQUIC 協(xié)議將計(jì)算從接收包到發(fā)送該包 ACK 之間的延遲時(shí)間，并顯式寫(xiě)入 ACK 幀中。 這樣的設(shè)定旨在更加精準(zhǔn)地計(jì)算網(wǎng)路的往返時(shí)間。
• Probe Timeout Replaces RTO and TLPQUIC 協(xié)議使用 PTO（probe timeout）探測(cè)超時(shí)機(jī)制，包含了對(duì)端的期望最大確認(rèn)延時(shí)，而不是一個(gè)固定的最小超時(shí)。 與 TCP 的 RTO 超時(shí)不同的是，QUIC 協(xié)議在 PTO 過(guò)期時(shí)不會(huì)去嘗試折疊擁塞窗口，因?yàn)槲膊繑?shù)據(jù)的丟失并不能表示網(wǎng)路發(fā)生了持續(xù)的擁塞。 發(fā)送方可以不受限制地發(fā)送更多的數(shù)據(jù)包在其還有剩余的擁塞窗口的條件下，即便此時(shí)已經(jīng)發(fā)生了 PTO 超時(shí)。 相對(duì)于 TCP 的 RTO 機(jī)制，PTO 機(jī)制更加激進(jìn)。
• The Minimum Congestion Window is Two PacketsTCP 使用一個(gè)數(shù)據(jù)包作為最小擁塞窗口，如果這個(gè)數(shù)據(jù)包丟失了，意味著需要等待 RTO 來(lái)進(jìn)行重傳，這很可能遠(yuǎn)遠(yuǎn)大于一個(gè)往返時(shí)間（RTT），QUIC 協(xié)議建議使用兩個(gè)數(shù)據(jù)包作為最小擁塞窗口，雖然這樣做會(huì)增加流量，但是被認(rèn)為是安全的。

03 QUIC 協(xié)議在網(wǎng)易云信的應(yīng)用

在網(wǎng)易云信音視頻服務(wù)的架構(gòu)中，信令用于 SDP 的交互 、 會(huì)話房間的創(chuàng)建 與管理 、 用戶(hù)信息的上傳與下發(fā) 等，其傳輸?shù)姆€(wěn)定性和及時(shí)性至關(guān)重要。傳統(tǒng)的 WEBRTC 建議使用 WebSocket 作為信令傳輸協(xié)議，受限于 TCP 協(xié)議的缺陷，其在建連時(shí)間、傳輸效率和弱網(wǎng)抗性方面的效果不盡人意。而這些問(wèn)題直接影響到音視頻服務(wù)的基線指標(biāo)，比如首幀時(shí)間、鏈路的穩(wěn)定性以及弱網(wǎng)抗性等。

云信 QUIC 加速服務(wù)設(shè)計(jì)：

網(wǎng)易云信使用 QUIC 協(xié)議替代 WebSocket 協(xié)議進(jìn)行信令的傳輸，并在應(yīng)用和協(xié)議層面做了若干優(yōu)化實(shí)踐：

• 多路復(fù)用： 根據(jù)不同信令的特性，給請(qǐng)求分類(lèi)分級(jí)。對(duì)于 Request/Reponse 類(lèi)型的消息，其可靠性和實(shí)時(shí)性的要求最高，使用高優(yōu)先級(jí)的 STREAM 進(jìn)行傳輸。對(duì)于用于鏈路保活的心跳消息，則使用較低優(yōu)先級(jí)的 STREAM 進(jìn)行傳輸。
• 不可靠的傳輸拓展： 有一類(lèi) Notify 消息類(lèi)型，不需要接收端進(jìn)行回復(fù)，往往用于廣播各端用戶(hù)的網(wǎng)絡(luò)狀態(tài)或者其他信息。其對(duì)于實(shí)時(shí)性的要求很高，但是對(duì)可靠性沒(méi)有很高的要求。對(duì)于這種信令，我們可以使用 QUIC 協(xié)議的不可靠傳輸特性進(jìn)行傳輸。這種特殊的傳輸使用一種 DATAGRAM 幀，傳輸這種特殊的幀，需要在 Initial 包中的 CH 模塊的 QUIC 傳輸參數(shù)表中進(jìn)行申明(name=max_datagram_frame_size, value=0x20)，用以通告對(duì)端對(duì)于 DATAGRAM 幀的支持。max_datagram_frame_size 傳輸參數(shù)是一個(gè)整數(shù)值（表示為可變長(zhǎng)度整數(shù)），表示端點(diǎn)愿意接收的 DATAGRAM 幀的最大大小（包括幀類(lèi)型、長(zhǎng)度和有效負(fù)載），以字節(jié)為單位。DATAGRAM 幀用于以不可靠的方式傳輸應(yīng)用程序數(shù)據(jù)。幀中的 Type 字段采用 0b0011000X 的形式（或值 0x30 和 0x31），最低有效位是 LEN 位（0x01），表示是否存在 Length 字段：如果該位設(shè)置為 0，則 Length 字段不存在，Datagram Data 字段擴(kuò)展到數(shù)據(jù)包的結(jié)尾；如果該位設(shè)置為 1，則存在長(zhǎng)度字段。 DATAGRAM 幀的結(jié)構(gòu)如下：

盡 管 DATAGRAM 幀在檢測(cè)到丟失時(shí)不會(huì)進(jìn)行重傳，但也是需要被 ack 的。

• 報(bào)文壓縮： 云信在傳輸層引入了 Deflate 算法對(duì) STREAM 幀進(jìn)行壓縮，旨在降低信令傳輸?shù)膸捳加谩?/li>
• 動(dòng)態(tài)的冗余策略： 因?yàn)樾帕罘橇魇綌?shù)據(jù)，F(xiàn)EC 并不能適用于斷續(xù)數(shù)據(jù)的傳輸，以 RTT 和丟包率等指標(biāo)動(dòng)態(tài)地增加冗余保護(hù)對(duì)提升傳輸?shù)娜蹙W(wǎng)抗性也有相當(dāng)積極的作用。

04 云信 QUIC 的弱網(wǎng)表現(xiàn)

首屏耗時(shí)和登錄耗時(shí) 

上圖是云信音視頻業(yè)務(wù)信令建連使用 TCP 和 QUIC 的對(duì)比。在 首幀耗時(shí) 的指標(biāo)上，QUIC 有 20% 的提升。在 登錄耗時(shí) 的指標(biāo)上，QUIC 有接近 30% 的提升。主要的原因是 QUIC 的建連對(duì)比 TCP+TLS 有 2~3 個(gè) RTT 的優(yōu)化，在高 RTT 的場(chǎng)景下握手時(shí)間縮短尤為明顯。在直播場(chǎng)景下，云信 QUIC 做了私有化的 0RTT 握手的優(yōu)化，建連更加快速。

抗丟包性 

上圖是云信信令數(shù)據(jù)在 QUIC 和 TCP 鏈路下能夠抗住的最大丟包率。QUIC 在上行丟包率達(dá)到 70% 的條件下仍然可以提供服務(wù)，下行邊界甚至可以抗住 75% 的丟包。TCP 鏈路在 45% 的丟包情況下就會(huì)出現(xiàn)斷開(kāi)重連。相對(duì)于 TCP 的信令鏈路 QUIC 鏈路有 50% 的提升。

主要原因：

• 云信實(shí)現(xiàn)了動(dòng)態(tài)冗余，會(huì)檢測(cè)到丟包之后增加冗余度，這樣就用冗余包彌補(bǔ)了高丟包，帶來(lái)了抗丟包性能。
• QUIC 改進(jìn)的流量控制和擁塞控制算法讓 QUIC 在弱網(wǎng)絡(luò)下可能取得更大的傳輸優(yōu)勢(shì)。

帶限 

我們還做了在帶寬受限的情況下，QUIC 對(duì)于帶寬的使用率，基本上 QUIC 對(duì)于帶寬的使用率都能達(dá)到 90% 以上，然而 TCP 就要差很多。

05展望&總結(jié)

網(wǎng)易云信在可靠數(shù)據(jù)加速上可靠數(shù)據(jù)傳輸上已經(jīng)得到很大的提升，但是仍然還有一些需要優(yōu)化的地方：一旦單向發(fā)生丟包，會(huì)引起服務(wù)器和端都增加雙向的冗余度，帶來(lái)不必要的冗余增加。后續(xù)會(huì)檢測(cè)到單向丟包，只針對(duì)丟包的鏈路進(jìn)行冗余度增加。對(duì)于高 RTT 和高丟包場(chǎng)景，QUIC 擁塞控制算法需要持續(xù)優(yōu)化。 網(wǎng)易云信將持續(xù)在音視頻領(lǐng)域，在各種極端情況下為用戶(hù)提供優(yōu)質(zhì)的服務(wù)。

作者介紹 

董相成，網(wǎng)易云信資深音視頻引擎開(kāi)發(fā)工程師，負(fù)責(zé)網(wǎng)易云信低延遲直播業(yè)務(wù)和音視頻媒體引擎開(kāi)發(fā)，在音視頻數(shù)據(jù)傳輸和網(wǎng)絡(luò)數(shù)據(jù)轉(zhuǎn)發(fā)方面有著豐富的經(jīng)驗(yàn)。