持续创作，加速成长！这是我参与「掘金日新计划 · 10 月更文挑战」的第33天，点击查看活动详情
大家好,我是bug郭,一名双非科班的在校大学生。对C/JAVA、数据结构、Spring系列框架、Linux及MySql、算法等领域感兴趣,喜欢将所学知识写成博客记录下来。 希望该文章对你有所帮助！如果有错误请大佬们指正！共同学习交流
作者简介:
- CSDN java领域新星创作者blog.csdn.net/bug..
- 掘金LV3用户 juejin.cn/user/bug..
- 阿里云社区专家博主,星级博主,developer.aliyun.com/bug..
- 华为云云享专家 bbs.huaweicloud.com/bug..
拥塞控制
这也是滑动窗口的延伸,限制滑动窗口的发送速率保证可靠性! 拥塞控制是衡量发送方到接收方,这整个线路之间的拥堵状况(处理能力)这里和流量控制一样限制了发送方的传输速率!
我们知道两个设备进行通信,中间链路情况十分复杂,中间有很多设备,而每个设备的信息处理能力又不一样!如果中间一个设备处理的很慢,那其他设备处理的再快也无济于事!
这就导致,整个链路的传输速率也下降,这也促使发送方降低发速率!
发送方如何得知中间链路的阻塞状态呢?
这里无法直接得出,我们需要通过实验得出一个结论,找到这个最适合的发送能力,既要保证传输速率快,又要避免丢包!
- 发送方一开始取的拥塞窗口大小非常小,取纵轴的1个单位(1个单位的大小是1个字节,10个字节,具体要看操作系统代码如何实现)
- 一开始发送方通过指数增长的方式,增加传输速率,到达了一个合适的值后,就降低增长速率!
- 到达阈值后就是指数增长就会变成线性增长,使速率无限接近最大速率,直到产生丢包
- 丢包后,说明网络拥塞,自接将速率减少到最开始的初始值,避免丢包过多,又反复进行上述过程,当第二次指数增长时,会将阈值减小到当前出现丢包窗口的一半(一开始到达
24就产生了丢包,那第二次就会将阈值减少到12),然后进行线性增长,直到找到一个最合适的值!
这个过程可能有些许复杂,可以联系俩个人谈恋爱! 一开始在一起时,热恋期好感度指数增长,到了后面,新鲜感没了,没有增长的这么快了,最后吵架闹分手,就好感度一重新开始,所谓小别胜新欢,然后又热恋,显然这次热恋期没第一次长,然后种种最后爱情的镜头还是财米油盐!
这里的拥塞窗口和刚刚的流量控制都是对发送方发送速率的约束,那么最后发送方发送的速率是取决于那个呢? 发送速率 = Min(拥塞窗口,流量控制);
延时应答
演示应答是流量控制的的延伸 流量控制是告诉发送方不要发送的太快! 延时应答是在这个基础上,尽可能然窗口更大一些!
刚刚的流量控制,当接收方的接收缓冲区满后,发送方就会停止发送数据,而是定期发送窗口探测报文,为了得知当前接收方接收缓冲区的大小,然后接收方就会发送返回一个窗口大小的报文!
而这里的延时应答就是将这个窗口大小的报文延时传送给发送方! 这样延时处理后,给接收方些许时间处理数据,使得窗口大小变大,然后下次发送方就可以提高发送速率!
捎带应答
这里又是延时应答的延伸!
因为延时应答的存在导致接收方接收到数据后ACK可能不是及时传输,那么当ACK延时后,当再次发送时,发现和另一条发送数据的发放时间一样,那么就可以将ACK和另一条数据一起封装分用,进行打包发送,提高发送效率!
就是将
ACK和数据一起打包传输返回给主机A!
客户端和服务器之间的通信方式有多种!
- 一问一答:客户端一个请求返回一个响应(网页)
- 一问多答:下载文件
- 多问一答:上传文件
- 多问多答 :直播 这里的捎带应答策略针对的是一问一答方式
这里捎带应答ACK和数据报丢了咋整,和正常的丢包程序一样处理!
