TCP的滑动窗口机制，谈谈其设计演化过程( 二 ) _TCP

增加了消息标识和发送限制之后，可以认为是PAR机制的一个增强版。
对于数据的传输，现在可以提供可靠性、效率和基本的数据流控了。

文章插图

TCP面向流的滑动窗口确认在增加了消息标识和发送限制之后，整个消息的发送和确认过程，已经较为完善了。
但从传输的"数据"的角度来看，前面我们讲的，其实都是面向消息的。也就是说，发送和确认都是以消息为单位。
而实际上，TCP是面向字节流的，本身并没有消息的概念。TCP传输的数据，我们通常称之为报文段。具体如何识别并组装为一条完整的消息，是应用层的工作。
正因为如此，TCP是以字节为单位来处理数据流的。如果要对TCP传输的数据做标识，那就需要一个字节给一个标识。
这样一来，TCP每次就只能发送一个字节的数据，然后每次也只能确认一个字节的数据，这显然是不合理的。既浪费带宽，又降低了发送效率。
TCP的设计者确实也没有这么做，而是将数据划分为一个个数据段，每次可以发送一段数据。
对于每一段数据，使用一个序号来进行标识。每次确认数据的时候，也是确认一段数据而不是一个字节。
事实上，序号是报文段中数据字节的偏移量，表示数据字节的位置。
TCP缓冲区设想一个场景，主机A和主机B建立了一个新的连接：

主机A有一个很大的数据字节流需要传输，但是主机B没有办法全部接收；
所以主机B限制主机A报文段能够传输的字节数大小，直到已发送的字节被确认；
主机B允许主机A发送更多的字节。

所以，每台主机都需要跟踪哪些字节已经发送了，哪些字节还没有发送，哪些已经确认了。这个流程，和前面以消息为单位的发送限制机制很类似。
为此，TCP引入了缓冲区的概念，将发送方的缓冲区，划分为四个部分。
发送方的缓冲区

文章插图

如图所示，发送方的缓冲区，被划分为四个部分，具体说明如下。
第一部分：已发送，并且已确认的字节（Bytes Sent And Acknowledged）
对应于图中的 Category #1 部分，从第1到第31个字节，共31字节。
第二部分：已发送，但尚未确认的字节（Bytes Sent But Not Yet Acknowledged）
对应于图中的 Category #2 部分，从第32到第45个字节，共14字节。
第三部分：尚未发送，但可以立即发送的字节（Bytes Not Yet Sent For Which Recipient Is Ready）
对应于图中的 Category #3 部分，从第46到第51个字节，共6字节。
这部分，代表发送方当前还可以发送的字节数，也是接收方当前还可以接收的字节数。
第四部分：尚未发送，并且还不能发送的字节（Bytes Not Yet Sent For Which Recipient Is Not Ready）
对应于图中的 Category #4 部分，从第52到第95个字节，共44字节。
这部分字节，已经超出了接收方可以接收的最大窗口大小，因此暂不能发送。
发送窗口（Send Window）黑色方框部分，表示发送窗口（Send Window），通常也简单的称为窗口。
发送窗口由两部分组成，对应于发送缓冲区的第二部分（Category #2，灰色方框内）和第三部分（Category #3，红色方框内）。
如图所示，发送窗口大小为20字节，第二、三部分分别为14字节和6字节。
窗口的左边缘为窗口的第1个字节（第32字节），右边缘为窗口的最后一个字节（第51字节）。
窗口的左边缘位置，决定了窗口的右边缘位置。左边缘是第一和第二部分的分界线，右边缘是第三和第四部分的分界线。
发送窗口的大小，决定了发送方可以同时发送的字节数，即未被接收方确认的字节数。
可用窗口（Usable Window）可用窗口（Usable Window），对应于缓冲区的第三部分（Category #3），即发送方当前仍可以发送的字节数。
发送消息之后窗口的变化如果在可用窗口内，发送了一些数据，将会改变发送窗口的位置，以及各部分的大小。
在上面的例子中，发送方的可用窗口为6字节。如果发送方将6个字节的数据发送出去，那么这6个字节将会变成未确认状态，合并到第二部分。
第二部分的范围变为，从第32到第51个字节，共20个字节。
而可用窗口，即窗口的第三部分，将变为0 。这通常被称为零窗口（Zero Window）。