一、流量控制
一般来说，我们总是希望数据传输得更快一些，但是如果发送方把数据发送得太快，接收方可能来不及接收，造成数据的丢失，数据重发，造成网络资源的浪费甚至网络拥塞。所谓的流量控制（flow control）就是让发送方的发送速率不要太快，要让接收方来得及接收。利用滑动窗口机制，就可以很方便的在TCP连接上实现流量控制。
用滑动窗口机制，使用关闭窗口控制发送方发送数据。发送方持续发送报文，但是接收方处理不过来，那就是浪费网络资源。
使⽤ Nagle 算法，用于自动连接许多的小缓冲消息；尽可能发送大块数据，避免网络中充斥着许多小数据块，浪费网络资源。
二、拥塞控制
网络是一个相当复杂的环境，我们发送数据不能只考虑交互两端的情况，基于交互两端的情况做出流量控制是不够的，我们还需要考虑网络的情况，网络上的包就像来来往往的车流，如果没有管制，那将是灾难的，试想，如果在十字路口没有红绿灯还没有交警，那将会发生什么？
1. 拥塞的形成
如上图，当数据到达一个大的管道（如一个快速局域网）并向一个较小的管道（如一个较慢的广域网）发送时便会发生拥塞。当多个输入流到达一个路由器，而路由器的输出流小于这些输入流的总和时也会发生拥塞。
上图显示了一个典型的大管道向小管道发送报文的情况。之所以说它典型，是因为大
多数的主机都连接在局域网上，并通过一个路由器与速率相对较低的广域网相连（我们再次
假定图中上半部分的报文段（9 ~ 20）都是相同的，而图中下半部分的 ACK也都是相同的）。
在该图中，我们已经标记路由器 R1为“瓶颈”，因为它是拥塞发生的地方。假定瓶颈路由器具有足够的容纳这 20个分组的缓存。那么将正常进行，否则，就会引起路由器丢弃分组。
而在TCP的实现上，数据包发送出去，我们通过一个计时器timer采样了RTT并计算RTO，如果因为网络拥堵，网络包应答超时或丢失，那么发送方将重发，而本身网络就处理能力有限而且拥堵，这时候还重发，试想如果成千上万的网络包都这样，这无疑雪上加霜，形成“网络风暴”，最后网络瘫痪。
2.拥塞窗口
前面我们说过，如果我们采用一问一答的方式，即我发送一个包，你应答一次，然后我再发送下一个包，这传输速率显然很慢，严重影响我们的用户体验，所以我们制定了一个策略：窗口控制（滑动窗口），即相应数量以内的包在未被确认的情况下，发送方也能继续发送，这提高了数据的传输速度。
下图为滑动窗口的初步商定：
但是我们只考虑发送方和接收方的情况下而进行窗口大小的设定，如果窗口过大，发送方一股脑的将数据快速传输出去，而网络的传输能力又有限，就会导致包的传输超时或者丢包。
所以，我们需要在上面窗口大小的基础上加上“网络传输能力”的限制，这个窗口的大小就是拥塞窗口。对拥塞窗口大小的调整就是拥塞控制。
注意：前面我们说过，发送窗口的大小受到接收方窗口大小和拥塞窗口大小的限制。
发送窗⼝的值是swnd = min(cwnd, rwnd)，也就是拥塞窗⼝和接收窗⼝中的最⼩值。
拥塞窗⼝ cwnd是发送⽅维护的⼀个的状态变量，它会根据⽹络的拥塞程度动态变化的。
3. 什么影响拥塞窗口的大小？
1）网络没有拥塞，拥塞窗口就会变大
2）网络有拥塞，拥塞窗口就会变小
另外，“网络是否拥塞”是通过是否发生了超时重传，超时重传就认为网络拥塞。
4. 了解TCP拥塞控制的前提
1）假设接收方的总是有足够大的缓冲区，发送方的发送窗口仅由网络的拥塞程度决定，不考虑接收方的接收窗口大小（事实上发送窗口的大小由拥塞窗口和接收方的接收窗口大小共同控制）
2）以最大报文段MSS的个数作为讨论单位，而不是以字节为单位
发送窗口、拥塞窗口、接收窗口实际都是以字节为单位，但是为了更好的探讨，使用报文段（MSS）为单位。
3）发送方以n个包的发送为一轮（在这n个包的发送过程内，不用考虑接收方是否应答）
5. 拥塞控制主要是四个方法（算法）：
1）慢启动，
2）拥塞避免，
3）拥塞发生，
4）快速恢复。
三次握手后，通过报文中的MSS选项得知通信双方最大报文的大小、窗口大小即滑动窗口大小。
TCP模块通常将MSS设置为（MTU-40）字节（减掉的这40字节包括20字节的TCP头部和20字节的IP头部）。这样携带TCP报文段的IP数据报的长度就不会超过MTU（假设TCP头部和IP头部都不包含选项字段，并且这也是一般情况），从而避免本机发生IP分片。对以太网而言，MSS值是1460（1500-40）字节。
窗口大小随着数据发送不断变化，发送端开始发送数据。
1）慢启动
前面我们讲到，发送端为了提高网络效率，不会发送一个确认一个，而是在一定范围内的报文发送不需要应答也能继续发送数据。于是有了滑动窗口。
同理，我们也不能上来就一股脑的发送报文数据，这会导致，接收端处理不过来，丢包；网络传输不过来，产生拥塞。
所以我们需要慢慢来，一步步的提高传输窗口，试探网络的承受能力，达到一个合理的值。
慢启动的规则：
- 当发送⽅每收到⼀个 ACK，拥塞窗⼝ cwnd 的⼤⼩就会加 1个MSS单位大小的字节数。
- 慢启动的拥塞窗口增加也不是没有上限的，有时我们会达到中间路由器的极限，此时分组将被丢弃。所以需要一个门限ssthresh，初始值为65535个字节。拥塞窗口初始化大小为1个MSS单位大小的字节数。
- 当慢启动阶段的拥塞窗口大小增长到门限ssthresh的时候，慢启动阶段结束，进入拥塞避免阶段。
可以看出慢启动算法，发包的个数是指数性的增⻓。
每个报文的应答确认ACK都会让拥塞窗口增加一个MSS单位的大小，如上图，第一个往返时间内的ACK让cwnd增加一个MSS的字节数，第二个往返时间段内发送2个，返回两个ACK，让窗口变成4个MSS大小的字节数，一次类推，直到cwnd >= ssthresh,停止慢启动，变为拥塞避免即这个时候就要注意增长不要让网络拥塞了，需要更小心的试探网络，让增长的幅度减小。
2）拥塞避免
慢启动阶段停止，进入拥塞避免阶段，这个阶段就是更加小心的慢慢试探网络情况，所以增长的幅度降低。
拥塞避免规则：
- 变成了每次ACK增长1/cwnd个单位的MSS，cwnd为本次往返时间内的拥塞窗口大小，MSS为最大报文段大小。那么本次往返时间段内共增加了1个MSS单位大小的字节数。
- 拥塞避免阶段也不可能无休止的增长上去，当触发了重传机制，也就进⼊了「拥塞发⽣算法」。
3）拥塞发生
当⽹络出现拥塞，也就会发⽣数据包重传，重传机制主要有两种：
- 超时重传
- 快速重传
超时重传，拥塞发生时的算法规则：
- 网络是复杂的，发生超时重传，发送方压根不知道网络发生了什么，只能往最坏的情况去想，我们假设网络拥堵严重，此时就只能让拥塞窗口即cwnd = 1MSS字节，重新试探网络。
- 既然是重新试探网络，则重新启动慢启动阶段。
- 但是由于第一次的教训，为了避免给网络添堵，sshthresh = cwnd /2，cwnd为发生超时重传时的拥塞窗口大小。
简要概括就是：
- cwnd = 1MSS字节，可谓是一夜回到解放前。
- sshthresh = cwnd /2，cwnd为发生超时重传时的拥塞窗口大小。
- 进入慢启动阶段。
快速重传，拥塞发生时的算法规则：
上面那种发生超时重传，网络流量断崖式下跌，这是武断的，所以人们在已有的基础上进行了改进，在收到3个重复的 ACK时就开启重传，而不用等到RTO超时，导致流量断崖式下跌。因为TCP认为，你都收到ACK了，说明网络也没有那么差。
快速重传，有两种实现方式：TCP Tahoe、TCP Reno。
- TCP Tahoe的实现和RTO超时一样。
- TCP Reno的实现是：
- cwnd = cwnd /2
- sshthresh = cwnd
- 进入快速恢复算法——Fast Recovery
4）快速恢复算法 Fast Recovery
快速重传和快速恢复算法一般同时使用。快速恢复算法是认为，你还有3个Duplicated Acks说明网络也不那么糟糕，所以没有必要像RTO超时那么强烈。 注意，正如前面所说，进入Fast Recovery之前，cwnd 和 sshthresh已被更新：
- cwnd = cwnd /2
- sshthresh = cwnd
快速恢复的算法规则如下：
TCP Reno版本
- cwnd = sshthresh + 3 * MSS （3的意思是确认有3个数据包被收到了）
- 重传3个重复ACK指定的数据包
- 如果再收到3个重复的ACK一样的ACK，那么认为重传成功，此时cwnd = cwnd +1MSS单位字节
- 如果收到了新的ACK，那么，cwnd = sshthresh ，然后就进入了拥塞避免的算法了。
TCP New Reno版本
上面这个算法也有问题，那就是——它依赖于3个重复的ACK。注意，3个重复的ACK并不代表只丢了一个数据包，很有可能是丢了好多包。但这个算法只会重传一个，而剩下的那些包只能等到RTO超时重传，于是，进入了恶梦模式——超时一个窗口就减半一下，多个超时会超成TCP的传输速度呈级数下降，而且也不会触发Fast Recovery算法了。
通常来说，正如我们前面所说的，SACK或D-SACK的方法可以让Fast Recovery或Sender在做决定时更聪明一些，但是并不是所有的TCP的实现都支持SACK（SACK需要两端都支持），所以，需要一个没有SACK的解决方案。而通过SACK进行拥塞控制的算法是FACK。
于是，1995年，TCP New Reno（参见 RFC 6582 ）算法提出来，主要就是在没有SACK的支持下改进Fast Recovery算法。
- 当sender这边收到了3个Duplicated Acks，进入Fast Retransimit模式，开发重传重复Acks指示的那个包。如果只有这一个包丢了，那么，重传这个包后回来的Ack会把整个已经被sender传输出去的数据ack回来。如果没有的话，说明有多个包丢了。我们叫这个ACK为Partial ACK。
- 一旦Sender这边发现了Partial ACK出现，那么，sender就可以推理出来有多个包被丢了，于是乎继续重传sliding window里未被ack的第一个包。直到再也收不到了Partial Ack，才真正结束Fast Recovery这个过程。
我们可以看到，这个“Fast Recovery的变更”是一个非常激进的玩法，他同时延长了Fast Retransmit和Fast Recovery的过程。
5）其他算法
TCP Vegas 拥塞控制算法
这个算法1994年被提出，它主要对TCP Reno 做了些修改。这个算法通过对RTT的非常重的监控来计算一个基准RTT。然后通过这个基准RTT来估计当前的网络实际带宽，如果实际带宽比我们的期望的带宽要小或是要多的活，那么就开始线性地减少或增加cwnd的大小。如果这个计算出来的RTT大于了Timeout后，那么，不等ack超时就直接重传。（Vegas 的核心思想是用RTT的值来影响拥塞窗口，而不是通过丢包） 这个算法的论文是《TCP Vegas: End to End Congestion Avoidance on a Global Internet》这篇论文给了Vegas和 New Reno的对比：
关于这个算法实现，你可以参看Linux源码：/net/ipv4/tcp_vegas.h， /net/ipv4/tcp_vegas.c
HSTCP(High Speed TCP) 算法
这个算法来自RFC 3649（Wikipedia词条）。其对最基础的算法进行了更改，他使得Congestion Window涨得快，减得慢。其中：
- 拥塞避免时的窗口增长方式： cwnd = cwnd + α(cwnd) / cwnd
- 丢包后窗口下降方式：cwnd = (1- β(cwnd))*cwnd
注：α(cwnd)和β(cwnd)都是函数，如果你要让他们和标准的TCP一样，那么让α(cwnd)=1，β(cwnd)=0.5就可以了。 对于α(cwnd)和β(cwnd)的值是个动态的变换的东西。 关于这个算法的实现，你可以参看Linux源码：/net/ipv4/tcp_highspeed.c
TCP BIC 算法
2004年，产内出BIC算法。现在你还可以查得到相关的新闻《Google：美科学家研发BIC-TCP协议 速度是DSL六千倍》 BIC全称Binary Increase Congestion control，在Linux 2.6.8中是默认拥塞控制算法。BIC的发明者发这么多的拥塞控制算法都在努力找一个合适的cwnd Congestion Window，而且BIC-TCP的提出者们看穿了事情的本质，其实这就是一个搜索的过程，所以BIC这个算法主要用的是Binary Search——二分查找来干这个事。 关于这个算法实现，你可以参看Linux源码：/net/ipv4/tcp_bic.c
TCP WestWood算法
westwood采用和Reno相同的慢启动算法、拥塞避免算法。westwood的主要改进方面：在发送端做带宽估计，当探测到丢包时，根据带宽值来设置拥塞窗口、慢启动阈值。 那么，这个算法是怎么测量带宽的？每个RTT时间，会测量一次带宽，测量带宽的公式很简单，就是这段RTT内成功被ack了多少字节。因为，这个带宽和用RTT计算RTO一样，也是需要从每个样本来平滑到一个值的——也是用一个加权移平均的公式。 另外，我们知道，如果一个网络的带宽是每秒可以发送X个字节，而RTT是一个数据发出去后确认需要的时候，所以，X * RTT应该是我们缓冲区大小。所以，在这个算法中，ssthresh的值就是est_BD * min-RTT(最小的RTT值)，如果丢包是Duplicated ACKs引起的，那么如果cwnd > ssthresh，则 cwin = ssthresh。如果是RTO引起的，cwnd = 1，进入慢启动。 关于这个算法实现，你可以参看Linux源码： /net/ipv4/tcp_westwood.c
拥塞算法示意图
以上就是拥塞控制的全部内容了，看完后，你再来看下⾯这张图⽚，每个过程我相信你都能明⽩：
拥塞避免是发送方使用的流量控制，而通告窗口则是接收方进行的流量控制。前者是发送方感受到的网络拥塞的估计，而后者则与接收方在该连接上的可用缓存大小有关。