基于链路信息估计的低轨卫星网络传输控制协议

王子涵 张 娇 张 远 潘 恬 黄 韬

（北京邮电大学信息与通信工程学院 北京 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协议在卫星网络中的传输性能.

作者贡献声明：王子涵负责文献调研、撰写全文并完成相关实验；张娇负责确定论文思路、具体方案以及修改论文；张远负责代码实现并协助分析实验结果；潘恬负责论文框架设定并修改论文；黄韬负责对论文学术性和技术性内容进行审阅和关键性修订.