王子涵 張 嬌 張 遠(yuǎn) 潘 恬 黃 韜

（北京郵電大學(xué)信息與通信工程學(xué)院 北京 100876）（wangzh9932@sohu.com）

隨著商業(yè)低軌衛(wèi)星（low earth orbit, LEO）星座快速發(fā)展，在可以預(yù)見的將來，低軌衛(wèi)星星座網(wǎng)絡(luò)將會給大眾提供更加廉價、方便、快捷、穩(wěn)定的網(wǎng)絡(luò)接入.而截至2017年6月，全球互聯(lián)網(wǎng)普及率為51.7%，意味著全球仍有一半的人口未實現(xiàn)互聯(lián)網(wǎng)連接.相對于地面通信系統(tǒng)，低軌衛(wèi)星通信系統(tǒng)易于快速實現(xiàn)大范圍的全球覆蓋，適合低人口密度、有限業(yè)務(wù)流量的國家或地區(qū).相對于高軌以及靜止軌道衛(wèi)星通信系統(tǒng)，低軌衛(wèi)星通信系統(tǒng)鏈路具有多方面優(yōu)勢：1）傳播損耗小，更有利于系統(tǒng)為手持終端用戶提供服務(wù)；2）傳輸時延小，實時性較好；3）采用極地軌道或大傾角軌道時可為高緯度地區(qū)提供服務(wù)；4）可利用多普勒頻移進(jìn)行定位，實現(xiàn)導(dǎo)航增強(qiáng)功能；5）星座能夠?qū)τ脩籼峁┒嘀馗采w，可以增強(qiáng)抗毀性.

雖然低軌衛(wèi)星網(wǎng)絡(luò)有著諸多優(yōu)勢和應(yīng)用潛能，但目前的應(yīng)用大都還局限在語音、短消息等低速通信業(yè)務(wù).隨著互聯(lián)網(wǎng)的不斷發(fā)展，衛(wèi)星網(wǎng)絡(luò)作為地面網(wǎng)絡(luò)的重要補(bǔ)充必然會承載更多種類的業(yè)務(wù)，如視頻、直播、遠(yuǎn)程教育等.而這些業(yè)務(wù)都需要衛(wèi)星網(wǎng)絡(luò)提供可靠的高速率接入.為了與地面網(wǎng)絡(luò)協(xié)同，衛(wèi)星網(wǎng)絡(luò)必然會順應(yīng)當(dāng)前的趨勢采用TCP（Transmission Control Protocol）/IP協(xié)議體系來提供可靠傳輸.而衛(wèi)星網(wǎng)絡(luò)固有的長時延、高突發(fā)誤碼率、上下行信道帶寬不對稱、拓?fù)鋾r變等特性，使得衛(wèi)星網(wǎng)絡(luò)直接應(yīng)用針對地面網(wǎng)絡(luò)設(shè)計的TCP傳輸控制協(xié)議時性能表現(xiàn)很差.

首先，衛(wèi)星網(wǎng)絡(luò)較長的端到端往返時延（roundtrip time，RTT）會使TCP在慢啟動階段的擁塞窗口（congestion window，CWND）增長緩慢，并且無法從丟包后帶寬減半的狀態(tài)快速恢復(fù)到填滿帶寬的狀態(tài)，不能充分利用網(wǎng)絡(luò)的帶寬資源；衛(wèi)星鏈路較高的誤碼率也會讓TCP頻繁降低擁塞窗口，這是因為TCP認(rèn)為所有的丟包都是由于鏈路擁塞造成的，使得衛(wèi)星鏈路在傳輸過程中由誤碼引起的丟包也被當(dāng)作網(wǎng)絡(luò)擁塞的信號，引起源端不必要的降窗操作；文獻(xiàn)[1]指出，地面網(wǎng)絡(luò)的誤碼率小于10-9，衛(wèi)星網(wǎng)絡(luò)誤碼率范圍為10-4～10-8.衛(wèi)星網(wǎng)絡(luò)中上行和下行帶寬通常有著很大的不對稱性，上行鏈路的有效帶寬一般遠(yuǎn)小于下行鏈路的帶寬，這導(dǎo)致TCP確認(rèn)信號流具有突發(fā)特性，進(jìn)而導(dǎo)致發(fā)送端速率增長緩慢、快速恢復(fù)機(jī)制效率低下.

另外，低軌衛(wèi)星網(wǎng)絡(luò)中的端到端往返時延變化較大，在地球同步軌道衛(wèi)星場景下，傳輸時延取決于用戶之間的距離，而在有著星間鏈路（inter-satellite link, ISL）的低軌衛(wèi)星網(wǎng)絡(luò)中，星座的拓?fù)潢P(guān)系會隨時間快速變化，導(dǎo)致傳輸時延發(fā)生變化，這可能會影響TCP對RTT的估計[2].每當(dāng)RTT發(fā)生變化，TCP都需要一些時間來適應(yīng)這種變化.在低軌衛(wèi)星星座網(wǎng)絡(luò)中，RTT會不斷發(fā)生變化，導(dǎo)致TCP無法足夠快速更新其估算的RTT.這可能會導(dǎo)致過早的超時重傳，降低鏈路的帶寬利用率.在低軌衛(wèi)星網(wǎng)絡(luò)中使用面向連接的TCP協(xié)議時，每次發(fā)生衛(wèi)星切換，都可能引發(fā)較大數(shù)量的TCP數(shù)據(jù)包丟失，特別是在信令交換沒有正確執(zhí)行的情況下.另外，在切換完成后，TCP會因為發(fā)生大量丟包而將其擁塞窗口減到最低[3].

這些衛(wèi)星網(wǎng)絡(luò)的特點導(dǎo)致現(xiàn)有典型網(wǎng)絡(luò)擁塞控制協(xié)議面臨嚴(yán)重的性能下降.例如基于丟包的TCP Cubic[4]、基于時延的TCP Vegas[5]、基于帶寬時延積（bandwidth-delay product，BDP）估計的TCP Westwood[6]和BBR[7].當(dāng)前這些針對地面網(wǎng)絡(luò)和高軌衛(wèi)星網(wǎng)絡(luò)設(shè)計的擁塞控制協(xié)議在低軌衛(wèi)星星座網(wǎng)絡(luò)中，都會遇到不同程度的性能降級.

本文分析了典型TCP擁塞控制協(xié)議在衛(wèi)星網(wǎng)絡(luò)中性能下降的原因，并提出了基于時延區(qū)分的衛(wèi)星網(wǎng)絡(luò)傳輸控制協(xié)議（delay-differentiated TCP，DDTCP）.DDTCP通過新的時延探測機(jī)制可以在動態(tài)變化的低軌衛(wèi)星網(wǎng)絡(luò)中根據(jù)時延變化趨勢快速、準(zhǔn)確探測當(dāng)前鏈路狀況，然后基于探測結(jié)果控制發(fā)送端的擁塞窗口變化，能夠有效提高網(wǎng)絡(luò)帶寬利用率.針對衛(wèi)星切換造成的短時間內(nèi)大量數(shù)據(jù)包丟失，DDTCP通過快速丟包重傳機(jī)制，可以在源端快速將丟失的數(shù)據(jù)包重傳，避免觸發(fā)超時重傳機(jī)制，重傳結(jié)束后擁塞窗口不會減到初始窗口，而是基于最新的探測值重新計算，避免再次從慢啟動階段開始.針對衛(wèi)星網(wǎng)絡(luò)長時延、小緩存的鏈路狀況，DDTCP使用動態(tài)擁塞窗口上界調(diào)整算法根據(jù)丟包率、網(wǎng)絡(luò)時延變化等信息，實時調(diào)整擁塞窗口上界，避免過大的擁塞窗口導(dǎo)致鏈路緩存溢出造成TCP數(shù)據(jù)包丟失.

我們在Linux內(nèi)核中實現(xiàn)了DDTCP協(xié)議，并在半實物衛(wèi)星網(wǎng)絡(luò)仿真平臺上進(jìn)行了性能驗證.實驗結(jié)果表明，與TCP Vegas，Cubic，BBR對比，DDTCP的吞吐量提高了19%以上, 同時可以保證數(shù)據(jù)傳輸更加穩(wěn)定，不會受到低軌衛(wèi)星網(wǎng)絡(luò)高動態(tài)變化的影響.

1 背景和相關(guān)工作

1.1 低軌衛(wèi)星網(wǎng)絡(luò)的特點

與傳統(tǒng)地面網(wǎng)絡(luò)不同，低軌衛(wèi)星通信網(wǎng)絡(luò)具有拓?fù)鋾r變、高誤碼、長時延、大時延帶寬積等特點.因此，傳統(tǒng)傳輸控制協(xié)議在衛(wèi)星網(wǎng)絡(luò)中會產(chǎn)生帶寬利用率低、丟包率較高等問題.在提出適應(yīng)低軌衛(wèi)星網(wǎng)絡(luò)的傳輸控制方案之前，我們將首先分析低軌衛(wèi)星網(wǎng)絡(luò)與傳輸控制協(xié)議性相關(guān)的獨有特征.具體地，將從丟包產(chǎn)生原因、時延變化規(guī)律、鏈路中斷3方面進(jìn)行分析.

1.1.1 丟包原因多樣

1）鏈路擁塞導(dǎo)致丟包.衛(wèi)星網(wǎng)絡(luò)同地面網(wǎng)絡(luò)的最大區(qū)別是衛(wèi)星網(wǎng)絡(luò)的往返時間較長.地面網(wǎng)絡(luò)的往返時間在幾十毫秒之內(nèi)，而衛(wèi)星網(wǎng)絡(luò)的往返時間往往在幾百毫秒.衛(wèi)星網(wǎng)絡(luò)更容易觸發(fā)超時重傳機(jī)制，該機(jī)制重新發(fā)送數(shù)據(jù)，導(dǎo)致數(shù)據(jù)在傳輸時造成擁塞，使得數(shù)據(jù)傳輸?shù)臅r間進(jìn)一步增加，惡性循環(huán)，造成網(wǎng)絡(luò)的崩潰.

2）比特錯誤導(dǎo)致丟包.衛(wèi)星鏈路具有較高的誤碼率，在同步軌道通信環(huán)境下，衛(wèi)星信道表現(xiàn)為高斯加性白噪聲，誤碼以隨機(jī)誤碼為主，而在中軌和低軌的環(huán)境下，由于受到多普勒頻移的影響，衛(wèi)星信道表現(xiàn)為萊斯或者瑞利信道，除了隨機(jī)誤碼的情況之外還有突發(fā)誤碼的出現(xiàn).傳輸控制協(xié)議在驗證數(shù)據(jù)包出現(xiàn)比特錯誤時，便會主動丟棄這一數(shù)據(jù)包，降低了網(wǎng)絡(luò)傳輸數(shù)據(jù)的效率.

1.1.2 時延變化差異大

1）隊列長度導(dǎo)致時延變化.在衛(wèi)星網(wǎng)絡(luò)中的每一個節(jié)點都有一定的緩存隊列，而在網(wǎng)絡(luò)擁塞程度不同的時候，緩存隊列的長度也不同，這就會導(dǎo)致在不同擁塞程度時，隊列長度會發(fā)生變化進(jìn)而往返時延發(fā)生改變.但是在低軌衛(wèi)星網(wǎng)絡(luò)中，由隊列長度變化導(dǎo)致的時延變化較小，衛(wèi)星運動以及衛(wèi)星切換往往是決定時延變化的主要因素.

2）衛(wèi)星運動引發(fā)時延變化.衛(wèi)星相對于地面端運動時，由于傳輸路徑改變，無線電在大氣層及電離層中的傳播時延也隨之改變.在低軌衛(wèi)星網(wǎng)絡(luò)中，傳播時延隨著衛(wèi)星之間的距離以及傳輸路徑的變化而變化，通信距離每增加1 000 km，就會帶來額外約13.3 ms的往返時延[8].

3）衛(wèi)星切換引發(fā)時延變化.在低軌衛(wèi)星通信系統(tǒng)中，作為核心交換節(jié)點的衛(wèi)星為了維持較低的恒定軌道高度，必須圍繞地球高速旋轉(zhuǎn)，造成衛(wèi)星覆蓋區(qū)域在地球表面上的快速移動，從而產(chǎn)生衛(wèi)星與用戶之間的切換.衛(wèi)星切換不可避免地會產(chǎn)生切換時延，易造成傳輸數(shù)據(jù)的大量丟失，由衛(wèi)星切換引起的時延往往在100 ms左右[9].圖1展示了在以傳播時延作為基礎(chǔ)度量，路由選擇傳播最短時延路徑（least delay path，LDP）時，由48顆衛(wèi)星組成的近極軌衛(wèi)星網(wǎng)絡(luò)中2顆衛(wèi)星之間鏈路傳播時延和跳數(shù)隨時間變化的結(jié)果.可以看到在低軌衛(wèi)星網(wǎng)絡(luò)中，鏈路傳播時延始終處于變化狀態(tài)，并且每隔10 min左右就會發(fā)生1次路徑變更，導(dǎo)致鏈路傳播時延發(fā)生較大突變.

Fig.1 Propagation delay and hops variation in LEO satellite constellations圖1 低軌衛(wèi)星星座中的傳播時延和跳數(shù)變化

1.1.3 鏈路頻繁發(fā)生中斷

低軌衛(wèi)星星座由于高動態(tài)變化，導(dǎo)致TCP鏈路可能因為天氣情況、衛(wèi)星切換、網(wǎng)絡(luò)拓?fù)潢P(guān)系變化以及軌道變化等多種原因發(fā)生頻繁中斷.在低軌衛(wèi)星網(wǎng)絡(luò)中，由于衛(wèi)星繞地球快速運行導(dǎo)致其服務(wù)范圍不斷變化，對于地面固定用戶，每個衛(wèi)星的最大可見時間在8～11 min之間，當(dāng)用戶即將離開當(dāng)前衛(wèi)星的服務(wù)范圍時需要將連接切換到新的衛(wèi)星，而每次衛(wèi)星切換都可能導(dǎo)致TCP數(shù)據(jù)包亂序、丟失，甚至產(chǎn)生短時間鏈路中斷[10].

此外當(dāng)衛(wèi)星運行至極地軌道交匯點附近時，由于相鄰軌道衛(wèi)星間的距離和視角快速變化，很難建立穩(wěn)定的衛(wèi)星間鏈路，所以衛(wèi)星會暫時關(guān)閉部分星間鏈路，等到離開極區(qū)后，重新建立衛(wèi)星間鏈路.在這個過程中發(fā)生的衛(wèi)星間鏈路切換以及由于衛(wèi)星運動引起的星座網(wǎng)絡(luò)拓?fù)潢P(guān)系的變化都會導(dǎo)致網(wǎng)絡(luò)路由發(fā)生變化，在路由更新過程中，舊路由不能被使用而新路由還未就緒，導(dǎo)致衛(wèi)星鏈路發(fā)生中斷.

1.2 網(wǎng)絡(luò)傳輸控制協(xié)議

網(wǎng)絡(luò)傳輸控制協(xié)議是為了在不可靠且多種應(yīng)用共享的互聯(lián)網(wǎng)絡(luò)上為網(wǎng)絡(luò)應(yīng)用提供可靠公平傳輸而設(shè)計.由于其重要性，工業(yè)界和學(xué)術(shù)界對此協(xié)議都進(jìn)行了持續(xù)研究.根據(jù)現(xiàn)有工作進(jìn)行源端速率調(diào)節(jié)的依據(jù)因素不同，應(yīng)用于衛(wèi)星網(wǎng)絡(luò)的擁塞協(xié)議主要可以分為3類：

1）基于丟包的傳輸控制協(xié)議

基于丟包的傳輸控制協(xié)議將丟包作為網(wǎng)絡(luò)出現(xiàn)擁塞的標(biāo)志.發(fā)送端逐步增大擁塞窗口以充分利用帶寬，而當(dāng)網(wǎng)絡(luò)出現(xiàn)丟包時，將擁塞窗口減小.這種類型的控制協(xié)議原理較為簡單，近年來主要的實現(xiàn)方法有TCP Hybla，TCP Hybla+，TCP Peach，TCP Peach+，TCP Swift，TCP Cherry等[11-12].

TCP Hybla主要修改了Reno在慢啟動和擁塞避免階段擁塞窗口的增加方式，以一個短RTT（25 ms）為基準(zhǔn)，使得不同RTT的TCP連接獲得相同的傳輸速率，抵消了由衛(wèi)星網(wǎng)絡(luò)長RTT引起的性能惡化.

TCP Peach 使用低優(yōu)先級的虛擬段探測帶寬以增加慢啟動階段擁塞窗口的增加速度.TCP Cherry部署了一種新型的低優(yōu)先級數(shù)據(jù)段，除探測網(wǎng)絡(luò)之外，還攜帶尚未傳輸?shù)臄?shù)據(jù)段.

2）基于時延的傳輸控制協(xié)議

基于時延的傳輸控制協(xié)議將時延增加作為出現(xiàn)擁塞的標(biāo)志.當(dāng)時延增加時，減小擁塞窗口；當(dāng)時延減小時，增加擁塞窗口.Vegas使用時延估計網(wǎng)絡(luò)情況，通過比較實際吞吐量和期望吞吐量來調(diào)節(jié)擁塞窗口的大小.SCPS-TP協(xié)議（Space Communication Protocol Specification — Transport Protocol）是面向空間鏈路設(shè)計的傳輸協(xié)議，可以有效提高衛(wèi)星網(wǎng)絡(luò)的傳輸性能[13].但是SCPS-TP默認(rèn)使用的擁塞控制算法是Vegas，在低軌衛(wèi)星星座網(wǎng)絡(luò)中無法區(qū)分時延變化是由衛(wèi)星運動引起還是網(wǎng)絡(luò)擁塞引起，因此存在帶寬競爭能力較弱的問題.Illinois[14]則是動態(tài)地調(diào)整加性增加窗口和乘性增加窗口來充分利用帶寬.Illinois將丟包作為主要的擁塞信號決定窗口的增減，并將排隊時延作為次要擁塞信號決定窗口變化的速率.

3）基于BDP估計的傳輸控制協(xié)議

基于BDP估計的傳輸控制協(xié)議通過測量網(wǎng)絡(luò)的帶寬和時延來調(diào)節(jié)發(fā)送窗口.Westwood在報文丟失時，利用帶寬估計值和最小RTT設(shè)定擁塞窗口的大小，能夠?qū)崿F(xiàn)更快速地恢復(fù)，其在無線網(wǎng)絡(luò)中表現(xiàn)較好.TCP-J使用可用帶寬估計（available bandwith estimation, ABE），進(jìn)行帶寬估計能夠?qū)崿F(xiàn)更快速地恢復(fù)，TCP-J在無線網(wǎng)絡(luò)中表現(xiàn)較好.TCP-WestwoodBR是TCP-Westwood的一個擴(kuò)展，解決了衛(wèi)星網(wǎng)絡(luò)等高錯誤環(huán)境中的性能問題.TCP-WestwoodBR主要修改了3個部分：在同一窗口中檢測到多個損失時可能會立即重發(fā)送所有未完成的數(shù)據(jù)包；在連續(xù)損失發(fā)生時使用固定的超時值而不是在指數(shù)后退和發(fā)生損失時仍保持擁塞窗口.BBR由谷歌在2016年提出，它認(rèn)為網(wǎng)絡(luò)上的數(shù)據(jù)包總量大于瓶頸鏈路帶寬和時延的乘積時出現(xiàn)擁塞.BBR分別估計帶寬和時延，得到的網(wǎng)絡(luò)容量更加準(zhǔn)確，減少了緩沖區(qū)膨脹現(xiàn)象的發(fā)生，使得時延大大降低.BBR不再將丟包作為擁塞控制信號，在丟包率較高的網(wǎng)絡(luò)中，BBR依舊擁有較高的吞吐量.

當(dāng)前衛(wèi)星網(wǎng)絡(luò)傳輸控制協(xié)議主要沿用類似于地面?zhèn)鬏斂刂茀f(xié)議的設(shè)計思路[15]，缺乏專門針對低軌衛(wèi)星網(wǎng)絡(luò)的特點而設(shè)計的高性能的傳輸控制協(xié)議.因此，本文將首先分析低軌衛(wèi)星網(wǎng)絡(luò)特點，然后提出面向衛(wèi)星網(wǎng)絡(luò)特征的高性能傳輸控制協(xié)議.

2 研究動機(jī)

本節(jié)通過實驗分析現(xiàn)有典型協(xié)議Vegas和BBR在衛(wèi)星網(wǎng)絡(luò)中性能下降的原因.

實驗拓?fù)淙鐖D2所示，2臺主機(jī)分別作發(fā)送端，1臺主機(jī)作接收端.發(fā)送端1使用TCP Vegas作為默認(rèn)的TCP擁塞控制算法，發(fā)送端2使用TCP BBR作為默認(rèn)的擁塞控制算法.我們使用一臺具有雙網(wǎng)卡的主機(jī)作為交換機(jī)，并在上面通過Linux提供的tc命令設(shè)置網(wǎng)絡(luò)的傳播時延為40 ms、帶寬為100 Mbps.然后在發(fā)送端運行iperf軟件進(jìn)行網(wǎng)絡(luò)吞吐量測試.

Fig.2 Experimental topology圖2 實驗拓?fù)?/p>

Vegas通過RTT的變化來計算期望吞吐量與實際吞吐量的差值，進(jìn)而主動調(diào)整擁塞窗口.因此，Vegas不依靠丟包就能預(yù)測網(wǎng)絡(luò)擁塞，從而在丟包之前擁塞避免，能減少數(shù)據(jù)包的丟失，更有效地利用帶寬.然而，Vegas算法以RTT為主要參數(shù)來控制擁塞窗口的變化，而低軌衛(wèi)星星座網(wǎng)絡(luò)的拓?fù)浣Y(jié)構(gòu)是實時且高動態(tài)變化的，這會造成RTT的非擁塞原因增大.Vegas算法本身并沒有能力識別RTT的增大是由于網(wǎng)絡(luò)擁塞造成的還是由于路徑變化造成的.如果是路徑的改變導(dǎo)致RTT的增加，那么Vegas算法也會減小發(fā)送窗口，從而浪費了網(wǎng)絡(luò)帶寬資源.

圖3顯示了TCP Vegas在鏈路時延動態(tài)變化的場景下的吞吐量與擁塞窗口的變化.鏈路的初始傳播時延設(shè)置為40 ms，在第20 s的時候，我們通過腳本將傳播時延修改為100 ms.可以看到，在開始的20 s內(nèi)，Vegas將40 ms作為基準(zhǔn)RTT，然后根據(jù)RTT值的變化調(diào)整擁塞窗口，在這種穩(wěn)定狀態(tài)下可以達(dá)到95 Mbps左右的吞吐量，充分利用了鏈路帶寬.而在傳播時延變?yōu)?00 ms后，Vegas仍然將基準(zhǔn)RTT維持在40 ms，然后因為探測到的RTT值始終大于基準(zhǔn)RTT，Vegas一直在嘗試減小擁塞窗口，導(dǎo)致吞吐持續(xù)降低.可以看到，由于Vegas在鏈路狀況發(fā)生變化后不會主動探測新的鏈路信息，在這種高動態(tài)網(wǎng)絡(luò)中不能充分利用網(wǎng)絡(luò)的帶寬資源.

Fig.3 Throughput and congestion window value of TCP Vegas圖3 TCP Vegas的吞吐量與擁塞窗口值

此外，雖然Vegas是基于RTT的擁塞控制協(xié)議，但是在具體實現(xiàn)中，Vegas仍然會對具體的丟包事件做出反應(yīng).這會導(dǎo)致Vegas在有著一定誤碼率的衛(wèi)星鏈路上性能表現(xiàn)更加糟糕.

BBR通過主動探測鏈路帶寬和時延來最大化利用當(dāng)前網(wǎng)絡(luò)帶寬資源.根據(jù)BBR的擁塞控制流程，只要網(wǎng)絡(luò)拓?fù)洵h(huán)境不發(fā)生劇烈變化，幾乎不會引起擁塞丟包而發(fā)起數(shù)據(jù)重傳.但是在高度動態(tài)變化的低軌衛(wèi)星星座網(wǎng)絡(luò)中，衛(wèi)星與地面用戶之間會頻繁發(fā)生鏈路切換，造成當(dāng)前連接所在鏈路的可用帶寬和時延產(chǎn)生突變.這種情況會在一定程度上降低BBR在衛(wèi)星網(wǎng)絡(luò)環(huán)境中的吞吐量.

圖4顯示了TCP BBR在2種不同場景下的吞吐量變化.對于場景1，我們在20 s的時候?qū)㈡溌窌r延從40 ms修改為100 ms，可以看到在鏈路時延發(fā)生變化后，BBR仍然以最小歷史RTT作為RTT估計值，導(dǎo)致計算出的BDP偏小，無法將可用帶寬占滿.對于場景2，我們在第20 s后，通過腳本逐漸將RTT增大到100 ms，可以看到在20 s以后，BBR每隔10 s吞吐量就會有一個波谷，這是因為BBR進(jìn)入時延探測階段基本不發(fā)數(shù)據(jù)包導(dǎo)致的.盡管此時時延變化并不是由于擁塞引起的，但是因為BBR沒有對這類時延變化進(jìn)行區(qū)分，所以會強(qiáng)制進(jìn)入時延探測階段.對于實時性要求較高的應(yīng)用來說，這會對服務(wù)質(zhì)量造成一定影響.

3 DDTCP設(shè)計

3.1 核心思想

DDTCP是一個基于BDP探測的傳輸控制協(xié)議.針對衛(wèi)星網(wǎng)絡(luò)特點和現(xiàn)有方案的不足，DDTCP在保留原BBR算法擁塞控制機(jī)制的基本原理的基礎(chǔ)上，在發(fā)送端通過確認(rèn)包到達(dá)時間計算鏈路RTT，并且保存近期內(nèi)的RTT信息，然后根據(jù)時延變化趨勢對鏈路狀況進(jìn)行分類處理.針對衛(wèi)星運動導(dǎo)致的時延變化，由于其對鏈路BDP影響較小，所以發(fā)送端擁塞窗口保持不變.針對衛(wèi)星切換導(dǎo)致的時延變化，由于時延會發(fā)生比較大的突變，同時衛(wèi)星切換也會伴隨著路由變化，在這種情況下，DDTCP會經(jīng)歷一個完整的帶寬時延探測，并根據(jù)探測結(jié)果更新?lián)砣翱?DDTCP的窗口調(diào)節(jié)算法可以保障衛(wèi)星網(wǎng)絡(luò)在衛(wèi)星運動切換過程中吞吐量保持平穩(wěn)，不會因路由切換出現(xiàn)較大波動.

3.2 設(shè)計過程

3.2.1 新的時延探測機(jī)制

1） 時延區(qū)分

在低軌衛(wèi)星星座網(wǎng)絡(luò)中，時延變化可能由衛(wèi)星運動引起，也可能由于衛(wèi)星切換而導(dǎo)致的鏈路變化引起.衛(wèi)星和地面的相對運動會造成鏈路時延緩慢，接近線性的增加，而衛(wèi)星切換可能會造成十幾到上百毫秒的時延突變.DDTCP利用這個現(xiàn)象區(qū)分衛(wèi)星網(wǎng)絡(luò)的變化狀態(tài)，在BBR算法的基礎(chǔ)上，提出的改進(jìn)的擁塞控制機(jī)制能更好地適應(yīng)衛(wèi)星網(wǎng)絡(luò)狀況的變化.

2） 衛(wèi)星運動引起的時延變化

在BBR算法中，如果在一段時間內(nèi)發(fā)送端沒有監(jiān)測到更低的RTT，就會重新進(jìn)入時延探測階段，在無誤碼情況下會造成2%的帶寬流失.在地面網(wǎng)絡(luò)中，時延變化基本是由于緩存隊列長度變化引起的，這個機(jī)制可以探測當(dāng)前網(wǎng)絡(luò)狀況是否發(fā)生大的改動.而在衛(wèi)星網(wǎng)絡(luò)中，即使網(wǎng)絡(luò)中緩存隊列沒有發(fā)生變化，鏈路時延也會隨著衛(wèi)星的運動而不斷發(fā)生改變.隨著衛(wèi)星逐漸遠(yuǎn)離地面用戶，鏈路時延會不斷增大，在這種情況下，BBR算法就會在鏈路沒有發(fā)生變化的情況下頻繁進(jìn)入時延探測階段，導(dǎo)致平均吞吐量下降.同時，BBR在進(jìn)入時延探測階段后，為了排空網(wǎng)內(nèi)堆積的緩存隊列，會限制已發(fā)送未確認(rèn)的數(shù)據(jù)包數(shù)量，一般是限制在4個數(shù)據(jù)包以內(nèi)，通過這種方式來探測接近真實的傳播時延，但是也會導(dǎo)致待發(fā)送數(shù)據(jù)包在這段時間內(nèi)堆積在源端發(fā)送隊列中，使得服務(wù)時延增加.對于實時性要求比較高的音視頻業(yè)務(wù)來說，BBR不必要地頻繁進(jìn)入時延探測階段，會極大影響這類業(yè)務(wù)的服務(wù)質(zhì)量.針對這個問題，DDTCP在發(fā)送端會保存過去一段時間內(nèi)的鏈路時延信息.在擁塞控制狀態(tài)機(jī)進(jìn)入時延探測階段前，DDTCP會通過保存的RTT和當(dāng)前的RTT信息，判斷當(dāng)前時延是否處于緩慢線性增加，如是，則說明時延變化是由于衛(wèi)星運動引起的，就會跳過這次時延探測；否則，就進(jìn)入時延探測階段.具體來說，DDTCP會利用式（1）計算最近n個RTT周期內(nèi)的時延變化率，如果連續(xù)n個周期RTT都處于增加狀態(tài)，并且變化率不超過δ，那么認(rèn)為時延變化是衛(wèi)星運動引起的；否則是網(wǎng)絡(luò)中緩存隊列增加引起的.

3） 衛(wèi)星切換引起的時延變化

在BBR算法中，發(fā)送端在整個發(fā)送過程中會維持一個最小的RTT作為基礎(chǔ)RTT用于鏈路時延的估計，并根據(jù)這個值計算擁塞窗口.但是在低軌衛(wèi)星星座網(wǎng)絡(luò)中，由于衛(wèi)星切換、路由更新等都會造成傳輸路徑的變化，導(dǎo)致鏈路時延發(fā)生十幾毫秒甚至上百毫秒的時延突變.

如果鏈路時延值從較小突然增大時BBR算法仍然按照之前探測到的最小RTT計算，將造成鏈路帶寬時延積估計偏小，無法充分利用帶寬資源.例如，如果RRT由路徑變化之前的10 ms變化為100 ms，BBR還按照RTT= 10 ms計算擁塞窗口，那么帶寬利用率會下降為原來的1/10.而傳輸路徑變化在低軌衛(wèi)星網(wǎng)絡(luò)中會頻繁發(fā)生，因此DDTCP在源端監(jiān)測到時延發(fā)生較大突變后，會立即進(jìn)入時延探測階段，并將基礎(chǔ)RTT更新為時延探測階段中的最小值，然后按照新的基礎(chǔ)RTT計算擁塞窗口.

在擁塞控制狀態(tài)機(jī)進(jìn)入時延探測階段之前，DDTCP使用新的時延探測算法，根據(jù)輸入的當(dāng)前以及歷史RTT，輸出是否進(jìn)入時延探測階段以及引起時延變化的原因.具體算法為：

算法1.新的時延探測算法.

輸入：當(dāng)前以及歷史往返時延RTTi.

ifRTTi- RTTi-1＞thresholdthen

/* 傳輸路徑可能發(fā)生變化*/

gotoProbeRTT（true）；

else

forindex:= idowntoi - ndo

diff:=RTTindex- RTTindex-1；

ifdiff / RTTindex＞deltathen

gotoProbeRTT（false）；

endif

endfor

/*RTT變化是由于衛(wèi)星運動引起*/

SkipProbeRTT；

endif

3.2.2 快速重傳機(jī)制

一般情況下，隨著衛(wèi)星運動引起拓?fù)潢P(guān)系發(fā)生變化，衛(wèi)星網(wǎng)絡(luò)的路由也需要隨之更新，在更新路由規(guī)則這段時間內(nèi)，為了避免路由環(huán)路產(chǎn)生，舊路由不能被使用，因此衛(wèi)星會將收到的所有數(shù)據(jù)包和確認(rèn)包進(jìn)行丟棄處理.如果丟棄的數(shù)據(jù)包和確認(rèn)包是數(shù)據(jù)流的中間部分，那么在路由更新完成后，可以通過后續(xù)數(shù)據(jù)包到達(dá)接收端后產(chǎn)生重復(fù)確認(rèn)包，然后利用TCP快速重傳機(jī)制重新發(fā)送路由更新過程中丟失的數(shù)據(jù)包；而如果丟棄的數(shù)據(jù)包是數(shù)據(jù)流的尾部，那么發(fā)送端只能等待超時重傳（retransmission timeout，RTO），計時器超時后利用超時重傳機(jī)制重新發(fā)送丟失的數(shù)據(jù)包.但是如果路由更新需要較長時間，那么前幾次的超時重傳會由于鏈路不可用而失敗，導(dǎo)致RTO定時器以指數(shù)形式退讓到比較大的值，降低了衛(wèi)星網(wǎng)絡(luò)的傳輸效率，增加了流完成時間.

針對這種情況，DDTCP在發(fā)送端增加一個計時器，每收到一個確認(rèn)包就將計時器重置一次.如果計時器超時，說明可能發(fā)生了路由更新導(dǎo)致的大量數(shù)據(jù)包被丟棄，DDTCP就將當(dāng)前已發(fā)送未確認(rèn)的數(shù)據(jù)包全部插入到發(fā)送隊列.在完成時延探測階段，即探測到鏈路恢復(fù)正常后，就開始發(fā)送這部分?jǐn)?shù)據(jù)包.這樣，通過發(fā)送冗余包的機(jī)制解決了路由更新導(dǎo)致的超時重傳等問題，減小了流完成時間.具體算法為：

算法2.快速重傳算法.

輸入：往返時延RTTi，重傳計時器Timer：

if 計時器超時 then

/* 一段時間內(nèi)沒有收到確認(rèn)包*/

for已發(fā)送未確認(rèn)的數(shù)據(jù)包 do

插入到發(fā)送隊列；

endfor

else if 接收到確認(rèn) then

重置計時器；

endif

3.2.3 動態(tài)擁塞窗口上界

BBR算法將當(dāng)前鏈路中的已發(fā)送未確認(rèn)數(shù)據(jù)包的數(shù)量上限設(shè)置為2倍的BDP，這會在鏈路瓶頸處造成大約1個BDP的緩存隊列長度，如果網(wǎng)絡(luò)中交換機(jī)的緩存很小，那么多個使用BBR算法的TCP數(shù)據(jù)流同時傳輸時可能會產(chǎn)生大量數(shù)據(jù)包丟失；而如果網(wǎng)絡(luò)中交換機(jī)的緩存很大，BBR算法在和其他基于丟包驅(qū)動的擁塞控制算法競爭時，固定的上限設(shè)置也會限制使用BBR算法的數(shù)據(jù)流可以占用的緩存比例，導(dǎo)致BBR算法的帶寬估計偏小，無法與其他擁塞控制算法公平占用帶寬.

基于這些問題，DDTCP使用動態(tài)擁塞窗口上限調(diào)整算法來根據(jù)網(wǎng)絡(luò)狀況實時調(diào)整已發(fā)送未確認(rèn)數(shù)據(jù)包的數(shù)量上限.具體算法為：

算法3.擁塞窗口上限調(diào)整算法.

輸入：丟包率loss，吞吐throughput，往返時延RTT，帶寬估計值BtlBw，RTT估計值RTprop；

輸出：擁塞窗口上限CWND.

ifloss ＞ thresholdthen

/* 隊列緩存占用過大*/

DecreaseCWND；

else ifthroughput＜B+lBwthen

/* 帶寬利用率不足，或者有確認(rèn)包被堆積在

網(wǎng)絡(luò)中*/

IncreaseCWND；

else ifRTT＞RTpropthen

/* 隊列緩存占用偏大*/

DecreaseCWND；

else

MaintainCWND；

endif

當(dāng)發(fā)送端監(jiān)測到上一個RTT周期內(nèi)丟包率大于一定閾值或者實際RTT測量值大于RTT估計值，這表明當(dāng)前的擁塞窗口上限偏大，導(dǎo)致網(wǎng)絡(luò)中緩存隊列過大甚至溢出，因此DDTCP會減小擁塞窗口上限.而如果上一個RTT周期內(nèi)的實際吞吐量小于帶寬估計值，表明當(dāng)前的擁塞窗口上限不足以完全利用鏈路可用帶寬，因此DDTCP會嘗試增加擁塞窗口上限.當(dāng)然，為了維持?jǐn)?shù)據(jù)傳輸?shù)姆€(wěn)定性，擁塞窗口上限CWND的變化范圍被限制在1倍BDP到2倍BDP之間.

4 理論分析

本節(jié)通過建立DDTCP算法在穩(wěn)態(tài)時（即帶寬探測階段）的數(shù)學(xué)模型以證明其在RTT動態(tài)變化的衛(wèi)星網(wǎng)絡(luò)場景中的穩(wěn)定性.具體來說，基于DDTCP算法的擁塞窗口動態(tài)調(diào)整，衛(wèi)星網(wǎng)絡(luò)的傳輸性能將不受頻繁的時延變化的影響.

4.1 啟動階段和排空階段的行為

由于DDTCP與BBR在啟動階段和排空階段的行為相同，同時在啟動階段僅估計鏈路的瓶頸帶寬BWe，而且排空階段的持續(xù)時間較短，兩者對穩(wěn)態(tài)時算法的性能沒有重大影響.為簡化分析，我們將忽略這2個階段，僅對一些重要結(jié)論進(jìn)行闡述.

在啟動階段，發(fā)送端首先發(fā)送10個數(shù)據(jù)包，隨后等待對數(shù)據(jù)包的確認(rèn).收到每一個已發(fā)送數(shù)據(jù)包的ACK時，BBR便會基于該RTT內(nèi)傳輸字節(jié)數(shù)與RTT的比率更新鏈路帶寬的實時估計值和數(shù)據(jù)包的發(fā)送間隔Δtj，同時得到下一個RTT的數(shù)據(jù)包發(fā)送速率dP，滿足

其中j代表第j個RTT持續(xù)時間，B[tP]是收到數(shù)據(jù)包P的ACK時的累積字節(jié)數(shù)，B[tC]是發(fā)送數(shù)據(jù)包P之前的累積字節(jié)數(shù)，tP和tC則分別表示2個累積字節(jié)數(shù)對應(yīng)的時間.是基于式（2）和第1個數(shù)據(jù)包的ACK計算，（在本節(jié)的分析中將帶寬單位統(tǒng)一為包/s）.α在BBR的最初版本中被設(shè)定為2，即每經(jīng)過一個RTT，源端將以2倍的比例增大數(shù)據(jù)包的發(fā)送速率.

4.2 DDTCP算法的穩(wěn)定性

DDTCP在帶寬探測階段會保持相對恒定的發(fā)送速率增益和擁塞窗口，其中發(fā)送速率增益為1.25和0.75的2個RTT周期主要用于調(diào)整多流競爭場景的帶寬分配，在單流情況下，這2個RTT周期的影響可以忽略不計.

在數(shù)據(jù)傳輸進(jìn)入帶寬探測階段，且鏈路處于穩(wěn)定狀態(tài)時，可以假設(shè)BWe和 Δt在一個完整的TCP連接中保持不變，兩者滿足

記此理想狀態(tài)下的鏈路RTT為RTTstable，易知此值為一個常數(shù)，也即式（2）的分母將保持不變.

此時，考慮任意一個數(shù)據(jù)包P，則當(dāng)此包處于“飛行狀態(tài)”時，源端發(fā)送的字節(jié)數(shù)為

其中RTTP=t1-t0為數(shù)據(jù)包P的RTT，t1和t0分別表示發(fā)出數(shù)據(jù)包P和收到其ACK的時間.

將式（5）代入式（2）可得穩(wěn)定狀態(tài)下的鏈路帶寬估計為

即鏈路在第j個帶寬探測周期內(nèi)的帶寬估計值將保持恒定，后續(xù)公式均滿足條件j≥1.

接下來，考慮在帶寬探測階段RTT發(fā)生變化的情況.仍記鏈路的平均無擁塞時延為RTTstable，則實際的RTT將在此值附近上下波動，第j個帶寬探測周期的帶寬估計值為

其中Wj為第j個帶寬探測周期的CWND，其基于第j-1個帶寬探測周期的估計帶寬和RTTmin計算得到，也即此周期的為啟動階段和排空階段測得的所有RTTmin樣值的數(shù)學(xué)期望.

在實際系統(tǒng)中使用時，算法3中的擁塞窗口上限β是我們關(guān)注的重點，在1～2倍BDP，它與RTT近似滿足反比例關(guān)系，即.其中γ為一個常數(shù)，為一段時間內(nèi)的RTT參考值，而經(jīng)指數(shù)加權(quán)移動平均（exponential weighted moving average，EWMA）算法的平滑作用，對因衛(wèi)星鏈路切換而造成的RTT抖動不敏感.

將相關(guān)參數(shù)代入式（7），可得

式（8）表明第j個帶寬探測周期的帶寬估計與γ和RTTstable有 關(guān)，而與RTT的抖動無關(guān).γ和RTTstable會根據(jù)衛(wèi)星運動和拓?fù)渥兓ㄟ^指數(shù)平滑動態(tài)調(diào)整，因此帶寬估計值在面對低軌衛(wèi)星網(wǎng)絡(luò)的時延抖動時能夠保持相對恒定，基于DDTCP算法調(diào)節(jié)擁塞窗口具有良好的穩(wěn)定性.

5 實驗結(jié)果

5.1 實驗環(huán)境

5.1.1 衛(wèi)星網(wǎng)絡(luò)拓?fù)?/p>

文獻(xiàn)[16-17]提出的由48顆衛(wèi)星組成的低軌衛(wèi)星星座是一種典型的星座設(shè)計方案.該星座由6個圓軌道組成，每個軌道有8顆衛(wèi)星，軌道高度為1 450 km，具體參數(shù)如表1所示.在極軌星座中，第2個軌道與最后一個軌道相鄰，并且軌道上衛(wèi)星的運動方向相反，這2個相反運動方向軌道之間的區(qū)域稱為反向縫.在反向縫兩側(cè)，由于2個軌道內(nèi)衛(wèi)星的相對運動角速度很大，很難建立穩(wěn)定的跨越反向縫的星間鏈路.因此反向縫兩側(cè)的衛(wèi)星只有3條星間鏈路，其他衛(wèi)星各自有4條衛(wèi)星間鏈路.

Table 1 Detailed Parameters of LEO Satellite Constellation Network表1 低軌衛(wèi)星星座網(wǎng)絡(luò)詳細(xì)參數(shù)

5.1.2 仿真環(huán)境和DDTCP實現(xiàn)

仿真環(huán)境使用Linux操作系統(tǒng)，我們在安裝有VMWare EXSI系統(tǒng)的服務(wù)器上部署了3臺虛擬機(jī)，其中1臺虛擬機(jī)用于低軌衛(wèi)星網(wǎng)絡(luò)仿真，另外2臺虛擬機(jī)用于模擬半實物仿真中的真實用戶節(jié)點.考慮到容器有自己獨立的網(wǎng)絡(luò)命名空間，擁有獨立的網(wǎng)絡(luò)協(xié)議棧，并且容器對資源的要求比較低，批量化操作也比較容易，所以我們采用容器的方式搭建低軌衛(wèi)星星座.容器實例基于Ubuntu 14.04服務(wù)器版本鏡像，在容器中安裝不帶內(nèi)核模塊的Open vSwitch（OVS），為了保證整個網(wǎng)絡(luò)環(huán)境的吞吐量，在容器所在的物理機(jī)上安裝OVS內(nèi)核模塊.在容器中運行OVS時，能夠在物理機(jī)中實例化一個OVS內(nèi)核模塊，容器中的OVS用戶態(tài)程序與物理機(jī)中的OVS內(nèi)核模塊通過netlink的方式進(jìn)行通信.這樣可以通過OVS的快速路徑保證低軌衛(wèi)星仿真網(wǎng)絡(luò)可以承載較高的吞吐量.我們使用Linux系統(tǒng)提供的veth pair來模擬衛(wèi)星之間的鏈路，具體使用時，將veth pair的兩端分別加到2個容器中，當(dāng)作這2個衛(wèi)星間的一條星間鏈路.另外，使用netem對衛(wèi)星網(wǎng)絡(luò)的時延變化、誤碼丟包等特征進(jìn)行模擬，通過配置延時、丟包率和隊列長度等參數(shù)，可以準(zhǔn)確還原真實的衛(wèi)星網(wǎng)絡(luò)環(huán)境.

在仿真系統(tǒng)實際運行時，我們在物理機(jī)中運行48個容器實例，然后通過腳本控制程序來模擬衛(wèi)星間的鏈路通斷.根據(jù)衛(wèi)星實時經(jīng)緯度信息計算2顆衛(wèi)星間是否存在鏈路，如存在鏈路，則判斷上一秒該鏈路的情況，執(zhí)行對應(yīng)的操作；如不存在，則將對應(yīng)的veth pair斷掉，從而實現(xiàn)衛(wèi)星間鏈路通斷.

DDTCP是在BBR代碼的基礎(chǔ)上，通過內(nèi)核模塊的形式實現(xiàn).具體來說，在BBR的擁塞控制結(jié)構(gòu)體struct bbr中增加了一個大小為10的環(huán)形緩沖區(qū)用于保存過去10個周期內(nèi)的RTT信息.在函數(shù)bbr_update_min_rtt中，DDTCP利用這些保存的歷史RTT信息以及當(dāng)前RTT信息，判斷是否需要進(jìn)入時延探測階段.接著，在tcp_congestion_ops中增加in_ack_event以及對應(yīng)的回調(diào)函數(shù)ddtcp_ack，ddtep_ack在發(fā)送端收到確認(rèn)包的時候被調(diào)用，因此判斷DDTCP的快速重傳定時器是否超時以及更新計時器.然后在函數(shù)bbr_update_bw中增加函數(shù)dynamic_gain，根據(jù)上一周期內(nèi)的吞吐量、丟包率、時延等信息，動態(tài)調(diào)整擁塞窗口增益系數(shù)cwnd_gain.

5.2 仿真結(jié)果分析

我們選取了3種典型的擁塞控制算法與DDTCP進(jìn)行比較，分別是Vegas, Cubic, BBR.Hybla和Illinois的結(jié)果與Vegas和Cubic的結(jié)果類似，因此在本節(jié)的結(jié)果展示中，為了能清晰顯示不同方案的細(xì)節(jié)，我們省略了Hybla和Illinois的仿真結(jié)果.同時，仿真速度設(shè)置為10倍的真實速度.鏈路帶寬設(shè)置為100 Mbps.

文獻(xiàn)[18-19]中指出典型的衛(wèi)星網(wǎng)絡(luò)的誤碼率為10-4～10-8，因此選擇了2種場景進(jìn)行性能驗證.第1種是誤碼率為0的理想場景，驗證DDTCP的收斂性和公平性；第2種是誤碼率為10-7的典型衛(wèi)星網(wǎng)絡(luò)場景，驗證DDTCP在真實低軌衛(wèi)星網(wǎng)絡(luò)中的傳輸性能.

5.2.1 誤碼率為0場景下的性能測試

圖5展示了DDTCP與其他3種算法在無誤碼丟包的低軌衛(wèi)星網(wǎng)絡(luò)中的吞吐量隨時間變化的情況.可以看到在無誤碼丟包的場景下，DDTCP，BBR，Cubic，Vegas在前80 s都可以達(dá)到較高的吞吐量，在第80 s左右，傳輸路徑發(fā)生變化，導(dǎo)致鏈路時延由80 ms增大到140 ms左右，此后Vegas的吞吐量持續(xù)降低.而BBR在傳播時延發(fā)生變化后，經(jīng)歷了40 s左右的低吞吐量時期，之后吞吐量恢復(fù)到75 Mbps左右，同時幾乎每隔10 s就會進(jìn)入一次時延探測階段，在圖5中表現(xiàn)為向下的吞吐量驟降.Cubic的表現(xiàn)與BBR接近，可以看到在無誤碼丟包的場景下，基于丟包驅(qū)動的擁塞控制算法是可以取得不錯的性能表現(xiàn).而DDTCP只在第80 s左右有一個明顯的驟降，說明DDTCP進(jìn)入時延探測階段，獲取鏈路最新的傳播時延，之后DDTCP的吞吐量一直維持在93 Mbps左右，由于后面鏈路處于穩(wěn)定狀態(tài)，僅有衛(wèi)星運動引起的時延變化，所以DDTCP不會頻繁進(jìn)入時延探測狀態(tài)，數(shù)據(jù)傳輸更加穩(wěn)定.

Fig.5 Throughput variation of different algorithms when the bit error rate is 0圖5 誤碼率為0時不同算法的吞吐量變化

5.2.2 誤碼率為10-7場景下的性能測試

圖6展示了DDTCP以及Cubic，Vegas，BBR等算法在有誤碼丟包場景下的吞吐量變化.我們將網(wǎng)絡(luò)的誤碼率設(shè)為10-7，按照平均數(shù)據(jù)包長度1000 B來算，對應(yīng)的丟包率接近0.01%.可以看到在這種場景下，Cubic的吞吐量有比較明顯的下降.這是因為Cubic無法區(qū)分誤碼丟包和擁塞丟包，導(dǎo)致?lián)砣翱跁e誤地減小.Vegas由于其基于時延的擁塞窗口計算算法沒有考慮到低軌衛(wèi)星網(wǎng)絡(luò)這種鏈路時延動態(tài)變化的場景，所以擁塞窗口無法被正確設(shè)置，幾乎沒有吞吐量.而對于BBR和DDTCP來說，由于其基于BDP估計來計算擁塞窗口，所以不會受到誤碼丟包的影響.

Fig.6 Throughput variation of different algorithms when the bit error rate is 10-7圖6 誤碼率為10-7時不同算法的吞吐量變化

5.2.3 跨越反向縫場景下的性能測試

圖7顯示了4種擁塞控制算法在跨越反向縫通信場景下的吞吐量.在一開始，鏈路的傳播時延為60 ms左右，在第90 s后，發(fā)送端和接收端由于衛(wèi)星網(wǎng)絡(luò)相對地面的運動位于反向縫兩側(cè)，傳播時延變化為180 ms左右，同時傳播路徑也會發(fā)生比較大的變化.可以看到在這種場景下，BBR和Cubic在90～110 s的吞吐量變得非常低，而DDTCP僅有不到5 s的吞吐量驟降，之后吞吐量就恢復(fù)到之前的水平.這是因為此時網(wǎng)絡(luò)由于路由更新而發(fā)生了短時間內(nèi)的連續(xù)丟包，其他3種協(xié)議只能等待超時重傳.而DDTCP通過在發(fā)送端維護(hù)的重傳定時器觸發(fā)DDTCP的快速重傳機(jī)制，因此能夠?qū)嶋H吞吐量快速恢復(fù).

Fig.7 Throughput variation of different algorithms when communicating across reverse seams圖7 跨越反向縫通信時不同算法的吞吐量變化

5.2.4 DDTCP公平性測試

我們對DDTCP自身的公平性進(jìn)行測試，在4個發(fā)送端以20 s的間隔依次向同一個接收端發(fā)送一段數(shù)據(jù).圖8顯示了這4條流在低軌衛(wèi)星網(wǎng)絡(luò)場景中的帶寬占用結(jié)果.可以看出，DDTCP不同流之間的公平性較好.在新流加入后，舊的數(shù)據(jù)流能快速讓出帶寬；在某條數(shù)據(jù)流結(jié)束后，其他數(shù)據(jù)流也能快速將空出來的這部分帶寬占滿.不同流之間幾乎是平分瓶頸帶寬.

5.2.5 帶寬搶占性測試

我們測試不同擁塞控制算法在同一條瓶頸路徑下競爭時的帶寬分配情況.圖9展示了DDTCP分別與Cubic，Vegas，BBR在同一條瓶頸路徑傳輸時的帶寬占比結(jié)果.可以看到DDTCP的帶寬搶占性比較強(qiáng)，與Cubic和Vegas這類傳統(tǒng)的基于丟包或時延的擁塞控制算法共同競爭時，DDTCP會占用大部分帶寬.這其實是由于低軌衛(wèi)星網(wǎng)絡(luò)這個特殊環(huán)境造成的，低軌衛(wèi)星網(wǎng)絡(luò)中的誤碼丟包以及鏈路時延動態(tài)變化的特點都會導(dǎo)致這類傳統(tǒng)算法發(fā)生誤判并減小擁塞窗口.而DDTCP可以根據(jù)探測結(jié)果實時調(diào)整擁塞窗口到合適的大小，因此可以充分利用鏈路帶寬資源.當(dāng)DDTCP和BBR共同競爭時，在網(wǎng)絡(luò)狀況變化不劇烈的情況下，兩者都可以合理設(shè)置擁塞窗口.而在鏈路發(fā)生突變的情況下，例如衛(wèi)星切換、路由更新等，BBR不能對這類情況做出快速反應(yīng)，DDTCP卻可以通過新的時延探測、快速重傳以及動態(tài)擁塞窗口上限等機(jī)制在網(wǎng)絡(luò)發(fā)生變化后針對不同的情況做出不同的動作，圖9顯示DDTCP和BBR競爭時，DDTCP的吞吐量比BBR多15 Mbps左右.

6 結(jié) 論

在本文中，我們首先分析了低軌衛(wèi)星星座網(wǎng)絡(luò)的特點以及這個特點對傳統(tǒng)TCP擁塞控制協(xié)議造成的影響，通過分析和實驗驗證，發(fā)現(xiàn)現(xiàn)有的BBR，Vegas，Cubic典型TCP擁塞控制算法在衛(wèi)星網(wǎng)絡(luò)中都會遇到比較嚴(yán)重的性能降級.然后，利用低軌衛(wèi)星網(wǎng)絡(luò)中衛(wèi)星運動和路由更新引起的鏈路時延變化的特征，設(shè)計了新的時延探測算法來解決BBR算法存在的問題.提出的DDTCP協(xié)議在源端監(jiān)測RTT值的變化，對于衛(wèi)星運動引起的時延變化，由于傳輸路徑?jīng)]有發(fā)生變化，因此保持之前的RTT估計值不變；對于衛(wèi)星切換、路由更新引起的時延變化，DDTCP會立即進(jìn)入時延探測階段.這樣的設(shè)計可以避免不必要的時延探測，同時可以保證傳輸路徑變化后源端可以及時更新RTT估計值.另外，我們也設(shè)計了新的快速重傳算法和動態(tài)擁塞窗口上限調(diào)整算法.實驗結(jié)果表明，DDTCP可以在低軌衛(wèi)星星座網(wǎng)絡(luò)中提供更高、更穩(wěn)定的傳輸性能.與傳統(tǒng)擁塞控制算法相比，DDTCP可以實現(xiàn)19%以上的吞吐量提升.我們認(rèn)為本方案也可以為其他高隨機(jī)損耗網(wǎng)絡(luò)中的傳輸協(xié)議優(yōu)化提供一定的參考依據(jù).

在后續(xù)的工作中，我們將在更加多樣和真實的場景下對現(xiàn)有工作進(jìn)行性能驗證并優(yōu)化參數(shù)設(shè)置，并嘗試將顯示擁塞通告和帶內(nèi)網(wǎng)絡(luò)遙測等機(jī)制與本文方案結(jié)合，進(jìn)一步提高TCP協(xié)議在衛(wèi)星網(wǎng)絡(luò)中的傳輸性能.

作者貢獻(xiàn)聲明：王子涵負(fù)責(zé)文獻(xiàn)調(diào)研、撰寫全文并完成相關(guān)實驗；張嬌負(fù)責(zé)確定論文思路、具體方案以及修改論文；張遠(yuǎn)負(fù)責(zé)代碼實現(xiàn)并協(xié)助分析實驗結(jié)果；潘恬負(fù)責(zé)論文框架設(shè)定并修改論文；黃韜負(fù)責(zé)對論文學(xué)術(shù)性和技術(shù)性內(nèi)容進(jìn)行審閱和關(guān)鍵性修訂.