感兴趣的小伙伴看一看小编主页GGBondlctrl-CSDN博客

那么废话不多说直接开整吧~~

我们在之前了解到关于TCP协议的传输的过程由于每次传输后的确认应答机制那么这就导致每次发送方在发送数据后收到ack那么才会进行下一次数据的传输。

所以为了解决这个问题即在保证可靠传输的前提下进行让效率尽量高一点那么此时就引入了一个重要的概念“滑动窗口”

1.2滑动窗口机制

我们之前是发送一个数据然后等待ack然后再发送一个数据那么此时存在滑动窗口后具体的机制就是如下

所以此时即一个“批量传输”的过程即在发送一个数据后那么此时就不会进行等待接收ack那么就直接继续发送数据然后等连续发送了几条数据后再进行统一的等待过程

那么此时可以将上述的1~1000,1001~2000,2001~3000....来进行形象的描述成上述的过程那么此时就可发现此时的白色部分就像“一个窗口”

这里就涉及到什么时候进行下一个数据的传输了这里不是等所有的对应ack返回后在进行下一批的数据的发送而是等待一个ack收到后就直接进行滑动一个空格那么此时就是有滑动的效果了~~

1.窗口大小就是无需等待ack的接受的最大数据量的发送其实就是批量传输的最大值白色部分方框里面

2.发送前四个阶段的数据的时候不用等待接收ack这里的四个即表示的窗口的大小哦

3.当每次收到一个ack时那么窗口就向后面移动一个空格以此类推这里的空格就是数据哦

需要开辟

问题3此时可以看到图中有几个ack的放回是发生了一定的丢包的问题那么此时我们该如何进行解决的呢

解决办法

不用做任何的操作为啥不用做任何的操作注意这里涉及到一个重要的概念即确认序号

当第一个确认序号为1001的ack丢了之后那么可以看到下一个2001的ack没有发生丢包那么就已经表示在收到2001的ack收到之后就表示上一个数据1~1001已经传输到主机B了那么此时就算1001的ack丢包了也没有太大的关系~~~

ack丢包总结就算ack在回传的过程中存在丢包的问题那么只要存在一个ack放回成功就表示前面的数据已经安全的发送到位了~~

问题4可以看到上述的过程中是存在一个问题的当数据丢包后是如何进行解决的

具体方法在上述的展示中也进行了一定的理解下面由小编为大家讲解一下具体的过程吧~

在发生1001~2000的数据丢包后就会发现此时就会一直进行1001的ack确认报文的发送知道发送方意识到1001~2000丢包了那么就会进行重传~~

在接收到丢包的数据之后如果没有其他的数据丢包那么就直接发送7001表示在7001确认序号之前的数据我们都收到了不用再次从2001的ack进行传输了那么如果在这个丢包的数据之后还丢包了那么就会继续发送丢包是数据的首个序号重复上述解决过程

在上述的重传的中这个过程的效率是非常高的这里的重传做到了针对性已经收到了的数据不必重新发送那么这种重传就是“快速重传”

滑动窗口中也是包含有确认应答的机制只不过是转成批量的了批量的前提就是一段时间发送数据很多如果发送的数据少那么就会退化成确认应答的机制了

判断可靠性如果是滑动窗口那么就是在丢包的时候快速重传保证可靠性连续有多个ack进行数据的索取那么此时就能进行数据的重传

如果在丢包的时候确认应答保证可靠性达到超时时间后没收到ack那么就会进行重传

️2.流量控制

我们在上面的描述中了解到了关于滑动窗口这个概念这个的窗口越大更多的数据同时用一块时间等待提高了效率

答案是当然不能因为这里的在提高效率的前提就是保证可靠性如果接收方的接收缓冲区满了那么就会造成再次发送数据时就会发生丢包的后果这种后果就是重传也没有用了~~

2.2流量控制机制

此时就涉及到TCP协议报文其中一个字段即“16位窗口大小”这里的不为64k在TCP报头中还涉及到一个参数即“窗口扩展因子”那么此时真正的窗口大小就是16*2^窗口扩展因子

注意这个字段是在ack的发送的报文中存在才有意义在普通报文中进行发送这个是没有意义的

这里的窗口大小是根据接收方的接收缓冲区的剩余的空间大小来设定ack中窗口大小的数值然后这里发送方会根据这个数值来设置自己的窗口大小

如上当这里的窗口大小为0的时候可以发现发送方会停止发送然后发送方会尝试周期性的发送“窗口探测包”

这里的窗口探测包是不携带载荷的对于业务时是没有影响的主要的目的是为了触发ack的确认应答报文的发送来确定这里的ack报文中的窗口大小是多少那么当这里的缓冲区窗口大小不为0的时候发送方又会继续的发送数据

️3.拥塞控制

在上面我们讲解到了流量控制这个概念那么我就知道了这是针对接收方的角度来进行约束发送方的发送速度而这里谈到的拥塞控制描述的是关于网络环境来影响发送方的发送速率

我们知道网络环境是非常复杂的如果存在一处地方发生了堵塞的情况那么就会导致接收方接收的速度再快也没有用发送方发送速度再快也没有用

如果按照某个窗口的大小进行发送数据发生了丢包那么就表示这个网络环境存在堵塞的情况那么就会减小窗口的大小如果没有出现丢包的情况那么就增大窗口的大小~~~

上述的方法简化了问题适应了复杂多变的网络情况在中间节点的位置什么时候拥堵什么时候不拥堵那么按照上述的描述就可以让发送的速率动态的变化

3.2拥塞控制机制

我们知道网络环境是非常复杂的那么对于拥塞控制的标准就是要靠实验来进行的

1.慢启动

如果上述的条件没有发生丢包那么就会增大窗口的大小此时的增长速率就是按照指数来进行增长的

3.线性增长

由于指数增长非常快为了保证网络不会发生阻塞拥堵的情况那么当达到一定的阈值后就会线性增长

4.重回再增长

由于线性增长的持续存在那么到达一定的时间后还是会发生网络堵塞引起丢包问题那么一旦发生丢包问题那么就会将拥塞窗口设置成一个较低的值那么此时又会重新开始

第一ack快速重传滑动窗口中的概念然后提醒说明此处发生了丢包的问题

第二在方法一过后直接将拥塞窗口降到最低然后重新设定阈值经典版本

第三在方法一过后直接将拥塞窗口降到一个新的阈值不是最低点这是新的版本没有慢启动和指数增长了传输的效率大大增加

️4.总结

本期小编主要讲解了关于TCP协议中比较重要的特性即滑动窗口流量控制以及拥塞控制当然这里每一节涉及到的丢包的问题和控制发送方的发送窗口对应的两种控制的机制需要大家好好的理解理解~~~

~~~~最后希望与诸君共勉共同进步