🔎滑动窗口
上图展示了一个固定大小为4个格子的窗口
不断的向前滑动, 每次向前滑动1个格子, 窗口的大小保持不变
按数据包进行确认应答
采用逐条发送数据的方式传输数据
这种方式花费了大量时间等待ACK
按滑动窗口方式并行处理
采用批量发送数据的方式传输数据(固定窗口大小)
每次收到一条ACK 就继续发送下一条数据(保持窗口的大小不变, 向前滑动)
通过滑动窗口的方式进行传输数据, 可以提高数据的传输效率
滑动窗口是在批量传输大量数据时, 才会采取的措施
如果数据量较少, 还是会采用逐条发送的方式传输数据
🔎流量控制
滑动窗口的窗口越大, 意味着批量发送的数据越多, 整体的传输速度也就越快
但如果发送的太快, 超出了接收方的接收能力(接收方的接收缓冲区满了)
此时继续发送, 数据就会丢包
这种情况就难免有些得不偿失, 还不如发送的慢些(流量控制)
流量控制的本质就是通过接收方来限制发送方的发送速度
当ACK 为1时(有效状态), 此时的窗口大小(16)位就会生效
窗口大小的值就是接收方建议发送方发送的窗口大小
(接收方将接收缓冲区的剩余空间作为窗口大小)
举个栗子🥝
当发送方发现接收方的接收缓冲区满了之后, 就会暂停发送
但是仍然会每隔一段时间发出一个窗口探测报文
如果探测一会发现接收方的接收缓冲区腾出空间了, 就会继续发送
🔎拥塞控制
如果说流量控制表示的是接收方的处理能力
那么拥塞控制表示的则是传输路径的处理能力
传输路径上任何一个设备的处理能力遇到瓶颈, 都会对整体的传输效率产生影响
而拥塞控制做的就是衡量中间节点的传输处理能力(找出木桶效应中那块最短的木板)
图片来自网络
拥塞控制, 衡量中间节点的传输能力
但每次传输的传输路径不同, 导致了中间路径上的节点个数不同, 每个节点的情况也有可能不同
而且网络的拥堵情况不是一成不变的(可以理解为一天之中不可能所有时间都会出现早高峰)
所以每次通过实验的方式, 找到合适的发送速率
根据上图所示进行实验
●拥塞窗口: 按照多大的速率发送数据(暂时不考虑流量控制的情况)
●传输轮次: 第几次发送(第一次发送, 第二次发送, 第三次发送…)
●慢开始: 刚开始传输, 会给一个非常小的窗口(传输速度较慢)
●指数规律增长: 每次增长的速度翻倍, 增长速度非常快(2 --> 4 --> 8 --> 16 --> 32…)
●ssthresh的初始值: 当指数增长达到阈值时, 就会变成线性增长(避免一下超过上限很多, 采用逐渐达到上限的方式)
●网络拥塞: 当线性增长增长到一定程度(出现丢包), 认为当前的窗口大小达到了上限, 就会在下一轮传输时开启新的慢开始
实验流程描述
(1)先以较低的传输速度开始传输(慢开始)
(2)然后以指数级的增长速度传输
(3)当传输速度达到阈值时, 传输速度就会转变为线性增长(为了避免一下超过上限很多)
(4)当线性增长到一定程度, 会出现丢包的现象(认为当前窗口, 达到当前路径的传输上限)
(5)继续新一轮的慢开始
注意: 下一轮的阈值为上一轮的上限的一半(第二轮慢开始的阈值为第一轮慢开始的上限值的一半)
拥塞窗口(拥塞控制实验出来的窗口)
流控窗口(流量控制产生的窗口)
滑动窗口的大小 = Math.min(拥塞窗口, 流控窗口)
🔎延时应答
读取到数据立即返回ACK, 此时ACK 里面带有的窗口大小设为N
当等待片刻, 再去返回ACK, 此时ACK 里面带有的窗口大小, 大概率＞N
(等待过程中, 应用程序消费接收缓冲区中的数据)
延时应答的效果
就是通过延时, 让接收方的应用程序利用延时的这段时间多读取一些数据
这样返回的ACK 携带的窗口就会大一些, 这样发送方的发送效率就会快一些(仍然满足流量控制)
🔎捎带应答
捎带应答是基于延时应答的一种模式
基于延时应答
此时的 I am fine, thank you(ACK)会稍等一会再发送
就可能会把 And you捎带着一起发送(捎带应答)
🔎面向字节流(粘包问题)
当A 给B 连续发了多个应用层数据报之后
这些数据就累积到B 的接收缓冲区, 紧紧的挨在一起
此时B 的应用程序读取数据时, 就难以区分从哪到哪是一个完整的应用层数据报
举个栗子🥝
同学B
有可能将您看看我是那人吗
理解为(1)您看看我 (2)是那人吗
此时同学B 的接收缓冲区就难以区分从哪到哪是一个完整的应用层数据报
解决方法
(1)定义分隔符(类似于我们将每句话的结尾加上个句号, 代表一句话的结束)
(2)约定长度(类似于约定一句话的最长范围, 超过这个范围, 就不是这句话了)
🔎异常情况
(1)进程关闭 / 进程崩溃
进程虽然没了, 但是连接还在, 仍然可以四次挥手(断开连接)
(2)主机关闭(正常流程关机)
主机关闭会先关闭所有的用户进程
(可能进行完整的四次挥手, 也可能无法进行完整的四次挥手)
a. 进行完整的四次挥手
正常断开连接
b. 未进行完整的四次挥手
比如当对方发送fin, 还未来得及ACK 就关机了
此时对方就会超时重传fin, 重传几次之后, 发现都没有ACK, 就会尝试重置连接
如果还不行, 就会断开连接
(3)主机断电(非正常流程关机)
机器瞬间关闭, 来不及挥手
有两种可能: a. 对方是发送方 b. 对方是接收方
a. 对方是发送方
对方发送fin, 收不到ACK
超时重传fin, 重传几次之后, 发现都没有ACK, 尝试重置连接
如果还不行, 就会断开连接
b. 对方是接收方
对方无法知道发送方是直接没了还是没来的及发送新的数据
于是引出了“心跳包”
心跳包的属性: (1)周期性的 (2)没有心跳了, 表示挂了
于是接收方通过定期给发送方发送心跳包判断接收方是否还存在
如果存在, 等待发送方发送数据
如果不存在, 断开连接
(4)网线断开
这种情况与(3)主机断电相同
🔎总结
