1.停止等待协议

要实现可靠传输，最简便的方法就是：我发送一个数据包给你，然后你向我回复收到，我再继续发送下一个数据包。传输模型如下：

停止等待协议

这种一来一去的方式就是停止等待协议（stop-and-wait）。上文说到，TCP 首部的 ACK 字段为 1 时，表示这个报文是一个确认收到报文。

2.丢包

如果当前网络环境不可靠，就会导致数据包丢失。解决这个问题的方法是：超时重传。当一个数据包发出去后，发送端就开始计时，如果时间到了还没有收到确认回复，就可以认为是发生了丢包，此时发送端就再次发送此数据，也就是重传。

但重传会导致另一个问题：如果原先的数据包并没有丢失，只是在网络中待得比较久，这时接收方就会收到两份一样的数据。解决这个问题的方法就是：给数据包编号，接收方根据数据包的编号来判断这份数据是否已经收到过。

在 TCP 首部有两个字段：序号和确认号，他们表示发送方数据第一个字节的编号，和接收方期待的下一份数据的第一个字节的编号。前面讲到 TCP 是面向字节流的，但是他并不是一个字节一个字节的发送，而是一次截取一整段。截取的长度受多种因素影响，如缓存区的大小、数据链路层限制的帧大小等等。

3.连续 ARQ 协议

停止等待协议可以满足可靠传输了，但效率太低。发送方发送数据包之后就一直等待，等待的这段时间什么事也没做，浪费了资源。解决的办法是：连续发送数据包。这被称之为连续 ARQ（Automatic Repeat reQuest）。模型如下：

连续 ARQ

3.1.滑动窗口

连续 ARQ 带来了三个问题，第一个问题是：考虑到接收方缓冲区及读取数据的能力，所以发送方不能无限发送。如果发送太快导致接收方无法接受，就会频繁触发重传，浪费网络资源。所以发送方发送数据的范围需要考虑接收方缓冲区的情况。这就是 TCP 的流量控制。解决方法是：滑动窗口。模型如下：

滑动窗口

发送方需要根据接收方的缓冲区大小，设置自己的可发送窗口大小，处于窗口内的数据表示可发送，之外的数据不可发送。
当窗口内的数据接收到确认回复时，整个窗口会向前移动，直到发送完所有的数据。

在 TCP 首部有一个窗口大小字段，他表示接收方的剩余缓冲区大小，让发送方可以调整自己的窗口大小。通过滑动窗口，就可以实现 TCP 的流量控制，不至于发送太快，导致太多的数据丢失。

3.2.累积确认

连续 ARQ 带来的第二个问题是：网络中充斥着和发送数据包一样数据量的确认回复报文，因为每一个发送数据包，都有一个确认回复。提高网络效率的办法是：累积确认。接收方不需要逐个回复，而是累积到一定量的数据包之后，告诉发送方，在此数据包之前的数据都收到了。例如，收到 1234，接收方只需要告诉发送方我收到 4 了，那么发送方就知道 1234 都收到了。

3.3.选择确认 SACK

连续 ARQ 带来的第三个问题是：如何处理丢包。在停止等待协议中，用超时重传就解决了丢包，但连续 ARQ 中，还需要指定哪些数据包需要重传。

例如：接收方收到了 123 567 六个字节，编号为 4 的字节丢失了，按照累积确认的思路，只能发送 3 的确认回复，567 都必须丢掉，因为发送方会重传 567。这就是 GBN（go-back-n）的思路。但我们发现，这时只需要重传 4 即可，所以就有了：选择确认 SACK（Selective Acknowledgment）。在 TCP 报文的选项字段，可以设置已经收到的报文段，每一个报文段需要两个边界来进行确定。这样发送方就可以根据这个选项字段只重传丢失的数据了。