第3章：运输层（四）

声明：以下所有内容均来自陈老师的课件，此博客只是为了方便日后复习

• 运输层服务
• 多路复用与多路分解
• 无连接运输：UDP
• 可靠数据传输原理
• 面向连接的运输：TCP
• 拥塞控制原理
• TCP拥塞控制

6.拥塞控制的原理

拥塞

• 非正式的定义：“有太多的源主机以过高的速率发送了太多的数据，超过了网络的处理能力”
• 拥塞的表现
  • 分组经历比较长的时延（在路由器的缓存中排队）
  • 分组丢失（路由器缓存溢出）
• 与流量控制不同！
  • 流量控制：一个发送方给一个接收方发送数据的速度太快
• 网络中前10位的问题！

拥塞的原因/代价

• 场景1

  • 一个具备无穷大缓存的路由器
  • 输入、输出链路容量：R
  • 两条连接（2个发送方、2个接收方）
  • 不执行重传
  • 当分组到达速率接近R/2时，平均时延越来越大
    

• 场景2

  • 一个具有有限缓存的路由器
  • 发送方重传丢失（由于缓存溢出）、超时的分组
    • 应用层的输入 = 应用层的输出
    • 运输层的输入包括重传
      
  • 理想化：发送方有完美的信息
    • 发送方仅当缓存空闲时才发送一个分组
    • 不会丢失：
      
      
  • 理想化：发送方有一部分完美的信息
    • 分组可能丢失（在路由器由于缓存溢出而被丢弃）
    • 发送方知道分组在什么时候被丢弃了：仅当在确定了一个分组已经丢失时才重传
      
      
  • 现实情况：不必要的冗余
    • 分组可能丢失，由于缓存溢出而被丢弃
      • 需要重传
    • 然而，发送方有时会提前发生超时，超时时会发送第二个副本。最终，两个副本都被交付到接收方
      
      

• 拥塞的代价

  • 为了达到一个指定的接收方吞吐量，网络需要做很多工作（重传）
  • 不必要重传：链路中运载了一个分组的多个副本
    • 降低了最大的可达到的吞吐量

• 场景3

  • 四个发送方

  • 多跳路径

  • 采用超时/重传机制

  • 所有主机都有相同的!

  • 所有路由器都有相同的链路容量：R

  • 研究对象：A->C连接

  • Q：当和很大时，会发生什么？

  • A：当绿色的很大时，最右边的队列中的所有到达的红色分组都被丢弃了，红色的吞吐量->0
    
    

  • 拥塞的另一种代价：当分组丢失时，任何“用于这个分组的上游传输容量和缓存”都被浪费了

• 总结

  • 吞吐量永远无法超过链路容量
    
  • 当接近链路容量时，时延会增大
    
  • 丢包/重传降低了有效吞吐量
    
  • 不必要的冗余进一步降低了有效吞吐量
    
  • 上游传输容量/缓存浪费在了下游中丢失的分组上
    

• 拥塞控制方法

  • 端到端的控制
    • 没有来自网络层的显式反馈
    • 端系统根据观察到的分组丢失和时延来推断是否有拥塞
    • 是TCP采用的方法
      

• 网络辅助的拥塞控制

  • 路由器给发送/接收主机提供显式的反馈信息
  • 可以指示拥塞情况，或者显式地设置发送速率
  • TCP、ECN、ATM、DECbit协议中所采用的方法

7.TCP拥塞控制

TCP拥塞控制：AIMD（加性增、乘性减）

• 方法：发送方增加发送速率，直到发生分组丢失（暗示“拥塞”）；然后，在遇到丢包时间时减小发送速率
• 加性增（AI）：在每个RTT内，把发送速率线性（加性）增加1MSS，直到检测到丢包
• 乘性减（MD）：遇到每个丢包事件时，把发送速率减半（乘性减）
  

TCP AIMD

• “乘性减”细节：
  • 当通过三个冗余ACK检测到丢包时，把发送速率减半；当通过超时检测到丢包时，把发送速率减小1个MSS（TCP Reno，TCP的较新版本）
  • 当通过三个冗余ACK或超时检测到丢包时，都把发送速率减小到1个MSS（TCP Tahoe，TCP的早期版本）
• 为什么采用AIMD机制？
  • AIMD是一种分布式异步优化算法，它已被证实：
    • 能够优化大规模网络的拥塞流量
    • 具有令人满意的稳定性能

TCP拥塞控制的细节

• 
• TCP发送方的行为
  • 粗略地讲：发送cwnd个字节，等待RTT时间来接收ACK，然后再发送更多的字节
  • 
• TCP发送方限制它向其连接发送流量的速率：
• 根据所观察到的网络拥塞情况来动态调节拥塞窗口cwnd的值（从而实现TCP控制）

TCP慢启动

• 连接刚建立时。指数级地增加速率，直到发生第一个丢包事件：
  • 初始时，cwnd = 1 MSS
  • 每过一个RTT，把cwnd加倍
  • 具体实现方式：每接收到一个ACK就增大cwnd的值
• 概述：初始速率很慢，但是加速却是指数级的
  • 指数快速增长，慢启动时间很短，长期来看可以忽略
    

TCP：从慢启动阶段转移到拥塞避免阶段

• Q：发生丢包事件后，何时结束指数增长、转换为线性增长？
• A：当cwnd变成丢包事件前窗口的1/2
• 实现：
  • 变量ssthresh
  • 出现丢包事件时，把ssthresh设置为丢包事件前cwnd值的1/2
  • 

总结：TCP控制的FSM

TCP CUBIC

• 有比AIMD更好的“探测”可用带宽的方法？

• Insight/intuition：

  • Wmax：检测到丢包时的发送速率（拥塞窗口的长度）
  • 瓶颈链路的拥塞状态可能变化不大
  • 在丢包时进行速率减半之后，一开始先让发送速率迅速接近Wmax，接着再缓慢增大到Wmax
    

• K：假定无丢包情况下当TCP窗口长度将再次达到Wmax时的未来时间点

  • K是调整的

• 以当前时间t和K之间距离的立方为函数来增加拥塞窗口W

  • 当t远离K时，拥塞窗口长度的增加比较大
  • 当t原理K时，拥塞窗口长度的增加比较小（“谨慎”）

• TCP CUBIC是用于Linux操作系统的TCP默认版本；近些年普遍存在于流行的Web服务器中
  

TCP与拥塞的“瓶颈链路”

• TCP CUBIC增加发送速率直到某台路由器的输出链路（瓶颈链路）发生丢包
  
• 关注拥塞的瓶颈链路，有助于理解“拥塞”
  

TCP吞吐量

• 将TCP的平均吞吐量描述为关于拥塞窗口长度和RTT的函数
  • 忽略慢启动阶段，假设发送方总有数据要发送
• W：发生丢包事件时的拥塞窗口长度（字节为单位）

  • 平均窗口长度

  • 平均吞吐量：每个RTT吞吐

  • 

经高带宽路径的TCP

• 例子：1500字节报文段，100msRTT，想要取得10Gbps吞吐量
• 需要包含W = 83,333个报文段的平均拥塞窗口长度
• 吞吐量用丢包率L来表示【Mathis 1997】
  • 一条TCP连接的平均吞吐量 =
  • 为了达到10Gbps的吞吐量，需要的丢包率为（非常非常小的丢包率）
• 网络宽带增加，需要更新的TCP版本！

基于时延的TCP拥塞控制

• 保持端到端的管道“刚好充满，而不可以更满”：保持瓶颈链路忙于传输，但是避免高时延/缓存
  • 
• 基于时延的方法
  • RTTmin————在发送方测量到的最小RTT（不拥塞的路径）
  • 未拥塞吞吐量：cwnd/RTTmin（cwnd为拥塞窗口长度）
    
  • 不会导致丢包的拥塞控制
  • 在最大化吞吐量（“保持管道刚好充满...”）的同时，保持低时延（“...而不可以更满”）
  • 许多已部署的TCP都采用一种基于时延的拥塞控制方法
    • 例如，部署在谷歌内部骨干网络的BBR

明确拥塞报告（ECN）

• 网络辅助的拥塞控制
  • IP数据报首部的服务类型字段中的两个比特位被网络路由器标记，用于指示是否发生拥塞
  • 拥塞指示被传送到目的主机
  • 目的主机在其ACK报文段中设置ECE（明确拥塞通告回显）比特通知源主机中的TCP收到拥塞指示
  • 涉及到 IP (IP首部的ECN比特标记) 和 TCP (TCP首部的CWR、ECE比特标记)
    

TCP公平性

• 公平性目标：如果K条TCP连接分享一个链路带宽为R 的瓶颈链路，每条连接的平均传输速率接近R/K，即每一条连接都得到相同份额的链路带宽
  
• Q：TCP是公平的吗？
  • 例子：2条竞争的TCP连接
    • 加性增，斜率为1，吞吐量增加
    • 乘性减，吞吐量成比例减小
    • 
    • 
• 所有网络应用程序必须是公平的吗？
  • 公平性和UDP
    • 多媒体应用通常不使用TCP
      • 不希望应用发送数据的速率受拥塞控制的节制
    • 使用UDP：
      • 音视频应用发送数据的速率是恒定的，可容忍分组丢失
  • 公平性和并行TCP连接
    • 应用可以在2个主机之间打开多条并行的TCP连接
    • Web浏览器
    • 例如：带宽为R的链路支持了9个应用（每个应用使用1条TCP连接）
      • 如果新的应用要求建立1条TCP连接，则每条连接获得的带宽为R/10
      • 如果新的应用要求建立11条TCP连接，则这个新的应用获得的带宽将超过R/2