基于QUIC的實時通信優(yōu)化研究與應(yīng)用

于 波，李炫杉，王 衛(wèi)，徐福龍

1(中國科學(xué)院大學(xué)，北京 100049)

2(中國科學(xué)院 沈陽計算技術(shù)研究所，沈陽 110168)

3(東北大學(xué) 計算機科學(xué)與工程學(xué)院，沈陽 110169)

5G的到來讓移動設(shè)備有了更低延遲的網(wǎng)絡(luò)環(huán)境，也讓實時通信有了更好的應(yīng)用條件.實時通信的應(yīng)用場景有音視頻通話、在線會議、直播等，目前應(yīng)用最廣的是WebRTC框架，其本質(zhì)是在對等連接下進行媒體流的交換.本文研究的重點是如何優(yōu)化實時通信的傳輸，并將QUIC協(xié)議應(yīng)用到了實時傳輸中測試，并針對性地對QUIC協(xié)議進行改進.

本文先分析WebRTC與QUIC兩項技術(shù)的特點，然后設(shè)計出針對實時通信應(yīng)用場景下的QUIC協(xié)議改進方案，最后將改進后的QUIC協(xié)議進行應(yīng)用和驗證.

1 相關(guān)技術(shù)簡介

1.1 實時通信技術(shù)簡介

實時通信(Real-time communications)是一種無傳輸延遲的信息共享技術(shù)，通常通過對等連接(peer-to-peer)，在源地址與目標地址之間的直徑路徑中發(fā)送數(shù)據(jù)[1].

目前實時通信技術(shù)中應(yīng)用最為廣泛的是開源項目WebRTC，該項目由Google，Mozilla和Opera等機構(gòu)支持.利用WebRTC框架可以調(diào)用簡單的API在瀏覽器和移動端應(yīng)開發(fā)實時通信模塊，實現(xiàn)幾乎無延遲的媒體傳輸.

1.2 Quick UDP Internet Connection技術(shù)簡介

Quick UDP Internet Connection技術(shù)即快速UDP互聯(lián)網(wǎng)連接，簡稱為QUIC協(xié)議，該協(xié)議由Google開發(fā)，是工作在傳輸層的網(wǎng)絡(luò)傳送協(xié)議，目前傳輸層協(xié)議主要是TCP和UDP，QUIC是在UDP協(xié)議的基礎(chǔ)上改進.QUIC相對于以往的傳輸層協(xié)議有著眾多優(yōu)點：改進了擁塞控制、可以更快地進行連接的建立、多路復(fù)用不會出現(xiàn)對頭阻塞的情況、使用UUID作為連接標記可以更方便地對連接進行遷移等[2,3].

2 研究現(xiàn)狀

目前實時通信技術(shù)被廣泛應(yīng)用于視頻會議、直播等場景下.特別是WebRTC框架并不局限于Web環(huán)境，而是可以很方便地移植到桌面端、移動端甚至是物聯(lián)網(wǎng)設(shè)備上.微軟和蘋果都在各自的操作系統(tǒng)及瀏覽器中做了適配和應(yīng)用[4].另一方面，5G時代的到來使得移動端設(shè)備也擁有了更低的時延，這都是實時通信技術(shù)飛速發(fā)展的條件.針對實時通信技術(shù)的體驗優(yōu)化也顯得更重要.因此有研究者使用了“動態(tài)優(yōu)化多人傳輸音視頻文件質(zhì)量以提升體驗質(zhì)量”的思想來優(yōu)化多對多實時通信場景，比如在視頻會議中，參會人員之間傳輸?shù)牧髅襟w文件存在多種版本，根據(jù)每個參會人員使用設(shè)備的配置情況，對音視頻文件的幀速率、色彩等進行差異化傳輸[5].文獻[6]提出使用Network Functions Virtualization 技術(shù)(簡稱NFV)，發(fā)送音視頻流媒體文件時讓客戶端自主地選擇流媒體服務(wù)質(zhì)量，為虛擬網(wǎng)絡(luò)組件分配所需的資源，而且這個資源分配可以根據(jù)8實時網(wǎng)絡(luò)波動進行定制化，節(jié)省了服務(wù)端資源的情況下保證傳輸質(zhì)量.過去在音視頻傳輸領(lǐng)域，流媒體文件的下載都是漸進式的，于是有些研究者提出了HTTP自適應(yīng)流媒體技術(shù)，自適應(yīng)流媒體的本質(zhì)是對流媒體文件進行切片.通過不同質(zhì)量的切片，音視頻文件的傳輸過程結(jié)合客戶端的網(wǎng)絡(luò)情況變得更加動態(tài)，最終讓音視頻文件傳輸?shù)倪^程變得更加流暢，并保證了最佳的傳輸質(zhì)量[7].

但目前QUIC協(xié)議主要是應(yīng)用在Google的產(chǎn)品，如Chromium、Gmail中.其實將HTTP自適應(yīng)流映射到QUIC實現(xiàn)起來是很方便的[8]，因為QUIC的最初設(shè)計就是為了下一代HTTP，QUIC的低時延特性特別適用于實時通信這種媒體交換場景；但另一方面QUIC可以像TCP一樣提供可靠性保證，這在實時媒體的傳輸中往往是不必要的，因為在帶寬不足的情況下可以適當?shù)貭奚襟w質(zhì)量，允許少量的音視頻抖動來確保服務(wù)質(zhì)量.因此針對實時傳輸音視頻的場景，對QUIC進行了改進，拓展QUIC協(xié)議使其具有“不完全可靠”特性，讓實時通信達到最優(yōu)的交互體驗.

3 基于QUIC的實時通信優(yōu)化

3.1 QUIC協(xié)議在實時通信場景的優(yōu)勢

與傳輸層的另一個主流協(xié)議傳輸控制協(xié)議進行對比，在連接建立上，傳輸控制協(xié)議(TCP)的連接建立過程被形象地叫做“3次握手”，這是由于TCP在傳輸層負責提供“可靠性”傳輸，3次握手的過程如下：第1次握手是由客戶端向服務(wù)端發(fā)出，申請建立與服務(wù)器的連接；第2次握手由服務(wù)端發(fā)出，告知客戶端收到請求；第3次握手是客戶端確認建立連接以保證可靠性.顯然，3次握手的流程為了可靠而涉及到多次的包傳輸，因此需要多個往返時間，這種場景無法滿足實時通信的要求.而QUIC則更加能夠升任實施交付的場景，因為QUIC協(xié)議建立連接不需要多個RTT(往返時間)，實現(xiàn)了零往返時間連接.

由于QUIC協(xié)議基于UDP協(xié)議，因此QUIC在建立連接的時候會攜帶一次會話中所需要的完整參數(shù)，這使得QUIC的連接是0RTT的：不會為了可靠性去確認已發(fā)送的數(shù)據(jù)包.這個“0RTT連接”的特性優(yōu)化了參與會話的各個終端之間連接建立的速度，很適合用于實時音視頻通話場景.更近一步地看兩種傳輸協(xié)議在連接建立時的區(qū)別：為了保證數(shù)據(jù)包在傳輸過程中的安全性，傳統(tǒng)HTTP協(xié)議使用了TLS作為TCP的安全附加層，因此這個過程其實包括了TCP的3次握手和TLS等多次RTT.而在QUIC協(xié)議中，其內(nèi)置了TLS為客戶端進行數(shù)據(jù)完整性校驗和隱私數(shù)據(jù)防護，這使得QUIC協(xié)議既保證了安全加密的同時，還在傳輸速度上更勝一籌.

在會話標識上，TCP協(xié)議通過五元組進行標識，5個元素組成集合用以保證每個會話都有一個唯一標識，它包括：目標IP地址、源IP地址、目標端口號、源端口號、傳輸層協(xié)議.而QUIC的會話標識則更加有效便捷：只需要公共包頭和一個唯一標記ID，這樣一來QUIC協(xié)議便有了以下特性：連接轉(zhuǎn)移，由于標識ID可以被保存，因此一個連接可以在端的網(wǎng)絡(luò)發(fā)生狀態(tài)時進行連接轉(zhuǎn)移，比如實現(xiàn)無縫的網(wǎng)絡(luò)切換；NAT重綁，在目前NAT廣泛應(yīng)用的背景下，NAT其實對實時通信P2P連接造成了障礙，因此實時音視頻通信時需要通過NAT穿透技術(shù)建立連接，這時候會出現(xiàn)NAT競爭的情況.當多個端進行搶占NAT出口時，需要重新綁定端口，這時候QUIC的NAT重綁特性就顯得尤其重要.QUIC的會話標識特點使得其對于實時通信場景有著先天的優(yōu)勢.

現(xiàn)在正處在移動互聯(lián)網(wǎng)的時代，移動端設(shè)備成為了實時通信場景最主要的終端設(shè)備.移動端有一個特點就是網(wǎng)絡(luò)環(huán)境波動更加頻繁，比如由于地理位置的切換或者手機傳感器的變化等因素，移動設(shè)備的IP地址、Wi-Fi狀態(tài)、端口號會發(fā)生變化.QUIC的連接轉(zhuǎn)移可以幫助移動端的通話場景無斷網(wǎng)保持會話，改善通話過程的卡頓或延遲等體驗[9-10].

3.2 針對實時通信場景的rQUIC

QUIC協(xié)議雖然有著零往返時間、低延遲、連接遷移以及安全等特點，但是在實時通信這種場景下，還是可以針對場景需求進行優(yōu)化和改進.由于流媒體實時傳播追求“實時”這一要素，因此實時通信的場景存在以下特性：面向音視頻流文件，清晰度與流暢度之間可以根據(jù)網(wǎng)絡(luò)狀態(tài)進行取舍，最終達到可以優(yōu)化實時通信體驗質(zhì)量的效果.考慮到QUIC協(xié)議是基于UDP協(xié)議進行改進的可靠傳輸協(xié)議，那么在網(wǎng)絡(luò)狀態(tài)不好的情況下，QUIC協(xié)議能否通過犧牲一定的可靠性以達到提高傳輸效率的效果呢？于是針對實時流媒體傳輸場景，直接使用QUIC在弱網(wǎng)的情況下進行測試，發(fā)現(xiàn)確實會出現(xiàn)通信方在音視頻流上不同步的問題，使得整體表現(xiàn)不盡人意.

根據(jù)QUIC直接應(yīng)用時的表現(xiàn)數(shù)據(jù)，嘗試對QUIC協(xié)議針對于實時通信的特定場景進行改進.改進包括以下幾個方面：設(shè)計一種“不完全可靠”的機制，設(shè)計相應(yīng)的傳輸幀的格式以及優(yōu)化擁塞控制策略，使得QUIC更勝任允許適度丟包的通信場景，將改進后的協(xié)議命名為rQUIC(r意為real-time).

3.2.1 改進幀格式的設(shè)計

rQUIC的數(shù)據(jù)包格式中需要傳輸一個最大幀大小的參數(shù)dgram_size_max.這個參數(shù)用于通信多端進行數(shù)據(jù)流交換之前，參數(shù)類型為int，單位為B，通信多端之間除了告知對方dgram_size_max，還需要攜帶一系列參數(shù).包括通信端自身可接收的幀長度、負載和類型等.使用rQUIC協(xié)議在多個通信終端之間發(fā)送“不完全可靠”的數(shù)據(jù)報時，rQUIC協(xié)議會生成一個新媒體流幀，該媒體流幀會被立刻發(fā)送，在發(fā)送的過程中該幀可能會與其他幀進行合并.rQUIC會盡最大努力交付這些“不完全可靠”的合并幀.當通信終端判定某一端發(fā)送數(shù)據(jù)有已丟失的可能的時，直接通知該終端某個幀已丟失.rQUIC數(shù)據(jù)報會在丟包時引起ACK幀延遲，但不會在幀丟失后進行包的重新傳輸，而是對包進行序號重排.通過ACK幀的響應(yīng)時間控制媒體流的響應(yīng)接收時間，丟失的數(shù)據(jù)幀可以在稍后的時間進行接收和確認.而為了防止數(shù)據(jù)流的尾部丟失而導(dǎo)致客戶端無法確定數(shù)據(jù)流的傳輸結(jié)束時間，把流的結(jié)束位置加一個可靠性標記.當通信終端嘗試使用的某個數(shù)據(jù)流已經(jīng)丟失后，它將收到一個大小為0的流，即填補丟失的數(shù)據(jù)補充流.最終每個流的最后一個字節(jié)進行了可靠傳輸，則可以實現(xiàn)盡最大努力交付數(shù)據(jù)流.

3.2.2 部分可靠性標記

部分可靠性標記的設(shè)計很適合音視頻這種傳輸場景，對每一幀都增加標記，僅使用一位來表示其可靠或不可靠.增加一個標識位表面上看可能會稍稍增加發(fā)送和接收時的開銷，但其實造成的影響并不大.這主要是由于音視頻這種流媒體文件在傳輸過程需要往往都伴隨著編解碼的過程.如圖1所示，在傳輸音視頻的編解碼流程中，發(fā)送方的音視頻流首先經(jīng)過了編碼，然后傳輸?shù)氖蔷幋a后的數(shù)據(jù).在這個編碼的過程中，部分可靠性標志位幾乎不會增加發(fā)送方的開銷.而針對于接收方，發(fā)送方編碼后的文件通過P2P或服務(wù)器傳輸過來，需要使用接收終端的能力進行解碼，解碼的過程中也很少引起處理開銷的增加，當然由于接收終端需要根據(jù)數(shù)據(jù)包中的可靠性標記來判斷，對數(shù)據(jù)流做不同情況的處理，總體來說對于整個通信服務(wù)的體驗是改進的.

圖1 音視頻傳輸編解碼

3.2.3 擁塞控制策略優(yōu)化

CUBIC算法是一種經(jīng)典的擁塞控制算法，因此在傳輸協(xié)議的擁塞控制上，結(jié)合了實時音視頻通信場景，對CUBIC算法進行了優(yōu)化.在QUIC的官方代碼中，/core/congestion_control目錄下存放的是擁塞控制策略代碼，其中CubicBytes即CUBIC算法，通過原理分析了CubicBytes在流媒體傳輸、實時通信場景的匹配能力.CubicBytes是以Bytes為單位進行計算的，它與CUBIC的區(qū)別是計算單位不同，因此分析其中一個算法的理論即可.在經(jīng)典的BIC算法中，擁塞窗口的大小從最小值Wmin到最大值Wmax的增長過程使用了二分查找算法，其中如果用S代表擁塞窗口增長大小，W代表擁塞窗口大小，那么BIC算法有計算公式：

(1)

Wmin=Wmax×β

(2)

W′min=W

(3)

而CUBIC算法[11]則對BIC算法進行了以下改進，它用一個3次函數(shù)模擬BIC算法的擁塞窗口變化過程.由于二分查找算法會導(dǎo)致?lián)砣翱谠鲩L速度過快，因此設(shè)置了閾值以限制其增長，而使用三次函數(shù)模擬則可以實現(xiàn)擬合這個曲線，該曲線由以公式(4)-公式(6)描述：

Wmin=Wmax×β

(4)

(5)

W′min=W

(6)

其中C和β為常數(shù).由公式(5)可以看出，該算法對應(yīng)的曲線增長級別是立方級的.當網(wǎng)絡(luò)發(fā)生丟包時，立方級別的增長曲線會讓擁塞窗口的值迅速上升至閾值.而目前實時流媒體傳輸場景發(fā)生在移動端的情況居多，移動端的網(wǎng)絡(luò)情況常常伴隨著波動，這使得擁塞控制必須根據(jù)網(wǎng)絡(luò)狀態(tài)的變化進行改進.對CUBIC算法進行了自適應(yīng)算法優(yōu)化，使CUBIC可以更好地利用帶寬.由于QUIC協(xié)議的擁塞控制是可插拔的，因此客戶端在應(yīng)用層面可根據(jù)自己的需要，對擁塞控制進行定制化，可以方便地改進其擁塞控制.首先是網(wǎng)絡(luò)狀態(tài)進行評估，參考的網(wǎng)絡(luò)參數(shù)有當前窗口大小、排隊數(shù)據(jù)包數(shù)量、平滑往返時間、最近往返時間、往返時間的最大最小值、以及當前擁塞窗口大小等.使用下面的計算公式來量化網(wǎng)絡(luò)狀態(tài)：

RTTlast=a×SRTT+b×RTT

(7)

a+b=1

(8)

其中a和b為經(jīng)驗值，取a等于0.85，b等于0.15.RTT表示往返時間，SRTT表示平滑往返時間，RTTlast表示最新RTT值，公式(7)(8)用于更新最新的RTT值，該RTT值將用于計算下面的吞吐量差值DIFF.使用Exp表示吞吐量的期望值，Act表示吞吐量的實際值，Cwnd表示擁塞窗口大小，通過比較期望吞吐量和實際吞吐量來對擁塞窗口大小進行調(diào)整，則Exp、Act和其差值DIFF有計算公式：

(9)

(10)

DIFF=Exp-Act

(11)

公式(11)中的DIFF用于評估隊列中數(shù)據(jù)包的多少，并根據(jù)此進行自適應(yīng)網(wǎng)絡(luò)狀態(tài)的算法設(shè)計.參數(shù)e用于衡量當前網(wǎng)絡(luò)環(huán)境的狀態(tài)，將其初始值賦值為1，結(jié)合DIFF進行判斷，自適應(yīng)策略如下所述：如果e小于DIFF，則進一步比較最新更新過的RTTlast時間和平滑往返時間，當平滑往返時間比最新的RTTlast值大時，判定為網(wǎng)絡(luò)狀況不佳，于是對e進行縮小.反之增大e的取值.當e大于DIFF時，結(jié)合Cwnd值和RTT值進行動態(tài)自適應(yīng)變化.如果e值為1則增大滑動窗口大小，如果e值不為1則根據(jù)其大小進行增減操作.最后設(shè)置擁塞窗口Cwnd的最大值等于300，判斷是否達到閾值，以100為單位在算法中動態(tài)地增減擁塞窗口大小.當擁塞窗口值沒有到達極限值時，可以繼續(xù)對擁塞窗口進行大小改變.一旦發(fā)現(xiàn)擁塞窗口大小到達擁塞窗口的極限值，使用以上參數(shù)對網(wǎng)絡(luò)狀態(tài)進行判斷，如果發(fā)現(xiàn)已經(jīng)出現(xiàn)了網(wǎng)絡(luò)擁塞情況，則不作出改變；如果發(fā)現(xiàn)網(wǎng)絡(luò)狀況還不發(fā)生擁塞，則可以對擁塞窗口的極限值增大100.這樣就可以使CUBIC算法更快速地對網(wǎng)絡(luò)狀態(tài)的變化做出反應(yīng).自適應(yīng)擁塞控制偽代碼如算法1所示.

算法1.

輸入：e，ACK， DIFF， Cwnd，MaxCwnd，SlowStartThreshold

1.VariableACK=ACK+1

2. Update Variableiable RTT；

3.ifCwnd

4. Slow Start()；

5.else

6. Check network status()； // 判斷網(wǎng)絡(luò)狀態(tài)

7. Update parameters()； // 更新參數(shù)

8.endif

9.ifCwnd≥MaxCwnd

10.Break；

11.elseife>DIFF

12.ifMaxCwnd≥300

13. Update parameters()； // 更新參數(shù)

14. Go to Line 17.

15.else

16. Adjust Cwnd()； // 調(diào)整Cwnd

17.else

18. Increase Cwnd_Limit()； // 增大窗口極限值

19.endif

改進后算法可以更好地應(yīng)對網(wǎng)絡(luò)環(huán)境的波動情況，使得帶寬得到更加有效地占用，進一步提高網(wǎng)絡(luò)有效吞吐量.由于對rQUIC的幀格式增加了不完全可靠標記，因此在擁塞控制上進一步對帶有不完全可靠標記的數(shù)據(jù)流的幀內(nèi)容設(shè)置一個Expiration_time參數(shù)表示過期時間，當擁塞控制算法對數(shù)據(jù)包進行延遲返送后，執(zhí)行以下兩個操作，一是判斷是否超過過期時間，二是選擇性地發(fā)送.因為超過過期時間的包在音視頻通話過程中及時重發(fā)也意義不大，而直接丟棄卻很少影響傳輸后的的播放體驗，還可以節(jié)省很多傳輸上的開銷.在弱網(wǎng)的環(huán)境下，適當?shù)貋G包可以保證整個音視頻通話的流程度和舒適程度.對過期時間進行判斷、處理的偽代碼如算法2所示.

算法2.

輸入：x，Unreliable Tag，Expiration_time，max_ Expiration_time

1.// Set maximum expiration time設(shè)置最大過期時間

2.Variableiablemax_ Expiration_time=x

3.// Check Tag判斷是否有不可靠標記

4.ifTag.isUnreliable()

5.ifmax_ Expiration_time > Expiration_time

6. Drop randomly()； // 選擇性丟棄

7.else

8. Drop packet()； // 丟棄該包

9.Congestion Control()； // 正常擁塞控制

采用部分可靠性設(shè)計的新數(shù)據(jù)幀格式在對等連接中進行收發(fā)數(shù)據(jù)，可以在可靠的rQUIC數(shù)據(jù)流與不完全可靠的rQUIC數(shù)據(jù)流中共享一個握手和認證上下文，在0RTT時間上做更極限的優(yōu)化；更快的丟包恢復(fù)時間，充分適應(yīng)實時通信、對等連接的場景需要；rQUIC的“不完全可靠”數(shù)據(jù)流與改進后的擁塞控制算法，可以針對rQUIC數(shù)據(jù)流是否具有可靠性選擇是否進行擁塞控制；魯棒性得到了增強，改進后的rQUIC協(xié)議有著“部分可靠性”優(yōu)勢，仍可以根據(jù)序號重排算法對丟包這種不可靠的數(shù)據(jù)流進行ACK反饋，通信終端仍然可以得到確認信息以判斷是否發(fā)送、接收成功.因此改進后的rQUIC可以更快地建立通信連接，有更低的延遲.

根據(jù)上述對QUIC的研究，將改進后的rQUIC應(yīng)用到實時通信環(huán)境中進行測試，實時通信環(huán)境采用WebRTC框架搭建.

4 性能測試

性能測試采用開源測試工具Augmented Traffic Control(ATC)，將rQUIC協(xié)議應(yīng)用到RTC，對比基于TCP的RTMP協(xié)議.其中流媒體源文件碼率為800kbps，分辨率1280×720，編碼格式采用H.264，完全使用硬件編碼的方式以保證實驗穩(wěn)定性，測試所用硬件服務(wù)器(CPU Intel(R) Core(TM) i5-8400，16GB RAM，240G SSD RAID10)與macOS 10.14操作系統(tǒng)的筆記本MacBook Pro一臺和Android 9.0操作系統(tǒng)手機一部.通過模擬不同程度的丟包率和延遲來測試不同協(xié)議的表現(xiàn).

圖2是測試環(huán)境下所使用的網(wǎng)絡(luò)拓撲結(jié)構(gòu)，實驗的測試過程如下，首先對比的是改進后的rQUIC和QUIC，實驗變量為往返時間和帶寬.經(jīng)過幾輪測試后，使用每輪結(jié)果的吞吐量求平均值作為吞吐量參考值.結(jié)果如圖3所示，當變量是往返時間RTT時，可以看出在往返時間不大的情況下，兩種協(xié)議的表現(xiàn)情況并無懸殊，吞吐量也基本都可以保持在峰值附近.但是隨著往返時間的不斷增大，原始QUIC出現(xiàn)了吞吐量的下降，由此可以推論出，當網(wǎng)絡(luò)擁塞發(fā)生后，原始QUIC的處理能力不如改進后的rQUIC.由于rQUIC針對實時通信場景改進了擁塞控制算法，可以配合“選擇性發(fā)送”的策略使得網(wǎng)絡(luò)狀態(tài)不佳時仍然可以有平穩(wěn)出色的表現(xiàn).而當變量為帶寬時的實驗表現(xiàn)結(jié)果如圖4所示，當帶寬不斷增加時，兩種協(xié)議的平均吞吐量都增加了，但是對比兩種協(xié)議發(fā)現(xiàn)，rQUIC更快地發(fā)揮出了對應(yīng)帶寬下的最佳表現(xiàn)，而原始的QUIC則是相對更緩速地增加到了最優(yōu)的狀態(tài).可以推論出擁塞控制算法的改進和丟包策略起到了作用.使得rQUIC協(xié)議主動丟掉了一些重發(fā)的、沒有意義的數(shù)據(jù)包，傳輸開銷上相對更少，因此在帶寬相同的情況下，rQUIC協(xié)議的平均吞吐量更優(yōu).

圖2 網(wǎng)絡(luò)結(jié)構(gòu)

圖3 RTT不同時的實驗結(jié)果

圖4 帶寬不同時的實驗結(jié)果

圖5模擬的時rQUIC協(xié)議和TCP協(xié)議在實時通信場景下的表現(xiàn)對比，測試網(wǎng)絡(luò)環(huán)境的預(yù)設(shè)丟包率為1%，預(yù)設(shè)延遲為50ms.通過結(jié)果分析，在連接建立的初期，TCP協(xié)議率先達到最大的吞吐量，但TCP并沒有穩(wěn)定維持這個最大吞吐量.而rQUIC協(xié)議的表現(xiàn)則是平均吞吐量平穩(wěn)上升，穩(wěn)定持續(xù)維持在不錯的吞吐量上，較少地出現(xiàn)了下降情況.隨著時間的推移，TCP卻出現(xiàn)了多次卡頓的現(xiàn)象，導(dǎo)致有效吞吐量的平均表現(xiàn)一般.由此可以得出以下結(jié)論：TCP屬于可靠傳輸協(xié)議，通訊時間不斷增長的情況下，網(wǎng)絡(luò)可能會進入擁塞狀態(tài)，這時TCP傳輸性能會受到不小的波動，進而影響到通信的質(zhì)量.“不完全可靠傳輸”的rQUIC協(xié)議雖然舍棄了部分可靠性，但是穩(wěn)定性得到了增強，傳輸性能可以持續(xù)維持在較高水平，網(wǎng)絡(luò)性能得到了更加充分的發(fā)揮.

圖5 丟包率1%延遲50ms時的實驗結(jié)果

然后對比rQUIC協(xié)議和TCP協(xié)議在弱網(wǎng)場景下的表現(xiàn)，圖6是測試環(huán)境預(yù)設(shè)網(wǎng)絡(luò)丟包率為10%，預(yù)設(shè)網(wǎng)絡(luò)延遲為250ms時的結(jié)果對比.由于模擬的網(wǎng)絡(luò)情況較差，結(jié)果顯示TCP協(xié)議出現(xiàn)了多次傳輸卡頓，受到丟包的影響，有效吞吐量波動大，導(dǎo)致通信體驗不好.相反在此情況下rQUIC協(xié)議則更具備優(yōu)勢，rQUIC發(fā)揮出了其不完全可靠的特性，丟棄了不需要重傳的包以減少網(wǎng)絡(luò)質(zhì)量的波動.改進后的rQUIC擁塞控制算法也表現(xiàn)不錯，可以針對網(wǎng)絡(luò)狀態(tài)的波動進行自適應(yīng)調(diào)整.因此在弱網(wǎng)情況下，雖然也出現(xiàn)了卡頓的情況，但沒有使有效吞吐量有太明顯的下降，整個通信體驗是令人接受的.最后可以得出結(jié)論：rQUIC很適合應(yīng)用在實時音視頻通信和類似的流媒體傳輸場景下.

圖6 丟包率10%延遲250ms時的實驗結(jié)果

5 結(jié) 語

本文通過研究傳輸層協(xié)議QUIC的適用場景，將QUIC協(xié)議應(yīng)用到實時通信環(huán)境下，并根據(jù)QUIC協(xié)議可靠性的特點，針對視音頻通信做出改進.提出對QUIC進行改進使其在特定環(huán)境下表現(xiàn)出“不完全可靠”的特性.改進后的QUIC應(yīng)用到實時通信場領(lǐng)域可以充分地發(fā)揮出QUIC低延遲等特性，為音視頻通信提供更優(yōu)質(zhì)的體驗，這種特性還可以進一步應(yīng)用到游戲等領(lǐng)域.但由于QUIC協(xié)議目前尚未有最終定稿，以后還需根據(jù)更新版本后的QUIC進行更進一步的研究、測試和優(yōu)化.