TCP拥塞控制
- TCP使用端到端拥塞控制，因为IP层不向端系统提供显式的网络拥塞反馈。
- TCP令每一个发送方根据所感知到的网络拥塞程度来限制其能向连接发送流量的速率。
问题在于：
- TCP发送方如何限制它向连接发送流量的速率？
- TCP发送方如何感知它和目的地间的网络拥塞？
- 当TCP发送方感知到网络拥塞时，采用何种算法来改变发送速率？
TCP发送方如何限制它向连接发送流量的速率
拥塞窗口(congestion window)
- 发送方TCP的拥塞控制机制维护的一个状态变量。
- 它对TCP发送方能向网络中发送流量的速率进行了限制。
- 发送方中已发送且未被确认的数据量不会超过拥塞窗口（事实上，不会超过拥塞窗口和接受窗口的最小值）
TCP发送方如何感知它和目的地间的网络拥塞情况
- 丢包事件 超时事件或收到接收方的三个冗余ACK（一个初始ACK和其后的三个冗余ACK）
- 三个冗余ACK 是轻度拥塞的表征
- 超时事件 是重度拥塞的表征
- 发送方将丢包事件作为网络拥塞的指示。
- 发送方将对已发送分组的确认ACK作为网络畅通的指示。
- 潜在地，发送方还能通过RTT的变化来感知网络拥塞情况。
TCP发送方如何确定合适的发送速率
- 丢包事件指示拥塞，此时TCP发送方应降低发送速率
- 确认报文指示网络畅通，拥塞窗口应当增大。确认到达的速率大，拥塞窗口的增量也应大。
- 带宽探测。TCP在认为网络畅通时，逐步增加速率，在认为网络拥塞时，回退速率，并在稍后继续增加速率以探测拥塞开始速率是否发生了变化
TCP拥塞控制算法
- TCP拥塞控制算法包括强制的慢启动和拥塞避免机制，以及推荐的快速恢复机制。
慢启动
指数增
TCP连接开始时，拥塞窗口的初值通常置为一个MSS，即最大报文段（有效载荷）长度。
故初始发送速率约为MSS/RTT，其值往往远小于可用带宽，TCP希望快速找到可用带宽数量。
在慢启动状态，拥塞控制窗口从一个MSS开始且每当传输的报文段被确认就增加一个MSS。
在慢启动阶段的一个周期(RTT)，发送i个报文（拥塞控制窗口为
），并收到i个确认，从而将拥塞控制窗口增加到
。故慢启动阶段发送速率以指数增长。
何时结束慢启动阶段？
- 拥塞控制窗口达到或超过慢启动阈值。
这意味着继续指数增加发送速率很可能会导致拥塞。结束慢启动并进入拥塞避免模式。 - 检测到3个冗余ACK。
这意味着网络的轻度拥塞。
执行快速重传并进入快速恢复状态。 - 发生超时事件。
这意味着网络的重度拥塞。
重置拥塞控制窗口，并将慢启动阈值置为原拥塞控制窗口的一半。重新开始慢启动阶段。
云服务快速响应——前端服务器&TCP分岔
- 内容提供商希望快速响应用户请求，而慢启动机制下服务器可能需要较长时间处理用户的小请求报文。
- 典型地，从客户端系统发起TCP到数据中心服务器的响应全部到达，需要4*RTT（建立TCP1个RTT，交付响应3个RTT），当客户端系统距离服务器较远时，时延较大。
解决方案
- 内容提供商部署CDN服务网络，部署邻近用户的前端服务器。
- 客户连接前端服务器时TCP慢启动，拥塞窗口小但是由于该服务器邻近用户，RTT小故速度快,耗时
。
- 不同客户的请求到达前端服务器后由TCP分岔技术，通过一条大窗口TCP连接向数据中心传递数据，耗时
。
- 总响应时间变为
，其中
可忽略，故总时间约为一个RTT。
拥塞避免
加性增
TCP进入拥塞避免状态意味着此时的拥塞窗口大约是上次发生拥塞时窗口值的一半，故不可像在慢启动阶段那样激进地在每个RTT将拥塞窗口翻番，而应采取保守策略，即在每个RTT只将拥塞窗口增加一个MSS。
具体方法通常是，对每个新的报文段确认，将拥塞窗口增加（MSS/原拥塞窗口值）byte。从而在一个往返周期内，拥塞窗口可增加一个MSS。
故在拥塞避免阶段，拥塞窗口线性增长。
何时结束拥塞避免状态？
- 三个冗余的ACK。
这意味着网络的轻度拥塞。
将拥塞窗口值置为当前值的一半，将慢启动阈值置为原拥塞窗口值的一半。进入快速恢复阶段。 - 出现超时事件。
这意味着网络的重度拥塞。
拥塞窗口重置为一个MSS，慢启动阈值置为当前拥塞窗口值的一半，进入慢启动状态。
快速恢复
对于引起TCP进入快速恢复状态的缺失报文段，对收到的每个冗余ACK，拥塞窗口递增一个MSS。
当对缺失报文段的一个ACK到达时，TCP减小拥塞窗口并进入拥塞避免状态。
若出现超时事件，拥塞窗口重置为一个MSS，慢启动阈值置为当前拥塞窗口值的一半，进入慢启动状态。
早期TCP版本 Tahoe 在超时或3个冗余ACK后都进入慢启动阶段
较新的TCP版本 Reno 综合了快速恢复机制
拥塞控制回顾
忽略慢启动阶段，TCP是加性增，乘性减的，拥塞窗口-时间图呈锯齿状。
TCP 有多种拥塞控制算法， linux允许管理员配置拥塞控制的版本。
Vegas算法
通过RTT，在分组发生丢失之前，检测网络拥塞状况。
当检测到分组将要丢失时，线性地降低发生速率
TCP吞吐量（速率）
- 假定TCP链接长期存活，且RTT，拥塞控制窗口峰值W（发生丢包时的值）恒定。
- 从而，速率在W/2RTT和W/RTT间震荡。有平均吞吐量为0.75W/RTT
高带宽路径下的TCP
链接平均吞吐量 =
公平性
理想地，TCP趋于在竞争的多条TCP连接间提供对一段瓶颈链路带宽的平等分享。这是TCP拥塞控制机制的属性。
实践中，TCP连接通常能获得非常不平等的链路带宽份额。
当多条连接共享一个瓶颈链路时，具有较小RTT的连接能够在链路空闲时更快地抢到可用带宽，获得更高吞吐量。UDP UDP没有拥塞控制机制，不会扼制流量，从TCP视角看这是不公平的
并行TCP 同一应用通过使用多条并行连接，可用占用较大比例的带宽份额。
