TCP拥塞控制算法（TCP congestion control algorithm）：
该算法包括3个主要部分：①慢启动；②拥塞避免;③快速恢复。慢启动和拥塞避免是TCP的强制部分，两者的差异在于对收到的ACK做出反应时增加cwnd长度的方式。我们很快将会看到慢启动比拥塞避免能更快地增加cwnd的长度（不要被名称所迷惑！）。快速恢复是推荐部分，对TCP发送方并非是必需的。
1.慢启动（slow-start）
当一条TCP连接开始时，cwnd的值通常初始置为一个MSS的较小值［RFC 3390]，这就使得初始发送速率大约为MSS/RTT。例如，如果MSS = 500字节且RIT = 200ms,则得到的初始发送速率大约只有20kbps。由于对TCP发送方而言，可用带宽可能比MSS/RTT大得多，TCP发送方希望迅速找到可用带宽的数量。因此，在慢启动（slow-start）状态，cwnd的值以1个MSS开始并且每当传输的报文段首次被确认就增加1个MSS。
在图3-50所示的例子中，TCP向网络发送第一个报文段并等待一个确认。当该确认到达时，TCP发送方将拥塞窗口增加一个MSS,并发送出两个最大长度的报文段。这两个报文段被确认，则发送方对每个确认报文段将拥塞窗口增加一个MSS，使得拥塞窗口变为4个MSS,并这样下去。这一过程每过一个RTT，发送速率就翻番。因此，TCP发送速率起始慢，但在慢启动阶段以指数增长。
但是，何时结束这种指数增长呢？慢启动对这个问题提供了几种答案。
①重新开始慢启动：首先，如果存在一个由超时指示的丢包事件（即拥塞），TCP发送方将cwnd设置为1并重新开始慢启动过程。它还将第二个状态变量的值ssthresh （"慢启动阈值”的速记）设置为cwnd/2 ，即当检测到拥塞时将ssthresh置为拥塞窗口值的一半。
②转移到拥塞避免模式：慢启动结束的第二种方式是直接与ssthresh的值相关联。因为当检测到拥塞时ssthresh设为cwnd的值一半，当到达或超过ssthresh的值时，继续使cwnd翻番可能有些鲁莽。因此，当cwnd的值等于ssthresh时，结束慢启动并且TCP转移到拥塞避免模式。我们将会看到，当进入拥塞避免模式时，TCP更为谨慎地增加cwnd。
③执行快速重传：最后一种结束慢启动的方式是，如果检测到3个冗余ACK,这时TCP执行一种快速重传（参见3.5.4节）并进入快速恢复状态，后面将讨论相关内容。慢启动中的TCP行为总结在图3-51中的TCP拥塞控制的FSM描述中。
图3-51表示了TCP拥塞控制算法（即慢启动、拥塞避免和快速恢复）的完整FSM描述。该图也指示了新报文段的传输或重传的报文段可能出现的位置。尽管区分TCP差错控制/重传与TCP拥塞控制非常重要，但是注意到TCP这两个方面交织链接的方式也很重要。
2.拥塞避免
一旦进入拥塞避免状态，cwnd的值大约是上次遇到拥塞时的值的一半，即距离拥塞可能并不遥远！因此，TCP无法每过一个RTT再将cwnd的值翻番，而是采用了一种较为保守的方法，每个RTT只将cwnd的值增加一个MSS ［RFC 5681］。这能够以几种方式完成。一种通用的方法是对于TCP发送方无论何时到达一个新的确认，就将cwnd增加一个MSS （ MSS/cwnd ）字节。例如，如果MSS是1460字节并且cwnd是14600字节，则在一个RTT内发送10个报文段。每个到达ACK （假定每个报文段一个ACK）增加1/10MSS的拥塞窗口长度，因此在收到对所有10个报文段的确认后，拥塞窗口的值将增加了一个 MSS。
但是何时应当结束拥塞避免的线性增长（每RTT 1MSS）呢？
①当出现超时时，TCP的拥塞避免算法行为相同。与慢启动的情况一样，cwnd的值被设置为1个MSS，当丢包事件出现时，ssthresh的值被更新为cwnd值的一半。
然而，前面讲过丢包事件也能由一个②三个冗余ACK事件触发。在这种情况下，网络继续从发送方向接收方交付报文段（就像由收到冗余ACK所指示的那样）。因此TCP对这种丢包事件的行为，相比于超时指示的丢包，应当不那么剧烈：TCP将cwnd的值减半（为使测量结果更好，计及已收到的3个冗余的ACK要加上3个MSS），并且当收到3个冗余的ACK，将ssthresh的值记录为cwnd的值的一半。接下来进入快速恢复状态。
3.快速恢复
在快速恢复中，对于引起TCP进入快速恢复状态的缺失报文段，对收到的每个冗余的ACK， cwnd的值增加一个MSS。最终，当对丢失报文段的一个ACK到达时，TCP在降低cwnd后进入拥塞避免状态。如果出现超时事件，快速恢复在执行如同在慢启动和拥塞避免中相同的动作后，迁移到慢启动状态：当丢包事件出现时，cwnd的值被设置为1个MSS，并且ssthresh的值设置为当前cwnd值的一半。
快速恢复是TCP推荐的而非必需的构件［RFC56&1］。有趣的是，一种称为TCPTahoe的TCP早期版本，不管是发生超时指示的丢包事件，还是发生3个冗余ACK指示的丢包事件，都无条件地将其拥塞窗口减至1个MSS,并进入慢启动阶段。TCP的较新版本TCP Reno，则综合了快速恢复。
图3-52图示了 Reno版TCP与Tahoe版TCP的拥塞控制窗口的演化情况。在该图中，阈值初始等于8个MSS。在前8个传输回合，Tahoe和Reno采取了相同的动作。拥塞窗口在慢启动阶段以指数速度快速爬升，在第4轮传输时到达了阈值。然后拥塞窗口以线性速度爬升，直到在第8轮传输后出现3个冗余ACK。注意到当该丢包事件发生时，拥塞窗口值为12xMSS。于是ssthresh的值被设置为0. 5 x cwnd =6xMSS。
在TCP Reno（新）下，拥塞窗口被设置为cwnd = 9MSS，然后线性地增长。（快恢复）
在TCP Tahoe（旧）下，拥塞窗口被设置为1个MSS，然后呈指数增长，直至到达ssthresh值为止，在这个点它开始线性增长。（快重传）
4. TCP拥塞控制：回顾
在深入了解慢启动、拥塞避免和快速恢复的细节后，现在有必要退回来回顾一下全局。忽略一条连接开始时初始的慢启动阶段，假定丢包由3个冗余的ACK而不是超时指示，TCP的拥塞控制是：每个RTT内cwnd线性（加性）增加1MSS，然后出现3个冗余ACK事件时cwnd减半（乘性减）。因此，TCP拥塞控制常常被称为加性增、乘性减（Additive- Increase, Multiplicative- Decrease，AIMD）拥塞控制方式。AIMD拥塞控制引发了在图3-53中所示的“锯齿”行为，这也很好地图示了我们前面TCP检测带宽时的直觉，即TCP线性地增加它的拥塞窗口长度（因此增加其传输速率），直到出现3个冗余ACK事件。然后以2个因子来减少它的拥塞窗口长度，然后又开始了线性增长，探测是否还有另外的可用带宽。
5.对TCP吞吐量的宏观描述
在这个分析中，我们将忽略在超时事件后出现的慢启动阶段。（这些阶段通常非常短，因为发送方很快就以指数增长离开该阶段。）在一个特定的往返间隔内，TCP发送数据的速率是拥塞窗口与当前RTT的函数。当窗口长度是w字节，且当前往返时间是RTT秒时，则TCP的发送速率大约是w/RTT。于是，TCP通过每经过1个RTT将w增加1个MSS探测出额外的带宽，直到一个丢包事件发生为止。当一个丢包事件发生时，用W表示w的值。假设在连接持续期间RTT和W几乎不变，那么TCP的传输速率在W/(2 xRTT)到W/RTT之间变化。
这些假设导出了TCP稳态行为的一个高度简化的宏观模型。当速率增长至W/RTT时,网络丢弃来自连接的分组；然后发送速率就会减半，进而每过一个RTT就发送速率增加MSS/RTT，直到再次达到W/RTT为止。这一过程不断地自我重复。因为TCP吞吐量（即速率）在两个极值之间线性增长，所以我们有一条连接的平均吞吐量
6.经高带宽路径的TCP
TCP继续演化的需求能够通过考虑网格和云计算应用所需要的高速TCP连接加以阐述。例如，考虑一条具有1500字节报文段和100ms RTT的TCP连接，假定我们要通过这条连接以10Gbps速率发送数据"根据［RFC 3649］,我们注意到使用上述TCP吞吐量公式，为了取得lOGbps吞吐量，平均拥塞窗口长度将需要是83 333个报文段。对如此大量的报文段，使我们相当关注这83 333个传输中的报文段也许会丢失。在丢失的情况下，将会出现什么情况呢？或者以另一种方式说，这些传输的报文段能以何种比例丢失，使得在图3-52中列出的TCP拥塞控制算法仍能取得所希望的10Gbps速率？
考虑一条TCP连接的吞吐量公式，该公式作为丢包率（L）、往返时间（RTT）和最大报文段长度（MSS）的函数：
使用该公式，我们能够看到，为了取得10Gbps的吞吐量，今天的TCP拥塞控制算法仅能容忍2x10^(-10)的报文段丢失概率（或等价地说，对每5 000 000 000个报文段有一个丢包）。这是一个非常低的值。
