连续ARQ协议
停止等待协议已经可以满足可靠传输了，但有一个致命缺点：效率太低。发送方发送一个数据包之后便进入等待，这个期间并没有干任何事，浪费了资源。解决的方法是：连续发送数据包。模型如下：和停止等待最大的不同就是，他会源源不断地发送，接收方源源不断收到数据之后，逐一进行确认回复。这样便极大地提高了效率。但同样，带来了一些额外的问题:发送是否可以无限发送直到把缓冲区所有数据发送完？不可以。因为需要考虑接收方缓冲区以及读取数据的能力。如果发送太快导致接收方无法接受，那么只是会频繁进行重传，浪费了网络资源。所以发送方发送数据的范围，需要考虑到接收方缓冲区的情况。这就是TCP的流量控制 。解决方法是：滑动窗口 。基本模型如下：
- 发送方需要根据接收方的缓冲区大小，设置自己的可发送窗口大小，处于窗口内的数据表示可发送，之外的数据不可发送。
- 当窗口内的数据接收到确认回复时，整个窗口会往前移动，直到发送完成所有的数据
在TCP的首部有一个窗口大小字段，他表示接收方的剩余缓冲区大小，让发送方可以调整自己的发送窗口大小。通过滑动窗口，就可以实现TCP的流量控制，不至于发送太快，导致太多的数据丢失。连续ARQ带来的第二个问题是：网络中充斥着和发送数据包一样数据量的确认回复报文，因为每一个发送数据包，必须得有一个确认回复。提高网络效率的方法是：累积确认 。接收方不需要逐个进行回复，而是累积到一定量的数据包之后，告诉发送方，在此数据包之前的数据全都收到。例如，收到 1234，接收方只需要告诉发送方我收到4了，那么发送方就知道1234都收到了。第三个问题是：如何处理丢包情况。在停止等待协议中很简单，直接一个超时重传就解决了。但，连续ARQ中不太一样。例如：接收方收到了 123 567，六个字节，编号为4的字节丢失了。按照累积确认的思路，只能发送3的确认回复，567都必须丢掉，因为发送方会进行重传。这就是GBN（go-back-n) 思路。但是我们会发现，只需要重传4即可，这样不是很浪费资源，所以就有了：选择确认SACK 。在TCP报文的选项字段，可以设置已经收到的报文段，每一个报文段需要两个边界来进行确定。这样发送方，就可以根据这个选项字段只重传丢失的数据了。
可靠传输小结
到这里关于TCP的可靠传输原理就已经介绍的差不多。最后进行一个小结：
- 通过连续ARQ协议与发送-确认回复模式来保证每一个数据包都到达接收方
- 通过给字节编号的方法，来标记每一个数据是属于重传还是新的数据
- 通过超时重传的方式，来解决数据包在网络中丢失的问题
- 通过累积确认+选择确认的方法来提高确认回复与重传的效率
