敲黑板！！！
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个，收到接收方确认后，再发送下一个；
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适用于拥塞解决后（相当于拥塞发生前）。
另一个我们需要了解的概念：cwnd 是用于拥塞处理的窗口大小，取决于网络状况，由发送方探查网络主动调整。
慢启动算法
慢启动算法（Slow Start）作用在拥塞产生之前：对于刚刚加入网络的连接，要一点一点的提速，不要妄图一步到位。如下：
连接刚建好，初始化cwnd = 1（当然，通常不会初始化为1，太小），表明可以传一个MSS大小的数据。每收到一个ACK，cwnd++，线性增长。每经过一个RTT，cwnd = cwnd * 2，指数增长（主要增长来源）。还有一个ssthresh（slow start threshold），当cwnd >= ssthresh时，就会进入拥塞避免算法（见后）。因此，如果网速很快的话，Ack返回快，RTT短，那么，这个慢启动就一点也不慢。下图说明了这个过程：
拥塞避免算法前面说过，当cwnd >= ssthresh（通常ssthresh = 65535）时，就会进入拥塞避免算法（Congestion Avoidance）：缓慢增长，小心翼翼的找到最优值。如下：
每收到一个Ack，cwnd = cwnd + 1/cwnd，显然，cwnd > 1时无增长。每经过一个RTT，cwnd++，线性增长（主要增长来源）。慢启动算法主要呈指数增长，粗犷型，速度快（“慢”是相对于一步到位而言的）；而拥塞避免算法主要呈线性增长，精细型，速度慢，但更容易在不导致拥塞的情况下，找到网络环境的cwnd最优值。
拥塞发生时的算法慢启动与拥塞避免算法作用在拥塞发生前，采取不同的策略增大cwnd；如果已经发生拥塞，则需要采取策略减小cwnd。那么，TCP如何判断当前网络拥塞了呢？很简单，如果发送方发现有Seq发送失败（表现为“丢包”），就认为网络拥塞了。
丢包后，有两种重传方式，对应不同的网络情况，也就对应着两种拥塞发生时的控制算法：
超时重传。TCP认为这种情况太糟糕，调整力度比较大：ssthresh = cwnd /2cwnd = 1，重新进入慢启动过程（网络糟糕，要慢慢调整）快速重传。TCP认为这种情况通常比RTO超时好一些，主流实现TCP Reno的调整力度更柔和（TCP Tahoe的实现和RTO超时一样暴躁）：ssthresh = cwnd /2cwnd = 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.php.cn/link/fc3f0b553fd61e0a6b93792b735859f2
https://www.php.cn/link/c532c8500b58418bbf14edd4e346eb43
https://www.php.cn/link/4abd325e59c9705044764303dc5845b0
最后，小媛想说，如果你有哪方面的内容想要了解，可以在后台回复哦，我们会第一时间帮你解答或者直接发文！
作者：西瓜媛
编辑：西瓜媛
本文来自程序媛驿站，未经授权不得转载.
