TCP拥塞控制是通过控制一些重要参数的改变而实现的。TCP用于拥塞控制的参数主要有：
(1) 拥塞窗口（cwnd）:拥塞控制的关键参数，它描述源端在拥塞控制情况下一次最多能发送的数据包的数量。
(2) 通告窗口（awin）:接收端给源端预设的发送窗口大小，它只在TCP连接建立的初始阶段发挥作用。
(3) 发送窗口（win）:源端每次实际发送数据的窗口大小。
(4) 慢启动阈值（ssthresh）:拥塞控制中慢启动阶段和拥塞避免阶段的分界点。初始值通常设为65535byte。
(5) 回路响应时间（RTT）:一个TCP数据包从源端发送到接收端，源端收到接收端确认的时间间隔。
(6) 超时重传计数器（RTO）:描述数据包从发送到失效的时间间隔，是判断数据包丢失与否及网络是否拥塞的重要参数。通常设为2RTT或5RTT。
(7) 快速重传阈值(tcprexmtthresh):：能触发快速重传的源端收到重复确认包ACK的个数。当此个数超过tcprexmtthresh时，网络就进入快速重传阶段。tcprexmtthresh缺省值为3。
四个阶段
1．慢启动阶段
旧的TCP在启动一个连接时会向网络发送许多数据包,由于一些路由器必须对数据包进行排队，因此有可能耗尽存储空间，从而导致TCP连接的吞吐量（throughput）急剧下降。避免这种情况发生的算法就是慢启动。当建立新的TCP连接时，拥塞窗口被初始化为一个数据包大小（一个数据包缺省值为536或512byte）。源端按cwnd大小发送数据，每收到一个ACK确认，cwnd就增加一个数据包发送量。显然，cwnd的增长将随RTT呈指数级(exponential)增长：1个、2个、4个、8个……。源端向网络中发送的数据量将急剧增加。
2．拥塞避免阶段
当发现超时或收到3个相同ACK确认帧时，网络即发生拥塞（这一假定是基于由传输引起的数据包损坏和丢失的概率小于1%)。此时就进入拥塞避免阶段。慢启动阈值被设置为当前cwnd的一半；超时时，cwnd被置为1。如果cwnd≤ssthresh,则TCP重新进入慢启动过程;如果cwnd>ssthresh，则TCP执行拥塞避免算法，cwnd在每次收到一个ACK时只增加1/cwnd个数据包（这里将数据包大小segsize假定为1）。
3．快速重传和恢复阶段
当数据包超时时，cwnd被设置为1，重新进入慢启动，这会导致过大地减小发送窗口尺寸，降低TCP连接的吞吐量。因此快速重传和恢复就是在源端收到3个或3个以上重复ACK时，就断定数据包已经被丢失，并重传数据包，同时将ssthresh设置为当前cwnd的一半，而不必等到RTO超时。图2和图3反映了拥塞控制窗口随时间在四个阶段的变化情况。
效率和公平性
除了TCP拥塞控制的自相似性外，TCP拥塞控制的效率和公平性问题目前也受到了广泛的关注。
1. 效率
网络资源的使用效率是由源端要求的总资源与网络资源的接近程度决定的。如果源端总资源接近或等于网络所能提供的资源，那么这种算法的效率就是高的。超载或负载不足都是效率不高的表现。显然，效率只与总资源的利用率有关，而与各个源端之间的资源利用无关。
2．公平性
公平性是在发生拥塞时各源端（或同一源端建立的不同TCP连接或UDP数据报）能公平地共享同一网络资源（如带宽、缓存等）。处于相同级别的源端应该得到相同数量的网络资源。产生公平性的根本原因在于拥塞发生必然导致数据包丢失，而数据包丢失会导致各数据流之间为争抢有限的网络资源发生竞争，争抢能力弱的数据流将受到更多损害。因此，没有拥塞，也就没有公平性问题。
TCP层上的公平性问题表现在两方面：
(1) 面向连接的TCP和无连接的UDP在拥塞发生时对拥塞指示的不同反应和处理，导致对网络资源的不公平使用问题。在拥塞发生时，有拥塞控制反应机制的TCP数据流会按拥塞控制步骤进入拥塞避免阶段，从而主动减小发送入网络的数据量。但对无连接的数据报UDP，由于没有端到端的拥塞控制机制，即使网络发出了拥塞指示（如数据包丢失、收到重复ACK等），UDP也不会像TCP那样减少向网络发送的数据量。结果遵守拥塞控制的TCP数据流得到的网络资源越来越少，没有拥塞控制的UDP则会得到越来越多的网络资源，这就导致了网络资源在各源端分配的严重不公平。
网络资源分配的不公平反过来会加重拥塞，甚至可能导致拥塞崩溃。因此如何判断在拥塞发生时各个数据流是否严格遵守TCP拥塞控制，以及如何“惩罚”不遵守拥塞控制协议的行为，成了目前研究拥塞控制的一个热点。在传输层解决拥塞控制的公平性问题的根本方法是全面使用端到端的拥塞控制机制。目前，判断拥塞时不遵守拥塞控制的数据流的几种方法如下：
● 如果数据流遵守TCP拥塞控制方式，那么在拥塞发生时，作为响应，它首先应将拥塞窗口cwnd减半，然后在每个RTT内按常数速率增加cwnd。给定包丢失率p,TCP连接的最大传送速率为T byte/s，B为一个数据包的最大字节数，R为最小RTT。当某数据流的发送速率大于T时，则可断定该数据流没有执行拥塞控制。这一公式主要应用于没有突发级数据包丢失的情况。实际使用中以大于1.45B/(R)判定数据流没有执行拥塞控制，以小于1.22B/(R)为解除对该数据流“惩罚”的条件。
● 通过判断网络中占据高带宽的数据流是否对拥塞指示进行响应来决定其是否执行拥塞控制，也就是随着网络包丢失率的增加，其传送速率应相应降低。
如果包丢失率p增加x，则源端的发送速率应大致减少。例如，如果包丢失率增加4倍，那么发送速率应减少2倍。正是根据这一关系，通过检测数据流对包丢失率的反应，就可以大致判断该流是否执行了拥塞控制。对有ON/OFF特性的数据源和接收者经常变动的多点广播（multicast）方式，由于传送速率本身经常变化，所以这种判断方法在以上两种情况下并不理想。
(2) 一些TCP连接之间也存在公平性问题。产生问题的原因在于一些TCP在拥塞前使用了大窗口尺寸，或者它们的RTT较小，或者数据包比其他TCP大，这样它们也会多占带宽。总之，解决TCP拥塞控制公平性问题的根本出路是在Internet上全面实行端到端拥塞控制和融合IP层拥塞控制的新算法。
改进
事实上，在TCP Reno之前还有TCP Tahoe,两者的主要区别在于后者只有拥塞控制的前三部分，没有快速恢复，所以可以认为TCP Reno是TCP Tahoe的改进版。但TCP Reno算法仍有不足。
首先，源端在检测到拥塞后，要重传从数据包丢失到检测到丢失时发送的全部数据包（即Go-back-n算法），而这中间有些数据包被正确地传到接收端，而不必重传。
另外，在大多数TCP实现中，RTO计数器的值被认为是RTT的均值和方差的估计值的函数。而准确估计RTO和RTT值并不是一件容易的事。理论上，RTT的测量比较简单。它只是数据包从发出到确认ACK返回源端的时间。但由于TCP使用的是用一个ACK确认所有已收到数据的“累积”确认方式，所以实际中RTT的估计往往很复杂。
针对以上缺点，近年来人们又提出了一些改进算法，其中New-Reno和SACK都是改进版。SACK算法是在Reno基础上进行扩展，对数据包进行有选择地确认和重传。这样，源端就能准确地知道哪些数据包被正确的传到接收端，从而避免不必要的重传，减少时延，提高网络吞吐量。New-Reno没有选用SACK方法，而是尽力避免了Reno在快速恢复阶段的许多重传超时，利用一个ACK确认部分发送窗口，立即重传余下的数据包。显然，New-Reno只需修改源端代码。
综合来看，即使源端不通过等待超时来恢复一个窗口数据中丢失的包，Reno和New-Reno在一个RTT内至多也只能重传一个被丢弃的包。SACK使用“管道”（pipe）变量表示在发送路径上损失的数据包的数量。用tcpremtthresh判断拥塞是否发生。Reno 优于Tahoe，New-Reno和SACK则优于Tahoe和Reno。由于SACK不像New-Reno一次全部重传已发送包，而是有选择地重传，因此在一个窗口中出现数据包大量丢失时，SACK的性能优于New-Reno，但SACK的最大缺点在于要修改TCP协议。
由于RTT值与网络运行情况密切相关，因此近几年又出现了利用RTT控制拥塞的Vegas算法。Vegas就是通过观察以前的TCP连接中RTT值的改变情况来控制拥塞窗口cwnd。如果发现RTT变大，那么Vegas就认为网络发生拥塞，并开始减小cwnd；如果RTT变小，Vegas则解除拥塞，再次增加cwnd。这样，cwnd在理想情况下就会稳定在一个合适的值上。这样做的最大好处在于拥塞机制的触发只与RTT的改变有关，而与包的具体传输时延无关。由于它没有采用包丢失来判断网络可用带宽，而改以用RTT的改变来判断，所以能较好地预测网络带宽使用情况，并且对小缓存的适应性较强，其公平性、效率都较好。但Vegas算法距离在Internet上普遍应用还有一段距离。这倒不是算法本身的问题，而是由于使用Vegas和未使用Vegas算法在竞争带宽方面不公平所致。
