滑动窗口、流量控制 以及拥塞控制
- [1. 滑动窗口(效率机制)](#1. 滑动窗口(效率机制))
- [2. 流量控制(安全机制)](#2. 流量控制(安全机制))
- [3. 拥塞控制(安全机制)](#3. 拥塞控制(安全机制))
1. 滑动窗口(效率机制)
TCP 使用 确认应答 策略,对每一个发送的数据段,都要给一个 ACK 确认应答。收到 ACK 后再发送下一个数据段。这样做有一个比较大的缺点,就是性能较差。尤其是数据往返的时间较长的时候。
既然这样一发一收的方式性能较低,那么我们一次发送多条数据,使用滑动窗口,就可以大大的提高性能(其实是将多个段的等待时间重叠在一起了)。
滑动窗口存在的意义就是在保证可靠性的前提下,尽量提高效率。
- 窗口大小指的是无需等待确认应答而可以继续发送数据的最大值。上图的窗口大小就是 4000 个字节(四个段)。
- 发送前四个段的时候,不需要等待任何 ACK,直接发送;
- 收到第一个 ACK 后,滑动窗口向后移动,继续发送第五个段的数据;依次类推;
(相当于一份等待时间等待多份 ACK, 当然不能不等,可靠传输的灵魂就是确认应答, 若没有 ACK,可靠传输就形同虚设。) - 操作系统内核为了维护这个滑动窗口,需要开辟 发送缓冲区 来记录当前还有哪些数据没有应答;只有确认应答过的数据,才能从缓冲区删掉;
- 在一定范围内,窗口越大,传输速率就越快,网络的吞吐率就越高
那么如果出现了丢包,如何进行重传?这里分两种情况讨论。
- 情况一:数据包已经抵达,ACK 被丢了。
这种情况下,部分 ACK 丢了并不要紧,因为可以通过后续的ACK进行确认.
ACK 的确认号有特定含义,保证后一条 ACK 覆盖前一条,
比如并没有收到 1001 ACK, 但是收到了 2001 ACK 就说明 2001 之前的数据全部已经收到了。
若发送 4001 ~ 5000 之前,只收到了 4001, 但是它的意思是,4001 之前的都收到了,窗口就可以一次往下挪动 4 个。
- 情况二:数据包就直接丢了。
- 当某一段报文段丢失之后,发送端会一直收到 1001 这样的 ACK,就像是在提醒发送端 "我想要的是 1001" 一样;
- 如果发送端主机连续三次收到了同样一个 "1001" 这样的应答,就会将对应的数据 1001 - 2000 重新发送;
- 这个时候接收端收到了 1001 之后,再次返回的 ACK 就是 7001 了(因为2001 - 7000)接收端其实之前就已经收到了,被放到了接收端操作系统内核的接收缓冲区中;
(重传只需要把丢的数据重传就行了,后面已经传过的数据不用再传了。)
这种机制被称为 "高速重发控制"(也叫 "快重传")。
(为什么说是 "快" 重传,因为可能收到三个连续相同的 ACK 的时间内还没有触发超时机制,也就是还没超时呢,但是不等触发超时,直接就重传了。)
2. 流量控制(安全机制)
流量控制是滑动窗口的延伸,目的是为了保证可靠性。
- 在一定范围内,滑动窗口越大传输效率就越高,但是不能只考虑发送方,不考虑接收方,
- 接收端处理数据的速度是有限的。如果发送端发的太快,导致接收端的缓冲区被打满,这个时候如果发送端继续发送,就会造成丢包,继而引起丢包重传等等一系列连锁反应。
因此 TCP 支持根据接收端的处理能力,来决定发送端的发送速度。这个机制就叫做流量控制(Flow Control);
- 接收端将自己可以接收的缓冲区大小放入 TCP 首部中的 "窗口大小" 字段,通过 ACK 端通知发送端;
- 发送方接收到这个这个数据后,就会灵活的调整发送速度,调整窗口大小
- 窗口大小字段越大,说明网络的吞吐量越高;
- 接收端一旦发现自己的缓冲区快满了,就会将窗口大小设置成一个更小的值通知给发送端;
- 发送端接受到这个窗口之后,就会减慢自己的发送速度;
- 如果接收端缓冲区满了,就会将窗口置为 0;
- 这时发送方不再发送数据,但是需要定期发送一个窗口探测数据段,使接收端把窗口大小告诉发送端。
-
接收端如何把窗口大小告诉发送端呢?
回忆我们的 TCP 首部中,有一个16 位窗口字段,就是存放了窗口大小信息;
-
那么问题来了,16 位数字最大表示 65535,那么 TCP 窗口最大就是 65535 字节么?
实际上,TCP 首部40字节选项中还包含了一个窗口扩大因子 M,实际窗口大小是 窗口字段的值左移 M 位即 65535 * 2 ^M
3. 拥塞控制(安全机制)
拥塞控制,也是滑动窗口的延伸,限制滑动窗口的发送速率。
拥塞控制描述的是发送方到接收方整个链路直接的拥堵情况。
- 最终的滑动窗口的大小 = Min (流量控制窗口,拥塞控制窗口)
虽然TCP有了滑动窗口这个大杀器,能够高效可靠的发送大量的数据。
但是如果在刚开始阶段就发送大量的数据,仍然可能引发问题。
因为网络上有很多的计算机,可能当前的网络状态就已经比较拥堵。在不清楚当前网络状态下,贸然发送大量的数据,是很有可能引起雪上加霜的。
- 发送方开始时以一个较小的窗口来发送数据,
- 若数据很流畅到达,就逐渐加大窗口大小,
- 若加大到一定程度出现丢包,就减小窗口,
- 通过反复的增大/减小过程,逐渐找到一个合适的范围,拥塞窗口就在这个范围中不断变化,达到一个 "动态平衡"。
具体拥塞窗口是怎么变化的呢 ?
- 慢开始
初始值 窗口大小为 1, 然后以指数级别增长,"慢开始" 只是指初使时慢,但是增长速度非常快。 - 拥塞避免
窗口值到达 ssthresh 时,从指数增长变为 线性增长。 - 网络拥塞
出现大量丢包情况,说明网络拥塞了,拥塞窗口大小直接变为 1 。ssthresh 阈值变为此时拥塞窗口大小的一半,图中就是从 变为 24 的一半 12 。
(少量的丢包,我们仅仅是触发超时重传;大量的丢包,我们就认为网络拥塞;) - 然后重新慢开始,循环这个过程。
当TCP通信开始后,网络吞吐量会逐渐上升;随着网络发生拥堵,吞吐量会立刻下降;
-
为什么使用指数级别的增长速度 ?
因为希望能快速接近 ssthresh 阈值, 既希望速度快,又希望不大量丢包,如果初始情况给的窗口大小很小,可能合适的值是个很大的值,那么使用指数增长的话,能够很快的接近这个值。
-
ssthresh 的意义 ?
决定了什么时候从指数增长变为线性增长
-
拥塞窗口最理想的大小 ?
ssthresh 值与 出现拥塞的这个值之间是最理想的效果,这个范围之间传输速率较快,并且没有大量丢包。
-
为什么出现拥塞时,直接让窗口变为初始值 1 ?
因为网络的情况很复杂,不稳定,如果出现大量丢包,很可能速度降下来一点是不能解决问题的,速度降得太慢还会有可能出现持续丢包,就会对网络质量带来很大影响,一下让窗口变得很小,就是期望这次传输一定能成功。
拥塞控制,归根结底是TCP协议想尽可能快的把数据传输给对方,但是又要避免给网络造成太大压力的折中方案。
常见面试题:
- UDP 本身是无连接,不可靠,面向数据报的协议,如果要基于传输层UDP协议,来实现一个可靠传输,应该如何设计?
- UDP 大小是受限的,如果要基于传输层UDP协议,传输超过64K的数据,应该如何设计?
以上两个问题答案类似,都可以参考TCP的可靠性机制然后在应用层实现类似的逻辑:
如:
- 引入序列号,保证数据顺序;
- 引入确认应答,确保对端收到了数据,保证可靠传输;
- 引入超时重传,如果隔一段时间没有应答,就重发数据;
- 引入滑动窗口;
- 引入窗口扩大选项;
- 引入流量控制
- 引入拥塞控制
- ......
好啦! 以上就是对 TCP 滑动窗口、流量控制 以及拥塞控制的讲解,希望能帮到你 !
评论区欢迎指正 !