TCP特性的滑动窗口,流量控制

目录

一、TCP特性滑动窗口

二、TCP特性流量控制(作为滑动窗口的补充)


文章来源地址:https://www.uudwc.com/A/3wBnO/

一、TCP特性滑动窗口

提高传输效率(更准确的说,让TCP在可靠传输的前提下,效率不太拉跨)?

当然你要是想让TCP媲美UDP,也是痴人说梦,只能说减小差距。

一次性发一组数据,发数据的过程中,不需要等待ACK,就直接往前发,此时相当于“一份等待时间”等待四个ACK,把一次发多少数据,不用等待ACK这样的大小,称为窗口。? 

窗口越大,此时批量发送的数据越多,效率越高,但是窗口不能无限大,如果是无限大,相当于完全不必等待ACK,此时就和不可靠传输差不多了,如果你无限大,接收方是否可以处理过来,中间设备是否可以承受住,都是未知数

那么为什么要叫“滑动窗口”,哪里有滑动呢

当前A给B发送了1001——2000,2001——3000,4001——5000这样的数据,需要等4个对应的ACK,这四个ACK到达顺序,也会有先有后,如2001->3001->4001->5001这种顺序到达。

那么问题来了,大家觉得 2001到达主机B的时候A是否继续往下发下一条信息?还是等待5001到了,才继续发下一组消息。

当然是2001到达主机B的时候,A可以继续往下发下一条信息(要不等到5001,???那不是一样的慢吗)

收到2001这个ACK之后,于是A就立即发送5001-6000这个数据,此时A等待ACK,3001->4001->5001->6001,仍是等待4条ACK,还是窗口一样的大,但是往后挪动了一个格子,直观来看:窗口往后挪了一步

滑动窗口是一个“形象的比喻”,实际本质批量发送数据(可以缩短时间,但是还需要等待)

批量传输的方式传输,中间丢包了咋办。

对于TCP来说,必然不会影响他的可靠性啊

两种情况:

1.数据丢了

2.ACK丢了

首先ACK丢了?不用做任何处理,也是正确的,2001确认序号,表示2001之前的数据都收到了!!也包含1——1000。

虽然A没有收到1001这个ACK,但是2001这个ACK涵盖了1001的含义,(就相当于,有对象,结婚,有娃娃,小哥哥加你微信,你说我都有娃娃了,不就相当于你有结婚的伴侣了?)

其次数据丢了:?

此时必须要重传,啥时候重传,具体怎么重传。

在1001-2000丢失之后,2001-3000这个数据到达了B,B返回的ACK确认序号仍是1001,B仍然再向A索要1001这个数据~,虽然A后续给B的数据都会顺利的传递过去,但是如果只要是1001这个数没有,B始终会向A索要这个1001的数据,返回ACK确认序号,都是1001。

(返回ACK确认序号,都是1001)。

3次的重复应答(已经接收1-1001字节的数据),收到了3个同样的确认应答时,则选择重发。

接收方,有个缓冲区在接收数据

如果接收缓冲区,这一块是少了的,返回的ACK,就会始终索要1001这个数据报~一旦1001这个数据报被补充上了,此时1001-2000后面的数据都不必重新传输了,(都在缓冲区等待呢),接下来,就看后面数据加哪里缺失,直接索要缓冲区最后一条数据的下一个即可~

此时,相当于用最小的成本,来完成这个重传数据的操作(只是把丢了的数据重新传输,其他的数据都没有重复操作)快速重传->超时重传+滑动窗口下,产生的变形操作(本质仍然是超时重传)?

滑动窗口,也不是说使用TCP就一定涉及,如果你通信的双方大规模传输数据,肯定是滑动窗口(此时按照快速重传来工作),如果是传输通信数据规模小,此时就没有滑动窗口。仍然按照之前的超时重传来工作,滑动窗口的思想方法,非常实用。

二、TCP特性流量控制(作为滑动窗口的补充)

滑动窗口,窗口越大,传输的效率就越高,但是窗口无限大,可能会使接收方处理不过来了,或者使传输中间链路处理不过来,这样就会出现丢包···此时就要重新传输了,窗口大并没有提高效率,反而还会影响效率。

流量控制,给滑动窗口,踩刹车,?避免窗口过大,导致处理不过来。

如何衡量接收方处理速度

此处就使用接收缓冲区剩余空间大小作为衡量指标->如果剩余空间越大,应用程序消费数据的速度越快

TCP报头中,这个字段只对ACK报文才有意义,这个数字表示当前缓冲区剩余空间大小,这个数字返回给发送方,就可以作为发送方下一轮发送的参考依据,这里的16位,是否意味着窗口大小就是64KB呢?

实际上下面有一个选项,这个是窗口大小的扩展因子,他可以实现位运算,也就是《这种,换句话说,此时能表示窗口的大小,实际是可以表示非常大的窗口。

虽然A不再发数据了,但是也不知道B这边啥时候可以腾出空间,就会周期发送窗口探测包(⚠️不涵盖任何数据),只是触发ACK,查看当前接收的情况。

一旦发现不是0了,就可以继续发送了,接收方就可以根据窗口大小,来反向限制发送方传输速度。

原文地址:https://blog.csdn.net/weixin_72953218/article/details/132817190

本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如若转载,请注明出处: 如若内容造成侵权/违法违规/事实不符,请联系站长进行投诉反馈,一经查实,立即删除!

h
上一篇2023年09月18日 02:43
PostgreSQL 入门
下一篇 2023年09月18日 02:44