TCP可靠传输的实现

以字节为单位的滑动窗口

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

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

发送窗口里面的序号表示允许发送的序号，显然，窗口越大，发送方就可以在收到对方确认之前发送的数据就越多，因此就可以提高传输速率。前面讲过，接收方会把自己的接收窗口数值放在窗口字段中发送给对方。因此，A 的发送窗口一定不能超过 B 的接收窗口数值。在后面的我们将要讨论，发送方的发送窗口大小还要受到当时网络拥塞程度的制约。但在目前，我们暂不考虑网络拥塞的影响。

发送窗口后延部分表示已经已经发送且收到了确认。这些数据显然不在需要保留了，发送窗口前沿的部分表示不允许发送，因为接收方还没有为这部分数据提供缓存空间。

发送窗口的位置由窗口前沿和后延位置共同确定。发送窗口后沿的变化情况有两种可能，即不动（没有收到新的确认）和前移（收到了新的确认）。发送窗口后沿不可能向后移动，因为不能撤销掉已收到的确认。发送窗口前沿通常是不断向前移动，但也有可能不动。这对应于两种情况：一是没有收到新的确认，对方通知的窗口大小也不变；二是收到了新的确认但对方通知的窗口缩小了，使得发送窗口前沿正好不动。

发送窗口前沿也有可能向后收缩。这发生在对方通知的窗口缩小了。但 TCP 的标准强
烈不赞成这样做。因为很可能发送方在收到这个通知以前已经发送了窗口中的许多数据，现
在又要收缩窗口，不让发送这些数据，这样就会产生一些错误。
现在假定 A 发送了序号为 31 ～ 41 的数据。这时，发送窗口位置并未改变（图 5-16），
但发送窗口内靠后面有 11 个字节（灰色小方框表示）表示已发送但未收到确认。而发送窗
口内靠前面的9个字节（42～50）是允许发送但尚未发送的。

从以上所述可以看出，要描述一个发送窗口的状态需要三个指针：P1，P2和 P3（图 5-16)。指针都指向字节的序号。这三个指针指向的几个部分的意义如下：

• 小于 P1的是已发送并已收到确认的部分，而大于 P3的是不允许发送的部分。

• P3-P1=A的发送窗口

• P2-P1=已发送但尚未收到确认的字节数

• P3－P2= 允许发送但当前尚未发送的字节数（又称为可用窗口或有效窗口）、

再看一下B 的接收窗口。B 的接收窗口大小是 20。在接收窗口外面，到 30 号为止的数据是已经发送过确认，并且已经交付主机了。因此在 B 可以不再保留这些数据。接收窗口内的序号（31 ～ 50）是允许接收的。在图 5-16 中，B 收到了序号为 32 和 33 的数据。这些数据没有按序到达，因为序号为 31 的数据没有收到（也许丢失了，也许滞留在网络中的某处）。请注意，B只能对按序收到的数据中的最高序号给出确认，因此 B 发送的确认报文段中的确认号仍然是31（即期望收到的序号），而不能是32或33。
现在假定B收到了序号为31的数据，并把序号为31～33的数据交付主机，然后B删除这些数据。接着把接收窗口向前移动3个序号（图5-17），同时给A发送确认，其中窗口值仍为 20，但确认号是 34。这表明 B 已经收到了到序号 33 为止的数据。我们注意到，B还收到了序号为37,38和40的数据，但这些都没有按序到达，只能先暂存在接收窗口中。A 收到 B 的确认后，就可以把发送窗口向前滑动 3 个序号，但指针 P2不动。可以看出，现在 A 的可用窗口增大了，可发送的序号范围是 42～53。

A 在继续发送完序号 42 ~ 53 的数据后，指针 P2向前移动和 P3重合。发送窗口内的序号都已用完，但还没有再收到确认（图5-18）。由于A的发送窗口已满，可用窗口已减小到零，因此必须停止发送。请注意，存在下面这种可能性，就是发送窗口内所有的数据都已正确到达B，B也早已发出了确认。但不幸的是，所有这些确认都滞留在网络中。在没有收到B的确认时，A不能猜测：“或许B收到了吧！为了保证可靠传输，A只能认为B还没有收到这些数据。于是，A在经过一段时间后（由超时计时器控制）就重传这部分数据，重新设置超时计时器，直到收到 B 的确认为止。如果 A 收到确认号落在发送窗口内，那么 A 就可以使发送窗口继续向前滑动，并发送新的数据。

发送方的应用进程把字节流写入了TCP的发送缓存中，接收方的应用进程从TCP的接收缓存中读取字节流数据。下面我们就讨论窗口和缓存之间的关系.这里首先明确两点:

• 缓存空间和序号空间都是有限的，并且是循环使用的。
• 由于实际的缓存或窗口中的字节数是非常大的。图中只是说明一下情况。

我们首先查看一下图5-19（a）发送方的情况：

发送缓存用来暂时存放：

• 发送应用程序传给发送方TCP准备发送的数据。

• TCP已发出但尚未收到确认的数据。

发送窗口只是发送缓存的一部分，已被确认的数据应当从缓存中被删除。因此发送缓存和发送窗口的后延是重合的。发送应用程序最后写入发送缓存的字节减去最后被确认的字节，就是还保留在发送传中的被写入的字节数。发送应用进程必须控制写入缓存中的速度。不能太快，否则发送缓存就没有存放数据的空间。

再看一下图（b）接收方的情况。

接收缓存暂时用来存放：

• 按序到达，但尚未被应用进程接读取的数据。

• 为按序到达的数据。

如果收到的分组有差错，则要丢弃 。如果接收应用进程来不及读取收到的数据，接收缓存中就会被填满，使接收窗口减少到0。反之，如果接收应用程序接收到数据能够及时从接受缓存中读取到数据，接收窗口就可以增大，但最大就不能超过接收缓存的大小。图（b）还指出了下一个期待收到的字节号，这个字节号也是接收方给发送方的报文段中首部的确认号。

根据以上总结出：

• 虽然A的发送窗口是根据B接收窗口的大小而动态设置的，但是在同一时刻，A发送窗口和B的接受窗口并不是一样大的。这是因为通过网络传输需要经历一定的时间滞后（延迟），除此之外，发送方还要根据当时的网络环境要适当的调整自己的发送窗口。

• 对于不按序到达的数据（字节流），TCP标准并无明确规定，如果接收方把不按序的数据一律丢掉，那么接收窗口的管理就会简单很多，但是这回对网络资源的利用不利（因为发送方会不断的传送较多的数据）。因此TCP通常会把不按序到达的数据先临时放到接收窗口中，等到字节流中所缺少的字节接收到后，再按序交付上层的应用进程。

• TCP要求接收方必须有积累确认的功能，这样可以减少传输开销，接收方可以在合适的时候发送确认，也可以在自己有数据要发送时把确认信息捎带上。但是这里要注意：

  • 接收方不应该过分推迟发送确认，否则这样容易导致发送方不必要的重传，这样反而浪费了网络资源。TCP规定，确认推迟的时间不能超过0.5秒，若收到了一连串具有最大长度的报文，则必须每隔一个报文段就发送一个确认【RFC 1122】.

  • 二是捎带确认实际上并不是经常发生，因为大多数应用很少同时在两个方向上传输数据。

最后强调：TCP通信是全双工通信。通信中的每一方都在发送和接收报文段，因此，每一方都有自己的发送窗口和接收窗口。在谈到这些窗口的时候，一定要分清楚。