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

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

一、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了,就可以继续发送了,接收方就可以根据窗口大小,来反向限制发送方传输速度。


相关实践学习
通过Ingress进行灰度发布
本场景您将运行一个简单的应用,部署一个新的应用用于新的发布,并通过Ingress能力实现灰度发布。
容器应用与集群管理
欢迎来到《容器应用与集群管理》课程,本课程是“云原生容器Clouder认证“系列中的第二阶段。课程将向您介绍与容器集群相关的概念和技术,这些概念和技术可以帮助您了解阿里云容器服务ACK/ACK Serverless的使用。同时,本课程也会向您介绍可以采取的工具、方法和可操作步骤,以帮助您了解如何基于容器服务ACK Serverless构建和管理企业级应用。 学习完本课程后,您将能够: 掌握容器集群、容器编排的基本概念 掌握Kubernetes的基础概念及核心思想 掌握阿里云容器服务ACK/ACK Serverless概念及使用方法 基于容器服务ACK Serverless搭建和管理企业级网站应用
目录
打赏
0
0
0
0
27
分享
相关文章
【JavaEE】——四次挥手,TCP状态转换,滑动窗口,流量控制
四次挥手、TCP状态转换、(listed,established,close_wait,time_wait),滑动窗口,ack丢包,数据丢包,流量控制
TCP的滑动窗口与拥塞控制
【10月更文挑战第7天】这段内容详细介绍了TCP协议中确保数据包可靠传输的机制,包括使用ID确保顺序性与累计确认、发送端与接收端的缓存管理、超时重传策略及自适应重传算法,以及拥塞控制机制如慢启动、拥塞避免和快速重传。
【TCP】核心机制:滑动窗口、流量控制和拥塞控制
【TCP】核心机制:滑动窗口、流量控制和拥塞控制
155 2
提高网络稳定性的关键:TCP滑动窗口与拥塞控制解析
**TCP可靠传输与拥塞控制概要:** 小米讲解TCP如何确保数据可靠性。TCP通过分割数据、编号段、校验和、流量控制(滑动窗口)和拥塞控制(慢开始、拥塞避免、快重传、快恢复)保证数据安全传输。拥塞控制动态调整窗口大小,防止网络过载,提升效率。当连续收到3个相同ACK时执行快重传,快恢复避免剧烈波动。关注“软件求生”获取更多技术内容。
162 4
提高网络稳定性的关键:TCP滑动窗口与拥塞控制解析
TCP、UDP是如何流量、拥塞控制的?今天一口气讲透!
TCP、UDP是如何流量、拥塞控制的?今天一口气讲透!
216 2
TCP的滑动窗口和拥塞控制
TCP的滑动窗口和拥塞控制
106 0
【JavaEE初阶】 TCP滑动窗口与流量控制和拥塞控制
【JavaEE初阶】 TCP滑动窗口与流量控制和拥塞控制
AI助理

你好,我是AI助理

可以解答问题、推荐解决方案等