目录
一、TCP 可靠数据传输机制
- TCP 在 IP 不可靠服务之上创建 rdt 服务
- 流水线技术处理报文段
- 累积确认
- TCP 使用单个重发定时器
- 触发重发：超时事件或 3 次重复确认
3 次重复确认是相对于 GBN 和 SR 新增的机制。
1. 发送方的事件
1）sender 从应用程序接收数据
① 用序号 NextSeqNum 创造一个新的报文段
② 如果没有启动定时器，则启动定时器
- 定时器是最早没有被确认的报文发送时启动的
- 设置超时间隔：TimeOutInterval
2）超时
- 重发导致超时的报文
- 重新启动定时器
3）收到确认
① 当 ACK>sendbase 时，
- 确认对应的报文段并滑动窗口
- 如果还有未确认的报文，则重新启动定时器
② 当 ACK=sendbase 时，
不做任何操作：“目前” 只有在超时时才会重传该报文段。
2. TCP 的重复确认
由上图可知，在上一次窗口移动时，发送方必定收到了来自接收方的 ack=1，即接收方确认收到了 1 号字节之前的所有字节，并且期望下一个收到的是 seq=1 的报文段。
假设 seq=1 丢失了，但 receiver 收到了 seq=2、seq=3、seq=4、seq=6 。
当 TCP 接收方收到一个具有这样序号的报文段时，即其序号大于下一个所期望的、按序的报文段，它检测到了数据流中的一个间隔，这就是说有报文段丢失。这个间隔可能是由于在网络中报文段丢失或重新排序造成的。
因为 TCP 不使用否定确认，所以接收方不能向发送方发回一个显式的否定确认。相反，它只是对已经接收到的最后一个按序字节数据进行重复确认（即产生一个冗余 ACK）即可。
由上图可知，即使接收方接收到了 seq=2、seq=3、seq=4、seq=6，它也不会移动窗口，因为它期待的是 seq=1 。此外，接收方还会在接收 seq=2、seq=3、seq=4、seq=6 的同时一直反馈 ack=1 。
当 seq=1 重传成功时，接收方将能移动窗口：
随后，当 seq=9 反馈的 ack=10 到达发送方时，发送方将能移动窗口：
小结：
- ack=sendbase 时，往往是当前窗口中序号最大的报文段丢失了
- ack>sendbase 时，往往是正常的确认信息，并且采用的是累积确认
3. TCP 的重发场景
1）丢失 ACK 的情况
sendbase!=92：由于在 seq=92 超时前主机 A 没有再发送任何报文段，因此 seq=92 应该是窗口中唯一未被发送的报文段。
2）过早的超时设置
seq=92 重传成功，反馈 ack=120，由于 ack 的值没有大于 sendbase 的值，因此 sendbase 的值保持不变。
3）累积 ACK 的情况
seq=100 接收成功，反馈 ack=120，表明 120 字节之前的字节全部被接收成功，因此 sendbase 放心地修改为 120 。
4）丢失报文段的情况
seq=100 接收成功，但反馈 ack=92，表明 seq=92 丢失了，主机 B 期待接收 seq=92 。seq=92 重传成功，反馈 ack=120。由于 TCP 采用累积确认，因此 sendbase 的值直接修改为 120 。
二、TCP 采用快速重传
超时触发重传存在问题：超时间隔往往太长。
- 重传丢失报文段需要等待很长时间，从而增加了网络的时延。
解决方法：在超时之前，发送方可以通过重复的 ACK 来检测丢失的报文段。
- 发送方常常一个接一个地发送很多报文段
- 如果报文段丢失，则发送方将会接收到很多重复的 ACKs
- 如果发送方收到 3 次重复确认，则发送方认为该报文段已经丢失
3 次重复确认 = 对同一报文段的 4 个确认信息
启动快速重传：在定时器超时之前重发丢失的报文段。
三、产生 TCP ACK 的建议
