🔎滑动窗口

在这里插入图片描述

上图展示了一个固定大小为4个格子的窗口
不断的向前滑动, 每次向前滑动1个格子, 窗口的大小保持不变

在这里插入图片描述

按数据包进行确认应答

采用逐条发送数据的方式传输数据
这种方式花费了大量时间等待ACK

在这里插入图片描述

按滑动窗口方式并行处理

采用批量发送数据的方式传输数据(固定窗口大小)
每次收到一条ACK 就继续发送下一条数据(保持窗口的大小不变, 向前滑动)

通过滑动窗口的方式进行传输数据, 可以提高数据的传输效率

滑动窗口是在批量传输大量数据时, 才会采取的措施
如果数据量较少, 还是会采用逐条发送的方式传输数据

🔎流量控制

滑动窗口的窗口越大, 意味着批量发送的数据越多, 整体的传输速度也就越快

但如果发送的太快, 超出了接收方的接收能力(接收方的接收缓冲区满了)
此时继续发送, 数据就会丢包
这种情况就难免有些得不偿失, 还不如发送的慢些(流量控制)

流量控制的本质就是通过接收方来限制发送方的发送速度

在这里插入图片描述

当ACK 为1时(有效状态), 此时的窗口大小(16)位就会生效
窗口大小的值就是接收方建议发送方发送的窗口大小
(接收方将接收缓冲区的剩余空间作为窗口大小)

举个栗子🥝

在这里插入图片描述

当发送方发现接收方的接收缓冲区满了之后, 就会暂停发送
但是仍然会每隔一段时间发出一个窗口探测报文
如果探测一会发现接收方的接收缓冲区腾出空间了, 就会继续发送

在这里插入图片描述

🔎拥塞控制

在这里插入图片描述

如果说流量控制表示的是接收方的处理能力
那么拥塞控制表示的则是传输路径的处理能力

传输路径上任何一个设备的处理能力遇到瓶颈, 都会对整体的传输效率产生影响
而拥塞控制做的就是衡量中间节点的传输处理能力(找出木桶效应中那块最短的木板)

在这里插入图片描述
图片来自网络

拥塞控制, 衡量中间节点的传输能力
但每次传输的传输路径不同, 导致了中间路径上的节点个数不同, 每个节点的情况也有可能不同
而且网络的拥堵情况不是一成不变的(可以理解为一天之中不可能所有时间都会出现早高峰)
所以每次通过实验的方式, 找到合适的发送速率

根据上图所示进行实验
●拥塞窗口: 按照多大的速率发送数据(暂时不考虑流量控制的情况)
●传输轮次: 第几次发送(第一次发送, 第二次发送, 第三次发送…)
●慢开始: 刚开始传输, 会给一个非常小的窗口(传输速度较慢)
●指数规律增长: 每次增长的速度翻倍, 增长速度非常快(2 --> 4 --> 8 --> 16 --> 32…)
●ssthresh的初始值: 当指数增长达到阈值时, 就会变成线性增长(避免一下超过上限很多, 采用逐渐达到上限的方式)
●网络拥塞: 当线性增长增长到一定程度(出现丢包), 认为当前的窗口大小达到了上限, 就会在下一轮传输时开启新的慢开始

实验流程描述
(1)先以较低的传输速度开始传输(慢开始)
(2)然后以指数级的增长速度传输
(3)当传输速度达到阈值时, 传输速度就会转变为线性增长(为了避免一下超过上限很多)
(4)当线性增长到一定程度, 会出现丢包的现象(认为当前窗口, 达到当前路径的传输上限)
(5)继续新一轮的慢开始
注意: 下一轮的阈值为上一轮的上限的一半(第二轮慢开始的阈值为第一轮慢开始的上限值的一半)

拥塞窗口(拥塞控制实验出来的窗口)
流控窗口(流量控制产生的窗口)
滑动窗口的大小 = Math.min(拥塞窗口, 流控窗口)