一种适用于深空星际卫星网络的高效交互传输方法 【技术领域】
本发明属于深空星际卫星网络传输技术领域。背景技术 目前, 在国际互联网上得到广泛应用的 TCP 协议提出于上世纪 80 年代, 在几十年 的发展演变过程中, 先后出现了 TCP-Tahoe、 TCP-Reno、 TCP-NewReno 以及 TCP-SACK 等协议 版本, TCP-Reno 的应用最普遍。这些不同版本的 TCP 协议都是针对误码率极低和传播延时 非常小的有线网络设计的, 即数据在传输过程中由于误码导致差错的可能非常小, 以及等 待数据接收应答的时间非常短。所以, 一旦出现数据的丢失或损坏以及长时间的无应答, TCP 协议就会认为网络出现了拥塞, 并采取拥塞回避等流量控制算法。 这些假设不仅简化了 TCP 协议的处理流程, 而且很好地利用了有线网络的传输特性, 满足了地面互联网的发展需 要。
然而, 这些基于高速和可靠的信道传输假设却在深空星际卫星网络环境中无法成 立, 因此也就对 TCP 协议的传输性能造成了非常不利的影响。深空星际卫星网络的特点主 要包括如下几点 :
1) 极长的传播时延
地面网络的数据传输往返时间 (RTT, 发送端从发送数据到收到应答所需的时间 ) 为几到几十个毫秒, 典型的 RTT 为 80 毫秒。在深空星际卫星网络中的传播时延则比地面网 络大得多, 地球与月球之间的 RTT 在 2.6 秒左右, 是地面网络的 30 多倍 ; 地球与火星之间距 离更远、 RTT 更长, 是地面网络的几千倍 ; 地球与太阳系内其它行星之间的传播时延最长可 达几小时。
深空星际卫星网络中极长的传播时延对 TCP 协议造成了非常不利的影响, 突出表 现在如下两方面 : a) 连接建立等待时间过长, 超过了连接等待超时时间, 使得 TCP 协议在数 据传输之前就终止了连接 ; b) 拥塞窗口增长速度非常缓慢, 使得协议的慢启动阶段耗时过 长, 严重影响了星际网络的链路资源利用。
2) 极高的信道随机误码率
深空星际卫星网络的电磁环境非常恶劣, 不仅包括传播距离非常远造成的信号能 量大量衰减, 而且还包括空间环境中强烈的电磁干扰。这些都造成了星际卫星网络极高的 链路随机误码, 误码率可以高达 10-1。
深空星际卫星网络中极高的链路随机误码率严重影响了 TCP 协议的传输性能, 使 得协议在不断重传丢失信息的同时, 重复启动慢启动算法, 严重限制了 TCP 连接信息流量 的高速传输, 有时甚至导致信息的无法传输。
3) 严重的信道突发误码
由于深空环境中的带电粒子冲击、 运动天体传输链路的遮蔽以及行星大气层的剧 烈变化, 经常会有持续数分钟的突发误码情况发生。
深空星际卫星网络中严重的信道突发误码, 使得 TCP 协议的性能更加不稳定, 有
时甚至还会导致超时重传, 使得 TCP 的性能达到最差。
4) 严重的信道带宽不对称
由于受到卫星、 飞船等等航天器的功率限制, 深空星际网络的传输链路带宽呈现 出非常严重的不对称现象, 即从地球向深空的前向传输链路带宽比由深空返回的反向传输 链路带宽大的多, 往往相差百余倍, 有时甚至高达上千倍。
深空星际卫星网络中严重的链路带宽不对称, 使得 TCP 协议在信息传输过程中, 往往会因为反向传输链路的信息拥塞造成前向链路吞吐量的急剧下降。
5) 周期性的链路中断
由于受到地球、 其它行星的自转和卫星运动轨道相互之间的影响, 深空星际卫星 网络中的信息传输链路呈现周期性中断的特点。在传输链路周期中断期间, TCP 协议的信 息传输显然无法实现。
研究和分析表明, TCP 协议中的连接建立、 慢启动、 拥塞控制、 接收应答以及超时等 待等算法和关键参数的设置是导致 TCP 协议在深空星际卫星网络中性能差的主要原因。
为了改善 TCP 协议在误码率高、 长传播延时等各种网络环境中的传输性能, 目前 已经提出了很多改进方案, 可以归纳为如下几类。
一、 基本改进方案 这些方案提出较早, 对 TCP 协议的改动也很小, 有些已经成为 TCP 协议中的扩展选项。 1) 增大初始拥塞窗口值 : 就是初始拥塞窗口 cwnd 值 IW 从 1 个数据段按照以下公 式增加 : IW = min[4·MSS, max(2·MSS, 4380bytes)], MSS 为最大 TCP 数据段长度。
2) 扩大最大 TCP 发送窗口 : 就是把发送窗口从 16 位比特扩展到 30 位比特, 这样 最大发送窗口值从 64k 字节扩展到了 1G 字节。
3)T/TCP : 在收发两端的第一次连接之后, 其后的 TCP 连接跳过连接建立的三次握 手过程, 直接进入到信息传输阶段。
4) 多 TCP 连接 : 将一个 TCP 连接拆分成多个 TCP 连接, 从收发两端的信息传输效 果上看, 无疑是增加了数倍的信息传输流量。
5) 明确拥塞指示 : 通过在 IP 数据报头中设置网络拥塞指示信息位来告知发送端 网络的信息传输状态。
6)TCP 头压缩 : 压缩 TCP 头的信息量从而提高传输效率。
这些基本改进方案虽然具有协议改动小、 实施方便的优点, 但对协议性能的改进 非常有限。
二、 数据报优先级方案
1)Fast Start 协议 : 为了解决连接开始阶段数据流量低的问题, 在数据传输初始 阶段采用最近一次 TCP 连接的发送窗口来控制数据流量。为了避免突发的数据流量造成网 络拥塞, 设置初始阶段的 IP 分组优先级为低优先级。
2)TCP Peach : 采用了 Sudden Start 和 Rapid Recovery 等新的算法, 其核心思想 是发送大量低优先级的重复数据段, 根据返回的应答情况探测网络中的可用带宽和控制信 息流量。
3)TCP PBS : 沿用了 TCP-Peach 协议低优先级数据段发送的思路, 并改进了 Sudden
Start 和 Rapid Recovery, 提出了 Accelerative Start 和 Expeditious Recovery 两个新 的算法。
4)TP-Planet : 对 TCP 协议改动非常大, 包括 “INITIAL STATE” 和 “STEDY STATE” 两个状态集, 两个状态集又包含多个子状态。 在两个状态集, 协议均会发送大量低优先级的 无效数据段来探测网络状态。
5)TP-Satellite : 采用了超起始 Super Start 算法以取代慢启动算法, 增加了数 据丢失判断算法, 并采用了主动周期选择的应答算法。协议的突出特点就是间隔发送高低 优先级数据段, 根据不同优先级数据的接收情况判断网络状态, 并采取相应的信息流量控 制算法。
三、 可用带宽估计方案
1)TCP Westwood : 通过不断监测接收到的应答数据段实现端到端的可用带宽估 计, 并当出现数据丢失时, 利用可用带宽的估计计算拥塞窗口和慢启动门限等重要参数。
2)TCP-STAR : 除了通过监测应答数据段来估计可用带宽, 还增加了发送查询数据 段来判断数据接收情况。
3)Faster Recovery : 是对 TCP Westwood 协议的改进, 提出了一个基于带宽估计的 数据丢失恢复机制。 四、 拥塞窗口指示方案
此类方案的典型代表是 XCP 协议以及其改进协议 P-XCP。XCP 协议中, ECN 不再仅 仅采用单比特信息来表示网络拥塞与否, 而是在 TCP 头部分增加拥塞字段, 传输过程中路 由器参与拥塞字段参数值的调整和修改, 以此达到信息流量的精确控制和传输带宽的公平 分配。
五、 信道不对称改进方案
1)SACK : 接收端通知发送端哪些数据段已经正确接收, 发送端可以根据 SACK 信息 判断出没有成功接收的数据段, 并一次重传多个丢失的 TCP 数据段, 减少重传等待时间, 提 高重传效率。
2)NACK : 当接收端发现有数据丢失时, 直接向发送端发送未正确接收的数据段的 信息。
3)ACK 拥塞控制 : 为了减少瓶颈链路 TCP 应答数据段的数量, 接收端动态调整应答 数据段的发送周期因子。当网络出现应答信息拥塞时, 则延长 ACK 的发送间隔 ; 反之, 则减 小应答间隔。
六、 其它协议层修改方案
在其它协议层的修改主要集中在网络层下的数据链路层。 链路层的协议修改则大 多是增加重传机制, 即在发送端的链路层对接收到的 ACK 信息进行判断, 若发现有数据丢 失, 则直接重传该数据, 而不向传输层传送重传请求信息。目前, 链路层的典型修改方案是 Snoop 协议。
七、 代理方案
1)TCP-Splitting 代理 : 就是在网络物理环境发生变化的交界处设置网关代理以 切断 TCP 连接。这样一个端到端的 TCP 连接就会被切分成多段 TCP 连接。每一段连接都可 以采用特殊的传输控制协议, 如 STP、 突发误码重传协议、 AeroTCP 等。
2)TCP-Spoofing 代理 : 与 TCP-Splitting 代理方案的不同是保持了 TCP 协议端到 端连接的完整性, 在数据链路层实现虚假 ACK 应答的发送以及差错数据段的重传。
八、 跨层联合设计
为了达到数据传输的最优, 各层内部的信息相互共享, 层次之间相互协作、 联合设 计逐渐成为研究热点。应用层中的数据传输状态信息 ( 长数据流传输的开始、 中间、 结束, 或者一个单独的数据传输 ), 物理层的链路可用带宽和误码率信息, 都可以成为各个层设计 时考虑的参数。跨层联合设计是把原本各层中的 “私有” 信息 “共享” , 使得每个层的设计不 再独立、 单一, 有利于整体性能提高。
上述这些不同类型的改进方案大多是针对网络的某种特点而提出的, 有的是针对 误码率高的信道特点, 有的是针对特殊网络拓扑结构的情况, 有的则是针对传输延时不断 变化的特点, 综合考虑深空星际网络环境特点提出的改进方案则非常少。因此, 这些 TCP 改 进方案在深空星际网络中的性能表现就很差, 现在就分析深空星际网络的网络特点对改进 方案的性能影响。
1、 极长的传播时延, 使得 Fast Start、 STP、 TCP-Peach、 TCP Westwood、 TCP-STAR、 XCP 和 TP-Satellite 等各类改进方案中的典型协议消耗非常长的时间来等待连接建立的 确认, 同时也使得拥塞窗口增长非常缓慢, 限制了信息流量 ; 2、 极高的信道随机误码率, 导致 Fast Start、 STP、 TCP Westwood、 TCP-STAR 等改 进协议错误地认为网络拥塞情况严重, 使得协议不断启动慢启动算法, 协议前向吞吐量受 到极大限制 ;
3、 严重的信道突发误码, 使得 Fast Start、 STP、 TCP Westwood、 XCP 和 TCP-STAR 协 议已经无法正常传输数据, 也使得 TCP-Peach 协议通过发送大量无效数据段探测网络链路 状态的方法失去作用, 同时也降低了利用高低优先级交替发送数据的 TP-Satellite 协议 对链路状态判断的准确性 ;
4、 严重的信道带宽不对称, 使得反向链路数据传输严重拥塞, 导致很多改进方案 的前向链路吞吐量极低, 甚至无法传输数据 ;
目前提出的改进方案除了存在上述的问题外, 对于深空星际网络的拥塞状况也不 能作出判断, 即无法针对网络不同程度的拥塞作出相应的数据流量控制。
发明内容 本发明的目的在于提供一种可靠的为深空星际卫星网络设计的 TP-DSN 深空星际 卫星网络高效交互传输方法。 此方法能够避免连接等待的时间消耗, 迅速提升信息流量, 有 效区分链路误码和拥塞情况, 并根据网络的拥塞程度采用相应的信息流量控制, 极大地降 低了反向链路的传输带宽要求。
本发明的技术方案是 : 一种适用于深空星际卫星网络的高效交互传输方法, 特征 在于, 它是在源代码公开的 Linux 操作系统上实现。该方法包含以下步骤 :
步骤 (1), 连接监听
客户端进入 “监听” 状态, 等待服务器连接 ;
步骤 (2), 建立连接
步骤 (2.1), 从服务器端发送连接请求, 并按照拥塞窗口最大值 cwndmax 的 1/6 开始
发送数据信息, 设置数据信息 IP 包头中的两比特 “pri” 分别为 2、 1、 0, 即高、 中、 低优先级分 组数据交错发送, 每间隔一个时间 τ 就发送一个分组数据。 其中, RTTmin 为服务器与客户端的星际网络中两行星之间最短的传播时延 ;
步骤 (2.2), 从服务器来的连接请求, 经过深空星际网络传输到达客户端 ;
步骤 (2.3), 客户端收到连接请求后, 判断是否建立连接 :
步骤 (2.3.1) 若拒绝连接, 则返回拒绝连接应答信息, 丢弃之后接收到的分组数 据, 结束连接 ;
步骤 (2.3.2) 若接受连接, 则开始估计 RTTi 时间, 返回连接应答信息, 并接收到达 的分组数据 ;
步骤 (2.4), 客户端在接收了 cwndmax/6 的分组数据后, 返回数据接收应答信息, 应 答信息采用 M-NACK 格式, 即包括 : 20 个字节的标准 TCP 头、 期待服务器发送的下一个 TCP 数据段的序列值、 期待服务器发送的下一个连续 TCP 数据段的序列值, 以及所有没有正确 接受的 TCP 数据段的序列值。计算出数据发送返回 RTTi 时间, 并按照 RTTi 时间定时发送 M-NACK 应答信息 ; 步骤 (2.5), 服务器接收到连接应答信息后, 返回应答确认信息, 估计数据发送返 回 RTTi 时间, 并转入到步骤 (3)。
步骤 (3), 数据的丢失判断 :
步骤 (3.1), 服务器接收到 M-NACK 应答信息后, 根据 M-NACK 的信息内容判断是否 有数据丢失 :
步骤 (3.1.1), 若存在数据丢失, 则根据丢失数据的优先级和数量判断是否网络出 现拥塞 :
步骤 (3.1.11), 若丢失数据高、 中、 低优先级都存在, 而且成功接收数据中各种优 先级的数据都有, 则判断为网络中出现链路误码, 则转入到 (3.1.2) ;
步骤 (3.1.1.2), 其他情况则判断为网络拥塞, 根据具体的数据丢失情况分析网络 拥塞的情况 :
步骤 (3.1.1.2.1), 若丢失的分组数据都是低优先级分组数据, 即 lost_num = low_pri, lost_num 为整个丢失分组数据的数量, low_pri 为丢失的低优先级分组数据数 量, 则判断网络的拥塞情况较轻, 则将拥塞窗口 cwnd 值设置为当前值的 1/2, 并转入到步骤 (3.1.1.2.4) ;
步骤 (3.1.1.2.2), 若丢失分组数据为低优先级的全部分组数据和部分中等优先 级分组数据, 即 lost_num = low_num+mid_num, mid_num 为丢失的中等优先级分组数据数 量, 则判断网络的拥塞情况比较严重, 不仅路由器队列中的低优先级分组数据全部被丢弃, 而且中等优先级的分组数据开始被丢弃, 则将拥塞窗口 cwnd 值设置为当前值的 1/3, 并转 入到步骤 (3.1.1.2.4) ;
步骤 (3.1.1.2.3), 若丢失分组数据为中、 低优先级的全部分组数据和部分或者
全部高优先级分组数据, 即, 则判断网络的拥塞情况非常严重, 不仅中、 低优先级分组数据全部丢弃, 而且还会有高优先级分组数据的丢弃, 则将拥塞 窗口 cwnd 值设置为当前值的 1/4, 并转入到步骤 (3.1.1.2.4) ;
步骤 (3.1.1.2.4), 转入步骤 (7) ;
步骤 (3.1.2), 没有分组丢失, 则直接进入到步骤 (4)。若判断为网络出现误码, 则 开始重传丢失的分组数据。 丢失分组数据的重传仍然按照等间隔三级优先级交错发送的方 式进行, 发送间隔 τ 按照如下公式计算得出 : 步骤 (4) ;
在发送完丢失数据后, 并转入到步骤 (4), 拥塞回避阶段的判断 : 判断收发两端是否已经执行过拥塞回避 Congestion Avoidance 策略 : 步骤 (4.1) 若没有, 则并转入到步骤 (6) ; 步骤 (4.2) 若已经执行过拥塞回避 Congestion Avoidance 策略, 则转入到步骤 步骤 (5), 拥塞恢复 : 步骤 (5.1), 重新计算数据发送间隔时间 τ, 即 τ = RTTi/cwnd ; 步骤 (5.2), 三级优先级间隔重传丢失数据, 发送完丢失数据后, 并转入到步骤 步骤 (6), 初始发送数据 : 步骤 (6.1), 将 cwnd 值增加 1 倍, 即 cwnd = 2· cwnd, 若 cwnd ≥ cwndmax, 则令 cwnd 并按照三级优先级等间隔交错发送的(7) ;
(7) ;
= cwndmax。 重新计算数据发送间隔 τ, 即 方式发送分组数据 ;
步骤 (6.2), 当 cwnd 的分组数据发送完后, 将 cwnd 减半, 即 cwnd = cwnd/2, 重新计 按照三级优先级等间隔交错发送的方式发送分组数据 ;算数据发送间隔 τ, 即
步骤 (6.3), 在发送完数据后, 将 cwnd 增加 1 倍, 即 cwnd = 2· cwnd, 比较 cwnd 值 : 步骤 (6.3.1) 若 cwnd < cwndmax, 则转入到步骤 (3) ; 步骤 (6.3.2) 若 cwnd ≥ cwndmax, 则令 cwnd = cwndmax, 并转入到步骤 (7) ; 步骤 (7), 拥塞回避 : 每接收到一个 M-NACK 信息, 判断是否有数据包丢失 :步骤 (7.1) 若无分组数据丢失, 则判断当前拥塞窗口 cwnd 值是否等于 cwndmax 值 : 若小于 cwndmax, 则按照成功接收的分组数据数量增加 cwnd ; 若等于 cwndmax, 则不变。 重新计 算 τ, 即 τ = RTTi/cwnd, 并根据 τ 值间隔交错发送三级优先级的分组数据 ;
步骤 (7.2) 若发现分组数据丢失, 则转入到步骤 (3) ;
步骤 (8), 连接拆除 :
步骤 (8.1), 若服务器端发起连接拆除请求 :
步骤 (8.1.1), 服务器发送连接结束分组信息, 等待客户端的应答 ;
步骤 (8.1.2), 客户端收到连接结束分组信息后, 返回确认应答信息, 拆除此次连 接, 进入监听状态 ;
步骤 (8.1.3), 服务器接收到确认应答分组信息后, 拆除此次连接, 进入监听状态; 步骤 (8.2), 若客户端发起连接拆除请求 :
步骤 (8.2.1), 客户端发送连接结束分组信息, 等待服务器的应答 ;
步骤 (8.2.2), 服务器收到连接结束分组信息后, 返回确认应答信息, 拆除此次连 接, 进入到监听状态 ;
步骤 (8.2.3), 客户端接收到确认应答分组信息后, 拆除此次连接, 进入到监听状 态。
本发明在图 5 的环境中进行了仿真实验。实验中, 深空星际卫星网络中从地球 到月球的前向链路带宽为 1Mbits/s, 从月球到地球的反向链路带宽分别设为 10kbits/s、 5kbits/s、 1kbits/s 等, RTTmin 设为 2.4s, RTT 设为 3s, cwndmax 设为 60。随机误码的情况下, -2 分组数据的丢包率为 10 , 突发误码情况下, 链路平均突发误码长度为 40 个分组数据。实 验结果如下 :
表 1 文件传输时间 (s)
表 2 单个连接情况下的前向链路吞吐量 (kbits/s)
表 3 单个连接情况下的反向链路带宽占用 (kbits/s)
表 4 不同反向链路带宽情况下的前向链路吞吐量 (kbits/s)
表 5 不同反向链路情况下的反向链路带宽占用 (kbits/s)
从表 1 可以看出, TP-DNS 协议在不同大小文件的传输方面比其他协议占用的时间 少, 特别在传输几十 k 字节的小文件优势更明显。对于网页浏览方式的访问来说, TCP 连接 的文件传输一般也只有 10 ~ 20k 字节。表 2 和表 3 可以看出, 单个连接时, 无论是在随机 误码还是在突发误码的情况下, TP-DNS 均能够保持很高的前向链路吞吐量。并且反向链路 的带宽占用受到前向链路误码的影响非常小, 并且保持在非常低的水平。 然而, 其他协议的 前向链路吞吐量则受到了误码的严重影响, 而变得非常低。虽然 TP-Peach 协议在随机误码 情况时前向链路吞吐量也较高, 但其传输了大量用于探测网络的无效分组数据, 实际的信 息传输量很小。从表 4 和表 5 可以看出, 由于 TP-DNS 协议的反向链路带宽使用很少, 所以 当深空星际卫星网络中的反向链路带宽从 10kbits/s 减少到 1kbits/s 时, 前向链路的带宽 并没有受到影响。然而其他协议在反向链路带宽小于 5kbits/s 后, 前向链路的吞吐量就受 到了影响, 当反向链路接近 1kbits/s 时, 前向链路的吞吐量则非常低。
由 于 TP-DSN 需 要 修 改 系 统 的 堆 栈 协 议, 所 以 只 能 在 源 代 码 公 开 的 Linux 和 FreeBSD 等操作系统上实现。
实验证明, 不论在单连接的情况下, 还是在多个连接的情况下, 不论是否出现随机 误码或者突发误码, TP-DSN 能够节省连接过程消耗的等待时间, 迅速提升信息流量, 其前向 链路吞吐量为最高, 反向链路的带宽占用也最小。
附图说明
图 1 是 TP-DSN 协议框架。 图 2 是三级优先级数据交错发送策略。 图 3 是数据丢失原因判断 Loss Distinguish 策略。 图 4 是初始发送 Initialization Sending 策略。 图 5 是深空星际卫星网络框图。具体实施方式
TP-DSN 的协议框架如图 1 所示, 主要包含连接建立 Connection 阶段、 数据丢失 原 因 判 断 Loss Distinguish 阶 段、 初 始 发 送 Initialization Sending 阶 段、 拥塞回避 Congestion Avoidance 阶段、 拥塞恢复 Congestion Recovery 阶段。与 TCP 协议及改进方 案相比, 创新点主要体现在以下几方面。
一、 三级优先级数据交错发送
在整个信息传输过程中, TP-DSN 将分组数据分为三级优先级, 优先级的设置是在 IP 包头中的 TOS 字段中的二位优先级比特 (“pri” ) 实现。高、 中、 低三级优先级分组数据 采用交错发送的方法, 具体发送方法如图 2 所示, 即首先发送一个高优先级分组数据, 之后 连续发送两个中等优先级分组数据, 紧接着发送一个高优先级分组数据, 而后连续发送两 个低优先级分组数据。后面的分组数据按照上述方法循环执行。
二、 连接建立阶段数据发送
在连接建立阶段, 即收发两端在 TCP 连接握手过程中就开始传送信息数据。这样, 收发两端能够节省过长的连接等待时间, 在地球和月球之间的信息传输就可以节省 2 ~ 3s, 地球与其他行星之间的信息传输则能够节省更多的时间。在三次往返的连接建立交互 过程中, 分组数据等间隔发送。每次连接建立交互过程中的信息流量为发送拥塞窗口最大 值的 1/6, 即发送的分组数据为 cwndmax/6。为了避免协议过于复杂, 发送时间间隔 τ 设定 为地球与行星之间 RTT 的最小值 RTTmin 与拥塞窗口之间的比值, 即 若在地球与月球之间的 TCP 连接, 则 RTTmin 为 2.4s ; 若在地球与火星之间的连接, 则 RTTmin 为 200s。
三、 数据丢失原因判断 Loss Distinguish 策略
为了实现对数据丢失原因的区分和判断, 借鉴了 TP-Satellite 协议的设计思路, 增加了数据丢失原因判断 Loss Distinguish 策略。
数据丢失原因判断 Loss Distinguish 策略的具体内容是 : 发送端根据接收到的 M-NACK 信息判断是否有数据丢失。 当发送端发现有数据丢失时, 如图 3 所示, 在重传丢失数 据的同时, 发送端根据高、 中、 低三级优先级分组数据的丢失情况分析数据丢失原因, 并采 用相应的流量控制算法。
当星际卫星网络出现拥塞并且网络拥塞情况较轻时, 网络中的路由器首先将队列 中的低优先级数据包丢弃。这样的情况下, 整个丢失分组数据的数量 (lost_num) 就是丢失 的低优先级分组数据数量 (low_pri), 如公式 (1) 所示 :
lost_num = low_pri (1)
这种情况下, 数据丢失原因判断 Loss Distinguish 策略则减小拥塞窗口 cwnd 值, 将其设置为当前值的 1/2, 并启动拥塞回避 Congestion Recovery 策略。
当网络拥塞情况比较严重时, 不仅路由器队列中的低优先级分组数据全部被丢 弃, 而且中等优先级的分组数据开始被丢弃。 这种情况下, 丢失的分组数据数量为低优先级 分组数量 (low_num) 和丢失的中等优先级分组数据数量 (mid_num) 之和, 如公式 (2) 所示 :
lost_num = low_num+mid_num (2)
这种情况下, 数据丢失原因判断 Loss Distinguish 策略则将拥塞窗口 cwnd 值设 置为当前值的 1/3, 并启动拥塞回避 Congestion Recovery 策略。网络拥塞情况非常严重时, 路由器队列中已没有低优先级和中等优先级的分组数 据, 此时开始丢弃高优先级的分组数据。因此, 应答信息中表示的丢失分组数据表明, 不仅 中、 低优先级分组数据全部丢弃, 而且还会有高优先级分组数据的丢弃。所以, 丢弃的分组 数据量大于发送的低优先级和中等优先级两种分组数据量的总和, 如公式 (3) 所示 :
low_pri == low_num
mid_pri = mid_num (3)
lost_num > low_pri+mid_pri
这种情况下, 数据丢失原因判断 Loss Distinguish 策略则将 cwnd 值设置为当前 值的 1/4, 并启动拥塞回避 Congestion Recovery 策略。
除了上述三种情况外, TP-DSN 协议都认为数据的丢失是因为随机误码或者是突发 误码造成的, 所以不减小 cwnd 值, 信息流量不发生变化。
四、 初始发送 Initialization Sending 策略
TP-DSN 协议中的初始发送 Initialization Sending 策略的具体执行如图 4 所示, 在连接建立之后, 将发送端的拥塞窗口设置为连接建立阶段拥塞窗口值的两倍, 即 cwnd = cwndmax/3。数据按照三级优先级交错发送的算法等间隔发送, 时间间隔 τ 按照公式 (4) 计 算得出 :
其中, 发送返回时间 RTTi 是在连接建立过程中估计得出。
当按照上述方式完成分组数据的发送后, TP-DNS 协议将 cwnd 值减少一半, 按照公 式 (4) 重新计算数据发送时间间隔 τ, 并按照优先级等间隔交错发送的方法发送数据。
在完成数据发送后, 协议将 cwnd 值恢复为最大拥塞窗口值的 1/3, 并启动拥塞回 避 Congestion Avoidance 策略。
可以看出, 协议在初始发送 Initialization Sending 阶段的维持时间为一个 RTTi。在此阶段协议所发送的分组数据量为最大拥塞窗口值的一半。
本实施例是在源码公开的 Linux 操作系统中实现。
具体的工作流程如下 :
1、 连接监听
客户端, 客户端进入 “监听” 状态, 等待服务器端的连接。
2、 连接建立 Connection 阶段
(1) 服务器端发送连接请求, 请求与客户端的连接, 并按照拥塞窗口最大值 cwndmax 的 1/6 开始发送数据信息, 设置数据信息 IP 包头中的两比特 “pri” 分别为 2、 1、 0, 即高、 中、
低优先级分组数据交错发送, 每间隔一个时间 τ 就发送一个分组数据。 其中, RTTmin 为服务器与客户端的星际网络中两行星之间最短的传播时延 ;
(2) 从服务器端来的连接请求, 经过深空星际网络传输到达客户端 ;
(3) 客户端收到连接请求后, 判断是否建立连接 :
(3.1) 若拒绝连接, 则返回拒绝连接应答信息, 结束连接, 并丢弃之后接收到的分 组数据 ;(3.2) 若接受连接, 则开始估计 RTTi 时间, 返回连接应答信息, 并接收到达的分组数据 ; (4) 客户端在接收了 cwndmax/6 的分组数据后, 返回数据接收应答信息, 应答信息 采用 M-NACK 格式, 即包括 : 20 个字节的标准 TCP 头、 期待服务器发送的下一个 TCP 数据段的 序列值、 期待服务器发送的下一个连续 TCP 数据段的序列值, 以及所有没有正确接受的 TCP 数据段的序列值。计算出数据发送返回 RTTi 时间, 在等待 RTTi/2 时间之后按照 RTTi 时间 定时发送 M-NACK 应答信息 ; 有关 M-NACK 格式, 本申请人在专利号为 ZL200610114087.0 发 明名称为一种适用于卫星网络的高效交互传输方法的专利中有详细说明。
(5) 服务器接收到连接应答信息后, 返回应答确认信息, 估计数据发送返回 RTTi 时 间, 并进入到数据丢失判断阶段。
3、 数据丢失判断 Loss Distinguish 阶段
(1) 服务器接收到 M-NACK 应答信息后, 根据 M-NACK 的信息内容判断是否有数据丢 失:
(1.1) 若存在数据丢失, 则根据丢失数据的优先级和数量判断是否网络出现拥 塞:
(1.1.1) 若丢失数据高、 中、 低优先级都存在, 而且成功接收数据中各种优先级的 数据都有, 则判断为网络中出现链路误码, 则转入到 (1.2) ;
(1.1.2) 其他情况则判断为网络拥塞, 根据具体的数据丢失情况分析网络拥塞的 情况 :
(1.1.2.1) 若丢失的分组数据都是低优先级分组数据, 如公式 (1) 所示, 则判 断网络的拥塞情况较轻, 则将拥塞窗口 cwnd 值设置为当前值的 1/2, 并进入到拥塞回避 Congestion Avoidance 阶段 ;
(1.1.2.2) 若丢失分组数据为低优先级的全部分组数据和部分中等优先级分组数 据, 如公式 (2) 所示, 则判断网络的拥塞情况比较严重, 不仅路由器队列中的低优先级分组 数据全部被丢弃, 而且中等优先级的分组数据开始被丢弃, 则将拥塞窗口 cwnd 值设置为当 前值的 1/3, 并进入到拥塞回避 Congestion Avoidance 阶段 ;
(1.1.2.3) 若丢失分组数据为中、 低优先级的全部分组数据和部分或者全部高优 先级分组数据, 如公式 (3) 所示, 则判断网络的拥塞情况非常严重, 不仅中、 低优先级分组 数据全部丢弃, 而且还会有高优先级分组数据的丢弃, 则将拥塞窗口 cwnd 值设置为当前值 的 1/4, 并进入到拥塞回避 Congestion Avoidance 阶段。
(1.2) 没有分组丢失, 则直接进入到拥塞回避阶段的判断状态。 若判断为网络出现 误码, 则开始重传丢失的分组数据。丢失分组数据的重传仍然按照等间隔三级优先级交错
发送的方式进行, 发送间隔 τ 按照如下公式计算得出 :在发送完丢失数据后,进入到拥塞回避阶段的判断阶段。
4、 拥塞回避阶段的判断
判断收发两端是否已经进入到拥塞回避 Congestion Avoidance 阶段 :
(1) 若没有, 则进入到初始发送 Initialization Sending 阶段 ;
(2) 若已经进入到拥塞回避阶段, 则进入到拥塞回避 Congestion Avoidance 阶段。 5、 拥塞恢复 Congestion Recovery 阶段
重新计算数据发送间隔时间 τ, 即 τ = RTTi/cwnd, 三级优先级间隔重传丢失数 据, 当发送完丢失数据后, 转入到拥塞回避 Congestion Avoidance 阶段。
6、 初始发送 Initialization Sending 阶段
(1) 将 cwnd 值 增 加 1 倍, 即 cwnd = 2·cwnd。 若 cwnd ≥ cwndmax, 则 令 cwnd =
cwndmax。重新计算数据发送间隔 τ, 即并按照三级优先级等间隔交错发送的方式发送分组数据 ;
(2) 当 cwnd 的分组数据发送完后, 将 cwnd 减半, 即 cwnd = cwnd/2, 按照上述的公 式重新计算数据发送间隔 τ, 按照三级优先级等间隔交错发送的方式发送分组数据 ;
(3) 在发送完数据后, 将 cwnd 值增加 1 倍, 即 cwnd = 2·cwnd, 比较 cwnd 值 :
(3.1) 若 cwnd < cwndmax, 则转入数据丢失判断 Loss Distinguish 阶段 ;
(3.2) 若 cwnd ≥ cwndmax, 则结束初始发送 Initialization Sending 阶段, 转入到 拥塞回避 Congestion Avoidance 阶段。 7、 拥塞回避 Congestion Avoidance 阶段
(1) 每接收到一个 M-NACK 信息, 判断是否有数据包丢失 :
(1.1) 若无分组数据丢失, 则判断当前拥塞窗口 cwnd 值是否等于 cwndmax 值 : 若小 于 cwndmax, 则每接收到一个 M-NACK 应答信息 cwnd 增加 1 ; 若等于 cwndmax, 则不变。重新计 算 τ, 即 τ = RTTi/cwnd, 并根据 τ 值间隔交错发送三级优先级的分组数据 ;
(2.1.2) 若发现分组数据丢失, 则转入到数据丢失原因判断 Loss Distinguish 阶 段。
8、 连接拆除
服务器端发起连接拆除请求 :
(1) 服务器发送连接结束分组信息, 等待客户端的应答 ;
(2) 客户端收到连接结束分组信息后, 返回确认应答信息, 拆除此次连接, 进入监 听状态 ;
(3) 服务器接收到确认应答分组信息后, 拆除此次连接, 进入监听状态 ;
客户端发起连接拆除请求 :
(1) 客户端发送连接结束分组信息, 等待服务器的应答 ;
(2) 服务器收到连接结束分组信息后, 返回确认应答信息, 拆除此次连接, 进入到 监听状态 ;
(3) 客户端接收到确认应答分组信息后, 拆除此次连接, 进入到监听状态。