TCP- 自动重传协议(rdt1.0、rdt2.0、rdt3.0）、流水线

可靠： 1. 传输数据的bit不会收到损坏或者丢失，而且所有数据都是按照其发送顺序进行交付。
TCP是在不可靠的IP的端到端网络之上实现的可靠数据传输协议。

构造可靠数据传输协议

rdt1.0 假设信道可靠

就是单纯的发送和接受

rdt2.0 假设信道可能出现比特差错，但是信道不会丢包

rdt2.0 停止-等待协议。
肯定确认和否定确定：使得接收方可以让发送方知道哪些内容被正确接受，哪些内容接受有误并因此需要重复。
在计算机网络环境中，基于这样重传机制的可靠数据传输协议被称为 自动重传请求（Automatic Repeat reQuest,ARQ）协议。
ARQ协议需要三种协议功能来处理存在比特差错的情况：

差错检测：检验和(2B
接收方反馈：1bit, 1: ACK 0: NAK
重传：接收方收到有差错的分组时，发送方将重传该分组文。

rdt2.0的致命缺陷：没有考虑到ACK或NAK分组受损的可能性。
考虑处理受损ACK和NAK的三种可能性：

考虑人会怎么解决。如果ACK和NAK坏了，那么人都不知道这个是啥意思，好像就不是很好解决。
增加足够的检验和bit，使得发送方不仅可以检测差错，还可以恢复差错。
当发送方收到含糊不清的ACK和NAK分组时，只需重传当前数据分组即可。 =>这种方法在发送方到接收方的信道中引入了 冗余分组。
冗余分组的根本困难在于接收方不知道它上次所发送的ACK或NAK是否被正确的接收到。
为了解决冗余分组的问题： 是在数据分组中添加一个新的字段，让发送方对其数据分组编号，即将发送数据分组的序号(sequence number)放在该字段。

rdt2.1 增加了sequence

发送方：感觉很相似，就是多了一个sequence代表0或者1，然后会有相应的两组状态。

接收方：也是一个接受0，一个接受1，成功之后变成另外一个状态

rdt3.0 信道上不光可能出现bit出错，也可能丢包

rdt3.0 比特交替协议
rdt2.2已经使用的技术：使用检验和、序号、ACK分组和重传。这里解决丢包问题是让发送方负责监测和恢复丢包工作。
假设发送方传输一个数据分组，该分组丢失或者接收方对该分组的ACK发送了丢失。在这两种情况下，发送方都收不到应当到来的接收方的响应。
如果发送方愿意等待足够长的时间以便确定分组已经丢失，则它只需要重传该数据分组即可。
实践中对于等待时间采取的方法是：发送方明智地选择一个时间值，以判定可能发送了丢包。
如果在这个时间内没有收到ACK，则重传该分组。那么之前的分组可能会晚到，这样也会引入冗余分组的概念。
发送方不知道是数据分组丢失、ACK丢失、或者只是该分组或者ACK延时到达。动作都是：重传。
为了实现基于时间的重传机制，需要一个 倒计数计时期，在一个给定的时间过期后，可中断发送方。
发送方需要能做到：

每次发送一个分组时，便启动一个定时器
响应定时器中断
终止定时器

流水线可靠数据传输协议

rdt3.0的问题是：是一个停等协议
特殊的性能问题的一个简单解决方法是：不以停等方式运行，运行发送方发送多个分组而无须等待。
流水等待协议造成了一些影响：
1.必须增加序号范围，因为每个输送中的分组，必须有一个唯一的序号，而且也许有多个在输送中的未确认报文。
2.协议的发送方和接收方两端也许不得不缓存多个分组。发送方最低限度应当能缓冲哪些已发送但是没有确认的分组。接收方也许需要缓存那些已正确接受的分组。
3.所需序号范围和对缓冲的要求取决于数据传输协议如何处理丢失、损坏及延时过大的分组。

解决流水线的差错恢复有两种基本的方法：回退N步(GBN)和选择重传(SR)

总结一下：

自动重传协议是一种停止等待协议、信道利用率低。
rdt1.0假设信道是可靠的，就是单纯的发送和接收数据报
rdt2.0假设信道不会丢包，但是会出现bit差错，那么要保证可靠性，引入了：
1. ACK和NAK用于表示接受是否正确
2. 检验和用于表示发送过程是否出现问题
3. 重传机制，检验和错了
  缺陷：没有考虑到ACK报文发生错误的情况，解决方法：
4. 加更多的检验和字段，妄图去恢复
5. 收到的这个ACK不是我要求的，那么我就去重传它，带来了冗余问题
  解决冗余问题-> 增加sequence字段，代表接受的是不是上一个我发送的，还是重复发送的
  rdt3.0假设信道可能出现丢包、也可能出现bit差错，为了保证可靠性，引入了：
6. 计时器->只要在限定的时间内，没有收到我要的ACK包，那么我就去重传这个数据报。
  那么需要做到：
7. 每一个分组都有一个计时器
8. 能够响应计时器的中断
9. 终止计时器
为了解决信道率利用低的问题：引入了流水线可靠协议。
不以停等方式去运行，发送方可以发送很多个数据报而无须等待。
也带来了一些问题：
1. 序号范围
2. 发送方和接收方需要去维护缓存
3. 序号范围与缓存大小取决于数据传输协议。
  为了解决流水线可靠协议带来的问题（差错），一般有两种处理方式：1 GBN（回退N步）， 2 SR（选择重传）