先介绍拥塞控制的基本条件：
在某段时间，若对网络中某一资源的需求超过了该资源所能提供的可用部分，网络性能就要变坏，这种情况叫做拥塞。在计算机网络中的链路容量（即带宽）、交换节点中的缓存和处理机等，都是网络资源
若出现拥塞而不进行控制，整个网络的吞吐量将随输入负荷的增大而下降。
好吧，一本正经果然不适合刚开始想学习的人。举个例子：交通十字路口是有红路灯的，如果没有按照大部分中国司机的习惯就是往死里挤，然后道路只有那么宽，车子拥挤的越来越多，自然交通就瘫痪了，这里可以理解为拥塞了。所以要保持道路畅通就需要控制，所以就有了红绿灯，也就是要进行拥塞控制。
再用个图解释下理想的拥塞控制是如何的： 输入负载：单位时间内输入网络的吞吐数量
吞吐量：单位时间内从网络输出的吞吐数量。
刚开始时，吞吐量等于网络输入的负载，所以曲线呈45度上升，随着网络输入负载的增多超过某一限度时。由于网络资源受限，吞吐量不再增长而保持水平线，也就是吞吐量达到饱和。同时也说明输入的负载有一部分丢失掉了（在分组的丢失使拥塞的预兆），例如输入到网络中的某些分组被某个节点丢弃了，虽然如此在理想的拥塞控制下，网络的吞吐量维持到可达到的最大值。
四种TCP拥塞控制算法：满开始算法、拥塞避免算法、快重传、快恢复。
下面介绍四种拥塞控制算法的基本原理，为了更好的理解拥塞控制算法的使用。假设如下条件：
1、数据是单方向传送，而另一个方向只传送确认。
2、接收方总是有足够大的缓冲空间，因而发送方发送窗口的大小由网络拥塞程度来决定。
3、以TCP报文段的个数来讨论问题单位，而不是字节。
慢启动呈指数增长。达到慢开始门限值之后开始使用拥塞控制算法——线性加1。
直到发送方接受到的报文段小于自身发送的报文时，报文中途丢失了，重传计时器超时，这个时间则会判断出现了拥塞。
整个过程如下图：
这里再思考一下，慢开始和拥塞避免算法会不会有局限性。首先以报文丢失就作为拥塞的预兆好像不太合理，万一只是途中出现了意外而不是拥塞导致的呢，那么这里重新执行满开始算法会不会导致效率降低了。所以针对这种情况，后期提出了两个新的拥塞控制算法（改变TCP的性能）——快重传和快 恢复。用来解决误以为网络发生拥塞的情况。
慢开始和拥塞避免算法局限性：有时，个别报文会在网络中丢失，但实际网路并未发生拥塞。
- 这将导致发送发超时传送，并误以为网络发生了拥塞；
- 发送发错误的启动慢开始算法，并把拥塞窗口cwnd又设置为最小值1，因为降低了效率。
快重传算法：让发送发尽早知道发生了个别报文段的丢失。
所谓的快重传，就是使发送方尽快重传，而不是等待超时重传计时器超时再重传。
- 要求接收方不要等待自己发送数据时在进行捎带确定，而是要立即发送确认；
- 即使收到了失序的报文段也是立即发出对方收到的报文段的重复确认；
- 发送方一旦收到三个连续的重复确认，就将相应的报文段立即重传，而不是等待该报文段的超时重传计时器超时再重传。
具体过程见下图：
整个拥塞控制流程就是这样，是不是发现也就那么一回事。
