一开始，我总是容易把这2个概念搞混淆了，因此，为了加深理解，我写出来整理下思路。
一：流量控制
什么是流量控制，它涉及到哪些内容呢？
首先，我们看看一个最简单的tcp传输涉及到哪些东西
发送端，数据，网络，接收端（对端）
最基本的就是这4个对象。
流量控制是什么： 流量是什么？肯定就是数据。因为数据流动就形成了流量。
控制呢，控制谁？谁被控制？这就涉及到发送端和接收端了。这2端来进行“控制”和“被控制”。
正常情况下，发送端发送数据，接收端接收数据。就这么一个过程。2端也相安无事。
突然，发生了不正常情况，发送端发送数据加快了，接收端按照原先的情况接收数据就接收不过来，接收端缓冲区满了，不能在装多余的数据了，那多余的数据就会被丢弃，这样会导致发送端触发重发机制重发数据。所以必须进行控制。
流量控制就是：
如果发送端发送的数据过快，接收端来不及接收，那么分组数据就会丢失。为了避免这种数据丢失，就需要控制发送者的速度，使得接收者来得及接收，这就是流量控制。
为了控制发送者的速度，我们要怎么做呢？
TCP最开始是以1个段为单位进行数据发送，每发送一个段就进行一次确认应答处理。想想看，这样的传输方式有什么缺点呢，是不是传输的量少，传输效率就下降，且确认应答也会增多。
既然传输1个段有这些问题，那我一次能不能多传几个段呢？当然是可以的，这就引入了窗口的概念。多个段组成一个窗口进行连续发送。
前面我们讲数据超时重发时，说过序列号，就是对传送的数据按顺序进行编号。窗口就用到了这个序列号，利用序列号来进行分段编号。然后把分段组织起来变成一个窗口。
把数据分段编号，比如：
- 1-1000 为第一段
- 1001-2000 为第二段
- 2001-3000 为第三段
- 3001-4000 为第四段
- 4001-5000 为第五段
把数据进行了分段，这时候发送端发送一个段以后不必要一直等待确认应答，而是可以继续发送数据。而接收端确认时，不必每次确认，而是可以以更大的单位进行确认。
但是发送端也不能一直发送不进行确认，这样发送端不知道接收端是啥子情况。所以整理我们必须也控制一下，比如说我发送4个分段，就需要进行确认才发送新的数据。这4个分段就组成了一个窗口大小。
窗口大小：
就是指无需等待确认应答就可以继续发送数据的最大值
这个机制使用了大量缓冲区，通过对多个段同时确认应答。
接收端的窗口大小，发送端是怎么知道的？
1、建立连接时
接收端发送ACK确认时会告诉发送端，我接收端的窗口大小是多少。tcp里用rwnd表示（receiver window，接收端窗口）
2、建立连接后发送数据
接收方每次收到数据包后在发送确认报文时，同时告诉发送方自己的缓存区还剩余多少是空闲，我们也把缓存区的剩余大小称之为接收窗口大小，用变量win来表示接收窗口的大小。
发送方收到之后，便会调整自己的发送速率，也就是调整自己发送窗口的大小，当发送方收到接收窗口的大小为0时，发送方就会停止发送数据，防止出现大量丢包情况的发生。
在TCP的首部中，有一个16位窗口字段，此字段就是用来存放窗口大小信息的
假如我们有如下分段数组需要发送：
- 1-1000 为第一段
- 1001-2000 为第二段
- 2001-3000 为第三段
- 3001-4000 为第四段
- 4001-5000 为第五段
- ... ...
|1-1000|1001-2000|2001-3000|3001-4000|4001-5000|50001-6000|6001-7000|70001-8000|... ...|
比如1001-5000 组成一个窗口（四个分段）进行数据发送，在这个窗口内的数据即使没有收到确认应答也可以发送出去。如果从该窗口发送的数据在传输中丢失，也需要进行重发。因此，发送端主机在等待应答号返回前，也必须在缓冲区中保留这部分数据。
在收到确认应答的情况下，可以将窗口位置滑动到确认应答号的位置。这样可以顺序的将多个分段同时发送以提高通信的效率和性能。这种机制就叫滑动窗口机制。当然这个窗口大小也是会根据接收端返回的应答窗口大小进行调整。这个就是流控制（流量控制）。
每次接收端返回一个确认号，比如2001，3001，4001，收到3个确认号，没有收到5001，那么接收端会重复发3次4001，发送端主机连续3次收到同一个确认应答，就会对其进行重发。这个机制比超时管理更有效，因此也称为快速重发控制。
二：拥塞控制
还是让我们首先来看看，一个最简单的tcp传输涉及到哪些东西
发送端，数据，网络，接收端（对端）
流量控制是针对发送端的，是接收端指示发送端使用多大的发送窗口。拥塞控制是针对网络的。他俩是不同的。
网络发生拥塞了，当然整个网络的传输速率就会下降了。其实网络里包含路由器，交换机，主机等多种网络设备。
当主机发送到网络的数据包数量超过了网络的承载能力时，就会发生拥塞。如果在继续大量发送，就可能造成网络崩溃。
方法一：
TCP的拥塞控制策略：
TCP处理拥塞策略一般基于3个阶段：慢开始、拥塞避免 和 拥塞检测。
慢开始：指数增大
慢开始：发送端从非常慢的传输速率开始，但是很快就把速率增大到一个阙值。当到达阙值门限后，数据的增长开始放慢。最后，只要一检测到拥塞，发送端就回到慢开始或者拥塞避免阶段。
慢开始：指数增大
慢开始算法的思想：即拥塞窗口cwnd从1个最大报文段的长度（MSS）开始。MSS的数值是在连接建立时来确定的。每当一个报文被确认，拥塞窗口就增大1个MSS。随后是2,4,8...，按指数规律增大。
以下说明这个指数增长的规律：
发送方从cwnd=1 MSS 开始。在第一个ACK到达后，拥塞窗口增加1，也就是说现在cwnd=2。此时发送2个报文段。当相应2个ACK到达后，对于每一个ACK，窗口大小增加1 MSS，这就表示现在cwnd=4。此时发送4个报文段。当4个ACK到达后，窗口大小又增加4，也就是cwnd=8。 依次类推...
但是慢开始也不能无限的增长下去。慢开始无限增大，cwnd也会变得很大，这样必然会造成网络拥塞，所以要有一个停止阶段。发送方有一个称为ssthresh（慢开始门限）的变量。 当以字节计算的窗口大小达到这个ssthresh值时，慢开始阶段结束，++并进入下一个阶段++ - 拥塞避免。
拥塞避免：加法增大
拥塞避免：加法增大
我们从慢开始算法开始，拥塞窗口大小按照指数规律增长。但是为了发生拥塞之前避免它，就必须使指数增长变慢。于是TCP又定义了另外一个算法，叫做拥塞避免（congestion avoidance），使cwnd的值按照加法规律增长，而不是按照指数规律增长。
当拥塞窗口的大小达到慢开始的门限时（ssthresh），慢开始阶段就停止了，这时，加法增加阶段就开始了。
加法增的算法思想：
每当一个整个窗口中的报文段被确认后，拥塞窗口大小才增加1。 一个窗口就是指在一个RTT期间传输的报文段的数量。换言之，这个增长是基于RTT的，而不是基于到达的ACK的数量。
加法增的算法规律：
- 1.开始时： cwnd = i
- 2.经过1 RTT后： cwnd = i + 1
- 3.经过2 RTT后： cwnd = i + 2
- 4.经过3 RTT后： cwnd = i + 3
在拥塞避免算法中，拥塞窗口的大小按照加法规律增长，直到检测到拥塞为止。
拥塞检测：乘法减小
那怎么才能检测到拥塞现象呢？
做法就是：让发送方重传一个报文段。
这是TCP做出的一个重要的假设，之所以要重传报文是为了恢复一个遗失的分组，而这个分组假设是因为某个路由器有太多的输入分组而不得不丢弃，也就是说，路由器或者网络已变得超载和拥塞了。
重传可以发生以下2中情况：
- 1.当RTO计时器超时
- 2.当收到了三个重复的ACK应答时
反正不管哪一种情况，门限值都要下降到一半（乘法减小）。
整个拥塞流程梳理下：
1）拥塞窗口cwnd初始化为1个报文段，慢开始门限初始值为16
2）执行慢开始算法，指数规律增长到第4轮，即cwnd=16=ssthresh，改为执行拥塞避免算法，拥塞窗口按线性规律增长
3）假定cwnd=24时，网络出现超时（拥塞），则更新后的ssthresh=12，cwnd重新设置为1，并执行慢开始算法。当cwnd=12=ssthresh时，改为执行拥塞避免算法
“拥塞避免”并非完全能够避免了阻塞，而是使网络比较不容易出现拥塞。
方法二：快速重传、快速恢复
在前面流量控制里讲过整个快速重传机制。 就是一个发送端的数据包丢失了，怎么才能快速识别出来已经丢失了呢？ 而不是等待比较漫长的超时机制。 这个方法就是：发送端收到同一个确认包3次，就认为这个保丢失了。 这个机制就叫做快速重传机制。
根据上面的拥塞检测，快速重传后，慢启动门限阙值就要设置为拥塞窗口的一半。然后重新开始慢启动过程。
快速恢复（fast revovery）：
当发送方连续收到三个重复确认时，就执行“乘法减小”算法，把ssthresh门限减半（为了预防网络发生拥塞）。但是接下去并不执行慢开始算法(a)而是拥塞避免算法。 这就是快速恢复算法。
(a)这里没有执行慢启动算法是因为：收到重复的ACK不仅仅告诉我们一个分组丢失了。由于接收端只有在收到另一个报文段时才会产生重复的ACK，而该报文段已经离开了网络并进入了接收方的缓冲区。也就是说，在收发两端仍然有数据流动，而我们不想执行慢开始算法来突然减少数据流。而是将cwnd设置为ssthresh减半后的值，然后执行拥塞避免算法，使cwnd缓慢增大。
快速恢复算法出现在4.3BSD Reno版本中