梁向斌,趙寶康,彭 偉

(國(guó)防科技大學(xué)計(jì)算機(jī)學(xué)院,湖南 長(zhǎng)沙 410073)

1 引言

一直以來,地面網(wǎng)絡(luò)快速發(fā)展,但仍面臨一些挑戰(zhàn)。由于經(jīng)濟(jì)成本和地理因素,地面網(wǎng)絡(luò)無法全面覆蓋廣大農(nóng)村偏遠(yuǎn)地區(qū)[1,2]。當(dāng)發(fā)生自然災(zāi)害時(shí),地面網(wǎng)絡(luò)基礎(chǔ)設(shè)施易被毀壞,無法繼續(xù)提供通信保障[2]。衛(wèi)星網(wǎng)絡(luò)具有覆蓋范圍廣、帶寬高、抗毀能力強(qiáng)等優(yōu)勢(shì)[3],可以彌補(bǔ)地面網(wǎng)絡(luò)存在的不足。但是,衛(wèi)星網(wǎng)絡(luò)存在傳播時(shí)延長(zhǎng)、誤碼率高、帶寬不對(duì)稱等特點(diǎn),導(dǎo)致傳統(tǒng)的TCP協(xié)議在衛(wèi)星網(wǎng)絡(luò)中的性能不佳。

近年來,隨著中軌軌道衛(wèi)星MEO(Medium Earth Orbit)、低軌軌道衛(wèi)星LEO(Low Earth Orbit)等多種星座的發(fā)展,衛(wèi)星網(wǎng)絡(luò)呈現(xiàn)出高移動(dòng)性的特點(diǎn),這進(jìn)一步加劇了衛(wèi)星網(wǎng)絡(luò)環(huán)境的復(fù)雜性,如何在高移動(dòng)性衛(wèi)星星座網(wǎng)絡(luò)中提供高性能高可靠傳輸是研究人員面臨的一個(gè)挑戰(zhàn)。同時(shí),多種衛(wèi)星星座組成的巨型星座提供了多條路徑可供傳輸,因此利用多路徑傳輸協(xié)議提高衛(wèi)星網(wǎng)絡(luò)傳輸性能值得開展研究。相比于TCP,QUIC(Quick Udp Internet Connection)協(xié)議具有更短的握手時(shí)延,并引入了多流、連接遷移等特性,并且已有研究表明,QUIC[4]在地面網(wǎng)絡(luò)的眾多場(chǎng)景下性能優(yōu)勢(shì)明顯,因此特別值得在衛(wèi)星網(wǎng)絡(luò)中開展研究。高移動(dòng)性的衛(wèi)星網(wǎng)絡(luò)環(huán)境復(fù)雜多變,傳統(tǒng)的擁塞控制機(jī)制在此環(huán)境下魯棒性不強(qiáng),而隨著機(jī)器學(xué)習(xí)技術(shù)的不斷發(fā)展,基于機(jī)器學(xué)習(xí)的擁塞控制機(jī)制可以根據(jù)鏈路狀態(tài)適時(shí)調(diào)整擁塞窗口,這將有可能提升擁塞控制機(jī)制的魯棒性。

在以往的文獻(xiàn)中,文獻(xiàn)[5]關(guān)注多路徑傳輸;文獻(xiàn)[6]關(guān)注MPTCP(MultiPath TCP)的擁塞控制機(jī)制;文獻(xiàn)[7]關(guān)注傳輸層協(xié)議的優(yōu)化;文獻(xiàn)[8]關(guān)注MPTCP多路徑傳輸優(yōu)化。以上文獻(xiàn)都沒有針對(duì)衛(wèi)星網(wǎng)絡(luò)進(jìn)行全面分析,且缺乏對(duì)多路徑傳輸技術(shù)(Multipath TCP,多路徑QUIC)、QUIC和機(jī)器學(xué)習(xí)等新技術(shù)在巨型星座中應(yīng)用的研究,因此有必要就衛(wèi)星網(wǎng)絡(luò)傳輸優(yōu)化新技術(shù)進(jìn)行深入分析和總結(jié),為研究人員展開相關(guān)研究打下基礎(chǔ)。

本文在簡(jiǎn)要回顧經(jīng)典傳輸優(yōu)化技術(shù)的基礎(chǔ)上,重點(diǎn)對(duì)近年來最新的前沿技術(shù)展開分析。本文剩余部分組織如下:第2節(jié)討論傳輸層優(yōu)化,包括經(jīng)典的擁塞控制機(jī)制、性能增強(qiáng)代理PEP(Performance Enhancing Proxies)[9]技術(shù)以及QUIC;第3節(jié)討論跨層優(yōu)化技術(shù),包括容延容斷網(wǎng)絡(luò)DTN(Delay/disruption Tolerant Networking)以及多路徑傳輸協(xié)議;第4節(jié)對(duì)已有的傳輸優(yōu)化機(jī)制進(jìn)行對(duì)比分析;最后總結(jié)全文并展望。本文根據(jù)優(yōu)化技術(shù)所屬層級(jí)及優(yōu)化機(jī)制等對(duì)衛(wèi)星網(wǎng)絡(luò)傳輸優(yōu)化技術(shù)進(jìn)行分類,如圖1所示為分類框架。

2 傳輸層優(yōu)化

衛(wèi)星網(wǎng)絡(luò)具有傳播時(shí)延長(zhǎng)、誤碼率高、帶寬不對(duì)稱等不同于地面網(wǎng)絡(luò)的特點(diǎn),而TCP協(xié)議最初是為地面網(wǎng)絡(luò)設(shè)計(jì)的,所以在衛(wèi)星網(wǎng)絡(luò)中性能不佳。針對(duì)這個(gè)問題,前人提出了各種優(yōu)化方法,本文將傳輸層的優(yōu)化技術(shù)分為擁塞控制機(jī)制、性能增強(qiáng)代理和QUIC 3類。下面將對(duì)各技術(shù)進(jìn)行深入介紹。

2.1 擁塞控制機(jī)制

標(biāo)準(zhǔn)TCP擁塞控制算法分為慢啟動(dòng)、擁塞避免、快重傳、快速恢復(fù)4個(gè)階段,其在衛(wèi)星網(wǎng)絡(luò)中性能不佳主要是由以下3個(gè)原因?qū)е碌?

(1)衛(wèi)星網(wǎng)絡(luò)中的長(zhǎng)傳播時(shí)延導(dǎo)致標(biāo)準(zhǔn)TCP慢啟動(dòng)階段過長(zhǎng),無法快速增長(zhǎng)到合適的擁塞窗口大小;

(2)衛(wèi)星網(wǎng)絡(luò)誤碼率高,標(biāo)準(zhǔn)TCP擁塞控制算法無法區(qū)分擁塞和誤碼產(chǎn)生的丟包,因此誤碼產(chǎn)生的丟包導(dǎo)致了不必要的擁塞窗口減小;

(3)在LEO、MEO等移動(dòng)性高的衛(wèi)星網(wǎng)絡(luò)中,頻繁的衛(wèi)星切換進(jìn)一步加劇了連接的不穩(wěn)定性,增加了丟包的可能性。

針對(duì)上述問題,TCP-Peach[10]通過引入虛段來探測(cè)網(wǎng)絡(luò)帶寬。在慢開始階段和快重傳階段,發(fā)送方發(fā)送大量基于低優(yōu)先級(jí)的虛段。鏈路無擁塞時(shí),虛段的ACK使得擁塞窗口迅速增大;鏈路擁塞時(shí),低優(yōu)先級(jí)的虛段被丟棄,有效數(shù)據(jù)包不受影響。Peach一定程度上緩解了擁塞窗口過小導(dǎo)致的性能下降問題,缺點(diǎn)是虛段并沒有攜帶有效信息,會(huì)造成較大開銷。

而Peach+[11]用攜帶未確認(rèn)信息的NIL段代替Peach中的虛段,NIL段可以恢復(fù)某些丟失的包從而減少重傳,減少了引入額外段帶來的開銷。

不同于Peach和Peach+,TCP cherry[12]用攜帶待發(fā)數(shù)據(jù)的低優(yōu)先級(jí)補(bǔ)充段來探測(cè)可用帶寬,進(jìn)一步降低了引入額外段的開銷。然而當(dāng)?shù)蛢?yōu)先級(jí)補(bǔ)充段被丟棄時(shí),由此引發(fā)的重傳會(huì)降低鏈路效能。以上3種機(jī)制的共同缺陷是都需要傳輸鏈路上的所有路由器及接收方支持優(yōu)先級(jí)機(jī)制,因而阻礙了其部署。

Hybla[13]通過引入RTT0(Round-Trip Time)作為基準(zhǔn)往返時(shí)延,使擁塞窗口增長(zhǎng)速率不再依賴于RTT;同時(shí)為了快速處理丟包,啟用了選擇確認(rèn)和時(shí)間戳機(jī)制;除此之外,Hybla采用的包間隔技術(shù)避免了數(shù)據(jù)突發(fā)傳輸,降低了中間路由器緩沖區(qū)溢出的可能性。TCP Hybla特別適用于解決長(zhǎng)往返時(shí)延鏈路與其他鏈路共存時(shí)產(chǎn)生的性能損失問題。

BIC(Binary Increase Control)[14]使用了一種較為激進(jìn)的二分策略,以快速增長(zhǎng)擁塞窗口。具體細(xì)節(jié)是將丟包時(shí)的擁塞窗口定義為Wmax,發(fā)生丟包時(shí)減小后的窗口為Wmin,此后沒有丟包產(chǎn)生時(shí)每當(dāng)收到一個(gè)ACK,根據(jù)Wmax和Wmin的值采用二分法設(shè)置新的擁塞窗口。二分策略的優(yōu)點(diǎn)是擁塞窗口會(huì)以較快的速度增長(zhǎng),同時(shí)在接近Wmax時(shí),增長(zhǎng)速率會(huì)降低。然而BIC擁塞窗口增長(zhǎng)過程與RTT有關(guān),在LEO衛(wèi)星網(wǎng)絡(luò)中窗口增長(zhǎng)策略太過激進(jìn),無法保證與其他TCP協(xié)議的公平性。

根據(jù)BIC擁塞窗口增長(zhǎng)圖像所存在的缺陷,TCP-CUBIC[15]通過一個(gè)立方公式擬合了BIC圖像,以保持BIC的高效性,同時(shí)使得擁塞窗口增長(zhǎng)是關(guān)于自上次丟包發(fā)生后的時(shí)間的函數(shù),解除了與RTT的關(guān)聯(lián)性,從而保證了與其他TCP流的公平性。然而Cubic仍然是基于丟包的擁塞控制算法,在路由器部署大緩沖區(qū)的情況下,容易引起緩沖區(qū)溢出,甚至導(dǎo)致吞吐量為0。

BBR(Bottleneck Bandwidth and Round-trip propagation time)[16]通過周期性探測(cè)單位時(shí)間內(nèi)最大瓶頸帶寬和最小往返時(shí)延解決了Cubic遇到的緩沖區(qū)溢出問題。當(dāng)增大帶寬時(shí),如果RTT增大,說明發(fā)生了緩沖區(qū)隊(duì)列排隊(duì),此時(shí)應(yīng)該降低帶寬; 如果RTT不變,說明可用帶寬增加。然而當(dāng)瓶頸鏈路緩沖區(qū)較小時(shí),BBR探測(cè)到可用帶寬增長(zhǎng)過快可能導(dǎo)致大量包丟失。

上述機(jī)制均無法區(qū)分產(chǎn)生丟包的原因,而AdaBoost-TCP[17]在接收端基于機(jī)器學(xué)習(xí)構(gòu)建了一種自適應(yīng)識(shí)別模型,從而可以區(qū)分丟包的類型,并通過顯式擁塞通知機(jī)制告知發(fā)送端,發(fā)送端根據(jù)丟包類型采取合適的擁塞控制策略。但是,其采用的標(biāo)準(zhǔn)TCP的擁塞窗口增長(zhǎng)方法并不適用于衛(wèi)星網(wǎng)絡(luò),所以該方法有待進(jìn)一步優(yōu)化。

Remy[18]是一種基于機(jī)器學(xué)習(xí)的擁塞控制機(jī)制,在地面網(wǎng)絡(luò)中表現(xiàn)較好。然而,目前在衛(wèi)星網(wǎng)絡(luò)中基于機(jī)器學(xué)習(xí)的擁塞控制機(jī)制研究還較少,未來,這一方面的研究有望進(jìn)一步提升衛(wèi)星網(wǎng)絡(luò)傳輸性能。表1對(duì)上述擁塞控制機(jī)制進(jìn)行了總結(jié)。

Table 1 Summary of congestion control mechanisms表1 擁塞控制機(jī)制總結(jié)

2.2 性能增強(qiáng)代理

作為提升衛(wèi)星網(wǎng)絡(luò)中TCP性能的最有效的機(jī)制之一,PEP實(shí)質(zhì)是在傳輸鏈路的中間節(jié)點(diǎn)上部署代理,實(shí)踐中最常采用的是分段技術(shù)。即中間代理充當(dāng)發(fā)送方的“接收方”以及接受方的“發(fā)送方”,從而將衛(wèi)星鏈路從整個(gè)傳輸鏈路中分離出來,在衛(wèi)星鏈路部分使用增強(qiáng)的TCP協(xié)議或其他傳輸協(xié)議,在地面鏈路使用標(biāo)準(zhǔn)的TCP協(xié)議,以提升衛(wèi)星網(wǎng)絡(luò)傳輸性能。本文將PEP分為集中式PEP、分布式PEP和混合式PEP。如圖2所示,分布式PEP通過2個(gè)PEP將整個(gè)傳輸鏈路分為3段,PEP間的衛(wèi)星鏈路使用更適合衛(wèi)星網(wǎng)絡(luò)傳輸?shù)膮f(xié)議,2段地面鏈路使用標(biāo)準(zhǔn)的TCP協(xié)議;集中式PEP通過1個(gè)PEP將整個(gè)鏈路分為2段,服務(wù)器到PEP間的地面鏈路采用標(biāo)準(zhǔn)的TCP協(xié)議,PEP到客戶端間的衛(wèi)星鏈路采用優(yōu)化的TCP協(xié)議;混合式PEP是指除了地面中間節(jié)點(diǎn)的代理外,在衛(wèi)星上再部署一個(gè)代理,從而將衛(wèi)星鏈路部分分成2段,進(jìn)一步減少單個(gè)衛(wèi)星段的傳播時(shí)延。

Figure 2 Agent of distributed performance enhancement圖2 分布式性能增強(qiáng)代理

SaTPEP[19]是一種分布式PEP。2個(gè)SaTPEP分別作為衛(wèi)星鏈路段的發(fā)送端和接收端?；驹砣缦?接受端SaTPEP通過檢測(cè)衛(wèi)星鏈路段狀態(tài)設(shè)置滑動(dòng)窗口值,而發(fā)送端SaTPEP將擁塞窗口設(shè)置為滑動(dòng)窗口值以達(dá)到快速增加傳輸速率的目的; 同時(shí),通過部署至少衛(wèi)星鏈路段的時(shí)延帶寬積大小的緩沖區(qū)來完全避免擁塞,因此,所有的丟包都是由誤碼引起,當(dāng)丟包發(fā)生時(shí),擁塞窗口不會(huì)減小。SaTPEP很好地解決了衛(wèi)星鏈路慢啟動(dòng)時(shí)間過長(zhǎng)和誤碼引起的擁塞窗口過小的問題。但是,為了避免擁塞,SaTPEP對(duì)緩沖區(qū)資源提出了極高的要求,這限制了其部署。

PEPsal[20]是一種集中式PEP。從發(fā)送端到PEPsal的地面鏈路采用標(biāo)準(zhǔn)TCP協(xié)議,從PEPsal到終端用戶的衛(wèi)星鏈路采用了與標(biāo)準(zhǔn)TCP協(xié)議兼容的TCP Hybla協(xié)議,緩解了衛(wèi)星鏈路長(zhǎng)傳播時(shí)延、高誤碼率對(duì)傳輸性能的影響。由于PEPsal不需要終端用戶做任何軟硬件修改,所以特別適用于以衛(wèi)星網(wǎng)絡(luò)作為接入互聯(lián)網(wǎng)最后一跳的場(chǎng)景。

Luglio等人[21]通過在衛(wèi)星上部署轉(zhuǎn)發(fā)代理,提出了混合式PEP(“split TCP”代理),“split TCP”代理將集中式PEP中的衛(wèi)星鏈路段再分割為PEP到衛(wèi)星段和衛(wèi)星到終端用戶段。從而縮短了單個(gè)衛(wèi)星鏈路段傳播時(shí)延,緩解了集中式PEP緩沖區(qū)溢出的問題;其次,在集中式PEP中,衛(wèi)星傳播鏈路的上行鏈路和下行鏈路中任何一段被遮擋,傳輸都會(huì)失敗。而在“split TCP”代理中,單個(gè)衛(wèi)星鏈路段的縮短會(huì)極大提高傳輸成功的概率。但是,“split TCP”代理對(duì)機(jī)上處理能力要求較高,而衛(wèi)星上維護(hù)軟硬件的設(shè)備會(huì)更加復(fù)雜,遇到的問題也更加難以解決。

聚焦于PEP技術(shù)在衛(wèi)星網(wǎng)絡(luò)中的安全性問題,Pavur等人[22]通過部署2個(gè)QPEP(QUIC PEP)代理使衛(wèi)星鏈路段使用QUIC協(xié)議傳輸報(bào)文,從而利用QUIC的加密特性實(shí)現(xiàn)衛(wèi)星段加密傳輸;同時(shí),通過調(diào)整QPEP隧道的空閑會(huì)話時(shí)間、利用QPEP實(shí)時(shí)檢測(cè)TCP連接狀態(tài)等保證了QPEP連接與傳統(tǒng)的PEP性能相當(dāng)。該方案兼顧了衛(wèi)星段傳輸性能和安全性,下一步對(duì)QUIC協(xié)議的擁塞控制算法、衛(wèi)星段空閑會(huì)話保持時(shí)間的研究可能會(huì)進(jìn)一步提升其性能。

2.3 QUIC

QUIC由Google于2013年發(fā)布,現(xiàn)正被IETF標(biāo)準(zhǔn)化的傳輸協(xié)議[5]。圖3以HTTP/2為例展示了QUIC的協(xié)議模型。

Figure 3 Protocol stacks of QUIC and TCP圖3 QUIC和TCP協(xié)議棧

由于QUIC數(shù)據(jù)包是基于UDP協(xié)議的、同時(shí)整合了TLS(Transport Layer Security),所以可以保證在其信息不被篡改的情況下順利通過中間設(shè)備。另外,不同于TCP在內(nèi)核空間中的實(shí)現(xiàn),任何優(yōu)化都需要操作系統(tǒng)更新,QUIC是在用戶空間實(shí)現(xiàn)的,可以適應(yīng)用戶需求快速迭代。除了上述特性,相比于TCP,QUIC也引入了以下特性來提升網(wǎng)絡(luò)傳輸性能:

(1)握手協(xié)議。如圖4所示,傳統(tǒng)的TCP+TLS1.2在初次連接時(shí)需要1個(gè)RTT的TCP握手時(shí)延和2個(gè)RTT的TLS握手時(shí)延,而更為先進(jìn)的TLS1.3的TLS握手時(shí)延降低為1個(gè)RTT。相比于TCP+TLS1.2/TLS1.3,QUIC協(xié)議強(qiáng)制使用TLS1.3加密,在初次連接第1次握手時(shí)就交換了密鑰,從而使得初次連接只需要消耗1個(gè)RTT[23]。在后續(xù)連接中,由于可以使用之前緩存在客戶端的信息,實(shí)現(xiàn)了0 RTT的握手。

Figure 4 Connection establishment of QUIC圖4 QUIC連接建立

(2)多流傳輸。Web訪問中,為了減少頁面加載時(shí)間,HTTP/2引入了流的概念,一個(gè)TCP連接可以傳輸多個(gè)不相關(guān)的流,但是,由于TCP保證整個(gè)連接層面的有序可靠交付,如圖5a所示,stream3中一個(gè)包的丟失將阻礙所有流的傳輸。為了克服TCP中存在的隊(duì)頭阻塞問題,QUIC同樣引入了流的概念,如圖5b所示,每個(gè)流內(nèi)部保證可靠有序交付,steam 1流中數(shù)據(jù)包的丟失不會(huì)引起其他流的阻塞。

Figure 5 Multi-stream transmission of QUIC圖5 QUIC多流傳輸

(3)連接遷移。QUIC使用一個(gè)64位的ID代替TCP中的五元組來標(biāo)志一個(gè)連接[23],因此當(dāng)客戶端IP或端口號(hào)發(fā)生改變時(shí),例如現(xiàn)有移動(dòng)設(shè)備在Wi-Fi和5G網(wǎng)絡(luò)中切換時(shí),QUIC可以實(shí)現(xiàn)無縫遷移。

大量研究工作已經(jīng)證明了QUIC在地面網(wǎng)絡(luò)某些場(chǎng)景下的性能優(yōu)勢(shì),因此QUIC在衛(wèi)星網(wǎng)絡(luò)中的應(yīng)用也引起了研究人員的興趣。

Zhang等人[24]在GEO(Geostationary Earth Orbit)環(huán)境中比較了QUIC與TCP的性能差異。實(shí)驗(yàn)結(jié)果表明,在所有條件下,QUIC都取得了更好的性能,尤其在傳輸大量小文件時(shí)最為明顯。這主要?dú)w因于QUIC的握手時(shí)延更短。同時(shí),在丟包率增加時(shí),TCP由于發(fā)生了隊(duì)頭阻塞,導(dǎo)致性能急劇下降;而QUIC由于多流特性保證了較低的性能損失。

Wang等人[25]在模擬衛(wèi)星網(wǎng)絡(luò)環(huán)境中以Web頁面為訪問對(duì)象測(cè)量了QUIC結(jié)合BBR擁塞控制算法的性能。相比于QUIC默認(rèn)的擁塞控制算法CUBIC,當(dāng)丟包率較大時(shí),前者吞吐量顯著大于后者。原因在于BBR更能反映鏈路的擁塞狀況,故而誤碼引起的丟包對(duì)BBR擁塞窗口影響有限。但是,BBR自身的探測(cè)機(jī)制導(dǎo)致其在探測(cè)階段爭(zhēng)奪帶寬時(shí)明顯處于弱勢(shì)。

不同于Zhang等人[24,25]研究QUIC應(yīng)用于單跳衛(wèi)星鏈路,Yang等人[26]通過實(shí)驗(yàn)進(jìn)一步發(fā)現(xiàn),QUIC在衛(wèi)星間鏈路、多跳衛(wèi)星鏈路中性能仍顯著優(yōu)于TCP及TCP-ECN(Explicit Congestion Notification)的。但同時(shí)發(fā)現(xiàn),QUIC與TCP一樣,無法應(yīng)對(duì)LEO衛(wèi)星切換時(shí)產(chǎn)生的連接中斷問題。

PEP技術(shù)極大地提高了衛(wèi)星網(wǎng)絡(luò)傳輸性能。為此,Border等人[27]在GEO環(huán)境中比較了QUIC、TCP和TCP-PEP的性能差異。同樣,在丟包率較高時(shí),QUIC性能優(yōu)于TCP的,但在所有情況下,TCP-PEP都能表現(xiàn)出最好的性能,QUIC端到端層面的丟包恢復(fù)可能是導(dǎo)致這一結(jié)果的原因之一。同時(shí),相比于其他方法,QUIC默認(rèn)的加密機(jī)制帶來了額外開銷。

QUIC強(qiáng)制使用TLS1.3加密機(jī)制,為了消除TLS1.3與TLS1.2的差異帶來的影響,Deutschmann等人[1]進(jìn)一步比較了QUIC和TCP/TLS1.3-PEP在GEO環(huán)境中的性能差異。實(shí)驗(yàn)結(jié)果表明,傳輸小文件時(shí),得益于更短的握手時(shí)延,QUIC性能最優(yōu)。但是,與Border等人[27]的結(jié)論類似,傳輸大文件時(shí)TCP-PEP更優(yōu)。值得注意的是,文獻(xiàn)[1]在實(shí)驗(yàn)中測(cè)量了2種QUIC實(shí)現(xiàn)(picoquic和quicly)的性能,實(shí)驗(yàn)結(jié)果顯示picoquic性能顯著優(yōu)于quicly的?？梢?QUIC作為一個(gè)正在標(biāo)準(zhǔn)化的協(xié)議,不同的實(shí)現(xiàn)對(duì)于其性能有較大的影響。未來可以采取措施進(jìn)一步提升QUIC在衛(wèi)星網(wǎng)絡(luò)中的性能,例如增大初始和最大擁塞窗口,引入前向糾錯(cuò)機(jī)制等。表2總結(jié)了上述QUIC性能分析工作。

3 跨層優(yōu)化

跨層優(yōu)化技術(shù)是指多個(gè)協(xié)議層通過跨層協(xié)作改善網(wǎng)絡(luò)性能,本文主要關(guān)注與傳輸層緊密相關(guān)的DTN和多路徑傳輸協(xié)議。

3.1 容延容斷網(wǎng)絡(luò)

DTN體系結(jié)構(gòu)如圖6[28]所示,主要包含以下基本規(guī)范:

(1)通過在傳輸層和應(yīng)用層之間加入束(Bundle)層提供可靠傳輸[29],束層的消息為長(zhǎng)度可變的多個(gè)報(bào)文的集合,可以在異構(gòu)網(wǎng)絡(luò)中采用存儲(chǔ)轉(zhuǎn)發(fā)的形式傳遞,發(fā)送端可以區(qū)分確認(rèn)應(yīng)答包是來自中間DTN節(jié)點(diǎn)還是真正的接收者。

Table 2 Performance analysis of QUIC 表2 QUIC性能分析

Figure 6 Protocol stack of delay tolerant networking圖6 容延容斷網(wǎng)絡(luò)協(xié)議棧

(2)DTN的托管傳輸(Custody Transfer)機(jī)制可以應(yīng)對(duì)衛(wèi)星鏈路中斷。消息可以存儲(chǔ)在中間節(jié)點(diǎn),一旦某個(gè)節(jié)點(diǎn)接收到消息,將負(fù)責(zé)把消息可靠傳輸給下一節(jié)點(diǎn),當(dāng)發(fā)生網(wǎng)絡(luò)中斷時(shí),消息會(huì)被托管到所在節(jié)點(diǎn)中。

Caini等人[28]在異構(gòu)網(wǎng)絡(luò)中比較了DTN、PEPsal、端到端Hybla和NewReno的性能差異。實(shí)驗(yàn)中網(wǎng)絡(luò)狀態(tài)可分為全連接和有中斷連接。全連接中DTN性能接近于PEPsal和端到端Hybla的且明顯優(yōu)于NewReno的。同時(shí)Caini等人[28]在束層引入了滑動(dòng)窗口機(jī)制,當(dāng)滑動(dòng)窗口大于1時(shí),DTN性能甚至優(yōu)于PEPsal和Hybla的,這是因?yàn)榛瑒?dòng)窗口機(jī)制有效提高了DTN中間節(jié)點(diǎn)的占空比。有中斷連接中,當(dāng)中斷發(fā)生在連接建立時(shí),僅有DTN可以開始數(shù)據(jù)傳輸。這是因?yàn)閱⒂猛泄軅鬏數(shù)腄TN可以將數(shù)據(jù)存儲(chǔ)在中間節(jié)點(diǎn),當(dāng)中斷發(fā)生在傳輸中,DTN也能免于遭受長(zhǎng)時(shí)延。而其他方案由于中斷超時(shí)后采用指數(shù)回退算法探測(cè)網(wǎng)絡(luò)可用性,時(shí)延較大。實(shí)驗(yàn)不足之處是未將DTN與使用更為廣泛的分布式PEP進(jìn)行比較。

TBL(Tiny BundLe)[30]遵循了DTN (1)和(2)的基本規(guī)范,但TBL僅提供了satellite-LTE(Long Term Evolution)混合網(wǎng)絡(luò)所需的托管傳輸功能,從而減少了束層消息報(bào)頭開銷。文獻(xiàn)[30]在S-LTE網(wǎng)絡(luò)中,衛(wèi)星鏈路存在不同程度遮擋的條件下對(duì)比了DTN、TCP-Hybla和TCP-Reno的性能。實(shí)驗(yàn)結(jié)果表明,Hybla、DTN都能顯著提升S-LTE網(wǎng)絡(luò)傳輸性能,且這2種技術(shù)同時(shí)使用時(shí)可以最大化提升傳輸性能,這與Caini等人[28]的實(shí)驗(yàn)結(jié)果一致。但是,文獻(xiàn)[28,30]均沒有測(cè)量DTN-Hybla對(duì)長(zhǎng)時(shí)間中斷的抗干擾能力。

除了DTN具體實(shí)現(xiàn)及在各種場(chǎng)景下的測(cè)量外,擁塞控制機(jī)制、托管傳遞策略、DTN匯聚層協(xié)議等也一直是DTN技術(shù)的關(guān)鍵。例如,針對(duì)行星間通信,Bisio等人[31]在DTN中提出了基于早期隨機(jī)探測(cè)和顯示擁塞控制的方案;Han等人[32]則對(duì)比了BP/LTPCL、BP/TCPCL和BP/UDPCL等不同匯聚層協(xié)議在地月通信中的性能,發(fā)現(xiàn)DTN的優(yōu)勢(shì)之一是束層可以根據(jù)不同的環(huán)境選擇相適應(yīng)的匯聚層協(xié)議。

3.2 多路徑傳輸

多路徑傳輸技術(shù)使一個(gè)物理設(shè)備可以同時(shí)使用多條鏈路。其中,MPTCP已經(jīng)作為網(wǎng)絡(luò)協(xié)議標(biāo)準(zhǔn)被Linux內(nèi)核所支持,如圖7所示,手機(jī)終端在一個(gè)連接中通過2個(gè)TCP流可以同時(shí)使用蜂窩網(wǎng)絡(luò)和Wi-Fi網(wǎng)絡(luò)。而由于QUIC協(xié)議的諸多優(yōu)點(diǎn),有研究人員也提出了多路徑QUIC。同時(shí)現(xiàn)有衛(wèi)星網(wǎng)絡(luò)已逐漸形成了地球同步衛(wèi)星GEO(Geostationary Earth Orbit)、MEO、LEO等多種星座共存的衛(wèi)星網(wǎng)絡(luò)拓?fù)?這促進(jìn)了多路徑傳輸協(xié)議在衛(wèi)星網(wǎng)絡(luò)中的應(yīng)用。多路徑傳輸技術(shù)的優(yōu)化主要包括多路徑擁塞控制算法及對(duì)調(diào)度算法的改進(jìn)。本文將重點(diǎn)討論MPTCP、多路徑QUIC這2種多路徑協(xié)議。

Figure 7 Protocol stack of multipath TCP圖7 多路徑TCP協(xié)議棧

Du等人[33]將LEO的傳輸狀態(tài)分為穩(wěn)定期和切換期,為了解決衛(wèi)星切換導(dǎo)致的性能損失問題,提出了OMSR(On-demand Multipath Source Routing)機(jī)制。在穩(wěn)定期,地面終端僅有一個(gè)網(wǎng)關(guān)衛(wèi)星可用,網(wǎng)關(guān)衛(wèi)星通過SMR(Split Multipath Routing)協(xié)議[34]發(fā)現(xiàn)多個(gè)路徑,依靠OMSR從中選擇2個(gè)重疊最少的路徑,網(wǎng)關(guān)衛(wèi)星采用基于源地址的路由協(xié)議將不同的TCP流分配到不同的路徑上;在切換期,地面終端可以同時(shí)利用2個(gè)衛(wèi)星網(wǎng)關(guān),這時(shí)較慢的那條路徑的TCP流將被發(fā)送到新的衛(wèi)星網(wǎng)關(guān)上,從而實(shí)現(xiàn)衛(wèi)星網(wǎng)關(guān)的平穩(wěn)切換。實(shí)驗(yàn)結(jié)果顯示,MPTCP-OMSR充分利用了MPTCP(MultiPath TCP)多路徑的特性。然而,在切換期,2個(gè)網(wǎng)關(guān)衛(wèi)星為了防止選擇的路徑重合,需要共享信息,這增加了網(wǎng)關(guān)衛(wèi)星的機(jī)載處理負(fù)載。

為了克服OMSR的缺陷,Du等人[35]設(shè)計(jì)了一個(gè)可以感知MPTCP子流的SDN控制器。位于地面的SDN控制器可以獲得衛(wèi)星網(wǎng)絡(luò)的完整拓?fù)鋱D,從而利用集中式路由將不同的子流分配到不同的路徑上,這極大地減小了網(wǎng)關(guān)衛(wèi)星的機(jī)載處理負(fù)載。同時(shí),當(dāng)衛(wèi)星切換時(shí),集中式路由策略可以避免由于衛(wèi)星間交換路由信息而消耗帶寬。

Cloud等人[36]提出了基于網(wǎng)絡(luò)編碼NC(Network Coding)的MPTCP方案,以解決衛(wèi)星網(wǎng)絡(luò)高丟包率和多路徑傳輸調(diào)度的問題。其主要思想是使用隨機(jī)線性方法基于塊編碼,基本原理為發(fā)送端MPTCP/NC層將源數(shù)據(jù)包以塊為單位編碼并基于輪詢策略分配到2個(gè)TCP子流中,在各個(gè)子流的Fast-TCP/NC層,編碼產(chǎn)生冗余包以解決高丟包率問題。不足之處是隨機(jī)線性編碼引入了較大的NC報(bào)頭開銷。

為了減少NC報(bào)頭開銷,Giambene等人[37]提出了PBNC(Path-Based Network Coding)-MPTCP。PBNC在IP層進(jìn)行編碼,只需要將偽隨機(jī)函數(shù)產(chǎn)生的種子放入編碼包的NC報(bào)頭,這降低了NC報(bào)頭開銷;同時(shí),PBNC在IP層啟用了NACK包使得大多數(shù)丟包在IP層就能夠被恢復(fù),這進(jìn)一步降低了衛(wèi)星網(wǎng)絡(luò)中由于包丟失而引起的性能下降。

傳統(tǒng)的多路徑擁塞控制機(jī)制在多變的衛(wèi)星網(wǎng)絡(luò)環(huán)境中魯棒性和擴(kuò)展性較差。近年來,隨著機(jī)器學(xué)習(xí)技術(shù)的廣泛應(yīng)用,Mai等人[38]提出了DDPG(Deep Deterministic Policy Gradient)算法,通過與底層網(wǎng)絡(luò)交互,DDPG學(xué)習(xí)最優(yōu)的擁塞控制策略,在最大化吞吐量的同時(shí)保證公平性。DDPG的優(yōu)勢(shì)在于對(duì)易變網(wǎng)絡(luò)環(huán)境的適應(yīng)性較強(qiáng)。

相比于單路徑傳輸,調(diào)度算法是多路徑傳輸協(xié)議中極為重要的要素,其根據(jù)不同路徑的相關(guān)信息和調(diào)度策略將發(fā)送方緩沖區(qū)的數(shù)據(jù)分配到不同的路徑上,之后由各子路徑進(jìn)行發(fā)送。Lowest-RTT算法[39]將各個(gè)子路徑根據(jù)RTT的大小進(jìn)行降序排序并賦予優(yōu)先級(jí),按照優(yōu)先級(jí)次序分配數(shù)據(jù)包,當(dāng)優(yōu)先級(jí)最高的路徑擁塞窗口為零時(shí),則從剩余子路徑中選擇RTT次低的路徑。Lowest-RTT考慮了各個(gè)子路徑的往返時(shí)延,但在衛(wèi)星網(wǎng)絡(luò)中,當(dāng)各路徑異構(gòu)性過高時(shí),容易造成較為嚴(yán)重的隊(duì)頭阻塞問題,甚至慢路徑會(huì)影響快路徑的傳輸效率。

針對(duì)上述問題,ECF(Earliest Completion First)[40]通過比較待傳輸數(shù)據(jù)包在慢路徑上的傳輸時(shí)間和快路徑上的傳輸時(shí)間決定是否啟用慢路徑,從而優(yōu)先保證了快路徑的傳輸效率,并且在可能的情況下慢路徑作為補(bǔ)充,從而提高整體的傳輸效率。然而在傳輸大批量數(shù)據(jù)時(shí),僅在數(shù)據(jù)傳輸即將結(jié)束時(shí)ECF的決策機(jī)制才會(huì)起作用,無法解決傳輸過程中的隊(duì)頭阻塞問題。

為了解決隊(duì)頭阻塞問題,當(dāng)快路徑擁塞窗口為零時(shí),STMS(Slide Together Multipath Scheduler)[41]根據(jù)各子路徑的RTT和帶寬計(jì)算當(dāng)在慢路徑上傳輸時(shí)需要預(yù)留給快路徑的數(shù)據(jù)量,即將這些預(yù)留數(shù)據(jù)量留給未來快路徑空閑時(shí)傳輸,從而使得快路徑上后發(fā)送的低序號(hào)數(shù)據(jù)包和慢路徑上先發(fā)送的高序號(hào)數(shù)據(jù)包同時(shí)到達(dá)接收端。STMS有效解決了隊(duì)頭阻塞問題,充分聚合了多個(gè)路徑的帶寬。

De Coninck等人[42]在QUIC基礎(chǔ)上提出了MPQUIC(MultiPath QUIC)。與MPTCP不同的是,MPQUIC支持多流機(jī)制,即一個(gè)連接中包含多個(gè)流,因此其調(diào)度算法可以進(jìn)行更細(xì)粒度的流調(diào)度;同時(shí),MPQUIC的數(shù)據(jù)幀獨(dú)立于其組成的數(shù)據(jù)包,所以當(dāng)一個(gè)包丟失時(shí),組成它的數(shù)據(jù)幀可以根據(jù)鏈路擁塞程度,選擇在不同的路徑上重傳,而MPTCP需要在相同的路徑上按序重傳。實(shí)驗(yàn)表明,在類似于衛(wèi)星的高時(shí)延帶寬積和高誤碼率的環(huán)境中,MPQUIC的性能優(yōu)于MPTCP的。這是因?yàn)镸PQUIC對(duì)于各個(gè)鏈路的往返時(shí)延、丟包等有更精確的信息,因此在各個(gè)鏈路上的調(diào)度更加合理,從而緩解了MPTCP遇到的緩沖區(qū)溢出、隊(duì)頭阻塞等問題。

為了充分利用多流機(jī)制的優(yōu)勢(shì),在ECF[20]的基礎(chǔ)上,SA-ECF(Stream-Aware ECF)[43]引入了更細(xì)粒度的流感知調(diào)度算法,其基于2條路徑的流預(yù)測(cè)完成時(shí)間,選擇兩者中較小者作為傳輸路徑,而流與流之間根據(jù)其權(quán)重采用權(quán)重輪詢算法。SA-ECF可以實(shí)現(xiàn)快速傳輸關(guān)鍵流,同時(shí)保持各流的公平性,但在衛(wèi)星網(wǎng)絡(luò)等異構(gòu)網(wǎng)絡(luò)中,SA-ECF無法充分利用各路徑帶寬,且沒有考慮不同的流對(duì)資源有不同需求。

PStream(Priority-based Stream)[44]則考慮了MPQUIC中各流的大小和優(yōu)先級(jí)特性以及各流之間的公平性,單個(gè)流綜合利用多個(gè)路徑以最小化完成時(shí)間,同時(shí)流與流之間采用權(quán)重輪詢算法以保持公平性,然而PStream算法的調(diào)度具有超前性,在衛(wèi)星網(wǎng)絡(luò)鏈路狀況易變的情況下性能較差。

盡管多路徑傳輸協(xié)議如MPTCP在地面網(wǎng)絡(luò)中已經(jīng)有所應(yīng)用,但在衛(wèi)星網(wǎng)絡(luò)中,設(shè)計(jì)出能夠應(yīng)對(duì)多變環(huán)境的擁塞控制算法和流調(diào)度算法是目前多路徑傳輸面臨的一大挑戰(zhàn)。而隨著QUIC標(biāo)準(zhǔn)化的不斷推進(jìn),多路徑QUIC的實(shí)現(xiàn)及優(yōu)化也值得進(jìn)一步研究。表3對(duì)MPTCP和MPQUIC的相關(guān)工作進(jìn)行了總結(jié)。

4 傳輸優(yōu)化技術(shù)分析與比較

由于現(xiàn)有衛(wèi)星網(wǎng)絡(luò)的星座構(gòu)成、應(yīng)用場(chǎng)景、優(yōu)化目標(biāo)不盡相同,故存在多種優(yōu)化方法,而評(píng)價(jià)各種優(yōu)化技術(shù)采取的評(píng)判指標(biāo)也有所不同,這進(jìn)一步加劇了不同技術(shù)之間比較的難度。具體使用哪種優(yōu)化技術(shù),需要從應(yīng)用場(chǎng)景、用戶需求、技術(shù)復(fù)雜程度、經(jīng)濟(jì)成本等多方面綜合考慮。針對(duì)不同優(yōu)化技術(shù)的優(yōu)點(diǎn)和缺點(diǎn),表4按照本文的分類方法對(duì)其進(jìn)行了總結(jié)。

Table 3 Summary of multipath transmission technologies表3 多路徑傳輸技術(shù)總結(jié)

Table 4 Analysis and comparison of transmission layer optimization techniques in satellite networks表4 衛(wèi)星網(wǎng)絡(luò)傳輸層優(yōu)化技術(shù)分析與比較

5 結(jié)束語

在第六代通信技術(shù)(6G)的設(shè)想中,衛(wèi)星網(wǎng)絡(luò)作為6G網(wǎng)絡(luò)的重要組成部分,可以有效彌補(bǔ)地面網(wǎng)絡(luò)的不足,覆蓋廣大山區(qū)、農(nóng)村等偏遠(yuǎn)地區(qū)。然而衛(wèi)星網(wǎng)絡(luò)存在傳播時(shí)延長(zhǎng)、誤碼率高、帶寬不對(duì)稱等問題。同時(shí),近年來隨著LEO、MEO等多種星座的發(fā)展,衛(wèi)星網(wǎng)絡(luò)又表現(xiàn)出了強(qiáng)移動(dòng)性、易被遮擋的特性,這進(jìn)一步加劇了衛(wèi)星網(wǎng)絡(luò)環(huán)境的復(fù)雜性。針對(duì)衛(wèi)星網(wǎng)絡(luò)存在的上述問題,本文結(jié)合優(yōu)化技術(shù)所屬層級(jí)和優(yōu)化機(jī)制對(duì)各種優(yōu)化技術(shù)進(jìn)行了分類。首先,簡(jiǎn)要回顧了經(jīng)典的優(yōu)化技術(shù),包括針對(duì)衛(wèi)星網(wǎng)絡(luò)特點(diǎn)設(shè)計(jì)的專有擁塞控制機(jī)制、部署在衛(wèi)星網(wǎng)絡(luò)中間節(jié)點(diǎn)的PEP技術(shù)、DTN技術(shù)等。接著,重點(diǎn)分析了QUIC、多路徑傳輸、機(jī)器學(xué)習(xí)等新技術(shù)在衛(wèi)星網(wǎng)絡(luò)領(lǐng)域的應(yīng)用及對(duì)衛(wèi)星網(wǎng)絡(luò)傳輸性能的提升。最后,對(duì)上述優(yōu)化技術(shù)的優(yōu)缺點(diǎn)及使用場(chǎng)景進(jìn)行了分析與總結(jié)。

雖然研究人員在衛(wèi)星網(wǎng)絡(luò)傳輸優(yōu)化技術(shù)領(lǐng)域已經(jīng)做了大量的工作,但依然有很大改進(jìn)空間,可以從如下幾個(gè)方面對(duì)衛(wèi)星網(wǎng)絡(luò)傳輸優(yōu)化開展進(jìn)一步研究:

(1)擁塞控制機(jī)制是其他技術(shù)的基礎(chǔ)。傳統(tǒng)的基于固定參數(shù)或模型的擁塞控制機(jī)制具有決策機(jī)械的問題,難以適應(yīng)動(dòng)態(tài)變化的衛(wèi)星網(wǎng)絡(luò)環(huán)境,而隨著機(jī)器學(xué)習(xí)和人工智能理論和實(shí)踐的不斷深化,其在不同的前沿技術(shù)領(lǐng)域得到了廣泛應(yīng)用。結(jié)合機(jī)器學(xué)習(xí)的智能決策算法能夠根據(jù)不同的環(huán)境及需求做出相應(yīng)的決策,進(jìn)而有針對(duì)性地達(dá)到更加優(yōu)越的傳輸性能。例如,基于強(qiáng)化學(xué)習(xí)的智能擁塞控制策略能夠基于大量經(jīng)驗(yàn)進(jìn)行學(xué)習(xí),捕獲到衛(wèi)星網(wǎng)絡(luò)環(huán)境狀態(tài)與擁塞控制決策之間的關(guān)系,從而根據(jù)當(dāng)下的環(huán)境狀態(tài),做出最優(yōu)的決策。

(2)由于QUIC在用戶空間實(shí)現(xiàn)并且強(qiáng)制使用TLS1.3進(jìn)行加密,導(dǎo)致QUIC在老舊硬件設(shè)備中存在性能問題,因此在將QUIC應(yīng)用于衛(wèi)星網(wǎng)絡(luò)時(shí),在保證不降低傳輸性能的情況下減小QUIC對(duì)CPU處理能力的需求是一個(gè)重要的研究方向。實(shí)踐證明,PEP技術(shù)是改善衛(wèi)星網(wǎng)絡(luò)傳輸性能較為成熟的方法之一,而考慮到QUIC協(xié)議具有握手時(shí)延短、多流復(fù)用等諸多優(yōu)勢(shì),已有研究人員結(jié)合PEP技術(shù)與QUIC協(xié)議的優(yōu)勢(shì),以期望進(jìn)一步提升衛(wèi)星網(wǎng)絡(luò)傳輸性能。但是,正如QUIC協(xié)議仍在不斷優(yōu)化的過程中,這2項(xiàng)技術(shù)在衛(wèi)星網(wǎng)絡(luò)中的融合仍需進(jìn)一步研究。

(3)巨型星座時(shí)代,多路徑傳輸技術(shù)是提升衛(wèi)星網(wǎng)絡(luò)傳輸性能最有前景的研究方向之一,但相比于單路徑傳輸,多路徑傳輸在衛(wèi)星網(wǎng)絡(luò)中發(fā)揮性能優(yōu)勢(shì)的同時(shí)還要處理擁塞控制和多路徑數(shù)據(jù)調(diào)度問題,因此設(shè)計(jì)一個(gè)能夠有效協(xié)同并適用于衛(wèi)星網(wǎng)絡(luò)環(huán)境的擁塞控制機(jī)制和多路徑調(diào)度算法是推動(dòng)多路徑傳輸技術(shù)應(yīng)用于衛(wèi)星網(wǎng)絡(luò),并提升衛(wèi)星網(wǎng)絡(luò)傳輸性能的關(guān)鍵。