前言
🌟🌟本期讲解关于TCP协议的重要的机制"连接的建立和断开"~~~
🌈感兴趣的小伙伴看一看小编主页：GGBondlctrl-CSDN博客
🔥 你的点赞就是小编不断更新的最大动力
🎆那么废话不多说直接开整吧~~
TCP的协议特性分析，就像和每位大佬的交谈~~~~
目录
📚️1.滑动窗口
1.1概念的引出
我们在之前了解到，关于TCP协议的传输的过程，由于每次传输后的确认应答机制，那么这就导致每次发送方，在发送数据后，收到ack那么才会进行下一次数据的传输。
问题：这就导致大量的时间浪费在等待接收ack的传输过程中了；
所以为了解决这个问题，即在保证可靠传输的前提下进行让效率尽量高一点；那么此时就引入了一个重要的概念"滑动窗口"；
1.2滑动窗口机制
我们之前是发送一个数据，然后等待ack，然后再发送一个数据，那么此时存在滑动窗口后，具体的机制就是如下：
所以此时，即一个"批量传输"的过程，即在发送一个数据后，那么此时就不会进行等待接收ack，那么就直接继续发送数据，然后等连续发送了几条数据后，再进行统一的等待过程；
问题1：那么此时的所谓的"滑动窗口"的滑动的描述是从何而来的呢？
且看如下的图：
那么此时可以将上述的1~1000,1001~2000,2001~3000....来进行形象的描述成上述的过程，那么此时就可发现，此时的白色部分就像"一个窗口"；
问题2：这里的滑动是如何进行提现的呢？
这里就涉及到什么时候进行下一个数据的传输了，这里不是等所有的对应ack返回后在进行下一批的数据的发送，而是等待一个ack收到后，就直接进行滑动一个空格，那么此时就是有滑动的效果了~~
所以机制总结如下：
1.窗口大小就是无需等待ack的接受的最大数据量的发送（其实就是批量传输的最大值，白色部分方框里面）
2.发送前四个阶段的数据的时候，不用等待接收ack（这里的四个即表示的窗口的大小哦）
3.当每次收到一个ack时，那么窗口就向后面移动一个空格，以此类推（这里的空格就是数据哦）
4.操作系统内核为了维护这个滑动窗⼝, 需要开辟 发送缓冲区 来记录当前还有哪些数据没有应答;（ 只有确认应答过的数据, 才能从缓冲区删掉）
5.窗口越大，那么对应的网络吞吐量就会变大；
1.3丢包问题
1.ack丢包
具体的情况就是如下图所示：
问题3：此时可以看到，图中有几个ack的放回是发生了一定的丢包的问题，那么此时我们该如何进行解决的呢？
解决办法：
不用做任何的操作，为啥不用做任何的操作；注意这里涉及到一个重要的概念，即确认序号；
当第一个确认序号为1001的ack丢了之后，那么可以看到下一个2001的ack没有发生丢包，那么就已经表示，在收到2001的ack收到之后，就表示上一个数据1~1001已经传输到主机B了那么此时，就算1001的ack丢包了，也没有太大的关系~~~
ack丢包总结：就算ack在回传的过程中存在丢包的问题，那么只要存在一个ack放回成功，就表示前面的数据已经安全的发送到位了~~
2.传输的数据丢包
具体的情况是如下所示的：
问题4：可以看到上述的过程中是存在一个问题的，当数据丢包后是如何进行解决的？
解决：
具体方法在上述的展示中也进行了一定的理解，下面由小编为大家讲解一下具体的过程吧~
在发生1001~2000的数据丢包后，就会发现此时就会一直进行1001的ack确认报文的发送，知道发送方意识到1001~2000丢包了，那么就会进行重传~~
注意：
在接收到丢包的数据之后，如果没有其他的数据丢包，那么就直接发送7001，表示在7001确认序号之前的数据我们都收到了，不用再次从2001的ack进行传输了；那么如果在这个丢包的数据之后还丢包了，那么就会继续发送丢包是数据的首个序号，重复上述解决过程
总结：
在上述的重传的中，这个过程的效率是非常高的，这里的重传做到了针对性，已经收到了的数据，不必重新发送，那么这种重传就是"快速重传"
1.4滑动窗口和确然应答的比较
滑动窗口中也是包含有确认应答的机制，只不过是转成批量的了，批量的前提就是一段时间发送数据很多，如果发送的数据少，那么就会退化成确认应答的机制了
判断可靠性：
如果是滑动窗口：那么就是在丢包的时候，快速重传保证可靠性，连续有多个ack进行数据的索取，那么此时就能进行数据的重传；如果是确认应答： 如果在丢包的时候，确认应答保证可靠性，达到超时时间后，没收到ack，那么就会进行重传
📚️2.流量控制
2.1概念的引出
我们在上面的描述中了解到了，关于滑动窗口这个概念，这个的窗口越大，更多的数据同时用一块时间等待，提高了效率；
问题5：但是这里的问题就是，窗口大小能无限大吗？
答案是当然不能，因为这里的在提高效率的前提就是保证可靠性，如果接收方的接收缓冲区满了，那么就会造成再次发送数据时，就会发生丢包的后果，这种后果就是重传也没有用了~~
那么此时为了控制发送的速度，就引入了"流量控制"的概念
2.2流量控制机制
此时就涉及到TCP协议报文其中一个字段：即"16位窗口大小"，这里的不为64k，在TCP报头中还涉及到一个参数，即"窗口扩展因子"，那么此时，真正的窗口大小就是16*2^窗口扩展因子；
注意：这个字段是用来反馈给发送方，表示下次发送的窗口的大小
注意：这个字段是在ack的发送的报文中存在才有意义，在普通报文中进行发送，这个是没有意义的；
这里的窗口大小，是根据接收方的接收缓冲区的剩余的空间大小，来设定ack中窗口大小的数值，然后这里发送方会根据这个数值来设置自己的窗口大小；
具体的图示是如下的：
解释：
如上，当这里的窗口大小为0的时候，可以发现发送方会停止发送，然后发送方会尝试周期性的发送"窗口探测包" （这里的窗口探测包是不携带载荷的，对于业务时是没有影响的，主要的目的是为了触发ack的确认应答报文的发送，来确定这里的ack报文中的窗口大小是多少）；那么当这里的缓冲区（窗口）大小不为0的时候，发送方又会继续的发送数据；
📚️3.拥塞控制
3.1概念的引出
在上面我们讲解到了流量控制这个概念，那么我就知道了，这是针对接收方的角度来进行约束发送方的发送速度，而这里谈到的拥塞控制描述的是关于网络环境来影响发送方的发送速率；
我们知道网络环境是非常复杂的，如果存在一处地方发生了堵塞的情况，那么就会导致，接收方接收的速度再快也没有用，发送方发送速度再快也没有用；
所以就有以下方案：
如果按照某个窗口的大小进行发送数据，发生了丢包，那么就表示这个网络环境存在堵塞的情况，那么就会减小窗口的大小，如果没有出现丢包的情况，那么就增大窗口的大小~~~
所以总结：
上述的方法简化了问题，适应了复杂多变的网络情况，在中间节点的位置，什么时候拥堵，什么时候不拥堵，那么按照上述的描述， 就可以让发送的速率动态的变化；
如此以上，那么就叫做"拥塞控制"
3.2拥塞控制机制
我们知道网络环境是非常复杂的，那么对于拥塞控制的标准就是要靠实验来进行的；
具体的步骤：
1.慢启动：
刚开时的时候，传输数据的窗口是非常小的，因为保守起见
2.指数增长：
如果上述的条件没有发生丢包，那么就会增大窗口的大小，此时的增长速率就是按照指数来进行增长的
3.线性增长：
由于指数增长非常快，为了保证网络不会发生阻塞拥堵的情况，那么当达到一定的阈值后，就会线性增长
4.重回再增长：
由于线性增长的持续存在，那么到达一定的时间后，还是会发生网络堵塞引起丢包问题，那么一旦发生丢包问题，那么就会将拥塞窗口设置成一个较低的值，那么此时又会重新开始
那么上述的具体过程就是如下图所示：
解释：
此时我们看到当出现丢包的问题时：
第一：ack快速重传（滑动窗口中的概念），然后提醒说明此处发生了丢包的问题；
第二：在方法一过后直接将拥塞窗口降到最低，然后重新设定阈值；（经典版本）
第三：在方法一过后直接将拥塞窗口降到一个新的阈值，不是最低点；（这是新的版本没有慢启动和指数增长了，传输的效率大大增加）
那么以上就是关于拥塞控制的小编了解的全部知识了~~~
📚️4.总结
💬💬本期小编主要讲解了关于TCP协议中比较重要的特性，即滑动窗口，流量控制，以及拥塞控制，当然这里每一节涉及到的丢包的问题，和控制发送方的发送窗口对应的两种控制的机制需要大家好好的理解理解~~~
🌅🌅🌅~~~~最后希望与诸君共勉，共同进步！！！
💪💪💪以上就是本期内容了， 感兴趣的话，就关注小编吧。
😊😊 期待你的关注~~~