TCP阻塞控制是TCP实现可靠传输的其中一个手段，本文重点讨论一下阻塞控制的原理和几个实现的算法。
为什么会产生TCP的阻塞呢，其实就是发送端发送的报文速度要接收端大。这样就会造成网络阻塞的问题，如果不使用一定手段进行控制，就会造成死锁。如图
现在我们知道了网络阻塞是要必须要进行控制的，那我们现在要知道什么时候进行控制，一般是两个时刻：1.网络传输TCP报文过程中发生丢失报文，2.报文需要重传。
很明显报文丢失和重传其实都证明了网络出现了拥塞，阻塞是分两种情况的一种是阻塞比较严重，这种情况下一个明显特征就是重传定时器溢出了（重传定时器是一个发送端计算是否超时需要重传的工具）。重传定时器都溢出了，那肯定就是有很多报文没有按时发送到接收端或者接收端的ACK报文没有到达发送端。另一种情况是没有阻塞情况没那么严重的情况，这种情况的特征是同一个报文确定了四次，这也证明了这个报文传输过程中丢失了(如果对重传确定机制不熟悉的朋友可以看看TCP的其他一些博客了解一下，这里就不具体展开了)。
对于上面两种情况TCP采用的措施也是不同的，但是总体思想是一样的就是设立一个阻塞窗口，并且控制阻塞窗口来控制发送窗口(发送窗口=min(阻塞窗口,接收窗口))，TCP对于阻塞控制一共有四种算法，分别是慢开始，阻塞避免，快重传，快恢复四种算法。对于第一种情况就是重传定时器溢出的情况，TCP一般采取的措施是慢开始和拥塞避免。如图
这种算法流程是阻塞窗口一开始使用从1开始以指数增长也就是(1,2,4,8,16……)。这样增长到ssthresh（慢开始门槛，我可以理解成从慢开始变回阻塞避免算法的一个分割线把），就转换为阻塞避免算法(17,18,19,20,21….)，也就是逐步加一。如果碰到重传计时器溢出的情况，就立刻把阻塞窗口变成一，然后慢开始门槛变成出现阻塞时候的窗口值的一半。然后重新执行慢开始和阻塞避免算法。这种算法其实是付出很大代价的把阻塞窗口变成一意味着也把发送窗口也变成一，这种情况其实是付出很大代价的。。。但是没办法谁叫发生了重传定时器溢出呢。
另外一种情况是有一个报文的确定报文重传了三次（也就是发送了四次）。这种情况下的算法采用快重传快恢复，算法如图
。这种情况前面和上面算法是一样的，就是采取慢开始和阻塞避免算法，但是遇到重传四次重复的确定报文的时候。把ssthresh变成出现阻塞时候阻塞窗口的一半同时阻塞窗口也变成阻塞时候的阻塞窗口的一般，然后进行线性增加，也就是拥塞避免算法。
上面的就是我对TCP阻塞控制的一些总结。如果大家对这方面也有自己的见解，欢迎和我一起讨论。
