滑动窗口，TCP的流量控制机制

TCP 协议与包括 UDP 在内的其他传输层协议的主要差别在于：数据传输质量 。UDP 协议将数据发送出去之后就不管了，但 TCP 还会对已发送的数据进行跟踪，以防丢失。这样就有效地实现了 TCP 协议的两个关键特性：

可靠性（ reliability ），保证数据可靠送到目的地（如有丢失，必须能够检测出来，并重传）；
流量控制（ flow control ），控制数据发送速度，以免冲垮接收方；

为实现这两个设计目标，TCP 协议引入了所谓的 滑动窗口（ sliding window ）机制。理解滑动窗口机制，是掌握 TCP 协议的关键，也是学习其他 TCP 知识的前提。本节带领大家将滑动窗口机制一举拿下！

UDP局限性

UDP 数据包完全依赖 IP 包进行网际传输，可以看作是加上端口号的 IP 包而已。因此，UDP 协议的传输质量完全取决于 IP 包。由于 IP 协议只是一种“尽力而为”的网络协议，不能保证可靠性，因而 UDP 也是不可靠的。

由于网络链路问题，IP 包在传输的过程中随时可能丢包，承载在其上的 UDP 包也肯定会丢。如上图，发送方通过 UDP 协议给接收方发送 4 个数据报，其中承载数据③的 IP 包丢失了，但双方均不知情。

一个数据报发送出去后，可能会到达目的地，也可能不会。由于发送方无法从接收方那得到任何反馈，因而无法保证可靠性，流量控制就更别提了。因此，我们需要在 IP 协议之上，引入额外的机制，来处理丢包问题。

确认机制

由于 IP 协议缺乏反馈机制，为保证可靠性，TCP 协议规定：当接收方收到一个数据后，必须回复 ACK 给发送方。这样发送方就能得到反馈，如果数据发出去后很长时间都没有收到 ACK 确认，说明数据很有可能已经丢失了。

一旦数据在传输过程中丢失，发送方必须重传。因此，TCP 每次发送数据后，都会启动一个定时器。如果定时器超时还没收到对方确认，TCP 就会重新发送数据。我们来看一个例子：

图中左边是发送方待发送字节流状态，字节流中每个字节都有一个序号，假设从零开始。数据颜色代表发送状态：

灰色，表示已经发出去而且收到对方确认的数据；
蓝色，表示已经发出去但还未收到确认的数据；
绿色，表示还未发送的数据（包括未来要发但此刻还不存在的数据）；

刚开始时，发送方已经成功发送了前 5 个字节，如灰色部分所示。随后它开始发送数据①，其实序号为 5 ，总共 5 个字节。再啰嗦一句，起始序号 5 保存在 TCP 报文段中的序号字段；而数据长度 5 无须保存，TCP 可以根据 IP 包数据长度和 TCP 头部长度来计算。

发送方在发送数据的同时，启动了一个计时器。这些数据虽然已经发送出去了，但还没收到对方确认，因而处于蓝色状态。随后它收到接收方发来的确认，状态转为灰色，万事大吉！注意到，确认号是最后一个字节加一，也就是下一个数据的起始序号。

紧接着，发送方又发出了数据②，首字节序号为 10 ，总共 4 个字节。这次比较背，数据②在传输过程中丢失了！发送方等到计时器超时都没收到确认，因此它将数据重新发送一次，并再次启动计时器。

这时，数据②仍维持蓝色不变，因为发送方还没收到确认。等数据成功送达对方，并收到对方的确认后，数据转成灰色状态。待发送字节流颜色不断交替，滚滚向前。

接收缓冲区

由于承载 TCP 报文段的 IP 包是独立路由的，可能走不同的网络路径，无法保证一定按照发送顺序送达目标主机。 TCP 协议需要向上提供连续字节流传输服务，如果报文段错序到达，TCP 必须根据序号重新排列数据。

另一方面，数据到达后目标主机后，接收方应用程序可能忙于其他事情，无法及时处理。鉴于这两个点，TCP 接收方需要在内存中准备一个接收缓冲区，用于临时保存数据。

当 TCP 报文段到达后，数据先临时保存在缓冲区中，位置由序号决定。当相邻的数据均达到后，组成连续字节流提交给应用程序。当应用程序将数据取走后，缓冲区中的副本就可以删除。如果应用程序忙于其他任务，数据则继续缓存在缓冲区中。

TCP 协议一般由操作系统内核实现，应用程序只需通过系统调用发送/接收数据，完全不用关心序号或 ACK 。 TCP 数据到达后，内核先将其保存于接收缓冲区，再通知应用程序读取。

我们来看一个新例子，这次站在接收方的角度，考察数据流在接收缓冲区中的状态：

刚开始时，接收方缓冲区已接收了 5 字节数据，但应用程序尚未读取；
发送方又发来 5 字节数据，接收方回复 ACK ，数据保存在缓冲区，应用程序仍未读取；
与此同时，接收方通告窗口大小为 5 字节，表示自己还能接收 5 字节数据（超过缓冲区就会溢出）；
应用程序将缓冲区中的 10 字节数据全部读取，接收方通告新窗口大小为 15 字节；
发送方又前后发来两份数据，分别是数据②和数据③，大小均为 4 字节；
其中，数据②在网络中丢失了；
数据③顺利到达，接收方根据序号将其保存在缓冲区中，并回复 ACK ，确认号和窗口均不变；
由于数据②尚未到达，未能组成连续数据提交给应用程序；
因长时间没收到 ACK ，发送方重传数据②（数据③也被重传，因为 ACK 只确认 10 以前的数据）；
数据②顺利到达，接收方将其保存在缓冲区中，并回复 ACK （注意确认号，数据③也一并确认了）；
数据②和数据③组成连续数据，可以提交给应用程序读取；

综上所述，接收缓冲区主要起到两个关键作用：

应用进程繁忙时暂存数据；
数据乱序到达时重排数据；

流量控制

接收缓冲区大小是有限的，如果应用进程处理缓慢，发送方还拼命发送，最终肯定会压垮接收方。因此，当缓冲区有变化时，接收方应该通过 窗口大小 字段，将它的剩余大小告知发送方。

接收方通告的窗口大小通常称为 通告窗口（ advertised window ），可缩写为 awnd 。它起到约束发送方发送速度的作用：

如果接收方应用进程繁忙，迟迟未读取缓冲区里的数据，那么窗口大小将慢慢变小；
当窗口大小降为零，发送方就停止发送新数据；

通过通告窗口，发送方可以实时感知接收方缓冲区的状态，然后根据缓冲区剩余空间动态调整发送速度，这就是 TCP 的 流量控制（ flow control ）机制。

滑动窗口

重新站在发送方的角度，来考察数据的发送状态，可以分为四种：

已发送且已确认，这部分已经发送完毕，可以忽略；
已发送但未确认，这部分可能在网络中丢失，数据必须保留以便必要时重传；
未发送但可发送，这部分接收方缓冲区还有空间保存，可以发出去；
未发送且暂不可发送，这部分已超出接收方缓冲区存储空间，就算发出去也没意义；

注意到，第②和第③部分加起来就刚好是接收方缓冲区大小，如图红框部分。红框的左边缘由接收方的最后一个 ACK 确认决定，而长度由接收方通告的窗口大小决定，它规定了当前发送方能发送的最大数据量。

当发送方收到对方的 ACK ，意味着有数据已成功到达接收方，窗口左边缘将向右移动：

当接收方应用进程将数据从缓冲区取出后，向接收方通告新的窗口大小，这时窗口右边缘向右扩张：

随着双方通信的进行，由 已发送但未确认 以及 未发送但可发送 这两部分数据组成的窗口将不断向右移动，因此被形象地称为 滑动窗口（ sliding window ），TCP 流量控制机制也因此被称为滑动窗口机制。

延迟确认

TCP 协议规定，接收方收到数据后，必须发送 ACK 进行确认，以此实现可靠传输。然而，就算是一个小小的 ACK 确认，也需要一个完整 TCP 分组报文来承载，开销很大！

众所周知，最小的 TCP 分组包含 20 字节的 TCP 头部和 20 字节的 IP 头部，总共 40 字节。试想发送一个 40 字节的 TCP 报文，仅仅只为了告诉发送方 4 字节的确认号，效率得有多低！有效信息才占 10% ！

为了提高传输效率，TCP 实现了 延迟确认（ delayed ACK ）机制。延迟确认顾名思义就是收到数据不立马确认，而是等上一段时间，跟其他数据一起发送。我们来看几个例子：

第一个例子，发送方连续发来 4 个数据，原本需要发送 4 个 ACK 确认。启用延迟确认后，第一个 ACK 都稍作延迟跟后一个 ACK 一起合并发送。这样一来，每两个数据发送一个确认，效率提高一倍！

第二个例子，发送方发来 1 个数据，但是 TCP 没有立马发送 ACK 确认（灰色）。后来，接收方也要发送数据了， ACK 确认被捎带在数据分组里面进行回复。ACK 确认和数据一起拼车，省掉一个分组报文（灰色）。

你可能有疑问，如果收到数据后，短时间没有其他数据要发送，怎么办？其实很简单，请看第三个例子：TCP 收到数据后会启动一个定时器，定时器超时后就立马发送 ACK 确认（绿色）。

总结

TCP 双方实现接收确认机制，保证数据可靠传输；
接收方引入缓冲区实现数据重排，以及在应用进程繁忙时暂存数据；
接收方通过窗口大小字段实时通告缓冲区剩余空间；
发送方根据接收方通告的窗口大小，控制发送速度，以免冲垮接收方；
由最新 ACK 和通告窗口大小划定的数据区域称为 通告窗口 ，发送方据此实现 流量控制 ；