TCP拥塞
TCP拥塞控制机制
端到端的拥塞控制机制
- 路由器不向主机有关拥塞的反馈信息
- 路由器的负担较轻
- 符合网络核心简单的TCP/IP架构原则
- 端系统根据自身得到的信息，判断是否发生拥塞，从而采取动作
拥塞控制的几个问题
- 如何检测拥塞
- 轻微拥塞
- 拥塞
- 控制策略
- 在拥塞发送时如何动作，降低速率
- 轻微拥塞，如何降低
- 拥塞时，如何降低
- 在拥塞缓解时如何动作，增加速率
- 在拥塞发送时如何动作，降低速率
TCP拥塞感知
发送端如何探测到拥塞
- 某个段超时了（丢失事件 ）：拥塞
- 超时时间到，某个段的确认没有来
- 原因1：网络拥塞（某个路由器缓冲区没空间了，被丢弃）概率大
- 原因2：出错被丢弃了（各级错误，没有通过校验，被丢弃）概率小
- 一旦超时，就认为拥塞了，有一定误判，但是总体控制方向是对的
- 有关某个段的3次重复ACK：轻微拥塞
- 段的第1个ack，正常，确认绿段，期待红段
- 段的第2个重复ack，意味着红段的后一段收到了，蓝段乱序到达
- 段的第2、3、4个ack重复，意味着红段的后第2、3、4个段收到了 ，橙段乱序到达，同时红段丢失的可能性很大（后面3个段都到了， 红段都没到）
- 网络这时还能够进行一定程度的传输，拥塞但情况要比上面好
TCP速率控制方法
如何控制发送端发送的速率
- 维持一个拥塞窗口的值(主要手段) ：CongWin （表示发送方往网络中的注入字节数）
- 发送端限制 已发送但是未确认 的数据量（的上限）: LastByteSent - LastByteAcked ≤ CongWin
- 从而粗略地控制发送方的往网络中注入的速率
- CongWin是动态的，是感知到的网络拥塞程度的函数
- 超时或者3个重复ack，CongWin下降
- 超时时：CongWin降为1MSS，进入SS阶段然后再倍增到 CongWin(原) / 2（每个RTT），从而进入CA阶段
- 3个重复ack ：CongWin降为CongWin/2,CA阶段
- 否则（正常收到Ack，没有发送以上情况）：CongWin跃跃欲试上升（这是为了满足“在不发生拥塞的情况下提高吞吐率”的目的）
- 超时或者3个重复ack，CongWin下降
TCP拥塞控制和流量控制的联合动作
联合控制的方法
- 发送端控制发送但是未确认的量同时也不能超过接收窗口，满足流量控制要求
- SendWin = min { CongWin , RecvWin }
- 同时满足 拥塞控制和流量控制要求
TCP慢启动
- 连接刚建立, CongWin = 1 MSS
- 如: MSS = 1460bytes & RTT = 200 msec
- 初始速率 = 58.4kbps
- 可用带宽可能 >> MSS/RTT
- 应该尽快加速，到达希望的速率
- 当连接开始时，指数性增加发送速率，直到发生丢失的事件
- 启动初值很低
- 但是速度很快
- 当连接开始时，指数性增 加（每个RTT）发送速率 直到发生丢失事件
- 每一个RTT， CongWin加倍
- 每收到一个ACK时， CongWin加1（相当于每个RTT，CongWin加倍）
- 慢启动阶段：只要不超时或 3个重复ack，一个RTT， CongWin加倍
- 总结:
- 初始速率很慢，但是加速却是指数性的
- 指数增加，SS时间很短，长期来看可以忽略
AIMD
- 乘性减: 丢失事件后将CongWin降为1(ss阶段通常可忽略，故相当于直接减少到 CongWin/2 )，将CongWin/2作为阈值，进入慢启动阶段（倍增直到 CongWin/2）
- 加性增： 当 CongWin >阈值时，一个 RTT 如没有发生丢失事件，将 CongWin 加1MSS : 探测（也就是主键添加，探测是否到达阈值）
改进
- Q：什么时候应该将指数性增长变成线性？
- A：在超时之前，当CongWin变成上次发生超时的窗口的一半
实现:
- 变量：Threshold
- 出现丢失（超时或者3个ACK），Threshold设置成CongWin的1/2
总结：TCP拥塞控制
- 当CongWin＜Threshold, 发送端处于慢启动阶段（ slow-start）, 窗口指数性增长.
- 当CongWin > Threshold, 发送端处于拥塞避免阶段 （congestion-avoidance）, 窗口线性增长.
- 当收到三个重复的ACKs (triple duplicate ACK), Threshold设置成 CongWin/2， CongWin=Threshold+3.
- 当超时事件发生时timeout, Threshold=CongWin/2 CongWin=1 MSS，进入SS阶段
TCP发送端拥塞控制
| 事件 | 状态 | TCP发送端行为 | 解释 |
|---|---|---|---|
| 以前没有收到ACK的data，被ACKed | 慢启动(SS) | CongWin = CongWin + MSS,If (CongWin > Threshold)，状态变成“CA” | 每一个RTT CongWin 加倍 |
| 以前没有收到ACK的data，被ACKed 拥塞避免(CA) | CongWin = CongWin+MSS * (MSS/CongWin) | 线性增加, 每一个RTT对CongWin 加一个1 MSS | |
| 通过收到3个重复的ACK，发现丢失的事件 | SS or CA | Threshold = CongWin/2, CongWin = Threshold+3, 状态变成“CA” | 快速重传, 实现乘性的减，CongWin 没有变成1MSS. |
| 超时 | SS or CA | Threshold = CongWin/2,CongWin = 1 MSS,状态变成“SS” | 进入slow start |
| 重复的ACK | SS or CA | 对被ACKed 的segment， 增加重复ACK的计数 | CongWin and Threshold不变 |
TCP拥塞控制FSM
TCP吞吐量
TCP的平均吞吐量是多少，使用窗口window尺寸W和RTT来 描述?
(忽略慢启动阶段，假设发送端总有数据传输)
- W：发生丢失事件时的窗口尺寸（单位：字节）
- 平均窗口尺寸（#in-flight字节）：3/4W
- 平均吞吐量：一个RTT时间吞吐3/4W， avg TCP thruput = 3/4 * (W/RTT) bytes/sec
由下图所示，w/2→w所需要的时间是2RTT
因此 T = (w/2 + w) / (2*RTT) = 3w/4RTT
TCP 公平性
公平性目标: 如果 K个TCP会话分享一个链路带宽为R的 瓶颈，每一个会话的有效带宽为 R/K
2个竞争的TCP会话:
公平性和 UDP
- 多媒体应用通常不是用 TCP
- 应用发送的数据速率希望 不受拥塞控制的节制
- 使用UDP:
- 音视频应用泵出数据的速率是恒定的, 忽略数据的丢失
也就是UDP会抢占TCP的资源
- 音视频应用泵出数据的速率是恒定的, 忽略数据的丢失
公平性和并行TCP连接
- 2个主机间可以打开多个并行的TCP连接
- 例如: 带宽为R的链路支持了 9个连接;
- 如果新的应用要求建1个TCP连接,获得带宽R/10
- 如果新的应用要求建11个TCP连接,获得带宽R/2
