基于鏈路信息估計的低軌衛星網絡傳輸控制協議

王子涵 張 嬌 張 遠 潘 恬 黃 韜

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

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

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

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

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

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

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

我們在Linux內核中實現了DDTCP協議，并在半實物衛星網絡仿真平臺上進行了性能驗證.實驗結果表明，與TCP Vegas，Cubic，BBR對比，DDTCP的吞吐量提高了19%以上, 同時可以保證數據傳輸更加穩定，不會受到低軌衛星網絡高動態變化的影響.

1 背景和相關工作

1.1 低軌衛星網絡的特點

與傳統地面網絡不同，低軌衛星通信網絡具有拓撲時變、高誤碼、長時延、大時延帶寬積等特點.因此，傳統傳輸控制協議在衛星網絡中會產生帶寬利用率低、丟包率較高等問題.在提出適應低軌衛星網絡的傳輸控制方案之前，我們將首先分析低軌衛星網絡與傳輸控制協議性相關的獨有特征.具體地，將從丟包產生原因、時延變化規律、鏈路中斷3方面進行分析.

1.1.1 丟包原因多樣

1）鏈路擁塞導致丟包.衛星網絡同地面網絡的最大區別是衛星網絡的往返時間較長.地面網絡的往返時間在幾十毫秒之內，而衛星網絡的往返時間往往在幾百毫秒.衛星網絡更容易觸發超時重傳機制，該機制重新發送數據，導致數據在傳輸時造成擁塞，使得數據傳輸的時間進一步增加，惡性循環，造成網絡的崩潰.

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

1.1.2 時延變化差異大

1）隊列長度導致時延變化.在衛星網絡中的每一個節點都有一定的緩存隊列，而在網絡擁塞程度不同的時候，緩存隊列的長度也不同，這就會導致在不同擁塞程度時，隊列長度會發生變化進而往返時延發生改變.但是在低軌衛星網絡中，由隊列長度變化導致的時延變化較小，衛星運動以及衛星切換往往是決定時延變化的主要因素.

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

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

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

1.1.3 鏈路頻繁發生中斷

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

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

1.2 網絡傳輸控制協議

網絡傳輸控制協議是為了在不可靠且多種應用共享的互聯網絡上為網絡應用提供可靠公平傳輸而設計.由于其重要性，工業界和學術界對此協議都進行了持續研究.根據現有工作進行源端速率調節的依據因素不同，應用于衛星網絡的擁塞協議主要可以分為3類：

1）基于丟包的傳輸控制協議

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

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

TCP Peach 使用低優先級的虛擬段探測帶寬以增加慢啟動階段擁塞窗口的增加速度.TCP Cherry部署了一種新型的低優先級數據段，除探測網絡之外，還攜帶尚未傳輸的數據段.

2）基于時延的傳輸控制協議

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

3）基于BDP估計的傳輸控制協議

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

當前衛星網絡傳輸控制協議主要沿用類似于地面傳輸控制協議的設計思路[15]，缺乏專門針對低軌衛星網絡的特點而設計的高性能的傳輸控制協議.因此，本文將首先分析低軌衛星網絡特點，然后提出面向衛星網絡特征的高性能傳輸控制協議.

2 研究動機

本節通過實驗分析現有典型協議Vegas和BBR在衛星網絡中性能下降的原因.

實驗拓撲如圖2所示，2臺主機分別作發送端，1臺主機作接收端.發送端1使用TCP Vegas作為默認的TCP擁塞控制算法，發送端2使用TCP BBR作為默認的擁塞控制算法.我們使用一臺具有雙網卡的主機作為交換機，并在上面通過Linux提供的tc命令設置網絡的傳播時延為40 ms、帶寬為100 Mbps.然后在發送端運行iperf軟件進行網絡吞吐量測試.

Fig.2 Experimental topology圖2 實驗拓撲

Vegas通過RTT的變化來計算期望吞吐量與實際吞吐量的差值，進而主動調整擁塞窗口.因此，Vegas不依靠丟包就能預測網絡擁塞，從而在丟包之前擁塞避免，能減少數據包的丟失，更有效地利用帶寬.然而，Vegas算法以RTT為主要參數來控制擁塞窗口的變化，而低軌衛星星座網絡的拓撲結構是實時且高動態變化的，這會造成RTT的非擁塞原因增大.Vegas算法本身并沒有能力識別RTT的增大是由于網絡擁塞造成的還是由于路徑變化造成的.如果是路徑的改變導致RTT的增加，那么Vegas算法也會減小發送窗口，從而浪費了網絡帶寬資源.

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

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

此外，雖然Vegas是基于RTT的擁塞控制協議，但是在具體實現中，Vegas仍然會對具體的丟包事件做出反應.這會導致Vegas在有著一定誤碼率的衛星鏈路上性能表現更加糟糕.

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

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

3 DDTCP設計

3.1 核心思想

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

3.2 設計過程

3.2.1 新的時延探測機制

1） 時延區分

在低軌衛星星座網絡中，時延變化可能由衛星運動引起，也可能由于衛星切換而導致的鏈路變化引起.衛星和地面的相對運動會造成鏈路時延緩慢，接近線性的增加，而衛星切換可能會造成十幾到上百毫秒的時延突變.DDTCP利用這個現象區分衛星網絡的變化狀態，在BBR算法的基礎上，提出的改進的擁塞控制機制能更好地適應衛星網絡狀況的變化.

2） 衛星運動引起的時延變化

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

3） 衛星切換引起的時延變化

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

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

在擁塞控制狀態機進入時延探測階段之前，DDTCP使用新的時延探測算法，根據輸入的當前以及歷史RTT，輸出是否進入時延探測階段以及引起時延變化的原因.具體算法為：

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

輸入：當前以及歷史往返時延RTTi.

ifRTTi- RTTi-1＞thresholdthen

/* 傳輸路徑可能發生變化*/

gotoProbeRTT（true）；

else

forindex:= idowntoi - ndo

diff:=RTTindex- RTTindex-1；

ifdiff / RTTindex＞deltathen

gotoProbeRTT（false）；

endif

endfor

/*RTT變化是由于衛星運動引起*/

SkipProbeRTT；

endif

3.2.2 快速重傳機制

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

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

算法2.快速重傳算法.

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

if 計時器超時 then

/* 一段時間內沒有收到確認包*/

for已發送未確認的數據包 do

插入到發送隊列；

endfor

else if 接收到確認 then

重置計時器；

endif

3.2.3 動態擁塞窗口上界

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

基于這些問題，DDTCP使用動態擁塞窗口上限調整算法來根據網絡狀況實時調整已發送未確認數據包的數量上限.具體算法為：

算法3.擁塞窗口上限調整算法.

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

輸出：擁塞窗口上限CWND.

ifloss ＞ thresholdthen

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

DecreaseCWND；

else ifthroughput＜B+lBwthen

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

網絡中*/

IncreaseCWND；

else ifRTT＞RTpropthen

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

DecreaseCWND；

else

MaintainCWND；

endif

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

4 理論分析

本節通過建立DDTCP算法在穩態時（即帶寬探測階段）的數學模型以證明其在RTT動態變化的衛星網絡場景中的穩定性.具體來說，基于DDTCP算法的擁塞窗口動態調整，衛星網絡的傳輸性能將不受頻繁的時延變化的影響.

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

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

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

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

4.2 DDTCP算法的穩定性

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

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

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

此時，考慮任意一個數據包P，則當此包處于“飛行狀態”時，源端發送的字節數為

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

將式（5）代入式（2）可得穩定狀態下的鏈路帶寬估計為

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

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

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

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

將相關參數代入式（7），可得

式（8）表明第j個帶寬探測周期的帶寬估計與γ和RTTstable有 關，而與RTT的抖動無關.γ和RTTstable會根據衛星運動和拓撲變化通過指數平滑動態調整，因此帶寬估計值在面對低軌衛星網絡的時延抖動時能夠保持相對恒定，基于DDTCP算法調節擁塞窗口具有良好的穩定性.

5 實驗結果

5.1 實驗環境

5.1.1 衛星網絡拓撲

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

Table 1 Detailed Parameters of LEO Satellite Constellation Network表1 低軌衛星星座網絡詳細參數

5.1.2 仿真環境和DDTCP實現

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

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

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

5.2 仿真結果分析

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

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

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

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

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等算法在有誤碼丟包場景下的吞吐量變化.我們將網絡的誤碼率設為10-7，按照平均數據包長度1000 B來算，對應的丟包率接近0.01%.可以看到在這種場景下，Cubic的吞吐量有比較明顯的下降.這是因為Cubic無法區分誤碼丟包和擁塞丟包，導致擁塞窗口會錯誤地減小.Vegas由于其基于時延的擁塞窗口計算算法沒有考慮到低軌衛星網絡這種鏈路時延動態變化的場景，所以擁塞窗口無法被正確設置，幾乎沒有吞吐量.而對于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后，發送端和接收端由于衛星網絡相對地面的運動位于反向縫兩側，傳播時延變化為180 ms左右，同時傳播路徑也會發生比較大的變化.可以看到在這種場景下，BBR和Cubic在90～110 s的吞吐量變得非常低，而DDTCP僅有不到5 s的吞吐量驟降，之后吞吐量就恢復到之前的水平.這是因為此時網絡由于路由更新而發生了短時間內的連續丟包，其他3種協議只能等待超時重傳.而DDTCP通過在發送端維護的重傳定時器觸發DDTCP的快速重傳機制，因此能夠將實際吞吐量快速恢復.

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

5.2.4 DDTCP公平性測試

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

5.2.5 帶寬搶占性測試

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

6 結 論

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

在后續的工作中，我們將在更加多樣和真實的場景下對現有工作進行性能驗證并優化參數設置，并嘗試將顯示擁塞通告和帶內網絡遙測等機制與本文方案結合，進一步提高TCP協議在衛星網絡中的傳輸性能.

作者貢獻聲明：王子涵負責文獻調研、撰寫全文并完成相關實驗；張嬌負責確定論文思路、具體方案以及修改論文；張遠負責代碼實現并協助分析實驗結果；潘恬負責論文框架設定并修改論文；黃韜負責對論文學術性和技術性內容進行審閱和關鍵性修訂.