滑动窗口
有一类算法题,就是通过滑动窗口的思想来解决的,算法中的“滑动窗口”借鉴自 TCP 的滑动窗口
TCP 是要保证可靠传输的==>代价,降低了传输的效率(重传,确认重传等操作)
TCP 希望能在可靠传输的基础上,也有一个不错的效率,就引入了“滑动窗口”
- 这里的提高效率,只是“亡羊补牢”,使传输效率的损失,尽可能降低
- 引入滑动窗口,也不能使传输效率比 UDP 还高
窗口
A 每次都需要收到 ACK 之后,再发下一个数据
- 低效,有大量的时间都消耗在等待 ACK 上
改进方案:
- 把“发送一个等待一个”改为“发送一批等待一批”
- 把多次等待 ACK 的时间合并时一份了
- 批量发送的数据越多,效率就越高
- 批量发送的数据中,不需要等待的数据的量,称为“窗口大小”
- 批量发送的是数据的字节数,而不是条
- 窗口就是一次能发多少数据,具体的数据量就是窗口大小
滑动
当收到了第一个 ACK
之后,不会继续等待剩下的 3 个 ACK
到了之后再发下一组,而是收到这个 ACK
之后,就立即发送下一条数据
- 收到
2001 ACK
,说明1001-2000
数据得到应答了 - 然后立即发送
5001-6000
这个数据,此时等待的ACK
范围就是2001-6000
(四份数据),窗口大小还是 4000 - 窗口大小不变,只是窗口所处的位置改变了
每收到一个 ACK,窗口就往后挪,因为 ACK 是接连不断的发送的,所以窗口就往后挪动了,就滑起来了
滑动窗口就是批量传输数据的一种实现方式
滑动窗口丢包
情况一:
不需要任何处理;批量发数据,批量 ACK,多个 ACK 只是丢其中的一部分,不可能全丢
确认序号的含义:表示的是收到的数据最后一个字节的下一个序号。进一步理解成,确认序号之前的数据,都已经收到了,接下来你要发的数据就从确认序号这里往后发
- 虽然 1001 ACK 丢了,但是 2001 ACK 到达了。发送方收到 2001 ACK 之后,意味着 2001 之前的数据都已经收到了
- 后一个
ACK
能涵盖前一个ACK
的意义
情况二:
1001-2000
丢包之后:
- 在
A
发过去2001-3000
之后,此时,B
收到的数据为:1-1000
,2001-3000
- 此时
B
收到2001-3000
的时候,返回的ACK
确认序号不是3001
,而是1001
B
就是在向A
索要1001
的数据- 接下来,
B
和搜到的3001-4000
,4001-5000
,5001-6000.
… 对应的ACK
确认序号都是1001
- 主机
A
连续收到1001
这样的ACK
之后,主机A
意识到1001
数据包丢了,于是主机重传1001-2000
- 当
1001-2000
重传过来之后,由于执勤啊2001-7000
数据都是已经发过了,此时的1001-2000
相当于是补全了之前的空缺,此时就意味着1-7000
的数据都齐了,于是接下来索要7001
开头的数据即可
上述过程,没有任何拖泥带水的操作,快速的识别出了是哪个数据丢包,并且针对性的进行了重传,其他顺利到达的数据都无需重传,这个过程称为“快速重传”
快速重传可以视为是“滑动窗口”下搭配的“超时重传”
滑动窗口/快速重传、确认应答/超时重传
他们彼此之间并不冲突。如果通信双方单位时间发送的数据量比较少,就是按照之前的确认应答/超时重传;如果单位时间内发送的数据比较多,就会按照滑动窗口/快速重传
流量控制
滑动窗口,窗口大小对于传输数据的性能是直接相关的,但窗口能无限大吗?
通信是双方的事,发送方发的快乐,你也得确保接收方能处理得过来
- 接收缓冲区:内核中的内存空间,每个
Socket
对象都有一个这样的缓冲区,其类似于一个阻塞队列(BlockingQueue
) - 这个传输过程就是一个“生产者消费者模型”
- 如果发送速度特别快,消费数据比较慢,就会使接收缓冲区满,此时如果继续强行发送数据,就会“丢包”(被接收方丢弃)
- 这里就需要根据接收方的处理能力,反向制约发送方的发送速度,这就是流量控制
此处可以通过“定量”的方式来实现制约,看接收缓冲区剩余空间大小
- 如果空闲空间比较大,就可以认为应用程序处理速度比较快
- 就可以让发送方发的快一点,设置一个更大的窗口大小
- 如果空闲空间比较小,就可以认为应用程序处理速度比较慢
- 就可以让发送方发的慢一点,设置一个更小的窗口大小
TCP 中,接收方收到数据的时候,就是把接收缓冲区剩余空间大小通过 ACK 数据报,反馈给发送方。之后发送方就可以依据这个数据来设置发送的窗口大小了
- 这里面的“
16
位窗口大小”体现了刚才谈到的接收方接收缓冲区的剩余空间,这个属性只有在ACK
报文中才有效(ACK
这一位为1
)
此处的 16 位表示范围 64KB,是否意味着发送方窗口大小最大就是 64KB 呢?
- 不是的
- 选项中,可以设置一个特殊的选项“窗口扩展因子”
- 发送方的窗口大小 = 窗口大小 << 窗口扩展因子(左移运算符)
- 左移一位就相当于
*2
此时假设接收方应用程序没有读取任何数据,就是一直在生产,却没有消费,最后发送方的窗口大小就变成 0 了,接收缓冲区就满了,发送方就不能再发送了。那发送方不发送数据,要等待多久呢?
- 原本是要通过 ACK 来知道对方接收缓冲区中的剩余空间的,但是不发送数据就没有 ACK 呀
- 所以当窗口大小为 0 的时候,等待一个“超时时间”后,会发送一个“窗口探测包”,不携带任何业务数据(载荷部分是空的),只是为了触发 ACK,通过这个操作来查询一下,接收方接收缓冲区剩余多少。如果还是 0,就过一会之后再查
- 接收方也会在接收缓冲区不为 0 的时候(消费了一定数据之后),主动触发一个“窗口更新通知”这样的数据,告诉接收方缓冲区内的余量情况
流量控制,也不是 TCP 独有的机制,其他的协议也可能会涉及到流量控制(比如,数据链路层中有的协议也支持流量控制)
拥塞控制
这个操作,也是和刚才的流量控制有关联的
- 滑动窗口==>踩油门
- 流量控制==>踩刹车
- 拥塞控制==>踩刹车
流量控制,是站在接收方的视角来限制发送方的速度
拥塞控制,是站在传输链路的视角来限制发送方的速度
假设 B 处理速度非常快,此时 A 可以无限速度的发送数据吗?
- 当然不行,中间的链路可能顶不住
- 此时节点 a 已经负载很高了,如果 A 发送很快,那么这个节点可能就直接丢包了
流量控制,就可以精准的使用接收方接收缓冲区来进行衡量
考量中间节点的情况就麻烦了
- 中间的节点非常多
- 每次传输数据,走的路线还都不一样
- 中间哪个节点遇到瓶颈了不清除
- 中间节点传输数据不止有 A 的,还有很多其他设备的数据
别害怕,可以通过做实验的方式,来找到一个合适的发送速度
- 在拥塞控制中,将中间所有的节点视为一个整体,不关心内部的细节
然后进行“实验”(面多加水,水多加面)
- 先按照一个比较小的速度,发送数据
- 数据非常畅通,没有丢包,说明网络上传输数据整体是比较畅通的,就可以加快传输数据的速度
- 增大到一定的速度之后,发现出现丢包了,说明网络上可能存在拥堵了,就减慢传输数据的速度
- 减速之后,发现又不丢包了,继续再加速
- 加速之后又丢包了,再减速
- …
一直持续地动态变化,这是很科学的,因为网络环境也是一直变化的,所以以变化应对变化
流量控制会限制发送窗口,拥塞控制也会限制发送窗口。这两个机制会同时起作用,最终实际的发送窗口大小,取决于上述两个机制得到的发送窗口较小值
窗口大小变化过程
-
刚开始传输数据,拥塞窗口会非常小,用一个很小的速度来发送数据(慢启动)
- 因为当前网络是否拥堵是未知的
-
不丢包,增大窗口大小(指数增长)
- 每过一轮,窗口大小就翻倍,增长速度特别快,会在短时间内达到很大的窗口大小
-
增长到一定程度,达到某个指定的阈值,此时即使没有丢包,也会停止指数增长,变成线性增长
- 这样就不会太快的进入丢包的节奏
-
线性增长也会持续使发送速度越来越快,达到某个情况下,就会出现丢包
- 一旦出现丢包,接下来就需要减慢发送速度,也就是减少窗口大小
此时有两种处理方式:
- 经典的方案,回归慢启动开始非常小的初始值,先指数增长,再线性增长
- 现在的方案,回归到新的阈值上,直接进行线性增长(以后都不会指数增长了)