【Linux 网络】拒绝传输卡顿!滑动窗口如何让数据 “跑赢” 等待?

一、滑动窗口

滑动窗口大小:指的是无需等待确认应答而可以继续发送数据的最大值;注意:这里的无需等待确认应答,不是不要确认应答,而是暂时不要;

站在发送方(主机A 视角):

图中序号为①的那里就是发送方的发送缓冲区,而滑动窗口就是发送缓冲区里面白色部分,所以滑动窗口属于发送缓冲区的一部分;

站在逻辑上,发送缓冲区就是一个以为数组:

这个一维数组存储就是发送的数据,而 滑动窗口就是用两个指针指向的下标构成的区域内的窗口;

结论:

1.滑动窗口的存在把发送缓冲区划分成三个部分:

a.滑动窗口内的数据直接发,暂时不需要应答

b.滑动窗口的左边部分的数据,已经发送,已经确认

c.滑动窗口的右边部分的数据,待发送;

2.滑动窗口滑动的方向是:从左向右;因为左边部分的数据已经发送过了,属于无效的数据,这意味这部分的数据可以被覆盖;

3.滑动窗口滑动的本质:两个指针的移动(下标变大)

问题:滑动窗口的大小由谁来定?

答:由对方的接收缓冲区的剩余空间的大小决定;

结论:流量控制是由滑动窗口实现的;------这个结论还有待补充;

怎么确定滑动窗口的大小?

答:start = 确认序号,end = start + 对方接收缓冲区的剩余空间的大小;

问题:滑动窗口能向左滑动吗?

答:不能;因为要发送的数据在右边;

问题:滑动窗口范围会变化吗?

答:滑动窗口范围会随着对方的接收缓冲区的剩余空间的大小动态变化;当对方的用户层不拿数据时,对方的接收缓冲区的剩余空间的大小变小,此时我们的滑动窗口大小就变小;如果对方的拿完我们发送的数据,此时对方的剩余空间不变,此时我们的滑动窗口也不变,如果此时对方用户层不拿数据,导致我方的滑动窗口变小,一会儿对方就把数据那完了,此时对方的接收缓冲区的剩余空间大小变大,就会导致我们的滑动窗口变大;

问题:如果主机 A 给对方发送 4 条报文,此时主机B就要应答 4 次,如果前三次的应答丢包了,第四次应答成功,此时主机 A 根据确认序号就知道这四条报文都发送成功了,如果前三次没丢报,就第四次丢包了,此时 主机 A 只能确认前三次的报文对方收到了,关于第四次报文没有收到应答此时根据超时重传,重新发送一条原来的第四条报文给主机B;

如果主机A发送一批报文,只有 1001 - 2000 丢包了,此时对方的应答这一批的报文的序号超过3个是1001,则主机A 100% 确定1001 - 2000 的报文丢了,此时主机A 立马就是发送 1001 - 2000 的报文,这就是快重传机制(当收到3个以上同样的应答时,就使用快重传),但是主机A不确定 1001 - 200 后面是否有报文丢失,但是没有关系,因为给 1001 - 2000 的时候是会有应答的;这个应答就会告诉主机 A 是否有报文丢失;

快重传 VS 超时重传:

快重传和超时重传是不冲突的,他们是互补关系;当主机 A 只发送一条报文时,这条报文丢失了就会触发超时重传,当主机A 发送超过3条报文时,只要有三条应答报文以上是序号是同样的就会触发超时重传,所以:超时重传用来兜底的,而快重传用来提供速率;

滑动窗口内的数据发送出去后,第一个报文丢失了,其余报文没有丢,此时为了支持重传,发出去的数据不能立即删除,以便后续确认和重传,说人话就是滑动窗口的 start 的指向不能变;

结论:重传机制和滑动窗口有关;

4 个报文只有第 2 个 或者 第 3 个报文丢了,此时应答回来的确认序号也就是第1个应答报文和第 4 个报文的序号他们的序号是一样的,而且这个序号的是第一个应答报文的序号,也就是第二个报文的起始序号,所以滑动窗口的 start 只会移动到第二个报文那里;支持重传;

4 个报文和就第 4 个丢了,此时第 3 个的应答序号一定指向第四个报文,也就是 start 指向第四个报文;

结论:滑动窗口中的报文问题,起始就是最左侧丢包问题,这个和确认序号机制有关系,为了保证滑动窗口滑动的连续性,滑动窗口滑动不能跳过没有确认的报文;

滑动窗口,滑动出去了怎么办?

答:滑动窗口会重置 start 和 end 指向缓冲区的开始;

问题:滑动窗口里面的数据,直接打包成一个报文,不就号了?

答:这个和链路层有关;

小结:

1)滑动窗口是什么?

答:滑动窗口是输出缓冲区的一部分,可以暂时不用应答,可以直接发送的数据区域;

2)为什么要用滑动窗口?

答:滑动窗口是流量控制、重传机制的底层实现,滑动窗口是因,流量控制和重传机制是果;

相关推荐
虎头金猫3 天前
4K 视频总卡在公网带宽?用 N1 + OpenList 把网盘播放链路重新理顺
运维·服务器·网络·python·容器·beautifulsoup·pandas
AI职业加油站3 天前
AI智能体应用工程师证书:政策红利下的职业新风口
大数据·运维·人工智能·学习·职场发展
wuyk5553 天前
《WiFi 嵌入式物联网开发全套实战》| 第 16 章 ESP32 AP+STA 双模共存原理与工程坑点
网络·stm32·物联网
此冬歌咏3 天前
K8s 节点故障实战:优雅驱逐 31 秒,硬故障 331 秒,以及那个永远 Pending 的 Pod
运维·k8s
-梅3 天前
linux(8) 软硬链接
linux·运维·服务器
Wang's Blog3 天前
Java 项目实战: 外卖平台-文件下载与ServletOutputStream回写浏览器
服务器·项目开发
张洛闻Eren3 天前
k8s云原生【第十课】:水平 Pod 自动扩缩容
运维·数据库·云原生·kubernetes·github
琥珀色糖3 天前
SimlpeHttp
linux·服务器
其实防守也摸鱼3 天前
内网穿透与反向代理:原理、工具与实战指南
android·大数据·运维·安全·网络安全·自动化·渗透
第十人i3 天前
Linux 日志管理系统:journald 配置与优化
linux·服务器