本篇会加入个人的所谓鱼式疯言
❤️❤️❤️鱼式疯言:❤️❤️❤️此疯言非彼疯言
而是理解过并总结出来通俗易懂的大白话,
小编会尽可能的在每个概念后插入鱼式疯言,帮助大家理解的.
🤭🤭🤭可能说的不是那么严谨.但小编初心是能让更多人能接受我们这个概念 ！！！
引言
在当今这个信息爆炸的时代，网络通信的效率和稳定性对于我们日常生活的重要性不言而喻。想象一下，当你在浏览网页、视频通话或者在线游戏时，突然间网络卡顿，那种焦急和无奈的感觉是多么令人沮丧。幸运的是，有一项技术一直在幕后默默工作，确保我们的网络体验尽可能流畅——这就是TCP滑动窗口机制。本文将深入探讨这一机制的原理、作用以及它如何影响我们的网络生活。
目录
- 滑动窗口
- 快速重传
- 流量控制
- 拥塞控制
一. 滑动窗口
1. 滑动窗口的初识
有小伙伴肯定在算法的章节听过 滑动窗口 这个名词， 那么和我们今天是讲的 滑动窗口的Tcp的机制 是否相同呢？
其实啊， 是 算法的滑动窗口 是来自于我们
Tcp 机制的滑动窗口
的。
那么 滑动窗口到底是什么呢？
滑动窗口就是把 一组数据包裹成一个整体 ， 而这个 整体的数据规模 称为
窗口, 我们通过 数据的输入和输出 来进行
入窗口和出窗口的实现, 从而保证这个窗口在 每个数据中移动。 故我们称之为 滑动窗口 。
2. 滑动窗口的传输流程
对于上面的流程：
首先假设窗口大小为 4 个数据， 先从1001~5001 开始传输。
当传输到 4001 ~ 5001 这段数据时， 已经到达窗口大小了， 这时就需要等待前面三个ACK 都接收到再传输下一个数据， 还是一有ACK 返回就立刻传输呢 ?
其实是后者， 只要有一个ACK返回， 就立刻
传输下一个数据
。
如上图， 当传输到4001~ 5001 数据时， 发现 对端返回一个为3001的确认序号 ， 于是就立刻发送
5001 ~ 6001
这样序号的数据， 所以不必等待对端 返回 5001 的确认序号 。
这样以此往复， 就可以看到 窗口左端的数据在出窗口 ， 窗口右端的数据在入窗口 ， 从而出现窗口就开始在
数据和数据之间移动， 故称为
滑动窗口。
3. 滑动窗口的优势
在Tcp中， 我们之前是 先发送一个数据， 然后再接收一个
应答报文ACK
， 再发 下一个数据 ，就会浪费 等待ACK的时间 ， 这样的效率就会
明显降低
。
而在 滑动窗口的机制 下， 我们是 每发送一批数据 接收
一批应答报文 ACK。
通过上面这样发送 一批数据接收一批ACK 的方式就可以
有效提高数据传输的效率。
虽然有了滑动窗口的机制， 但是
滑动窗口
并 不是大幅度的提高传输的效率， 对于Tcp 本身来说， 是可靠传输的机制，就会有大量时间能耗。
而滑动窗口的这个机制， 不是真正加快效率， 而是减少因为可靠传输造成的时间都消耗， 相当于
亡羊补牢, 并不能做到像 Udp 的协议 那么快的传输效率。
对于
滑动窗口批量发送和接收， 窗口大小决定着传输的速度， 也就是说窗口越大， 传输的速度越快， 窗口越小， 传输的速度越慢， 但是窗口大小并不是可以无限增大的， 也需要考虑主机和主机之间 数据处理的快慢 ， 否则会因为 窗口太大，传输的过快 ，从而 造成数据丢包现象 。
所以定义一个 合适的窗口大小 是很重要的。
鱼式疯言
补充总结：
- 滑动窗口的本质作用是尽可能的减少因为 Tcp 的可靠传输 而造成的
时间的损耗。
- 想要提高可靠性， 就需要 消耗一定的时间， 想要 速度快 ， 就需要 消耗一定的可靠性 。
上面是滑动窗口传输成功的流程， 但是在网络传输过程， 存在着大量的不确定性， 比如我们上篇谈及过的有：
比特翻转， 数据高峰期丢失等… 都是有可能的。
一. 快速重传
为了应对进行 滑动窗口传输数据的过程中会出现 数据丢包问题 ， Tcp 又采取了一套
配合滑动窗口
的机制—— 快速重传。
1. 滑动窗口数据丢包的两种情况
在滑动窗口也存在两种数据丢包的情况：
一种是 数据包丢失 ， 一定是 应答报文 ACK 丢失 。
<1>. ACK丢失
如上图, 主机A的数据包是 正常发送给对端主机B 的, 但是
主机B在确认应答
时，返回给
主机A的ACK
出现了丢包。
首先当主机A 发送
1~1000 的数据
时， 返回
1001
的 ACK 丢包了， 这时主机A 继续发送 1001~6000 的数据， 并不会重新发送 1~1000 的数据。
因为ACK 的确认序号是 有顺序返回的 ， 当返回了1001 就会继续返回 2001 ， 即使
1001 没有收到， 但是一旦主机A 接收到了 后面的2001 的数据 时， 就会可以认为
前面的1~ 2000 的数据是接收到的。
当上述 一批一批的发送ACK 时， 即使丢失了前面的部分ACK， 后面一旦
有ACK的返回， 就说明 前面的数据是接收到的 。
所以我们 不需要做任何处理 即可。
鱼式疯言
总结提炼 ：
确认序号是
有序的，当 收到后面的序号 ，说明
前面的序号的数据是 发送成功的。
<2>. 数据包丢失
如上图， 主机A的数据包在传输主机B 的过程中 出现了丢失 ， ACK是
正常返回的
。
首先主机A 发送了
1~1000
的数据， 然后正常应答， 然后再发送1001 ~2000 的数据，结果数据包丢失了，
这时主机B是意识到还没接收到
1001~2000的数据的， 就会 返回1001 的确认序号
但由于是 批量发送的 ， 主机A 是继续发送2001 ~ 7000 的数据， 这时 主机A还没有意识到前面有数据丢失了 ， 这时主机B就会一直
返回 1001 的数据。
最后当主机A 发送完
2001 ~7000的数据时， 就会意识到了
数据1001 ~ 2000的数据 没有发送成功 ，所以就会
重新发送这段数据。 并且 后面数据由于确认序号是升序的 ， 已经 接收到后面的数据了 ， 就不需要重新发送后面的数据。
相当于 一个萝卜一个坑 ， 前面的坑虽然没有补上， 会
一直响应需要补上前面的坑， 后面的
坑如果被被补上了就不需要再补了。
而上诉这种重传的方式， 我们就称之为： 快速重传机制。
2. 快速重传的栗子说明
比如有一天女神要去参加闺蜜的婚礼，但是路上车打不上火， 这时她就问小编
女神： 我车打不着火了。
我： 检查一下车是不是没电了
女神： 我要是去迟了怎么办？
我： 检查一下车是不是没电了
女神： 我要是不能及时的话， 会耽误人家的大事的
我： 快检查一下车是不是没电了
女神： 我该怎么办，5555~~~
最后发现女神终于发现，真的是电动车没电了 。
我一直说 检查一下车是不是没电了 ， 就好比主机B一直
返回序号为 1001的报文。
要求 主机A 重新发送 ， 但是后面 女神的消息 是收到的， 所以不需要再重新发送 。
鱼式疯言
总结补充 ：
确认应答——超时重传
滑动窗口——快速重传
他们的使用场景就相当于牛顿的经典力学和爱因斯坦的相对论
当需要传输的 数据很多很庞大 时， Tcp一般采取 滑动窗口——快速重传 的相关机制。
当需要传输的 数据并没有那么多 时， Tcp一般采取 确认应答——超时重传 的相关机制。
我们提及滑动窗口，会想到窗口的大小会影响
传输的速度
， 所以选择 合适的窗口大小 是很有必要的
选择合适的窗口大小的意义就在于： 既要保证 数据包的不被丢失 ， 也要保证传输的速度尽可能的快 。
而控制窗口大小的机制主要有两个：
流量控制
，
拥塞控制
。
三. 流量控制
1. 流量控制的初识
如果说 滑动窗口比喻成踩油门 ， 那么 流量控制就好比是踩刹车 。
我们知道在前面小编带着小伙伴们写过一个简易的Tcp 回显服务器， 其中没使用一个Socket 对象， 都存在一个 缓存区 的概念。
缓存区就是用来 防止数据传输过多 ， 而
临时存放数据
的 一个空间区域 。
流量控制 就是： 根据缓存区的 剩余空间的大小 ， 来调整
滑动窗口的大小
。
2. 流量控制的大体流程
如上图第一张到第二张的变化：
假设缓存区大小为
100 byte
，
先是存放数据
60 byte
， 还剩
40byte
，
然后通信了一段时间， 变成
80byte 数据
， 还剩
20 byte
这时我们就知道了， 发送方 传输的数据很快 ，但是接收方 处理数据很慢
这时由于传输的数据相对太快了， 我们就需要把 窗口调整的小一点 ， 让传输的数据尽可能的慢一点， 让 接收方尽可能的能够处理数据。
而如何让发送方知道 窗口大小需要传输小一点 呢？
如上图， 有一个
16位的窗口大小， 当
Tcp需要 调整窗口大小 时， 就需要由接收方感知 缓存区的大小 ， 通过
ACK 报文返回缓存区中剩余的空间大小, 从而让 发送方调整窗口大小 ， 控制传输的速率。
鱼式疯言
总结补充：
- 窗口
不是固定不变， 而是通过 缓存区的剩余空间进行调整 ， 会 不断动态变化， 动态调整的 。
- 窗口扩展
16窗口大小为 64 MB， 如果 实际所需要的窗口大小 > 64MB ， 这时就会在 选项中扩展 。
其中有一个
扩展因子， 就会让 窗口大小
<<扩展因子 。
也就是如下方法：
假如 扩展因子为 3；
窗口大小 =
64MB * 2的3次方
四. 拥塞控制
1. 拥塞控制的引入
如果说
滑动窗口
和
快速重传
是 踩油门；
那么 流量控制 和 拥塞控制 就是
踩刹车
。
所以说 拥塞控制和流量控制 都是 控制窗口大小 来调整 传输的速度 。
在 主机A 和 主机B 的网络通信中， 在 传输的链路的过程中 ， 会经过大量的
交换机。
如果传输的 数据量很大，速度很快 ， 其中 一个交换机无法承受， 就会出现在
某个交换机中出现 丢包现象 。
那么我们有什么解决方案吗？
是检查 某个链路是否出现丢包 ， 还是 检查某个交换机出现丢包现象 。
其实上述的这两种方案都不可取， 所以Tcp 采取了
拥塞控制
的机制，来解决上述问题 。
下面让来看看吧 💞💞💞💞
2. 拥塞控制的大体流程
如上图：
我们程序猿不仅是技术人员，更有一个名字称为
工程师
， 聪明的工程师们就会通过做实验的方式， 来动态 调整窗口的大小 ，
控制传输速率
， 减少丢包问题 的发生。
首先， 设置 一个很小的窗口 ， 以 一个很小的速度 传输数据
确保数据在
链路传输中通畅， 再继续 加大窗口， 加快传输数据 。
当 传输速度达到一定 时， 再 增加数据
一旦出现
丢包， 就慢慢 减少窗口 ， 直到
不丢包；
在
不丢包的情况下， 继续加大窗口， 加快传输速率；
以此 循环往复 ，让窗口处在一个 相对大小的幅度上波动 。
既让一定大小的传输速率能 提高一定的效率 ， 也能 尽可能的不丢包 。
鱼式疯言
总之上诉过程就记住一句话：
面多加水， 水多加面。
总结
- 滑动窗口: 从一个数据的传输到一批数据的传输， 从而经可能减少时间损耗， 提高时间效率的过程，以及滑动窗口的流程分析，只要一有ACK 返回， 就立即发送下一条的数据。
- 快速重传： 当数据在进行滑动窗口时， 出现数据包丢失时，会一直返回发送方缺失的数据， 直到发送方重新发送丢失的数据。
- 流量控制： 流量控制就是一种通过监测缓存区中数据剩余空间来控制窗口大小来控制数据传输的速率， 从而减少丢包问题的出现。
- 拥塞控制： 在保证不丢包的情况下， 尽可能的加大窗口大小，加快传输速率，一旦丢包就减少窗口大小， 以此循环往复的进行动态调整。
如果觉得小编写的还不错的咱可支持 三连 下 (定有回访哦) , 不妥当的咱请评论区 指正
希望我的文章能给各位宝子们带来哪怕一点点的收获就是 小编创作 的最大 动力 💖 💖 💖
版权归原作者 邂逅岁月 所有， 如有侵权，请联系我们删除。