在整个网络体系结构中，拥塞控制是由TCP来实现的。对于互联网来说，TCP的拥塞控制非常重要。它是整个网络稳定可用的保证。在互联网上的拥塞发现、信息传递、拥塞控制行动，都需要由TCP来完成。
由于TCP是端到端的协议，它只部署在网络周边的各个端设备上，而在网络核心的设备上都没有TCP的处理功能。TCP要发现拥塞，主要由端设备依据网络实验的延长和丢包现象予以完成；如此，基本也不需要考虑拥塞信息传递的工作。然后，TCP通过恰当控制自己发送窗口的大小来调整自己发送数据的速率。
在这里要说一下拥塞控制和流量控制的区别。表面上看，它们都需要TCP控制自己发送数据的速率，也都是通过控制发送窗口的大小来实现的。但是它们的目的和控制依据是不同的。流量控制是以协调发送方与接收方能力为目的，只为了解决端到端的问题。它采取的方法是：接收方告诉发送方自己的接收能力；发送方则按照接收方的接收能力来发送数据；而拥塞控制的目的是防止过多的数据进入网络中，要解决一种全局性的问题。它采取的方法是：发送方通过超时现象揣测拥塞的发生；发送方依据一定的算法，谨慎地试探自己的发送窗口应该有多大为宜。
总体来说，流量控制可以使通信发送依据对方的接收能力来发送数据，让协议仿佛具有了伙伴协作的精神；拥塞控制可以让发送方会依据接收反馈情况来节制自己的发送速度，仿佛在使用公共网络时懂得谨慎、自律。它是整个网络体系结构中极为重要的一员。当然，随着网络技术的发展，人们也可以通过类似服务质量（Quality of Service，QoS）这样的方式来保证网络传输的稳定，并解决一些拥塞现象。QoS一般依据人们为网络设备设置的优先级转发策略、拥塞避免等机制为特定的数据流提供较为稳定的传输服务。从一定意义上来说，由于为特定的通信或者数据类型设置了流量保障，QoS有一定的开环拥塞控制的特点。采用QoS后，网络通信的稳定不必仅依赖TCP。关于QoS的知识，超出本部分的讨论内容，此处不再赘述。
1.TCP的拥塞发现
首先来看看TCP是如何发现拥塞的。
前面介绍过，端设备可以依据传输时延的增加或者丢包现象来发现拥塞，但TCP是一个主要工作在复杂的互联网上的协议，要想通过判断传输时延改变多少才能确定拥塞的发生或者即将发生，这是一种非常难以控制的事情。所以，TCP主要是通过丢包现象来发现拥塞。TCP主要依据两种现象来判定丢包，一种是超时现象，另一种是3-ACK现象。这两种现象在前面介绍TCP的可靠传输时都出现过。
（1）超时现象就是发送出去的TCP数据段迟迟收不到对应的确认，最终超过了等待时间的阈值。造成这种现象的原因可能是网络传输错误造成的验证问题，也可能是真正的丢包。即使是丢包，可能是由于拥塞造成的，也有可能是因为其他的网络故障造成的。所以，利用超时现象来判定拥塞的发生，有一定的不确定性，但这种判断的好处是，它是完全由端设备自己来进行的，不需要网络的其他部门做什么事情。对于现代品质很好的网络而言，出现超时一般也不会是一个数据段的超时，超时事件虽然不一定是拥塞造成的，但也意味着网络一定出现了某种比较严重的问题。TCP认定：当超时现象发生，就按照网络出现拥塞算。
（2）3-ACK现象是指某一个数据段出现了三次以上的重复确认。首先，这意味着，以重复的确认号开始的那个数据段应该是出现了某种问题，但它后面的数据段都正确传输了，而且确认的数据段也都回来了。后面数据的成功往返意味着，网络虽然出现了某种问题，但是大多数通信还是可以正常进行的，这说明网络的问题并不大。同样，那个被认为出现问题的数据段的问题未必就一定是拥塞造成的，但网络一定是有某种问题。TCP认定：当3-ACK现象出现时，就按照网络出现了不太严重的拥塞算。
利用超时现象或者3-ACK现象来判定拥塞虽然有一定的不确定性，但是，这种判断简单、方便，且不需要网络核心设备参与判断过程，也不需要额外的信息传输；而且，这些现象的出现毕竟都能说明网络通信出现了一定的问题。作为负担整个网络品质传输重任的协议，一个工作起来谨慎、自律的协议，TCP都要予以相应的反应。
2.TCP的拥塞控制措施
若发现了拥塞，TCP就要限制发送到网络上的数据段数量。它采取的方式依然是调整发送窗口的大小。发送方除了在流量控制机制中获知接收方的接收窗口外，还自己维护了一个拥塞窗口（Congestion Window，CWND）。TCP在设置自己的发送窗口时，要综合考虑这两个窗口的大小。简单地说，发送窗口不能超过这两个窗口中较小的那一个。即要满足式（5-4）：
真实的发送窗口是要同时看接收窗口和拥塞窗口的情况，但为了简单起见，我们后面的讨论只围绕拥塞窗口进行。接下来讨论TCP的拥塞窗口是如何设置的。另外还要注意的是，讨论拥塞窗口大小时，所使用的单位是数据段的个数，而不是可发送的字节数。如果依据之前讨论的拥塞窗口来计算发送窗口的大小，一般需要再乘以MSS。
TCP的拥塞控制，其细节非常复杂，这里仅介绍一些基本原理和要点。关于拥塞窗口大小的设置，互联网的建议标准［RFC 2581］定义了3种算法：慢启动、拥塞避免和快速恢复。我们接下来会逐一说明这些算法的处理过程。
在介绍这些拥塞避免算法之前，还要先介绍“轮次”的概念。“轮次”可以视为是各拥塞避免算法用到的一个基本时间周期。在一个轮次之内，拥塞窗口的大小是固定的。拥塞控制机制会根据某一个轮次的通信状况，依据不同的拥塞避免算法来决定下一个轮次的拥塞窗口的大小。轮次的时间长度应该没有具体的限制，简单来看，若某个轮次内拥塞窗口小，需要发送的数据少，其时间也会较短。
（1）慢启动。慢启动适用于网络情况不明的时候。如刚刚开始传输，或者网络出现了严重的拥塞后。
慢启动，其中“慢”的含义是，TCP连接从一个很慢的速度开始传输。此时，拥塞窗口被设置为一个很小的值，如1。此后每一个轮次的拥塞窗口大小都会乘以2，使窗口的大小以指数函数迅速提高，而发送数据的速度也迅速提高。直到达到一个特定的门限值，从此便开始转入拥塞避免算法。当然，如果这个门限值设置得过大，慢启动也可能以出现拥塞现象而结束。
刚刚提到的门限值叫作慢启动门限（Ssthresh），也是TCP拥塞控制中很重要的一个数值。它的大小会影响不同算法之间的切换；也会由于拥塞现象的发生而改变。(www.xing528.com)
（2）拥塞避免。适用于数据传输速度达到一定数值，通信相对稳定后的情况。当慢启动达到特定门限值后会采用拥塞避免。后面介绍的快速恢复算法在快速恢复之后也要执行拥塞避免算法。
拥塞避免算法是以线性函数逐渐增加拥塞窗口的大小。如每一轮过后，如果没有发生拥塞现象，下一轮的拥塞窗口大小将比本轮加1。当网络传输相对稳定时，可以逐渐试探性地增加拥塞窗口的大小，可在保障网络速度稳定的前提下尝试有无更快传输的可能。
拥塞避免以一种缓慢的速度逐渐增加拥塞窗口的大小，直到出现拥塞现象。
（3）快速恢复。快速恢复适用于应对网络发生了不太严重的拥塞的情况。前面介绍过，TCP通过超时重传和3-ACK两个现象来判断拥塞：超时现象被视为严重的拥塞，而3-ACK现象则被视为不严重的拥塞。当发生超时的时候，TCP连接从慢启动重新开始；若是发生了3-ACK现象，则执行快速恢复。
快速恢复只影响3-ACK现象下一个轮次的拥塞窗口值。它会将窗口大小减半，同时，修改慢启动门限，使其也等于这个窗口大小。快速恢复之后便会转入拥塞避免的处理过程。
3.算法间的切换
前面介绍了三种算法，亦即调整拥塞窗口的三种策略；还提到了一个被称为“慢启动门限”的数值。三种算法的切换关系如图5-19所示。每次发生超时或者3-ACK代表的拥塞事件时，门限值都会被设置为拥塞发生时拥塞窗口大小的一半。
图5-19 三种算法的切换关系
下面，我们利用一个例子来进一步说明这些算法的使用情况。假设一个TCP连接的慢启动门限初始门限为8。连接从慢启动开始，当拥塞窗口上升到14时，网络发生了超时，重又增加到12时发生了3-ACK事件。其前21个轮次使用的拥塞窗口大小及变动说明见表5-7。
表5-7 拥塞窗口变化情况
续表
一般来说，拥塞控制执行的算法都是从慢启动开始的，然后再到拥塞避免和快速恢复之间来回切换。只是偶尔才会从拥塞避免重新回到慢启动。在与TCP拥塞控制相关的文献中提及的名词“加性增”“乘性减”描述的就是拥塞避免和快速恢复这两种算法。
整个拥塞控制过程中，发送方总会以一定方式逐渐增加拥塞窗口，以追求更快的发送速度。这种努力总会以某种形式的拥塞结束。拥塞避免算法的“加性增”可以保证拥塞不会很快出现，“乘性减”则不会让速度降低太多。一个长时间的TCP连接，在其稳定运行时，其拥塞窗口大小随时间变化的函数呈锯齿状变化，其平均发送速率将始终在网络可用带宽附近徘徊。
最后，快速恢复算法常被说是“乘性减”，因为这是拿拥塞发生时的窗口大小乘以一个小于1的数作为新的门限值。通常使用的数都是0.5，但不只有0.5可以选。选择其他数值是否会更合适？是否有什么动态的选择方法？“加性增”，在本书的例子里是加1，是否有更合适的增加办法？诸如此类的或深或浅或概括或细致的问题，让拥塞控制一直是网络领域中一个处于一定活动状态的研究方向。
免责声明：以上内容源自网络，版权归原作者所有，如有侵犯您的原创版权请告知，我们将尽快删除相关内容。
