码迷,mamicode.com
首页 > 其他好文 > 详细

TCP流量控制

时间:2020-06-07 11:04:22      阅读:114      评论:0      收藏:0      [点我收藏+]

标签:连接   例子   nbsp   状态   读取   递增   说明   过程   cap   

TCP 为了防止发送方无脑的发送数据,导致接收方缓冲区被填满,所以就有了滑动窗口的机制,它可利用接收方的接收窗口来控制发送方要发送的数据量,也就是流量控制。

接收窗口是由接收方指定的值,存储在 TCP 头部中,它可以告诉发送方自己的 TCP 缓冲空间区大小,这个缓冲区是给应用程序读取数据的空间:

  • 如果应用程序读取了缓冲区的数据,那么缓冲空间区的就会把被读取的数据移除
  • 如果应用程序没有读取数据,则数据会一直滞留在缓冲区。

接收窗口的大小,是在 TCP 三次握手中协商好的,后续数据传输时,接收方发送确认应答 ACK 报文时,会携带当前的接收窗口的大小,以此来告知发送方。

假设接收方接收到数据后,应用层能很快的从缓冲区里读取数据,那么窗口大小会一直保持不变,过程如下:

技术图片

理想状态下的窗口变化

但是现实中服务器会出现繁忙的情况,当应用程序读取速度慢,那么缓存空间会慢慢被占满,于是为了保证发送方发送的数据不会超过缓冲区大小,则服务器会调整窗口大小的值,接着通过 ACK 报文通知给对方,告知现在的接收窗口大小,从而控制发送方发送的数据大小。

技术图片

服务端繁忙状态下的窗口变化

零窗口通知与窗口探测

假设接收方处理数据的速度跟不上接收数据的速度,缓存就会被占满,从而导致接收窗口为 0,当发送方接收到零窗口通知时,就会停止发送数据。

如下图,可以接收方的窗口大小在不断的收缩至 0:

技术图片

窗口大小在收缩

接着,发送方会定时发送窗口大小探测报文,以便及时知道接收方窗口大小的变化。

以下图 Wireshark 分析图作为例子说明:

技术图片

零窗口 与 窗口探测

  • 发送方发送了数据包 1 给接收方,接收方收到后,由于缓冲区被占满,回了个零窗口通知;
  • 发送方收到零窗口通知后,就不再发送数据了,直到过了 3.4 秒后,发送了一个 TCP Keep-Alive 报文,也就是窗口大小探测报文;
  • 当接收方收到窗口探测报文后,就立马回一个窗口通知,但是窗口大小还是 0;
  • 发送方发现窗口还是 0,于是继续等待了 6.8(翻倍) 秒后,又发送了窗口探测报文,接收方依然还是回了窗口为 0 的通知;
  • 发送方发现窗口还是 0,于是继续等待了 13.5(翻倍) 秒后,又发送了窗口探测报文,接收方依然还是回了窗口为 0 的通知;

可以发现,这些窗口探测报文以 3.4s、6.5s、13.5s 的间隔出现,说明超时时间会翻倍递增。

这连接暂停了 25s,想象一下你在打王者的时候,25s 的延迟你还能上王者吗?

发送窗口的分析

在 Wireshark 看到的 Windows size 也就是 " win = ",这个值表示发送窗口吗?

这不是发送窗口,而是在向对方声明自己的接收窗口。

你可能会好奇,抓包文件里有「Window size scaling factor」,它其实是算出实际窗口大小的乘法因子,「Windos size value」实际上并不是真实的窗口大小,真实窗口大小的计算公式如下:

「Windos size value」 * 「Window size scaling factor」 = 「Caculated window size 」

对应的下图案例,也就是 32 * 2048 = 65536。

技术图片

 

实际上是 Caculated window size 的值是 Wireshark 工具帮我们算好的,Window size scaling factor 和 Windos size value 的值是在 TCP 头部中,其中 Window size scaling factor 是在三次握手过程中确定的,如果你抓包的数据没有 TCP 三次握手,那可能就无法算出真实的窗口大小的值,如下图:

技术图片

 

如何在包里看出发送窗口的大小?

很遗憾,没有简单的办法,发送窗口虽然是由接收窗口决定,但是它又可以被网络因素影响,也就是拥塞窗口,实际上发送窗口是值是 min(拥塞窗口,接收窗口)。

发送窗口和 MSS 有什么关系?

发送窗口决定了一口气能发多少字节,而 MSS 决定了这些字节要分多少包才能发完。

举个例子,如果发送窗口为 16000 字节的情况下,如果 MSS 是 1000 字节,那就需要发送 1600/1000 = 16 个包。

发送方在一个窗口发出 n 个包,是不是需要 n 个 ACK 确认报文?

不一定,因为 TCP 有累计确认机制,所以当收到多个数据包时,只需要应答最后一个数据包的 ACK 报文就可以了。

转自https://www.toutiao.com/i6834634888386183688/?timestamp=1591490656&app=news_article&group_id=6834634888386183688&use_new_style=0&req_id=202006070844160100140470421E965B4E

TCP流量控制

标签:连接   例子   nbsp   状态   读取   递增   说明   过程   cap   

原文地址:https://www.cnblogs.com/cangqinglang/p/13059037.html

(0)
(0)
   
举报
评论 一句话评论(0
登录后才能评论!
© 2014 mamicode.com 版权所有  联系我们:gaon5@hotmail.com
迷上了代码!