上面的图表是从发送方的角度拍摄的快照。我们可以将数据分为4组:
第3类也称为可用窗口,因为这是发送方可以使用的窗口。
发送窗口包括黄色和绿色部分。这些字节要么已经被发送,要么可以被发送。
1*OqqxQKu4ZGasXzIlUZ9lyw.png
可用窗口在发送方发送了21-25字节并使用了可用窗口中的所有字节时可能为空。发送窗口保持不变。
1*JdTCgvYpVPRDcLyVb8Rwsg.png
当发送方接收到16-19字节的确认时,发送窗口向右滑动4个字节。队列中的接下来的字节会有一个更新的可用窗口。
1*9zFu_scvenahSK6m-khSjw.png
一些定义可以帮助我们更好地理解本文后面的复杂情况:
1*IYBc3_OiPWAZ7JCvIaktkA.png
基于这些定义,我们可以用以下公式表示可用窗口的大小。
1*SbgJAvyVKyXYvPLuoBbGtA.png
接收窗口分为3个类别:
第2类被称为接收窗口,也可以称为RCV.WND。
与发送窗口类似,有一个指针RCV.NXT,表示接收窗口的第一个字节。
1*u3KoxvVK-rrM1g4gX6fbZQ.png
接收窗口并非静态。如果服务器运行得高效,接收窗口可以扩展。否则,它可能会缩小。
接收方通过在TCP段头中的窗口字段中指示大小来传达其接收窗口。当发送方收到它时,这个窗口大小就成为了可用窗口。
发送和接收段需要时间。因此,接收窗口在特定时刻不等于可用窗口。
让我们模拟一次请求和响应,以更好地理解滑动窗口的工作原理。
有两个修改简化了我们的计算。
1*sAF4A2TyNeItzw2yK0xI9g.png
上面是一个显示了10个步骤示例的图表。
客户端请求一个资源,服务器以三个段响应它:
每一方都可以同时是发送方和接收方。
我们假设客户端的发送窗口(SND.WND)为300字节,接收窗口(RCV.WND)为150字节。因此,服务器的SND.WND为150字节,RCV.WND为300字节。
1*cU9TEaEoezDwvw__3G1DFw.png
这是客户端的起始状态。
我们假设它之前已经从服务器接收了300字节,因此RCV.NXT指向301。
由于它还没有发送任何内容,SND.UNA和SND.NXT都指向1。
1*IYBc3_OiPWAZ7JCvIaktkA.png
根据这个公式,客户端的可用窗口大小是1 + 300 - 1 = 300。
1*kfa6ZdhSR_VJggJ2abUSAQ.png
这是服务器的起始状态,反映了另一侧的状态。
因为它已经发送了300字节,SND.UNA和SND.NXT都指向301。
由于客户端还没有发送任何请求,RCV.NXT指向1。
服务器的可用窗口是301 + 150 - 301 = 150。
现在,第1步开始了。
客户端发送了第一个100字节的请求。在这一刻,窗口发生了变化。
可用窗口变为1 + 300 - 101 = 200。
1*ug0laVIMWQ3HGG-kPjZ0KA.png
在第2步,我们关注了服务器。
可用窗口变为301 + 150 - 351 = 100。
1*GAZqLwbVGj2yqUnm5DyI4w.png
移动到客户端。
可用窗口变为101 + 300 - 101 = 300。
1*50UitYxS9XW3N4XV2Z7tOg.png
再次移动到服务器的一端。
可用窗口是100字节。服务器可以发送80字节的段。
可用窗口变为301 + 150 - 431 = 20。
1*soNJeyvqRj0zqDDrtBL9Fg.png
客户端接收了文件的第一部分并立即发送了ACK。
可用窗口保持在300。
1*QJKwuY3HvslR9601ZRWCxA.png
此时,服务器在发送第2步时接收到ACK时。
1*thuJ7lCYqreqxsL8nMz_ag.png
在第4步中,服务器发送了文件的第一个80字节部分,并再次收到了ACK确认。
可用窗口的计算变为431 + 150 - 431 = 150。
1*8sS5S0OkW0I2Vbp40nkkZQ.png
在第8步,服务器发送了文件的第二部分,共100字节。
可用窗口的计算变为431 + 150 - 531 = 50。
1*qXP9BCX80vPpkplc5utP6Q.png
接下来,轮到客户端。
可用窗口保持不变。
1*LkQ7tG-_1XQROjOZ3vTC9g.png
最后,服务器接收了前一个响应的ACK。
可用窗口的计算变为531 + 150 - 531 = 150。
在之前,我们假设发送窗口和接收窗口保持不变。但在实际情况中,这个假设是不正确的,因为两个窗口中的字节存在于操作系统缓冲区中,而缓冲区中的可用空间可以调整。当我们的应用程序无法快速读取缓冲区中的字节时,可用空间会减小。
让我们看看窗口发生变化的情况,以及它如何影响可用窗口。
1*qyjkUdkAdsfrkRkqVlPClw.png
为了简化,本例重点关注客户端的可用窗口。在这个示例中,客户端始终是发送方,服务器是接收方。
1*u3KoxvVK-rrM1g4gX6fbZQ.png
当服务器发送ACK时,它还包括了更新后的窗口大小。
1*pkiC_TWGpIZF3aSPOz6lcA.png
一开始,客户端发送了一个150字节的请求。
1*zs4VuHChJJ-7vWFmXyr8Ug.png
当服务器接收请求时,应用程序读取了前50字节,剩下的100字节仍然在缓冲区中,从接收窗口中占用了100字节的可用空间。因此,接收窗口缩小到了200字节。
接下来,服务器发送了一个带有更新后的200字节接收窗口的ACK。
1*SZDl6q22CB6kzY3P-CCHFA.png
客户端接收ACK并将其发送窗口大小更新为200。
此时,可用窗口与发送窗口相同,因为所有150字节都已得到确认。
1*6gKYyaDUdOQSEGfHh6SWdA.png
再次,客户端发送了另一个200字节的请求,使用了可用窗口中的所有可用空间。
1*uJiRzHmdV4kT8lPW62bz0g.png
在服务器接收了这200字节之后,应用程序仍然运行缓慢,总共只读取了70字节,将280字节留在缓冲区中。这导致接收窗口再次缩小,现在只剩下20字节。
在ACK消息中,服务器与客户端分享了更新后的窗口大小。
1*xnUjR-R45hPoGO7qhvCHKg.png
再次,客户端在收到ACK后将其发送窗口更新为20字节,可用窗口也变为20字节。
在这种情况下,如果没有更多来自服务器的消息,客户端将停止发送大于20字节的请求,直到在后续消息中收到另一个窗口更新。
那么,如果没有更多消息来自服务器,我们会被困在20字节的可用窗口吗?
不会。为了避免这种情况,客户端的TCP定期检测窗口大小。
一旦释放更多的空间,
可用窗口就会扩大,可以发送更多的数据。