【运输层】TCP 的可靠传输是如何实现的？

本文链接：https://blog.youkuaiyun.com/swadian2008/article/details/137461751

TCP 的滑动窗口是以字节为单位的。

现假定 A 收到了 B 发来的确认报文段，其中窗口是 20 字节，而确认号是 31（这表明 B 期望收到的下一个字节序号是 31，而到序号 30 为止的数据已经收到了）。根据这两个数据，A 就构造出自己的发送窗口，如下图所示：//发送窗口

上图所示为 A 的发送窗口，发送窗口表示：在没有收到 B 的确认的情况下，A 可以连续把窗口内的数据都发送出去。凡是已经发送过的数据，在未收到确认之前都必须暂时保留，以便在超时重传时使用。

发送窗口里面的序号表示允许发送的序号。显然，窗口越大，发送方就可以在收到对方确认之前连续发送更多的数据，因而可能获得更高的传输效率。接收方会把自己的接收窗口数值放在窗口字段中发送给对方。因此，A 的发送窗口一定不能超过 B 的接收窗口数值。

发送窗口后沿的后面部分表示已发送且已收到了确认。这些数据显然不需要再保留了。而发送窗口前沿的前面部分表示不允许发送，因为接收方没有为这部分数据保留临时存放的缓存空间。//发送窗口的位置由窗口前沿和后沿的位置共同确定

现在假定 A 发送了序号为 31～41 的数据。这时，发送窗口位置并未改变，但发送窗口内靠后面有 11 个字节（灰色方框表示）表示已发送但未收到确认。而发送窗口内靠前面的 9 个字节（序号 42~50）是允许发送但尚未发送的。//发送窗口发送数据

再看一下 B 的接收窗口。设 B 的接收窗口大小是 20。在接收窗口外面，到序号为 30 的数据是已经发送过确认，并且已经交付主机了。因此在 B 可以不再保留这些数据。//接收窗口

接收窗口内的数据（序号31～50）是允许接收的。如上图所示，B 收到了序号为 32 和 33 的数据，但序号为 31 的数据没有收到（也许丢失了，也许滞留在网络中的某处）。请注意，B 只能对按序收到的数据中的最高序号给出确认，因此 B 发送的确认报文段中的确认号仍然是 31（即期望收到的序号）。

现在假定 B 收到了序号为 31 的数据，把序号为 31～33 的数据交付主机，删除这些数据。接着把接收窗口向前移动 3 个序号，如下图所示，同时给 A 发送确认，其中窗口值仍为 20，但确认号是 34。这表明 B 已经收到了到序号 33 为止的数据。//接收窗口接收数据

我们注意到，B 还收到了序号为 37，38 和 40 的数据，但这些数据都没有按序到达，只能先暂存在接收窗口中。A 收到 B 的确认后，就可以把发送窗口向前滑动 3 个序号，但指针 $P_{2_{}}$ 不动。可以看出，现在 A 的可用窗口增大了些，可发送的序号范围是 42～53。//窗口移动

A 在继续发送完序号 42～53 的数据后，指针 $P_{2}$ 向前移动和 $P_{3}$ 重合。