计算机网络之TCP的窗口滑动

TCP可靠传输的实现----以字节为单位的滑动窗口

一 、

 

 

 

数据传输在一个方向进行

 

 

主机A发送数据，主机B给出确认。

 

 

每一个小格子代表一个字节，小格子中的数字就是该字节的编号。

 

二、

 

 

 

 

主机B给主机A发送一个确认报文段，

在报文段的首段中的窗口字段值为20，相当于主机B表明自己接收窗口的尺寸为20字节，

确认号字段值为31，表明主机B希望收到的下一个数据的序号是31，而序号30为止的数据已经收到了

 

 

 

 

 主机A收到该确认报文段后，根据这两个字段的值，可以构造出自己的发送窗口。

 

 

 

 

三、

 

 

 

 

 

假定网络不存在拥塞问题，也就是主机A在构造自己的发送窗口时，仅仅考虑主机B的接收窗口，而不考虑拥塞窗口。

 

主机B告诉主机A，自己的接收窗口是20，所以，主机A构造的发送窗口尺寸也设置为20。

 

主机A在没有收到主机B的确认的情况下，可以连续把发送窗口的数据都发送出去。

 

 

凡是已经发送过的数据，在未收到确认之前，都必须暂时保留，以便在超时重传时使用。

 

 

发送窗口后沿不可能向后移动，因为不可能撤销掉已收到的确认。

 

 

发送窗口前沿可以向后收缩，但TCP的标准强烈不建议这样做，

发送方很可能在收到这个通知之前，就已经发送了窗口中的许多数据，现在又要收缩窗口，不让发送这些数据，显然就会产生错误。

 

四、

 

 

 

 

假定主机A发送了31-41的数据。

此时发送窗口的位置并没有改变，

发送窗口内，序号为31-41的数据已经发送，但未收到确认。

序号为42到50的数据是允许发送但尚未发送的。

如何描述发送窗口的状态？

 

 

 

 

五、

 

 

 

 

 

 

 

 

假设主机A发送的31-41数据中的32，33数据到达了主机B，由于它们的序号落在接收窗口内，所以主机B接收它们。

 

将它们存入缓存。

 

但它们是未按序到达的数据，因为序号为31的数据还没有到达，有可能是丢了，有可能是滞留在网络中的某处。

 

主机B只能对按序收到的数据中的最高序号给出确认，因此，主机B发送的确认报文段中的确认号仍然是31，

期望收到序号为31的数据，而不能是32或33。

 

 

 

 

 

假定主机B收到了序号为31的数据，并把序号为31到33的数据交付给应用进程。

 

之后主机B就可以删除这些数据，并将接收窗口向前移动三个序号，给主机A发送确认报文段。

 

 

六、

 

 

 

 

窗口字段的值，仍然为20，表明接收窗口的尺寸没有改变

确认号字段的值为34，表明主机B已经收到了序号33为止的数据。

 

七、

 

 

 

 

 

 

 

 

假设主机B发送的序号为34的确认报文还在传递过程中，此时主机B收到了之前主机A发送的31-41数据中的37,38,40号数据.

它们的序号都在接收窗口内，但是它们都是未按序到达的，只能暂存在接收缓存中，

 

八、

 

 

 

假设主机B发送的序号为34的确认报文到达了主机A，主机A收到后，就可以将发送窗口向前滑动三个序号

发送窗口的尺寸保持不变，仍为20。

这样就有新序号51-53落入发送窗口中，而序号31-33移出了发送窗口，序号31-33的数据可以删除了，因为已经收到了主机B针对它们的确认，表明主机B已经收到它们了，主机A没有必要再保留它们。

 

九、

 

 

 

 

主机A继续发送42-53的数据，现在，发送窗口的序号已经用完了。

 

 

 

 

 

主机A在未收到主机B发来确认的情况下，不能再发送新的数据。

 

 

 

发送窗口的数据如果迟迟收不到来自主机B的确认，则会产生超时重传。

 

十、补充说明

 

l  虽然发送方的发送窗口是根据接收方的接收窗口设置的，但在同一时刻,发送方的发送窗口并不总是和接收方的接收窗口一样大。

            原因如下

          （1）网络传送窗口值需要经历一定的时间滞后，并且这个时间还是不确定的。

 

          （2）发送方还可能根据网络当时的拥塞情况适当减小自己的发送窗口尺寸。

 

l  对于不按序到达的数据应如何处理，TCP并无明确规定。

 

         （1）如果接收方把不按序到达的数据一律丢弃，那么接收窗口的管理将会比较简单，但这样做对网络资源的利用不利，因为发送方会重复传送

较多的数据。

   （2）TCP通常对不按序到达的数据是先临时存放在接收窗口中，等到字节流中所缺少的字节收到后，再按序交付上层的应用进程。

 

 

l  TCP要求接收方必须有累积确认和捎带确认机制，这样可以减小传输开销。接收方可以在合适的时候发送确认，也可以在自己有

数据要发送时把确认信息顺便捎带上。

          （1）接收方不应过分推迟发送确认，否则会导致发送方不必要的超时重传，这反而浪费了网络的资源。

TCP标准规定，确认推迟的时间不应超过0.5秒。若收到一连串具有最大长度的报文段，则必须每隔一个报文段就发送一个确认[RFC 1122]。

    （2）捎带确认实际上并不经常发生，因为大多数应用程序很少同时在两个方向上发送数据。

 

l  TCP的通信是全双工通信。通信中的每一方都在发送和接收报文段。 因此，每一方都有自己的发送窗口和接收窗口。在谈到这些

窗口时，一定要弄清楚是哪一方的窗口。

 

 这是我的笔记整理，视频地址https://www.youtube.com/watch?v=0_xo-Aaahtg&t=604s

 

欢迎大家关注我的微信公众号，获取你不知道的宝藏。