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

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

隨著商業(yè)低軌衛(wèi)星（low earth orbit, LEO）星座快速發(fā)展，在可以預(yù)見的將來，低軌衛(wèi)星星座網(wǎng)絡(luò)將會(huì)給大眾提供更加廉價(jià)、方便、快捷、穩(wěn)定的網(wǎng)絡(luò)接入.而截至2017年6月，全球互聯(lián)網(wǎng)普及率為51.7%，意味著全球仍有一半的人口未實(shí)現(xiàn)互聯(lián)網(wǎng)連接.相對于地面通信系統(tǒng)，低軌衛(wèi)星通信系統(tǒng)易于快速實(shí)現(xiàn)大范圍的全球覆蓋，適合低人口密度、有限業(yè)務(wù)流量的國家或地區(qū).相對于高軌以及靜止軌道衛(wèi)星通信系統(tǒng)，低軌衛(wèi)星通信系統(tǒng)鏈路具有多方面優(yōu)勢：1）傳播損耗小，更有利于系統(tǒng)為手持終端用戶提供服務(wù)；2）傳輸時(shí)延小，實(shí)時(shí)性較好；3）采用極地軌道或大傾角軌道時(shí)可為高緯度地區(qū)提供服務(wù)；4）可利用多普勒頻移進(jìn)行定位，實(shí)現(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ǔ)充必然會(huì)承載更多種類的業(yè)務(wù)，如視頻、直播、遠(yuǎn)程教育等.而這些業(yè)務(wù)都需要衛(wèi)星網(wǎng)絡(luò)提供可靠的高速率接入.為了與地面網(wǎng)絡(luò)協(xié)同，衛(wèi)星網(wǎng)絡(luò)必然會(huì)順應(yīng)當(dāng)前的趨勢采用TCP（Transmission Control Protocol）/IP協(xié)議體系來提供可靠傳輸.而衛(wèi)星網(wǎng)絡(luò)固有的長時(shí)延、高突發(fā)誤碼率、上下行信道帶寬不對稱、拓?fù)鋾r(shí)變等特性，使得衛(wèi)星網(wǎng)絡(luò)直接應(yīng)用針對地面網(wǎng)絡(luò)設(shè)計(jì)的TCP傳輸控制協(xié)議時(shí)性能表現(xiàn)很差.

首先，衛(wèi)星網(wǎng)絡(luò)較長的端到端往返時(shí)延（roundtrip time，RTT）會(huì)使TCP在慢啟動(dòng)階段的擁塞窗口（congestion window，CWND）增長緩慢，并且無法從丟包后帶寬減半的狀態(tài)快速恢復(fù)到填滿帶寬的狀態(tài)，不能充分利用網(wǎng)絡(luò)的帶寬資源；衛(wèi)星鏈路較高的誤碼率也會(huì)讓TCP頻繁降低擁塞窗口，這是因?yàn)門CP認(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ò)中的端到端往返時(shí)延變化較大，在地球同步軌道衛(wèi)星場景下，傳輸時(shí)延取決于用戶之間的距離，而在有著星間鏈路（inter-satellite link, ISL）的低軌衛(wèi)星網(wǎng)絡(luò)中，星座的拓?fù)潢P(guān)系會(huì)隨時(shí)間快速變化，導(dǎo)致傳輸時(shí)延發(fā)生變化，這可能會(huì)影響TCP對RTT的估計(jì)[2].每當(dāng)RTT發(fā)生變化，TCP都需要一些時(shí)間來適應(yīng)這種變化.在低軌衛(wèi)星星座網(wǎng)絡(luò)中，RTT會(huì)不斷發(fā)生變化，導(dǎo)致TCP無法足夠快速更新其估算的RTT.這可能會(huì)導(dǎo)致過早的超時(shí)重傳，降低鏈路的帶寬利用率.在低軌衛(wèi)星網(wǎng)絡(luò)中使用面向連接的TCP協(xié)議時(shí)，每次發(fā)生衛(wèi)星切換，都可能引發(fā)較大數(shù)量的TCP數(shù)據(jù)包丟失，特別是在信令交換沒有正確執(zhí)行的情況下.另外，在切換完成后，TCP會(huì)因?yàn)榘l(fā)生大量丟包而將其擁塞窗口減到最低[3].

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

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

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

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

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

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

1.1.1 丟包原因多樣

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

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

1.1.2 時(shí)延變化差異大

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

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

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

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

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

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

此外當(dāng)衛(wèi)星運(yùn)行至極地軌道交匯點(diǎn)附近時(shí)，由于相鄰軌道衛(wèi)星間的距離和視角快速變化，很難建立穩(wěn)定的衛(wèi)星間鏈路，所以衛(wèi)星會(huì)暫時(shí)關(guān)閉部分星間鏈路，等到離開極區(qū)后，重新建立衛(wèi)星間鏈路.在這個(gè)過程中發(fā)生的衛(wèi)星間鏈路切換以及由于衛(wèi)星運(yùn)動(dòng)引起的星座網(wǎng)絡(luò)拓?fù)潢P(guān)系的變化都會(huì)導(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è)計(jì).由于其重要性，工業(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)丟包時(shí)，將擁塞窗口減小.這種類型的控制協(xié)議原理較為簡單，近年來主要的實(shí)現(xiàn)方法有TCP Hybla，TCP Hybla+，TCP Peach，TCP Peach+，TCP Swift，TCP Cherry等[11-12].

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

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

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

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

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

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

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

2 研究動(dòng)機(jī)

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

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

Fig.2 Experimental topology圖2 實(shí)驗(yàn)拓?fù)?/p>

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

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

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

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

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

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

3 DDTCP設(shè)計(jì)

3.1 核心思想

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

3.2 設(shè)計(jì)過程

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

1） 時(shí)延區(qū)分

在低軌衛(wèi)星星座網(wǎng)絡(luò)中，時(shí)延變化可能由衛(wèi)星運(yùn)動(dòng)引起，也可能由于衛(wèi)星切換而導(dǎo)致的鏈路變化引起.衛(wèi)星和地面的相對運(yùn)動(dòng)會(huì)造成鏈路時(shí)延緩慢，接近線性的增加，而衛(wèi)星切換可能會(huì)造成十幾到上百毫秒的時(shí)延突變.DDTCP利用這個(gè)現(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)星運(yùn)動(dòng)引起的時(shí)延變化

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

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

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

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

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

算法1.新的時(shí)延探測算法.

輸入：當(dāng)前以及歷史往返時(shí)延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)星運(yùn)動(dòng)引起*/

SkipProbeRTT；

endif

3.2.2 快速重傳機(jī)制

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

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

算法2.快速重傳算法.

輸入：往返時(shí)延RTTi，重傳計(jì)時(shí)器Timer：

if 計(jì)時(shí)器超時(shí) then

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

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

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

endfor

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

重置計(jì)時(shí)器；

endif

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

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

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

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

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

輸出：擁塞窗口上限CWND.

ifloss ＞ thresholdthen

/* 隊(duì)列緩存占用過大*/

DecreaseCWND；

else ifthroughput＜B+lBwthen

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

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

IncreaseCWND；

else ifRTT＞RTpropthen

/* 隊(duì)列緩存占用偏大*/

DecreaseCWND；

else

MaintainCWND；

endif

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

4 理論分析

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

4.1 啟動(dòng)階段和排空階段的行為

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

5 實(shí)驗(yàn)結(jié)果

5.1 實(shí)驗(yàn)環(huán)境

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

文獻(xiàn)[16-17]提出的由48顆衛(wèi)星組成的低軌衛(wèi)星星座是一種典型的星座設(shè)計(jì)方案.該星座由6個(gè)圓軌道組成，每個(gè)軌道有8顆衛(wèi)星，軌道高度為1 450 km，具體參數(shù)如表1所示.在極軌星座中，第2個(gè)軌道與最后一個(gè)軌道相鄰，并且軌道上衛(wèi)星的運(yùn)動(dòng)方向相反，這2個(gè)相反運(yùn)動(dòng)方向軌道之間的區(qū)域稱為反向縫.在反向縫兩側(cè)，由于2個(gè)軌道內(nèi)衛(wèi)星的相對運(yùn)動(dòng)角速度很大，很難建立穩(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實(shí)現(xiàn)

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

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

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

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

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

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

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

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的吞吐量有比較明顯的下降.這是因?yàn)镃ubic無法區(qū)分誤碼丟包和擁塞丟包，導(dǎo)致?lián)砣翱跁?huì)錯(cuò)誤地減小.Vegas由于其基于時(shí)延的擁塞窗口計(jì)算算法沒有考慮到低軌衛(wèi)星網(wǎng)絡(luò)這種鏈路時(shí)延動(dòng)態(tài)變化的場景，所以擁塞窗口無法被正確設(shè)置，幾乎沒有吞吐量.而對于BBR和DDTCP來說，由于其基于BDP估計(jì)來計(jì)算擁塞窗口，所以不會(huì)受到誤碼丟包的影響.

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

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

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

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

5.2.4 DDTCP公平性測試

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

5.2.5 帶寬搶占性測試

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

6 結(jié) 論

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

在后續(xù)的工作中，我們將在更加多樣和真實(shí)的場景下對現(xiàn)有工作進(jìn)行性能驗(yà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)實(shí)驗(yàn)；張嬌負(fù)責(zé)確定論文思路、具體方案以及修改論文；張遠(yuǎn)負(fù)責(zé)代碼實(shí)現(xiàn)并協(xié)助分析實(shí)驗(yàn)結(jié)果；潘恬負(fù)責(zé)論文框架設(shè)定并修改論文；黃韜負(fù)責(zé)對論文學(xué)術(shù)性和技術(shù)性內(nèi)容進(jìn)行審閱和關(guān)鍵性修訂.