1. 系统体系结构

• 交互式卫星宽带接入系统

• 非对称式卫星宽带接入系统

• 卫星宽带骨干传输系统

2. 卫星网络中的TCP协议

• TCP流量控制
  • 滑动窗口机制
• TCP拥塞控制
  • 慢启动
  • 拥塞避免
  • 超时重传
• TCP差错控制
  • 差错检测，差错恢复
  • 确认包，计时器，重传

2.1 TCP吞吐量问题

• 决定了数据传输速率
• 保证发送较大的数据报（减小TCP和IP包头开销）时
• TCP连接能充分利用有效的路径带宽（有效性）
• 能够和其他用户分享带宽资源（公平性）
• 吞吐量受多种条件/机制限制

2.1.1 TCP序号

• 每个发送字节有唯一序号，用来跟踪
• TCP协议序号空间为32比特环回
• IP数据报最大生存期2分钟
• 综上可以求出受TCP序号限制的最大传输速率

2.1.2 TCP传输窗口

• 用于TCP接收端控制发送端的发送数据量
• 标准TCP窗口大小64KB
• TCP包头窗口大小16bit
• 路径往返时间延时RTT
• 综上TCP有效带宽

2.1.3 慢启动

• TCP采用慢启动探测传输路径的有效带宽
• 存在问题
  • 传输速度的增加需要较长时间
  • 数据包的丢失被解释为拥塞（可能是其它原因导致的）

2.2 卫星TCP的问题

• 原TCP协议针对有线网络，传输延时和误码率低
• 确认机制用于端对端流量控制，拥塞控制，误差控制
• 报文丢失更多是因为拥塞造成的，因此降低发送速率

• 但是卫星TCP中，报文丢失往往是延时和链路差错造成的，采用相同的应对方法会造成不必要的吞吐率降低

  2.2.1 长延时

• 发送端根据接收端的确认调整速率、拥塞避免和差错回复

• 慢启动时间计算

• 即传输延时越长，慢启动时间越长

  2.2.2 大带宽延时积

• 窗口大小为16位，卫星链路延时t（时间较长）

• 系统吞吐率限制为

• 可以扩展窗口，但会导致报文段丢失概率增加

  2.2.3 高误码率

• 因错丢失的报文段必须重传，增加消耗

• 因错丢失导致传输速率降低，利用率下降

• 差错有突发性，TCP的快速重传和快速回复无法应对单窗口内的多个错误，限制窗口的增长

  2.2.4 链路不对称性

• 需采用慢速的反向链路

• 但反向链路带宽有限时会带来其它问题
  • 数据突发性
  • 降低窗口增长速度
  • 恢复机制效率降低

2.3 卫星TCP性能增长办法

2.3.1 端对端解决办法

• TCP增强技术：
  • 大窗口（LW）选项
    • 针对具有较大带宽延时积的网络
  • 增大初始窗口（IIW）
    • 增大慢启动开始时的初始化窗口大小
  • 字节计数（BC）
  • 慢启动后的延迟确认（DAASS）
  • 选择性确认（SACK）
    • 数据恢复算法，可以与已有拥塞控制算法混合使用
    • 在链路差错率大的条件下，不能防止大量超时出现
  • 显示拥塞通告（ECN）
    • 将IP包头中的1bit区域用于通知发生了拥塞
• TCP Vegas
  • 不以包丢失作为拥塞指示，而是使用传输速率实现拥塞控制
  • 不对称信道下工作不理想

• TCP Peach

  • 虚报文段探查，实现突发启动，使用TCP包头的一个保留比特区别虚报文段和数据报文段
  • 一个往返时间内，迅速将窗口提升到门限，具备高速恢复算法
  • 但会增加网络开销，需要支持报的优先级，算法实现难度大，未解决宽带不对称
  • TCP Swift 为改进版

    2.3.2 基于中间件解决办法/性能增强代理

• TCP分裂Splitting

  • 通信系统分为卫星段和非卫星段
  • 非卫星段仍采用标准地面的TCP协议
  • 卫星段采用专用的卫星传输协议

• TCP欺骗spoofing

  • 信关站发送欺骗性的确认指令，自行处理真实确认信号，数据压力转移到信关站上
  • 容易造成非卫星段和卫星段延时和性能差异较大而造成严重的数据缓冲区的累积，成为系统瓶颈
  • 无需修改终端的TCP协议栈

• 中间的解决方案中

• 逻辑上，分裂和欺骗本质一样
• 存在一些问题
  • 中间件的解决方案，破环了传输协议的端到端特性
  • 信关站为网络引入了单点故障特性，成为了唯一路由
  • 加密与认证协议，要求信关站成为系统的可信赖设施