面试必考 | TCP 协议（第三弹）—流量控制和拥塞控制

敲黑板！！！

TCP流量控制和拥塞控制在面试中也是经常会被问到的，找工作的童鞋们要掌握哦。

面试虐我千百遍，我待面试如初恋！

相关知识点

第一弹

a. TCP三次握手以及四次挥手过程描述；

b. 为什么要有三次握手和四次挥手；

第二弹

c. TIME_WAIT状态的描述以及作用；

d. TCP是通过哪些方式提供可靠性的？

第三弹

e. TCP流量控制与拥塞控制机制。

第一弹和第二弹的内容在以前的推文中发过，需要的童鞋可直戳

面试必考 | TCP 协议（第一弹）

面试必考 | TCP 协议（第二弹）

01 流量控制和拥塞控制的区别

在进行讲解之前，我们先明确两个概念：

MMS（Maximum Segment Size）：TCP一次传输发送的最大数据段长度。

RTT（Round-Trip Time）：往返时延，表示从发送端发送数据开始，到发送端收到来自接收端的确认（接收端收到数据后便立即发送确认），总共经历的时延。

TCP传输大块数据时，肯定需要进行数据分段，而每个分段所能携带的最大数据就是1个MSS，假设大块数据为100个MSS，那么发送方发送的方式大概有如下两种：

1、 每次发送1个，收到接收方确认后，才发送下1个；

2、 一口气发送100个，然后收到对方一起确认；显然，方式1中，一个RTT只能处理一个包，这样的传输效率太低了。

而方式2看似很美好，实际会存在两个问题，一个是接收方的接收窗口未必能一次性接收这么多数据，另外一个是网络的带宽也不一定足够大，容易出现丢包事故。

前一个问题就是标题中的流量控制(Flow control)，TCP采用的是滑动窗口机制(Sliding window)，后一个问题就是标题中的拥塞控制(Congestion control)。

发送方的发送窗口或者说网络传输交互就取决于这两个问题的控制，谁控制的更严格，谁就占据了决定性因素，这也是为什么两者总是一起出现一起被讨论。

流量控制是端到端的控制，例如A通过网络给B发数据，A发送的太快导致B没法接收(B缓冲窗口过小或者处理过慢)，这时候的控制就是流量控制，原理是通过滑动窗口的大小改变来实现。其目的就是让发送方的发送速率不要太快，让接收方来得及接收。

拥塞控制是A与B之间的网络发生堵塞导致传输过慢或者丢包，来不及传输。防止过多的数据注入到网络中，这样可以使网络中的路由器或链路不至于过载。拥塞控制是一个全局性的过程，涉及到所有的主机、路由器，以及与降低网络性能有关的所有因素。

02 流量控制

流量控制由滑动窗口协议来实现。

滑动窗口协议既保证了分组无差错、有序接收，也实现了流量控制。主要的方式就是接收方返回的 ACK 中会包含自己的接收窗口的大小，并且利用大小来控制发送方的数据发送。

下面给大家提供一个例子，来说明传输过程中是如何把滑动窗变为0的。

接收方在Ack中记录自己还能接收的数据量大小 Advertisedwindow。

AdvertisedWindow = MaxRcvBuffer – (LastByteRcvd -LastByteRead)

随Ack回复到发送方。

TCP的发送端缓存结构 发送端的缓存按照包的ID一个个排列，分成4个部分： （一）发送并且已经确认的 （二）发送了并且尚未确认的 （三）没有发送，但是已经确认要发送在等待的 （四）没有发送，并且暂时不会发送的 第三和第四部分区分开是为了流量控制，流量控制的依据是什么？TCP里接收端会给发送端报告一个窗口大小，叫Advertised Window。发送端需要保证上面第二和第三部分的长度加起来等于Advertised Window。

接收端缓存结构 接收端的缓存分成三个部分： （一）接受并且确认过的 （二）还没接收，但是马上就能接收的，要等空格填满 （三）还没接收，也没法接收的，也就是超过工作量（max buffer）的部分

• MaxRcvBuffer：最大缓存的量
• LastByteRead之后是已经接收了，但是还没被应用层消耗
• NextByteExpected之后是等待接收的

Advertised Window其实就是等待接收未确认部分的大小。其中这部分中有可能是有空挡的，比如7到14有，但6是空的。那NextByteExpected就只能待在这个位置了。

03 拥塞控制

TCP拥塞控制机制主要是要避免两种现象：包重传和包丢失。

网络的带宽是固定的，当发送端发送速度超过带宽后，中间设备处理不完多出来的包就会被丢弃，这就是包丢失。

如果我们在中间设备上加上缓存，处理不过来的包就会被加到缓存队列中，不会丢失，但是会增加时延。如果时延到达一定的程度，就会超时重传，这就是包重传。

拥塞发生前，可避免流量过快增长拖垮网络；拥塞发生时，唯一的选择就是降低流量。主要使用4种算法完成拥塞控制：

1. 慢启动
2. 拥塞避免
3. 拥塞发生
4. 快速恢复

算法1、2适用于拥塞发生前，算法3适用于拥塞发生时，算法4适用于拥塞解决后（相当于拥塞发生前）。

另一个我们需要了解的概念：cwnd 是用于拥塞处理的窗口大小，取决于网络状况，由发送方探查网络主动调整。

慢启动算法

慢启动算法（Slow Start）作用在拥塞产生之前：对于刚刚加入网络的连接，要一点一点的提速，不要妄图一步到位。如下：

1. 连接刚建好，初始化cwnd = 1（当然，通常不会初始化为1，太小），表明可以传一个MSS大小的数据。
2. 每收到一个ACK，cwnd++，线性增长。
3. 每经过一个RTT，cwnd = cwnd * 2，指数增长（主要增长来源）。
4. 还有一个ssthresh（slow start threshold），当cwnd >= ssthresh时，就会进入拥塞避免算法（见后）。

因此，如果网速很快的话，Ack返回快，RTT短，那么，这个慢启动就一点也不慢。下图说明了这个过程：

拥塞避免算法

前面说过，当cwnd >= ssthresh（通常ssthresh = 65535）时，就会进入拥塞避免算法（Congestion Avoidance）：缓慢增长，小心翼翼的找到最优值。如下：

1. 每收到一个Ack，cwnd = cwnd + 1/cwnd，显然，cwnd > 1时无增长。
2. 每经过一个RTT，cwnd++，线性增长（主要增长来源）。

慢启动算法主要呈指数增长，粗犷型，速度快（“慢”是相对于一步到位而言的）；而拥塞避免算法主要呈线性增长，精细型，速度慢，但更容易在不导致拥塞的情况下，找到网络环境的cwnd最优值。

拥塞发生时的算法

慢启动与拥塞避免算法作用在拥塞发生前，采取不同的策略增大cwnd；如果已经发生拥塞，则需要采取策略减小cwnd。那么，TCP如何判断当前网络拥塞了呢？很简单，如果发送方发现有Seq发送失败（表现为“丢包”），就认为网络拥塞了。

丢包后，有两种重传方式，对应不同的网络情况，也就对应着两种拥塞发生时的控制算法：

1. 超时重传。TCP认为这种情况太糟糕，调整力度比较大：
   1. ssthresh = cwnd /2
   2. cwnd = 1，重新进入慢启动过程（网络糟糕，要慢慢调整）
2. 快速重传。TCP认为这种情况通常比RTO超时好一些，主流实现TCP Reno的调整力度更柔和（TCP Tahoe的实现和RTO超时一样暴躁）：
   1. ssthresh = cwnd /2
   2. cwnd = cwnd /2，进入快速恢复算法（网络没那么糟，可以快速调整，见下）

可以看到，不管是哪种重传方式，ssthresh都会变成cwnd的一半，仍然是指数回退，待拥塞消失后再逐渐增长回到新的最优值，总体上在最优值（动态）附近震荡。

回退后，根据不同的网络情况，可以选择不同的恢复算法。

快速恢复 接着上一段拥塞发生的第二种情况，快速恢复算法的逻辑如下:

• cwnd = sshthresh + 3 * MSS （3的意思是确认收到3个重复的 ACKs）
• 重传Duplicated ACKs指定的数据包
• 如果再收到 duplicated Acks，那么cwnd = cwnd +1
• 如果收到了新的Ack，那么，cwnd = sshthresh ，然后就进入了拥塞避免的算法了。 其他的恢复算法有FACK，TCP Vegas等。 存在问题 拥塞控制用以上的方法控制窗口的大小有两个问题： 1）丢包不代表通道满了，也有可能是网络本来就有问题，所以这个时候收缩时不对的 2）等到发生丢包再收缩，其实已经晚了，应该在刚好用满时就不再加了

基于以上两个问题，又出现了TCP BBR拥塞算法。

更多的算法，可以从Wikipedia的 TCP Congestion Avoidance Algorithm 词条中找。

本文参考书籍主要为：

《TCP/IP 详解 卷一：协议》

https://www.jianshu.com/p/bf4f8ad18812

https://www.jianshu.com/p/f884ecc94c8f

https://www.cnblogs.com/iou123lg/p/9017044.html

最后，小媛想说，如果你有哪方面的内容想要了解，可以在后台回复哦，我们会第一时间帮你解答或者直接发文！

作者：西瓜媛

编辑：西瓜媛

本文来自程序媛驿站，未经授权不得转载.