TCP可靠传输

先前介绍的可靠性传输原理假想每个已经发送但是还没有收到确认的分段一个独立的计时器，但是因为这种方法会导致时间管理的开销非常大，只是存在于理论之中。即使有多个已经传输但是还没有收到确认的报文段，TCP也只用一个超时重传定时器。

下面通过描述不同的场景逐步介绍TCP的可靠性传输机制。为了方便讨论，假想数据从主机A向主机B传输一个大文件。

下图伪代码描述了TCP发送方关于数据传输和重传的三个事件：

• 从上层收到数据，发送方从上层收到数据，将数据分成各个报文段，每个报文段序号如何定义，参考TCP序列号和确认号
• 定时器超时，tcp通过重发响应超时事件，然后重启定时器。重发具有最小序列号且仍未应答的的报文段。
• 收到ACK，当接收方的ACK到达时，tcp将ACK的值y与Sendbase比较，sendbase是最早没有被确认的报文段的序号。tcp采用累积确认，所以y确认里字节编号在y之前的所有字节已经收到。如果y > sendbase，则该ACK是在确认一个或多个先前未被确认的报文段。因此发送方更新sendbase变量。

上图简单的描述TCP如何使用超时重传实现可靠性传输，但是存在许多缺陷。

缺陷场景一：主机A发送报文段给主机B，假设主机A等来自主机B的确认序号100。尽管主机B收到主机A的报文段，但是主机B的确认序号丢掉。此时发生超时，主机A重发同样的报文段。主机B收到同样序列号的报文段2词，就会丢掉主机A重传的报文段。

场景二：主机A连着发送两个报文段，第一序号为92，8个字节数据；第二个序号为100，20个字节数据。假设所有的报文段完成的到达主机B，B分别回复了确认序号。假设在超时之前两个确认序号都没收到，主机A超时重传序号为92的报文段并重启定时器，只要第二个报文段的确认序号在第二次超时之前到达，那么第二个报文段就不会被重传。

场景三：场景二的拓展，第一个报文段的ACK丢了，但是在定时器超时之前，主机A收到了确认号120，因为TCP是累积确认，那么主机A知道主机B已经收到序号120之前所有的字节。

快速重传

超时重传有一个问题就是，如果超时的时间周期过长，一旦发生丢包，发送方重传的时间变长会导致端对端的延时，造成网络性能降低。解决这一问题的方法就是，发送方可以在超时事件发生之前通过注意**冗余ACK(duplicate ACK)**较好的检测到丢包情况。冗余ACK就是再次确认某个报文段的ACK，而发送方先前已经收到对该报文段的确认。根据[RFC5681]总结的生成ACK的策略可知导致冗余ACK的原因。

当接收方收到比期望序号大的失序报文时，检测到数据流中存在间隔，说明有报文段丢失，因此接收方对已经收到的最后一个按序字节数进行重复确认(冗余ACK)。如果tcp发送方连续收到3个冗余ACK，就认为已被确认3次的报文段之后的报文段已经丢失。一旦收到3个冗余ACK，tcp就执行快速重传。