10分钟理解-TCP流量控制-滑动窗口

·  阅读 1959
10分钟理解-TCP流量控制-滑动窗口

「本文已参与好文召集令活动,点击查看:后端、大前端双赛道投稿,2万元奖池等你挑战!

TCP就像个老司机,除了买票上车(三次握手),还有荷载量(滑动窗口),这小车就在互联网的世界里反复运输,当乘客过多,车车肯定就装不下了,并通知乘客下一次我有空位你在上来。在互联网中TCP也是如此,当网络传输流量过大,就容易导致接受方处理不过来,容易造成请求积压,那么TCP是如何解决的呢?今儿就要探讨一下TCP流量控制手段滑动窗口

这里就用案例来说明,这样更容易理解。

假设A向B发送数据。在连接建立时,B告诉A:“我的接收窗口rwnd = 400”(这里rwnd表示receiver window)。这表示发送方A的发送窗口不能超过接收方B给出的接收窗口的数值,也就是400字节。这里注意一下,TCP的窗口单位是字节,不是报文段。再设每一个报文段为100字节长,而数据报文段序号的初始值设为1(见图中第一个箭头上面的序号seq = 1)。本文中A代表发送方,B代表消息接收方。

接收方的主机B进行了三次流量控制。第一次把窗口减小到rwnd =300,第二次又减到rwnd = 100,最后减到rwnd = 0,即不允许发送方再发送数据了。应当注意,B向A发送的三个报文段都设置了ACK = 1,只有在ACK = 1时确认号字段(ack)才有意义。

image-20210705195859028.png

总结一下,就是发送端只能发送接收端指定的报文大小,超过了则暂停发送消息。

滑动窗口流程讲完了,但是问题还没完。

1.如果发送方发送报文丢失,例如上图的seq=201,怎么解决?

2.如果B向A发送0窗口(rwnd=0)后,B的接收缓存又有了一些存储空间,于是B又给A发送于是B向A发送了rwnd = 400的报文段,但是该次请求丢失,那么A岂不是一直还是认为B是0窗口,然后一直等待吗?

带着问题再来梳理一下

A给B发送消息时,A的消息丢失,但不影响之后的消息发送,只要A重连后重新发送即可。但注意的是,重新发送的请求不能发送新数据。

当B给A端发送窗口值丢失时,此时TCP的持续计数器就起到了作用,当A端接收到0窗口通知,持续计数器就会启动,若持续计数器设置的超时时间已经到达,A就会给B发送一个0窗口探测报文,此时B就可以确认窗口值,如果窗口仍然是零,那么收到这个报文段的一方就重新设置持续计时器。如果窗口不是零,那么死锁的僵局就可以打破了。

总结第二下,滑动窗口由窗口值来控制传输流量的大小;利用重发机制解决发送端消息丢失;利用持续计数器和探测报文解决接收端发送的窗口值丢失导致的无限等待情况。

用通俗的案例在加深一下理解:我车子的荷载量只有200(TCP中的窗口值),每次载满后禁止乘客上车(发送端被阻塞),当有部分人下车后(TCP接收缓存又有一部分空间),就可以继续允许乘客上车。

读到这里,是不是又多了一个跟面试官吹牛的小知识点。勇敢牛牛向前冲!!

image.png

分类:
后端
标签: