拥塞控制机制是什么意思

拥塞是当多个用户竞争访问相同的资源(带宽、缓冲区和队列)时，在共享网络上发生的问题。就像在高速公路上发生的拥堵一样，许多车辆进入高速公路时没有考虑即将发生的拥堵或已经发生的拥堵，随着越来越多的车辆进入高速公路，拥堵变得越来越严重。最后，在斜坡上行驶的车辆可能向后滑动，根本无法向上行驶。

在分组交换网络中，数据包在通过网络时在交换设备的缓冲区和队列中进进出出。事实上，分组交换网络通常被称为“队列网络”。数据包交换网络的特点是数据包可以从一个或多个来源成组到达。缓冲区帮助路由器吸收突发数据包，直到它们能够自己解析这些数据包。如果流量过大，则缓冲区已满，进入的数据包将被丢弃。增加缓冲区的大小并不是解决方案，因为较大的缓冲区会导致太大的延迟。

拥塞通常发生在多个链路将数据包填充到单个链路时，例如当内部LAN连接到WAN链路时。拥塞也发生在核心网络中的路由器上，因为节点承载的业务流量超过了它们的设计处理能力。TCP/IP网络，如Internet，特别容易出现拥塞，因为它们基本的无连接性质，没有保证虚拟电路的带宽。任何主机在任何时间都会发送数据包，并且这些数据包的大小是可变的，因此无法预测流量模式并提供有保证的服务。除了服务质量外，无连接网络也有优点。

以下基本技术用于管理拥塞。

端系统流量控制这不是一个拥塞控制方案，而是一种防止发送方占用接收方缓冲区的方法。流量控制是接收实体执行的一种功能，用于限制发送实体发送的数据的数量或速率。最简单的流控制是停止等待过程，在发送下一个pdu之前必须确认所有pdu。更有效的协议包括向发送方提供某种形式的信用，即可以在不收到确认的情况下发送的数据量。HDLC滑动窗口技术就是这种机制的一个例子。

网络拥塞控制网络拥塞是指在分组交换网络中，由于传输的数据包数量过多，而存储和转发节点资源有限，导致网络传输性能下降的情况。拥塞的极端情况是死锁，而退出死锁通常需要网络重置操作。在这种方案中，终端系统减少流量，避免网络拥塞。这种机制类似于端到端流量控制，但目的是减少网络中的拥塞，而不是减少接收端的拥塞。

基于网络的拥塞避免在这种情况下，路由器检测到可能的拥塞，并尝试在队列填满之前降低发送方的速度。

资源分配这种技术包括对物理电路或其他资源的使用进行调度，可能是在特定的时间段内。通过一系列交换机建立虚拟电路来传递保证带宽是资源分配的一种形式。这是一项困难的技术，但它通过阻止超过网络容量的流量来消除网络拥塞。在本主题的末尾给出了相关主题的列表。

缓存可能是最终的拥塞控制方案。通过将内容移动到离用户更近的地方，可以在本地获得大量流量，而不是沿着可能发生拥塞的路由路径从远程服务器获得流量。高速缓存成为互联网上的一项重要业务。

排队和拥塞

任何关于拥塞的讨论都涉及队列。网络上的缓冲区使用不同的排队技术进行管理。正确管理队列可以最大限度地减少数据包丢失和网络拥塞，并提高网络性能。

最基本的技术是FIFO(先进先出)，这意味着数据包按照它们到达接口的顺序排队，数据包按照它们到达队列出口的顺序排队。较先进的报文优先排队，较晚的报文最后排队。此外，优先级队列方案使用具有不同优先级的多个队列，以便可以首先发送最重要的数据组。

一种重要的排队技术是将数据流分配到它们自己的队列中。区分数据流的目的是分配不同的优先级。同样重要的是，每个数据流都要负责确保它不会溢出自己的队列。这种分离的队列确保每个队列只包含来自单个源的数据包。

帧中继中的拥塞控制

帧中继用户与服务提供商协商CIR(保证信息速率)。CIR是一种有保证的服务级别，但如果网络容量允许，提供商通常允许用户在超出此级别的情况下突发数据。但是，超过CIR的帧被标记为丢弃。如果网络上的交换机拥塞，它会丢失丢弃的帧。这确保了服务提供者能够满足与用户协商的CIR级别。

丢弃帧从来都不是一个好主意，所以有两种可用的拥塞避免机制：

BECN(反向显式拥塞通知)在数据帧遇到拥塞路径的相反方向上传输的数据帧中，由帧中继网络设置的位。当交换机开始遇到拥塞(例如缓冲区/队列满)时，它可以用BECN位组向发送方反向发送一个帧，以通知发送方减速。

FECN(转发显式拥塞通知)是源(发送)终端请求目的(接收)终端减慢数据请求的第一个请求。当交换机拥塞时，它可以使用FECN位组向接收节点转发一个帧。这将通知接收节点，应该通知发送方减速。

发送方或接收方不必响应BECN或FECN，但随着拥塞持续增长，最终网络交换机将丢失帧。

TCP中的拥塞控制和避免

直到20世纪80年代中期，互联网很容易出现“拥塞崩溃”。这是因为缺乏对管理大量网络负载的控制。单独的连接使用发送方和接收方之间的数据流控制，以防止发送方发送过多的数据，使接收方无法处理。

但是这些早期的数据流控制是为了防止接收端缓冲区溢出而设计的，而不是网络节点。然而，早期的互联网包含大量相对较慢的链路，因此拥塞问题并不像今天这样严重。

在20世纪80年代末，Van Jacobson提出了拥塞控制机制，使TCP能够响应网络中的拥塞。基本的“信号”是被丢弃的数据包，它会使主机停止或减慢速度。

通常，当主机接收到一个数据包(或一组数据包)时，它会向发送方发送一个ACK(确认)。窗口机制允许主机发送多个数据包，而不是单个ACK。如果接收不到ACK，可能会导致主机溢出或网络拥塞。在这两种情况下，发送方都会减少或停止发送。

一个名为“加/增/乘/减”的策略管理一次发送的数据包数量。如果您绘制数据流图，您将看到锯齿形模式，其中数据组的数量增加(增加)，直到出现拥塞，然后在开始丢弃数据组时减少(乘法减少)。当出现拥塞信号时，窗口大小通常减半。

主机所做的是通过不断地以更高的速率测试网络来找到最佳的传输速率。有时，允许更高的传输速率，但如果网络繁忙并且数据包开始丢失，主机就会相应地减慢速度。在该方案中，网络被视为一个“黑匣子”，当拥塞发生时，数据组被丢弃。因此，拥塞控制由终端系统运行，它将丢失的数据包视为网络拥塞的唯一表示。

传输大文件的发送者会试图获得更高的速率，直到最终占用所有的带宽。其他主机的数据包可能无法通过。通常，最不重要的通信是由已经占用带宽的主机完成的。其后果对语音等实时通信尤其具有破坏性。即使链路有足够的带宽来处理其负载，性能不佳的主机也可能使链路饱和(尽管是暂时的)，从而中断语音通信，使用户无法通话。

当然，网络在管理拥塞方面发挥着积极的作用，其中“主动队列管理”和拥塞避免发挥了作用。RFC l254(网关拥塞控制调查，1991年8月)描述了由IETF性能和拥塞控制工作组审查的拥塞控制和避免机制。工作组将拥堵处理分为以下几类：

拥塞恢复当需求超过网络容量时，需要恢复网络。

避免预测拥塞并避免拥塞，这样拥塞就永远不会发生。

RFC 1254规定，如果没有拥塞恢复，互联网将停止运行，但它已经在没有拥塞避免的情况下工作了很长时间。目前，避免拥塞是提高互联网性能和服务质量的重要途径。

RFC 2309(关于Internet中的队列管理和拥塞避免的建议，1998年4月)指出，用于控制拥塞的基于路由器的机制可分为“队列管理”算法和“调度”算法。有关拥塞控制、拥塞避免方案和队列调度技术的有用信息，请参阅本RFC。

一个重要的目标是尽量减少丢失的数据分组的数量。如果主机高速传输，网络拥塞，会导致大量数据包丢失。拥塞避免试图在不限制网络吞吐量的情况下防止数据丢失。RFC 2309指出，最好是接受突发事件溢出队列，而不是试图保持队列未填充。这将从根本上有利于在高吞吐量下降低端到端延迟。RFC还指出，网络中的缓冲区会吸收数据突发，并在随后的突发(希望是空闲时间)中传输它们。这是允许突发数据传输的本质。我们希望路由器有一个正常的小队列的原因很清楚：我们需要队列容量来吸收突发数据。与直觉相反，维护一个通常较小的队列会带来更高的吞吐量和更低的端到端延迟。总之，队列限制不应该反映我们希望在网络中保持的稳态队列；相反，它们应该反映出我们想要吸收多少突发数据。

突发数据可以破坏多个主机。如果单个主机填充了多个主机正在使用的队列，则所有主机都需要后退。这将导致网络在一段时间内未被充分利用，因为主机以较低的速率发送数据包。然而，由于需要重新传输丢弃的数据包，他们最终建立了备份。然后发生的情况是，所有已经掉队的主机都试图在大约同一时间重新发送，这再次导致拥塞状态。这就是所谓的“全局同步”问题。

应该记住，TCP处理的是拥塞控制。UDP通常用于实时音频和视频流，因为它不需要恢复丢失的数据包。UDP是一种不可靠的传输协议，它不能将ACK信号发送回数据源。因为没有ACK，所以不可能用传统的TCP拥塞控制来控制UDP流。

互联网的早期创建者Lawrence G. Roberts在他1997年的论文《Explicit Rate Flow Control，A100 Fold Improvement over TCP》中对TCP及其拥塞控制方案做了一个有趣的评论。他认为，只要TCP只在终端站运行，它就不能实质性地改进其操作。如果不进行替换，TCP将在Internet等长距离传输中造成严重的过载和中断。TCP固有的慢启动速度和高延迟变化会严重影响用户。IETF甚至不考虑修改TCP。事实上，IETF没有对流量控制做任何研究，因为每个人似乎都相信“如果它在过去有效，它将继续有效”。TCP必须尽快被新的流控制取代，这些流控制与显式速率流控制一样好。

RFC 2581(TCP拥塞控制(APnll999))定义了四种与TCP相关的拥塞控制算法：慢启动、拥塞避免、快速重传和快速恢复。每个算法将在下面进行描述。

TCP发送方必须使用慢启动和拥塞避免算法来控制发送到网络的数据量。为了实现这些算法，必须为每个TCP连接状态添加两个参数。拥塞窗口(cwnd)是发送方对在收到确认(ACK)之前可以发送到网络的最大数据量的限制，而接收方通知窗口(rwnd)是接收方对未完成数据量的限制。Cwnd和rwind的最小值决定了数据传输。另一个状态参数，慢启动阈值(ssthresh)，用于确定是使用慢启动还是拥塞避免算法来控制数据传输。

慢启动拥塞控制慢启动可以减少主机第一次传输时突发的影响。它要求主机开始缓慢地传输，然后增加，直到拥塞开始发生。主机最初并不知道它可以发送的数据包数量，因此它使用慢启动方法来测量网络容量。主机通过向接收端发送两个数据包开始传输。当接收方接收到数据片段时，它返回一个ACK作为确认。发送方将窗口增加到两个，并发送四个数据组。当发送方将数据包加倍时，发送的数据包数量会继续增加，直到没有收到任何ACK，这表明数据流已经达到网络处理流量的极限或接收方处理接收流量的极限。

慢启动不能防止拥塞，它只是防止主机立即进入拥塞状态。如果主机正在发送一个大文件，最终它将达到使网络过载并开始丢失数据包的状态。缓慢启动对于避免拥堵问题至关重要。但是新的应用程序，如IP语音，不能容忍慢启动造成的延迟，在某些情况下，慢启动是禁用的，所以用户可以“抢占”带宽。这种趋势只会导致问题。

Reno (Fast retransmission and Fast Recovery)快速重传和快速恢复(Fast retransmission and Fast Recovery)是一种旨在将数据包丢失对网络吞吐量影响降到最低的算法。快速重传机制从另一个TCP机制中推断出信息，接收方使用该机制向发送方发送信号，表明它收到了一个乱序数据包。该技术是向发送方发送几个重复的ACK。

通过假设重复的ACK信号丢失数据包，快速重传利用了这种能力。如果收到三个这样重复的ACK，数据源将重新发送数据包，而不是等待一个ACK直到计时器到期。这发生在超时之前，从而提高了网络吞吐量。例如，如果主机接收到数据块5和数据块7，但没有数据块6，那么当主机接收到数据块7(但没有数据块6)时，它将为数据块5发送一个重复的ACK。

在快速重传算法发送完看似丢失的数据段后，“快速恢复”算法主导新数据的传输，直到不重复的ACK到达。不慢启动的原因是，接收到重复的ACK不仅意味着数据段已经丢失，而且意味着该数据段极有可能从网络中丢失(尽管网络会产生大量重复的数据段，保证不会丢失)。换句话说，因为接收方只在数据段已经到达时才生成重复ACK，所以我们知道存储在接收方缓冲区中的数据段一旦从网络中移除就不会消耗网络资源。此外，由于保存了ACK时钟，TCP发送方可以继续发送新的数据段(尽管传输必须继续使用减少的cwnd)。

快速恢复是一种在使用快速重放时取代慢启动的机制。请注意，虽然重复的ACK表示数据丢失了，但它也表明数据包仍在流动，因为数据源收到了一个序列号高于丢失数据包的数据包。在这种情况下，假设单个数据包丢失并且网络没有完全拥塞，发送方不需要完全减速到慢启动模式，而是需要将速度降低到先前速度的一半。

注意，这种机制被称为Reno。RFC 258(对TCP快速恢复算法的新Reno修改，1999年4月)描述了对Reno的修改，以便它可以覆盖这种情况，也就是说，当ACK检测到数据丢失时，不能覆盖所有未解析的数据。主动队列管理和拥塞防止数据包丢失，降低效率。如果主机发生突发传输和拥塞，将导致大量数据包丢失。因此，检测即将发生的拥塞并在其失控之前对其进行主动管理是非常有用的。

主动队列管理是一种技术，在这种技术中，路由器主动从队列中丢失数据包，作为发送方应该减速的信号。RFC 2309列出了活动队列管理的以下好处：

突然的变化是不可避免的。保持较小的队列和主动管理队列可以提高路由器吸收突发数据包而不会丢失太多数据包的能力。

如果数据源溢出了共享队列，那么共享队列的所有设备都会变慢(“全局同步”问题)。

从多个丢失的数据组中恢复比从单个丢失的数据组中恢复更困难。

大队列可能会导致延迟。主动队列管理允许队列较小，从而提高吞吐量。

当一个主机填满队列并阻止其他主机使用该队列时，就会发生阻塞。主动队列管理可以防止这种情况发生。

下面介绍了几种避免拥塞的解决方案。这些技术之外的下一步包括业务流量调整、资源预留、虚拟电路和QoS技术。稍后会详细介绍。

RED(Random Early Discard) RED是一种主动队列管理方案，提供了一种避免拥塞的机制。

与传统的拥塞控制方案不同，RED使用统计方法在队列溢出之前以“随机”的方式丢弃数据包。传统拥塞控制方案在已经满的队列结束时丢失数据包。以这种方式丢弃数据分组可以降低数据源的速度，从而在队列溢出和主机高速传输时保持队列稳定并减少丢失数据包的数量。

RED做出了两个重要决定。它决定何时以及放弃哪些数据组。RED跟踪平均队列大小，当平均队列大小超过定义的限制时丢弃数据包。每次有新的数据包到达队列时，都会重新计算队列的平均值。RED有两个与队列长度相关的阈值：minth和maxth。RED决定放弃基于minth和maxth的数据分组：

最小限定值(minth)指定了一个平均队列大小，低于此值数据包不会被丢弃。

最大限定值(maxth)指定了平均队列大小，超过该值所有数据包将被丢弃。

当报文到达路由器时，RED计算avgQ的平均长度。如果avgQ小于minth，则不丢弃报文。当minthavgQmaxth时，计算概率P，并以此概率丢弃报文。当avgQmaxth时，所有的包都被丢弃。因为RED使用基于时间的平均队长，所以实际队长可能大于平均值，并且只有当队列已满时才会丢弃到达的数据包。

概率P的计算方法如下：

Pb=maxpx (avgQ-minth)/(maxth-minth) P=Pb/(1-countPb)

P不仅取决于avgQ，还取决于自上次丢包以来进入队列的数据包计数。随着计数的增加，下一个数据包被丢弃的概率慢慢增加。这样做的主要目的是均匀丢包，避免连续丢包，从而避免对突发流和全局同步的偏置。

RED使用时间平均，这意味着如果最近的队列通常是空的，RED将不会像处理主要拥塞事件那样处理意外突发。然而，如果队列保持接近满，RED假定拥塞并开始以更高的速率丢弃数据包。

RFC 2309认为，Internet上的活动队列管理机制具有许多性能优势，并且使用RED算法似乎没有缺点。

WRED(加权RED)是一种基于通信类型、通信目的地或其他因素丢弃数据分组的技术。WRED还根据网外数据分组的标签丢弃数据分组。

ECN(显式拥塞通知)在RED中，当队列的平均长度超过一定的阈值时，即在队列满的情况下，RED才会丢包，而不是由于队列溢出而被迫丢包。在这种情况下丢失数据包，虽然允许RED有效地管理平均长度，但会浪费网络资源，并且不适合需要一定时间的多媒体应用程序。一种更有效的技术是路由器在数据包中设置拥塞通知位，然后将数据包发送给接收者。然后，接收方可以通过ACK中的消息告诉发送方放慢速度。这样，接收端就会一直收到自己的数据包，并且可以通过丢弃数据包的方式避免发送拥塞信号。

ECN是使用该技术的端到端拥塞避免机制。顾名思义，ecn提供直接的拥塞通知，而不是通过丢弃数据包间接发送拥塞信号。Ecns在适度拥堵的情况下工作。当拥塞严重时，采用弃包技术。

ECN在IP包头中需要一个位ECN字段。一个是ECN-capable Transport (ECT)位，由源端设置，表示源节点的传输协议支持ecn。另一个是CE(拥塞经历)位，由路由器设置，显示是否发生拥塞。

当队列长度超过一定限制时，使能ecn的路由器会在ecn可用主机发出的数据包的报头中设置CD(Encounter拥塞)位。数据包被转发给接收方，然后接收方向发送方发送一个包含拥塞指示器的ACK。这种ACK称为ECN-Echo。当发送方接收到这个显式信号时，它将发送数据包的速率降低到原始速率的一半。

注意，ECN需要修改TCP。ecn在RFC 2481(ADD显式拥塞通知IP的建议，1999年1月)中有描述。

TCP速率控制TCP速率控制是一种终端可以根据执行速率控制的网络设备的反馈来调整其传输的技术。

TCP速率控制也被称为ERC(显式速率控制)。一种形式的ERC被用于ATM网络。

来自packketeer的PacketShaper保存有关每个TCP连接状态的信息。这允许它向控制其性能的数据源发送反馈。其主要目的是通过平滑数据源的传输速率来控制突发。随着突发次数的减少，业务流量管理变得更加容易。

在端系统间的网络内执行速率控制进程。PacketShaper截获来自接收方的ACK并保留一段时间，这段时间经过精确计算，以便发送方可以用消除突发的方式传输它的下一个数据分组。

例如，数据源将数据分组发送到接收方。接收方将ACK返回到发送方。PacketShaper截获ACK并更改某些内部设置，如TCP窗口的大小。恰好这时，PacketShaper发送数据分组和数据分组的内容(ACK序号加上窗口大小)并通知发送方该传输另一个数据分组了。

结果是，来自源的数据分组稳定流动，并改进了资源管理。不利方面是路由器必须主动跟踪每个数据流。此外，更改传输中的数据分组的内容不是个好方法，这取决于网络。通信量管理和QoS设备执行TCP速率控制。

其他方案

上面描述的大多数方案是队列管理方案。如果希望使用这些方案之外的解决方法来管理网络业务流量，则需要考虑优先权方案、数据分组标记方案、虚电路方案和QoS方案。

拥塞管理资源

SallyFloyd的Web站点是有关拥塞控制，尤其是拥塞避免的信息的最佳来源之一。IETF端点拥塞管理(ecm)工作组具有有关新拥塞控制方案的信息和评价当前的拥塞控制方案的文档。SallyFloyd撰写了RFC 2914 ( Congestion Control Principles， September2000)。IETF Transport Area (传输区域)工作组(tsvwg)正在制订新的传输规范。