查看原文
其他

滑动窗口协议这样理解更简单

The following article is from 飞天小牛肉 Author 小牛肉

点击关注公众号,一周多次包邮送书

作者小牛肉

来源:飞天小牛肉(ID:CS-Wiki)


引言

想象一下这个场景:主机 A 一直向主机 B 发送数据,不考虑主机 B 的接收能力,则可能导致主机 B 的接收缓冲区满了而无法再接收数据,从而导致大量的数据丢包,引发重传机制。而在重传的过程中,若主机 B 的接收缓冲区情况仍未好转,则会将大量的时间浪费在重传数据上,降低传送数据的效率。

所以引入了流量控制机制,主机 B 通过告诉主机 A 自己接收缓冲区的大小,来使主机 A 控制发送的数据量。总结来说:所谓流量控制就是控制发送方发送速率,保证接收方来得及接收

TCP 实现流量控制主要就是通过 滑动窗口协议

对于发送方来说,窗口大小就是指无需等待确认应答,可以连续发送数据的最大值。


窗口大小具体由谁来设定呢?

窗口大小和 TCP 报文首部中 16 位的 窗口大小 Window 字段有关:

TCP 报文段首部

该字段的含义是指自己接收缓冲区的剩余大小,于是发送端就可以根据这个接收端的处理能力来发送数据,而不会导致接收端处理不过来。

所以,通常来说窗口大小是由接收方来决定的

滑动窗口详解

说了半天,窗口其实就是操作系统开辟的一个缓冲区

发送方在收到确认应答报文之前,必须在缓冲区中保留已发送的报文段(因为报文段可能在网络中丢失,所以必须把这些未确认的报文段保留这,以便必要时重传);如果在规定时间间隔内收到接收方发来的确认应答报文,就可以将这些报文段从缓冲区中清除。

站在发送方的角度,滑动窗口可以分为四个部分:

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

第 2 和第 3 部分加起来就刚好就是接收方窗口(缓冲区)大小,它规定了当前发送方能发送的最大数据量。

当发送方收到接收方发来的确认应答后,就将缓冲区中那些被确认的报文清除出去,然后窗口向右移动,如下图所示:

随着双方通信的进行,窗口将不断向右移动,因此被形象地称为滑动窗口(Sliding Window)


对于 TCP 的接收方,窗口稍微简单点,分为三个部分:

  1. 已接收
  2. 未接收准备接收 (也即接收窗口,再强调一遍,接收窗口的大小决定发送窗口的大小,或者说,决定缓冲区的大小。)
  3. 未接收并未准备接收

由于 ACK 直接由 TCP 协议栈回复,默认无应用延迟,不存在 “已接收未回复 ACK”


综上,举个例子,假设发送方需要发送的数据总长度为 400 字节,分成 4 个报文段,每个报文段长度是 100 字节:

1)三次握手连接建立时接收方告诉发送方,我的接收窗口大小(rwnd) 是 300 字节

此时的接收方滑动窗口如下:

接收方滑动窗口

此时的发送方滑动窗口如下:

发送方滑动窗口

2)发送方发送第一个报文段(序号 1 - 100),还能再发送 200 个字节

3)发送方发送第二个报文段(序号 101 - 200),还能再发送 100 个字节

4)发送方发送第三个报文段(序号 201 - 300),还能再发送 0 个字节

此时,发送方的窗口(缓冲区)中存了三个报文段了

此时的发送方滑动窗口如下:

发送方滑动窗口

5)接收方接收到了第一个报文段和第三个报文段,中间第二个报文段丢失。此时接收方返回一个报文段 ack = 101, rwnd = 200(假设这里发生流量控制,把窗口大小降到了 200,允许发送方继续发送起始序号为 101,长度为 200 的报文)

此时的接收方滑动窗口如下(本来窗口右端应该右移,但是这里发生了流量控制,接收方希望缩小窗口大小,所以正好,这里就不需要向右扩展了):

接收方滑动窗口

发送方收到了第一个报文段的确认,从窗口(缓冲区)中移除掉第一个报文段

此时的发送方滑动窗口如下:

发送方滑动窗口

6)发送方一直没有收到第二个报文段的确认应答,在等待超时后重传第二个报文段(序号 101 - 200)

7)接收方成功收到第二个报文段(缓冲区中有第二个和第三个报文段了),于是向发送方返回一个报文段 ack = 301, rwnd = 100(假设这里发生流量控制,把窗口大小降到了 100)

此时的接收方滑动窗口如下:(本来窗口右端应该右移,但是这里发生了流量控制,接收方希望缩小窗口大小,所以正好,这里就不需要向右扩展了)

接收方滑动窗口

发送方收到了第二个和第三个报文段的确认,从窗口(缓冲区)中移除掉这俩报文段

8)发送方发送第四个报文段(序号 301 - 400)

此时的发送方滑动窗口如下:

发送方滑动窗口

通俗的例子

下面来更通俗地解释下滑动窗口,看下面这个场景,老师说一段话,学生来记

最原始的模式,一股脑把所有的报文段全都发出去。

老师说 "危楼高百尺,手可摘星辰,不敢高声语,恐惊天上人"(咱把每个字看成一个报文段,总共 20 个报文段)

学生写道"危楼高百尺,手可......."

上面的模式过于简单粗暴,发送方发送速度太快,接收方跟不上,并且重传成本过高。

于是他们换了一种模式:每发送一个报文段就等待确认一个报文段,收到确认后才能发送下一个

老师说 "危",学生说"确认"

老师说 "楼",学生说"确认"

老师说 "高",学生说"高"

.........

上面的模式每发一个报文段,必须等到确认后才能再次发送,效率低下。

于是他们又换了一种模式:累积确认,既不是一股脑把所有的报文段全都发出去,也不是一次只发一个报文段,而是分组发送,每次发几个报文段。

老师说 "危楼高百尺" (5 个报文段),学生说 "确认"

老师说 "手可摘星辰",学生说 "手可..."(3 个报文段丢失)

老师说 "不敢高声语",学生说 "确认"

老师一直没有收到 "摘星辰" 的确认,于是重新说了一遍 "摘星辰",学生说 "确认"

老师说 "恐惊天上人",学生说 "确认"

上面的模式提高了效率,连续多个报文段一起进行发送, 但是到底该怎么决定多少个报文段一起发送呢呢?

于是他们在上面模式的基础上,做出了一些改进:滑动窗口,接收方认为状态好(窗口比较大)的时候, 让发送方每次多发一点;接收方认为状态不好(窗口比较小)的时候,让发送方每次少发送一点,起到一个流量控制的作用,限制发送方的速度。

学生告诉老师,我一次性可以接收 10 个报文段

老师说 "危楼高百尺,手可摘星辰",学生说 "危楼高百尺,手可..."(3 个报文段丢失,返回 ”可" 的确认应答,一共确认了 7 个报文段,老师的可用窗口右移,窗口中现在还有 “摘星辰” 3 个报文段)

学生说,我状态不行,一次性现在只能接收 5 个报文段(流量控制,缩小窗口)

老师说 "不敢"(窗口中还有 “摘星辰” 3 个报文段,所以只能发送 2 个),学生说 "确认"

老师一直没有收到 "摘星辰" 的确认,于是重新说了一遍,学生说 "确认"

(可用窗口恢复为 5 个)老师说 "恐惊天上人",......

·················END·················

推荐阅读

• Python的可等待对象在Asyncio的作用• 阿里终面:为什么应用刚启动的时候比较卡,过一会就好了?• 如何优雅的关闭服务?• 聊聊高可用的 11 个关键技巧• 如何在编码阶段减少代码中的bug?• 写好 JavaScript 异步代码的几个推荐做法• Python 的 import 是怎么工作的?

👇更多内容请点击👇

您可能也对以下帖子感兴趣

文章有问题?点此查看未经处理的缓存