TCP协议详解四：超时与重传

1. 概述

• tcp提供可靠的运输层，使用的方法是确认机制。
• 但是数据和确认都有可能丢失
• tcp通过在发送时设置定时器解决这种问题
• 定时器时间到了还没收到确认，就重传该数据

2. tcp管理的定时器类型

• 重传定时器：等待收到确认
• 坚持定时器：使窗口大小信息保持不断流动
• 保活定时器：检测空闲连接崩溃或重启
• 2MSL定时器：检测time_wait状态

3. 超时重传机制

3.1 背景

• 接收端给发送端的Ack确认只会确认最后一个连续的包
• 比如发送1,2,3,4,5共五份数据，接收端收到1,2，于是回ack3，然后收到4（还没收到3），此时tcp不会跳过3直接确认4，否则发送端以为3也收到了。这时你能想到的方法是什么呢？tcp又是怎么处理的呢？

3.1 被动等待的超时重传策略

• 直观的方法是：接收方不做任何处理，等待发送方超时，然后重传。
  • 缺点：发送端不知道该重发3，还是重发3,4,5
• 如果发送方如果只发送3：节省宽度，但是慢
• 如果发送方如果发送3,4,5：快，但是浪费宽带
• 总之，都在被动等待超时，超时可能很长。所以tcp不采用此方法

3.2 主动的快速重传机制

3.2.1 概述

• 名称为：Fast Retransmit
• 不以实际驱动，而以数据驱动重传

3.2.2 实现原理

• 如果包没有送达，就一直ack最后那个可能被丢的包
• 发送方连续收到3相同的ack，就重传。不用等待超时
  

  

• 图中发生1,2,3,4,5数据
• 数据1到达，发生ack2
• 数据2因为某些原因没有送到
• 后续收到3的时候，接收端并不是ack4，也不是等待。而是主动ack2
• 收到4,5同理，一直主动ack2
• 客户端收到三次ack2，就重传2
• 2收到后，结合之前收到的3,4,5，直接ack6

3.2.3 快速重传的利弊

• 解决了被动等待timeout的问题
• 无法解决重传之前的一个，还是所有的问题。
• 上面的例子中是重传2，还是重传2,3,4,5。因为并不清楚ack2是谁传回来的

3.3 SACK方法

3.3.1 概述

• 为了解决快速重传的缺点，一种更好的SACK重传策略被提出
• 基于快速重传，同时在tcp头里加了一个SACK的东西
• 解决了什么问题：客户端应该发送哪些超时包的问题

3.3.2 实现原理

• SACK记录一个数值范围，表示哪些数据收到了
• linux2.4后默认打开该功能，之前版本需要配置tcp-sack参数
• SACK只是一种辅助的方式，发送方不能完全依赖SACK。主要还是依赖ACK和timout

3.3.3 Duplicate SACK(D-SACK)

• 使用SACK标识的范围，还可以知道告知发送方，有哪些数据被重复接收了
• 可以让发送方知道：是发出去的包丢了，还是回来的ack包丢了

4. 超时时间的确定

4.1 背景

• 路由器和网络流量均会变化
• 所以超时时间肯定不能设置为一个固定值
• 超时长：重发慢，效率低，性能差
• 超时短：并没有丢就重发，导致网络拥塞，导致更多超时和更多重发
• tcp会追踪这些变化，并相应的动态改变超时时间（RTO）

4.2 如何动态改变

• 每次重传的时间间隔为上次的一倍，直到最大间隔为64s，称为“指数退避”
• 首次重传到最后放弃重传的时间间隔一般为9min
• 依赖以往的往返时间计算（RTT）动态的计算

4.3 往返时间（RTT）的计算方法

• 并不是简单的ack时间和发送时间的差值。因为有重传，网络阻塞等各种变化的因素。
• 而是通过采样多次数值，然后做估算
• tcp使用的方法有：
  • 被平滑的RTT估计器
  • 被平滑的均值偏差估计器

4.4. 重传时间的具体计算

• 计算往返时间（RTT），保存测量结果
• 通过测量结果维护一个被平滑的RTT估计器和被平滑的均值偏差估计器
• 根据这两个估计器计算下一次重传时间

5. 超时重传引发的问题-拥塞

5.1 为什么重传会引发拥塞

• 当网络延迟突然增加时，tcp会重传数据
• 但是过多的重传会导致网络负担加重，从而导致更大的延时和丢包，进入恶性循环
• 也就是tcp的拥塞问题

5.2 解决拥塞-拥塞控制的算法

• 慢启动：降低分组进入网络的传输速率
• 拥塞避免：处理丢失分组的算法
• 快速重传
• 快速恢复