拥塞控制和服务质量 congestion control and quality of service 是紧密联系在一起的两个问题：改进了其中的一个问题，则另一个问题也会有所改善；忽视了其中的一个问题，则通常意味着另一个也被忽视。在一个网络中，大多数防止或消除拥塞的技术，也能改进网络的服务质量。

之所以推迟到现在才讨论这些问题，是因为这些问题不止涉及到一层，而是涉及到三层：数据链路层、网络层和传输层。而且现在才讨论它们，也是为了能一次性地对这些问题做集中探讨、而不需要多次讨论同一主题。这里也给出了一些不同层中的拥塞控制和服务质量的示例。

---

24.1 数据通信量

对拥塞控制和服务质量要关注的重要方面是数据通信量 data traffic 。在拥塞控制中，要设法避免通信量拥塞；在服务质量中，要设法为通信量创造合理的环境。因此，在讨论拥塞控制和服务质量之前，首先讨论数据通信量本身。

24.1.1 通信量描述符

通信量描述符 traffic descriptors 是描述数据流的定性值。图24.1用这些值描述了通信量。

1. 平均数据速率

平均数据速率 average data rate 是在一段时间内发送的数据位数除以该时段所含的秒数。我们使用如下的等式：
$$\text{Average data rate}=\frac{\text{amount of data}}{\text{time}}$$

平均数据速率是通信量的一个非常有用的特性，因为它表明通信量所需要的平均带宽。

2. 峰值数据速率

峰值数据速率 peak data rate 定义了通信量的最大数据速率，如图24.1所示，它是 $y$ 轴方向上的最大值。峰值数据速率是一个很重要的概念，因为它表明让通信量通过网络、且无须改变数据流的情况下，网络所需的峰值带宽。

3. 最大突发长度

虽然峰值数据速率是很关键的，但是如果峰值持续时间很短，那么它通常可忽略不计。例如，如果数据正 $1\text{Mbps}$ 的速率稳定地传送，而突然以 $2\text{Mbps}$ 的峰值数据率传送了 $1\text{ms}$ ，网络也许可以处理这种情况。但是如果峰值速率持续 $60\text{ms}$ ，那么网络可能会出问题。最大突发长度 maximum burst size 一般是指以峰值速率传输通信量的最大时间长度 the maximum length of time the traffic is generated at the peak rate 。

4. 有效带宽

有效带宽 effective bandwidth 是指网络需要分配给通信流的带宽。有效带宽是三个值的函数：平均数据速率、峰值数据速率和最大突发长度。有效带宽的计算过程非常复杂。

24.1.2 通信量特征值

根据需要，数据流可以用以下通信量特征值 traffic profiles 之一来表述：恒定比特率、可变比特率或突发性。如图24.2所示。

1. 恒定比特率

在恒定比特率 constant-bit-rate, CBR 或固定速率的通信量模型中，具有恒定不变的数据速率。在这种类型的流中，平均数据速率和峰值数据速率是相同的，最大突发长度是无效的。对于一个网络而言，这种类型的通信量是可预知的，因而很容易处理。网络可以提前知道，要分配多少带宽给这种类型的流。

2. 可变比特率

在可变比特率 variable-bit-rate, VBR 类型中，数据流的速率随时间发生平滑的、而非突然的或急剧的变化。在这种类型的流中，平均数据速率和峰值数据速率是不同的。最大突发长度通常是一个很小的值。与恒定比特率的通信量相比，这种类型的通信量更难处理，但是它一般不需要重新整形，这将在后面可以看到。

3. 突发性数据

突发性数据 bursty data 是指在很短的时间内数据速率突然发生了变化。例如，它可能在几微秒内从零猛增到 $1\text{Mbps}$ ，或从 $1\text{Mbps}$ 猛降为零。它也可能在这个值上保持一会儿。在这种类型的数据流中，平均比特率和峰值比特率非常不同，最大突发长度非常重要。对于网络，这是最难处理的一种通信量类型，因为其特征值是不可预知的。为了处理这种类型的通信量，网络通常需要使用重新整形技术 reshaping techniques ，对其进行重新整形。这种技术稍后将会看到。突发性通信量是网络中发生拥塞的主要原因之一。

---

24.2 拥塞

拥塞 congestion 是分组交换网络 packet-switched network 中的一个重要问题。如果网络中的载荷 load（发送到网络中的分组数量），超过了网络的容量 capacity（网络中能处理的分组数量），那么在网络中就可能发生拥塞。拥塞控制 congestion control 指的是控制拥塞、使载荷低于网络容量的机制和技术。

为什么在网络中会发生拥塞？事实上，拥塞可能发生在任何涉及等待机制的系统之中 Congestion happens in any system that involves waiting 。例如，发生在高速公路上的拥塞是因为车流的某些异常，如在高峰期的事故，可能造成交通阻塞。在网络或者互联网络中也会发生拥塞，这是因为路由器和交换机中存在队列——在处理前、后保存分组的缓冲区。例如，路由器的每个接口中，都有输入队列和输出队列。当分组到达输入接口时，在将其转发前要经历三个步骤，如图24.3所示。

1. 在等待检验时，将分组置于输入队列的尾部。
2. 一旦分组到达了队列的前端，路由器的处理模块就将其从输入队列中移除，并运用路由表和目的地址来查找其路由。
3. 将分组置于适当的输出队列中，等待发送。
   
   这里需要注意两个问题。第一 ，如果分组的到达速率高于分组的处理速率，那么输入列会变得越来越长。第二，如果分组的转发速率低于分组的处理速率，输出队列也会变得越来越长。

拥塞控制包括了两个测试网络性能的要素：延迟 delay 和吞吐量 throughput 。图24.4说明了作为载荷函数的这两个性能度量。

• 延迟和载荷：注意，当载荷比网络容量小得多时，延迟 delay 最小。最小延迟是由传播延迟和处理延迟所组成的，并且它们都可以忽略不计。然而，当载荷达到网络容量时，延迟就会急剧增加，因为我们现在需要将 队列中的等待时间（对于路径中的所有路由器） 添加到总延迟中。注意，当载荷大于网络容量时，延迟会变为无穷大。
  如果这还不能说明问题，请考虑一下，在「几乎没有分组到达目的端」或「经过无穷大的延迟到达目的端」时队列的长度，此时队列变得越来越长。延迟会加重载荷，并因此会导致拥塞现象发生。当分组被延迟时，源端就会在没有收到确认的情况下重发分组，这个过程则会加重延迟和拥塞。
• 吞吐量和载荷：在【计算机网络】第二部分 物理层和介质(3) 数据和信号中，将吞吐量定义为在 $1$ 秒内通过一个节点的位数。可以将位换成分组、将节点换成网络，从而扩展这个定义，将网络吞吐量 throughput 定义为单位时间内通过网络的分组数量。
  注意，当载荷小于网络容量时，吞吐量随载荷的增加成比例地增长。当载荷达到网络容量后，期望吞吐量保持恒定。但是实际情况恰好相反，吞吐量会急剧下降。原因是路由器丢弃了分组。当载荷超过网络容量时，队列饱和了，此时路由器不得不丢弃一些分组。丢弃分组并不能减少网络中分组的数量，因为当分组没有到达目的端时，源端就运用超时机制重发它们。

---

24.3 拥塞控制

拥塞控制是指在拥塞发生之前预防拥塞、或在拥塞发生之后消除拥塞的技术和机制。通常，我们把拥塞控制分为两大类：开环拥塞控制（预防）和闭坏拥塞控制（消除）。如图24.5所示。

24.3.1 开环拥塞控制

在开环拥塞控制 open-loop congestion control 中，在拥塞发生之前，应用某种策略来预防拥塞现象的发生。在这些机制中，源端或目的端都可以处理拥塞控制。下面简要列出能预防拥塞的几种策略。

1. 重传策略

有时重发是不可避免的。如果发送方认为一个发送分组丢失或损坏，则该分组就需要重发。重发一般在网络上会增加拥塞现象，然而一个好的重传策略 retransmission policy 能预防拥塞，必须优化设计重传策略和重传定时器，使之具有高效率，并用来预防拥塞。例如，TCP所用的重传策略被设计用来防止和减轻拥塞。

2. 窗口策略

发送方窗口的类型也会影响拥塞。对拥塞控制而言，选择性重复窗口 Selective Repeat window 要优于回退N帧窗口 Go-Back-N window。在回退N帧窗口中，当一个分组的计时器到时，可以重发多个分组，尽管其中一些分组可能已安全与可靠地到达接收方，但这种重复会使拥塞更加严重。而选择性重复窗口试图发送那些被丢失或损坏的特定分组。

3. 确认策略

接收方使用的确认策略 acknowledgment policy 也可能影响拥塞。

• 如果接收方并不对它所接收的每一个分组进行确认，则它会使发送方放慢发送速度，从而有助于预防拥塞。有些协议就是采用这种办法。
• 接收方有一个要发送的分组或一个特定的计时器到时，接收方才发送一个确认。
• 接收端可以决定每次对 $N$ 个分组仅发送一个确认。

我们要知道确认也是网络中负载的一个部分，发送确认越少意味着网络的负载 load 越轻。

4. 丢弃策略

路由器使用好的丢弃策略 discarding policy 可以预防拥塞，同时不破坏传输的完整性。例如，在声音传输中，如果在可能发生拥塞时丢弃那些不敏感的分组，则仍可保证声音的质量，并且还能预防或减轻拥塞现象的发生。

5. 许可策略

在虚电路网络 virtual-circuit networks 中，许可策略 admission policy 是一种服务质量机制，也能预防拥塞。在允许数据流进入网络之前，与数据流通路相连的交换机首先检查其资源需求，如果网络有拥塞或可能出现拥塞，路由器将拒绝建立虚电路。

24.3.2 闭环拥塞控制

在拥塞发生之后，采用闭环拥塞控制 closed-loop congestion control 可以缓解拥塞状况。不同的协议采用了多种机制，下面对这几种机制进行介绍。

1. 背压

背压 backpressure 技术是一种拥塞控制机制。在这种技术中，一个拥塞点停止接收来自直接上行节点、或一些近邻节点的数据。这会引起上行节点或一些近邻节点发生拥塞，它们依此拒绝它们的上行节点或一些近邻节点的数据，依此类推。

背压是点到点拥塞控制，它从一点开始，然后传播，沿着数据流反方向到达源端。背压技术仅用于虚电路网络——在虚电路网络中，每个节知道数据的流是来自它的上行节点。图24.6表示了背压的思想。

在图24.6中，节点 III 有了超出它处理能力的输入数据，它停止将某些分组放入输入缓存区中，并通知节点 II 降低传输速率。节点 II 由于降低输出数据流的速率，可能会拥塞。如果节点 II 拥塞，则它通知节点 I 降低传输速率，它也可能会形成拥塞。如果是如此，则节点 I 通知源端降低数据传输速率。这样可以及时减轻拥塞。注意：为了消除阻塞，对节点 III 的压力反向移动到摞端。

我们讨论过的 一些虚电路网络不使用背压策略。但是，在第一个虚电路网络X.25，使用过这策略。这种技术在数据报网络不可能实现，因为在这种类型的网络中，一个节点（路由器）没有关于上行节点的知识。

2. 抑制分组

抑制分组 choke packet 是一个分组，该分组由节点发送给源端，通知它发生拥塞的情况。注意背压和抑制分组方法的不同：

• 在背压方法中，警告从一个节点到它的上行节点，虽然警告可能最后到达源端。
• 在抑制分组方法中，警告从已经发生拥塞的路由器直接传到源端，该分组经过的那些中间节点没被警告。

在ICMP中已看到过这种控制类型。当因特网中一个路由器被大量的IP数据报淹没时，它可能丢弃一些数据报，但它使用一个ICMP源站抑制报文通告源主机。警告报文直接发送给源站点，中间的路由器不进行任何处理。图24 .7表示抑制分组的思想。

3. 隐含信令

在隐含信令 implicit signaling 中，拥塞节点或节点们 the congested node or nodes 与源端之间没有通信。源端能从其他有关征兆中，察觉出在网络某处有拥塞。例如，当源端发送多个分组，暂时还没有收到确认时，一种设想是网络发生了拥塞。在接收确认过程中发生的延迟现象，就可以认为网络发生了拥塞：源端应该降低发送速率。在后面讨论TCP拥塞控制时，将看到这种类型的信令。

4. 显式信令

发生拥塞的节点能发送一种显式信令 explicit signaling 通知源端或目的端发生了拥塞。但是，显式信令方法与抑制分组方法是不同的：

• 在抑制分组方法中，有一个单独的分组用于此目的；
• 而在显式信令方法中，信号包含在携带数据的分组中。

就像在帧中继拥塞控制中所看到的那样，显式信令也具有前向或后向特征。

• 后向信令 backward signaling ：将一个位设置在分组中，并使之向与拥塞发生方向相反的方向移动。该位提示源端网络发生了拥塞，并提示它需要放慢发送速度，以避免分组的丢失。
• 前向信令 forward signaling ：将一个位设置在分组中，并使之向发生拥塞的方向移动。该位提示目的端网络发生了拥塞。在此情况下，接收端能使用诸如「放慢确认发送速度的策略」来减轻拥塞。

---

24.4 两个示例

为了更好地理解拥塞控制的概念，我们举两个例子：一个是TCP中的拥塞控制（重传、窗口、确认、隐含信令），另一个是帧中继中的拥塞控制（显式信令）。

24.4.1 TCP中的拥塞控制

在【计算机网络】第五部分 传输层(23) UDP、TCP和SCTP中已讨论过TCP，现在说明TCP如何利用阻塞控制，避免或减轻网络中的拥塞。

1. 拥塞窗口

在(23) UDP、TCP和SCTP中，曾提到过流量控制，并试图讨论「如何解决接收方由于大量数据的到来而陷入瘫痪」的情况。须知，发送方窗口大小取决于接收方可用的缓冲空间 rwnd ，即假设只有接收方能够规定发送方的发送方窗口大小。在这里完全忽视了另一个实体——网络。如果网络无法以发送方创建的速度传递数据，它必须告诉发送方减慢发送速率。也就是说，除了接收方之外，网络应当是确定发送方窗口大小的第二个实体。

现在，发送方窗口大小不仅取决于接收方，而且还取决于网络拥塞的情况。发送方有两种信息：接收方通告的窗口大小 receiver-advertised window, rwnd 和拥塞窗口大小 congestion window, cwnd ，实际的窗口大小是这两者中的最小者（实际的窗口大小 = min(rwnd, cwnd)）。我们简要说明如何确定拥塞窗口大小。

2. 拥塞策略

TCP处理拥塞的一般策略基于三个阶段：慢速启动（指数增长）、拥塞避免（加性增加）和拥塞检测（乘性减少）。在慢速启动阶段，发送方用很慢的传输速率开始，但迅速地增加到阈值 threshold 。在达到阈值时，为了避免拥塞而降低数据速率。最后，如果检测到拥塞，则发送方根据检测到拥塞的方式，返回慢启动或拥塞避免阶段 the sender goes back to the slow-start or congestion avoidance phase based on how the congestion is detected 。

(1) 慢速启动：指数增长

TCP拥塞控制所使用的一种算法称为慢速启动 Slow Start: Exponential increase 。这种算法也是基于「拥塞窗口的大小 cwnd 从一个最大段长度MSS开始」的思想。MSS是在连接建立期间，由「相同名称的选项 an option of the same name 」所确定的（最大段长度选项）。每次接收到一个确认时，窗口大小增加一个MSS值。正如其名，窗口是慢速启动，但是按指数规则增长的。

为了说明这个思想，让我们观察图24.8。注意：为了使讨论更清晰，这里进行了三个简化。使用段的个数而不是字节的个数（好像每段仅有一个字节）；假定 rwnd 比 cwnd 大得多，这样发送方窗口大小永远等于 cwnd ；还假定每段都是单独进行确认。

• 发送方以 cwnd= 1MSS 开始，这意味着发送方仅能发送一个段。
• 接收到段 $1$ 的确认后，拥塞窗口增加 $1$ ，cwnd 是 $2$ 。这意味着现在可发送另外两个段。当接收到每一个确认时，窗口大小都增加 1MSS 。
• 接收到段 $2,3$ 的确认后，拥塞窗口增加 $2$ ，cwnd 是 $4$ 。这意味着现在可发送另外四个段。
• 接收到段 $4,5,6,7$ 的确认后，拥塞窗口增加 $4$ ，cwnd 是 $8$ 。这意味着现在可发送另外八个段。
• 当所有 $7$ 个段都被确认时，cwnd = 8MSS 。

如果我们按照（整个窗口中的所有段被确认的）传输次数观察 cwnd 的大小，则发现其速率是按指数规律增长如下所示：

需要指出的是，如果有被延迟的 ACK ，则窗口大小的增长小于 $2$ 的幂 if there is delayed ACKs, the increase in the size of the window is less than power of 2 。

慢速启动不能一直继续下去，拥塞窗口大小按指数规律增长，直到到达阈值，就必须停止该阶段。发送方保存一个称为慢速启动阈值 slow-start threshold, ssthresh 的变量，当「拥塞窗口中的字节（这里简化为段数）」达到这个阈值时，慢速启动阶段结束、而下一个阶段开始。在大多数实现中，ssthresh 一直是 $65535$ 字节。

(2) 拥塞避免：加性增加

如果我们以慢速启动算法开始，则拥塞窗口大小按指数规律增长。为了在拥塞发生之前避免拥塞，必须降低指数增长的速度。TCP定义了另一个算法，称为拥塞避免 congestion avoidance ，这个算法是加性增加 additive increase 、而非指数增加。当拥塞窗口的大小达到慢速启动的阈值时，慢速启动阶段停止，加性增加阶段开始。

在这个算法中，每次整个窗口所有段都被确认（一次传输）时，拥塞窗口才增加 $1$ 。为了说明这个概念，将这个算法应用到与慢速启动相同的情况中，尽管我们将看到，拥塞避免算法通常在窗口的大小远远大于 $1$ 时启动 the congestion avoidance algorithm usually starts when the size of the window is much greater than 1 。图24.9表示这个思想。在这种情况下，发送方接收到「对一个完整窗口大小段的那些确认」后，窗口大小才增加一个段。即在拥塞避免算法中，拥塞窗口大小是加性增加的，直到检测到拥塞。

如果我们按照传输次数观察 çwnd 的大小，则发现其速率是按加性规律增长，如下所示：

(3) 拥塞检测：乘性减少

如果发生拥塞，拥塞窗口的大小必须减小。发送方能推测出发生拥塞现象的唯一方法，是需要重传段 The only way the sender can guess that congestion has occurred is by the need to retransmit a segment 。可是重传是在两种情况下发生：重传计时器到时或接收到了三个 ACK 。在这两种情况下，阈值就下降一半，即乘性减少 multiplicative decrease 。大多数TCP实现包含两个反应：

1. 如果计时器到时，那么存在着非常严重的拥塞的可能性——一个段可能己在网络中丢失，并且没有关于该发送段的消息。在这种情况下，TCP做出强烈的反应：
   a. 设置阈值为当前拥塞窗口大小的一半 ssthresh = cwnd / 2 ；
   b. 设置 cwnd 为一个段的大小 cwnd = MSS / 2 ；
   c. 启动慢速启动阶段。
2. 如果接收到三个 ACK ，那么存在着轻度拥塞的可能性——一个段可能已丢失，但自从接收到三个 ACK 后，有一些段可能已安全到达。这称为快速传送和快速恢复 fast transmission and fast recovery 。在这种情况下，TCP做出轻度的反应：
   a. 设置阈值为当前拥塞窗口大小的一半 ssthresh = cwnd / 2 ；
   b. 设置 cwnd 为阈值（有些实现是阈值加上三个段），注意先后顺序；
   c. 启动拥塞避免阶段。

用下列方法之一对拥塞检测做出反应：

• 如果检测出计时器到时，那么一个新的慢速启动阶段开始。
• 如果检测出三个 ACK ，那么一个新的拥塞避免阶段开始。

(4) 总结

在图24.10中，概括了TCP的拥塞策略与三个阶段之间的关系。

在图24.11中给出了一个例子。假定最大窗口大小 ssthresh 是 $32$ 个段，阈值设置为 $16$ 个段（最大窗口的一半）。在慢速启动阶段，窗口大小从 $1$ 开始按指数规律增长，直到它达到阈值。当它达到阈值后，拥塞避免（加性增加）过程允许窗口大小线性增长，直到计时器到时或到达最大窗口大小。

在图24.11中，当窗口大小为 $20$ 时，计时器到时。此时，进入乘性减少过程，将阈值设置为当前窗口大小的一半。当计时器到时，当前窗口大小是 $20$ ，因此现在阈值是 $10$ 。TCP再次进入慢速启动，并置窗口大小为 $1$ 。当到达新的阈值时，TCP进入加性增加阶段。当窗口大小为 $12$ 时，三个 ACK 事件发生。再次进入乘性减少过程，阈值和窗口大小设置为 $6$ ，这时TCP进入加性增加阶段，该阶段一直维持到另一个计时器到时、或者另外三个 ACK 事件发生为止。

24.4.2 帧中继中的拥塞控制

帧中继网络中的拥塞，会导致吞吐量降低和延迟增加，高吞吐量和低延迟是帧中继协议的主要目标。帧中继协议没有流量控制机制。另外，帧中继允许用户传送突发性数据。这意味着，帧中继网络有可能因为通信量过大、而发生拥塞现象，因此需要有拥塞控制机制。

为了避免拥塞，帧中继协议在帧中利用 $2$ 个位，明确地提示源端和目的端拥塞的发生（显式信令）。

• 后向显式拥塞通知 backward explicit congestion notification, BECN 位提示发送方网络中的拥塞情况。因为帧是从发送方传送出来的，有人可能问这是如何实现的。实际上有两种方法：交换机利用来自接收方的响应帧（全双工模式）；或者为了特定的目的，交换机可使用一个预定义连接 DLCI=1023 来发送专门的帧。发送方仅通过减小数据速率，对该提示信息做出响应。图24.12说明了运用BECN的情况。
  
• 前向显式拥塞通知 forward explicit congestion notification, FECN 位是用来提示接收方网络中拥塞的情况。有可能会出现「接收方不能采取任何措施来减轻拥塞」的情况。但是，帧中继协议假定：发送方和接收方能相互通信，并在较高层使用某种类型的流量控制机制。例如，如果在较高层有确认机制，接收方就能延迟发送确认，这样就可以迫使发送方放慢发送速度。图24.13说明了运用FECN的情况。
  

当两个端点运用帧中继网络进行通信时，可能会出现四种与拥塞有关的情况。图24.14说明了这四种情况、以及FECN和BECN的值。

---

24.5 服务质量

服务质量 quality of service , QoS 是一个网络互联问题，对该问题的讨论已经远远超出对它的定义。可以非形式地、将服务质量定义为数据流所追求的某种目标。

24.5.1 数据流特性

按传统的观点，数据流具有四种特性：可靠性、延迟、抖动和带宽，如图24.15所示。

1. 可靠性

可靠性 reliability 是数据流所需要的一个特性。缺乏可靠性意味着分组或确认的丢失，这些都必须通过重传来弥补。然而，应用层程序对可靠性的敏感程度是不同的。例如，电子邮件、文件传输和因特网访问与电话或音频会议相比，保证其可靠传输更为重要。

2. 延迟

源端到目的端的延迟 delay 是另一个数据流特性。此外，不同的应用对延迟的容许程度是不同的。在此情况下，电话、音频会议、视频会议和远程登录都需要最小的延迟，但是在文件传输或电子邮件中，延迟并不那么重要。

3. 抖动

抖动 jitter 是属于同一数据流的分组延迟的变化。抖动被定义为分组延迟的变化，较高的抖动意味着在延迟之间的差异较大，而低的抖动意味着差异很小。

例如，如果 $4$ 个分组离开的时间分别是 $0,1,2,3$ ，而到达的时间分别是 $20,21,22,23$ ，则它们都有相同的延迟为 $20$ 。另一方面，如果上述 $4$ 个分组的到达时间分别是 $21,23,21,28$ 。则它们延迟是不同的：$21,22,19,24$ 。对于音频和视频的应用，前者是完全可接受的，而后者是不能接受的。只要延迟对所有的分组都是相同的，分组以短或者长的延迟到达，无关紧要。

在(29)中，将看到多媒体通信如何处理抖动。如果抖动高，那么为了使用接收到的数据，就需要执行一些动作。

4. 带宽

不同的应用需要不同的带宽。在视频会议中需要发送数百万比特率来刷新彩色屏幕，但在一封电子邮件中的全部位的个数，甚至都不到一百万。

24.5.2 数据流类型

基于数据流的特性，可将数据流分成不同的组，每组都有相似的特性。这种分类方法既不够规范也不够普遍。一些诸如ATM之类的协议定义了类型的概念，稍后可以看到这一点。

---

24.6 改进QoS的技术

在第24.5节中，根据数据流的特性对QoS进行了定义。本节将讨论一些用于改进服务质量的方法。这里简要地讨论四种常用方法：调度、通信量整形、许可控制和资源预留。

24.6.1 调度

来自不同数据流的分组到达交换机或路由器，并由它进行处理。一种好的调度技术，会以公平合理的方式来对待不同的数据流。现在已经设计了多种调度技术用来改进服务质量，在这里讨论其中的三种技术：FIFO队列、优先权队列和加权公平队列。

1. 先进先出队列

在先进先出 first-in first-out, FIFO 队列中，分组在缓冲区（队列）中等待，直到节点（路由器或交换机）准备处理它们为止。如果平均到达速率高于平均处理速率，那么队列将被填满，新的分组将被丢弃。FIFO队列和那些必须在公共汽车站等待汽车的人类似。图24.16说明了FIFO队列的概念。

2. 优先权队列

在优先权队列 priority queuing 中，首先给不同的分组分配一个不同的
到达的优先权类。每个优先权类都有自己的队列，在最高优先权队列中的分组首先得到处理，而最后才对最低优先权队列中的分组进行处理。注意：系统不停地为一个队列提供服务，直到它变空为止。图24.17说明了，具有两个优先权级别的优先权队列（为了简单起见）。

与FIFO队列相比，优先权队列能提供更好的QoS，因为具有较高优先权的通信量（如多媒体），能用较少的延迟到达目的端。但是，优先权队列也有潜在的缺点——如果在高优先权队列中有持续的通信量，那么处于较低优先权队列中的分组将永远得不到处理，这种情形称为"饥饿" starvation 。

3. 加权公平队列

较好的调度算法是加权公平队列 weighted fair queuing 。在这种技术中，分组仍然被分成不同的类，并且属于不同的队列。然而，队列是基于队列的优先权来分配权重的，较高的优先权就意味着具有较高的权重。系统以轮换方式来处理每个队列中的分组，所处理的分组的数量等于相应队列的权重。例如，如果这些权重是 $3,2,1$ ，那么就对第一个队列中的 $3$ 个分组、第二个队列中的 $2$ 个分组和第三个队列中的 $1$ 个分组进行处理。如果系统并没有给不同类指定不同的权重，那么所有的权重就是相等的。这就是加权公平队列的原理。图24.18以三个类为例说明了这种技术。

24.6.2 通信量整形

通信量整形 traffic shaping 是一种控制「发送到网络中的通信量和速率」的机制。通信量整形有两种技术：漏桶和令牌桶。

1. 漏桶

如果桶在底部有一个小洞，只要桶中有水，水便从桶中以不变的速率漏下。如果桶中有水，水漏的速率并不依赖于将水倒入桶中的速率，即输入速率可以发生变化，但是输出速率保持恒定。同样，在网络中一种被称为漏桶 leaky bucket 的技术，能消除突发性通信量。将突发性大块数据存储到桶中，然后以平均速率发送出去。图24.19说明了漏桶和其效果。

在图24.19中，假设网络为每台主机都设定了 $3\text{Mbps}$ 的带宽。使用漏桶对输入通信量进行整形，是为了使通信量符合这个设定的带宽。在图24.19中，主机以 $12\text{Mbps}$ 的速率发送了 $2$ 秒的突发性数据，数据一共是 $24\text{M}$ 位。主机在之后的 $5$ 秒内没有任何反应，然后以 $2\text{Mbps}$ 的速率发送数据，持续时间为 $3$ 秒，此时的全部数据为 $6\text{M}$ 位。主机在 $10$ 秒内总共发送了 $30\text{M}$ 位的数据。在这同样的 $10$ 秒内，漏桶以 $3\text{Mbps}$ 的速率发送数据来使通信量保持平稳。

如果没有漏桶，因为该主机占用了比分配给它的更大的带宽，它开始所发送的突发性数据可能已经导致网络拥塞。漏桶还可以避免拥塞。做个类比，以高峰期间（突发性通信量）的高速公路为例，如果往返者们能错开他们的工作时间，那么高速公路上的拥塞状况就可以得到避免。

简单的漏桶实现过程如图24.20所示。FIFO队列保存了分组。如果这个通信量由固定大小的分组（例如 ATM 网中的信元）组成，那么在每个时钟单位时间内，进程从队列中移除固定数量的分组。

如果通信量是由变长分组组成的，那么固定输出速率必须是基于字节个数或位个数。以下是变长分组的算法：

1. 在计时开始时，将计数器初始化为 $n$ ；
2. 如果 $n$ 比分组的长度大，就发送分组，并将计数器的值减去分组的长度。重复该步骤，直到 $n$ 值小于分组的长度；
3. 重新设置计数器，并返回到步骤 $1$ 。

总的来说，漏桶算法通过均分数据速率，将突发性通信量整形为固定速率的通信量。如果桶已满，就可能丢失分组。

2. 令牌桶

漏桶算法有很大的局限性，它不能给空闲的主机提供信用。例如，如果一台主机在一 段时间内没有发送数据，其漏桶就变为空桶了。现在即使主机发送高突发性数据，漏桶也只能允许平均速率的数据。此时并没有考虑主机空闲时间。

另一方面，令牌桶 token bucket 算法允许空闲主机以令牌的形式为未来累积信用。在每个时钟单位时间内，系统发送 $n$ 个令牌到桶中。在每个数据信元（或字节）发送后，系统就从中去掉一个令牌。 例如，假设 $n$ 是 $100$ ，主机空闲了 $100$ 个时钟单位时间，那么令牌桶便收集了 $10000$ 个令牌。主机可以在一个时钟单位时间，消费所有这些令牌来发送 $10000$ 个信元，或者花去 $1000$ 个时钟单位时间，每个时钟单位时间内发送 $10$ 个信元。换句话说，只要令牌桶不是空的，主机就能发送突发性数据。图24.21说明了该算法的原理。

使用计数器可以很容易地实现令牌桶算法。令牌初始化为 $0$ 。每次增加 $1$ 个令牌，计数器就加 $1$ ，每次发送一个数据单元，计数器就减 $1$ 。当计数器为 $0$ 时，主机不能发送数据。

令牌桶允许以规定的最大速率发送突发性通信量。

3. 令牌桶和漏桶的结合使用

可将两种技术结合起来给空闲主机提供信用，同时调整通信量。在令牌桶之后应用漏桶；漏桶的速率需要高于将令牌放入桶中的速率 The leaky bucket is applied after the token bucket; the rate of the leaky bucket needs to be higher than the rate of tokens dropped in the bucket 。

24.6.3 资源预留

数据流需要诸如缓冲区、带宽、CPU时间等资源。如果提前对这些资源进行预留，将会提高服务质量。在这一节将讨论一个称为综合业务的QoS模型，该模型极大地依赖资源预留来提高服务质量。

24.6.4 许可控制

许可控制指的是由路由器或交换机使用的一种机制，它基于一个称为数据流规范 flow specifications 的预定义参数 predefined parameters 来接收或拒绝数据流。在路由器接收数据流并对其进行处理之前，它检查数据流规范，查看它的性能（根据带宽、缓冲区大小及CPU速度等）、以及之前它对其他数据流的约定，是否可以处理新的数据流 Before a router accepts a flow for processing, it checks the flow specifications to see if its capacity and its previous commitments to other flows can handle the new flow 。

---

24.7 综合业务

根据24.5节和24.6节的讨论，在因特网中已经设计出了两种用于提供服务质量的模型 two models have been designed to provide quality of service in the Internet ：综合业务和差分业务。两个模型都强调服务质量在网络层（lP）的使用，尽管这些模型也可以用于诸如数据链路层的其他层。本节讨论综合业务，第24.8节讨论差分业务方面的内容。

正如在第20章中所了解到的，IP最初是为尽力传递而设计的。这意味着每个用户接受同样级别的服务。这种类型的传递不能保证一项业务的最低要求，例如实时音频和视频应用所需的带宽。即使这样的应用偶然获得了额外的带宽，也可能对其他应用造成不利影响，并导致拥塞现象发生。

综合业务 integrated service 有时称为 IntServ ，它是设计用于IP的、基于数据流的QoS模型 flow-based QoS model 。这意味着，用户需要创建一条从源端到目的端的流，即一种虚电路，并将资源需求通知给所有的路由器。

24.7.1 信令

IP是一种无连接的、数据报、分组交换协议。如何在一种无连接的协议上实现一个基于数据流的模型呢？解决办法是在IP上使用信令协议 signaling protocol ，它为资源预留提供信令机制 provides the signaling mechanism for making a reservation 。这个协议称为资源预留协议 Resource Reservation Protocol, RSVP ，稍后会讨论到它。

24.7.2 数据流规范

当源端做资源预留时，需要定义数据流规范。数据流规范包括两个部分：资源规范 resource specification, Rspec 和通信量规范 traffic specification, Tspec 。Rspec 定义数据流需要预留的资源（如缓冲区、带宽等），Tspec 定义数据流的通信量特征。

24.7.3 许可

在路由器从一个应用接收到数据流规范后，它决定许可或拒绝这个业务。所做出的决定基于路由器的先前约定和资源的当前有效性 the previous commitments of the router and the current availability of the resource 。

24.7.4 业务类型

综合业务已经定义了两种类型的业务：保证型业务和受控载荷型业务。

• 保证型业务 guaranteed service ：这种类型的业务用于实时传输，这种传输需要保证端到端延迟最小。端到端延迟是指在各路由器中的延迟之和、在介质中的传播延迟和设置机制 the delays in the routers, the propagation delay in the media, and the setup mechanism 。只有第一项，即在各路由器中的延迟之和可由路由器来保证。
  这类业务保证分组在一定的传递时间内到达，并且只要数据流通信量在 Tspec 边界范围之内，即可保证不丢弃分组。可以说保证型业务就是定量业务，在这种业务中，端到端延迟量和数据速率必须由应用来定义。
• 受控载荷型业务 controlled-load service ：这种类型的业务用于「可以接受一定延迟、但对超载网络和丢失分组的危险很敏感」的应用。
  这些类型应用的较好实例有文件传输、电子邮件和因特网访问。受控载荷型业务是一种定性业务，因为应用要求较低的分组丢失率或零分组丢失率。

24.7.5 RSVP

在综合业务模型中，应用程序需要资源预留。正如在 IntServ 模型中所讨论的那样，为数据流进行资源预留。这意味着，如果要在IP层使用 IntServ ，则需要在IP层之外创建一条数据流通路，它是一种虚电路网络，最初被设计为一种数据报分组交换网络。在数据传输可以启动之前，虚电路网络需要信令系统来建立虚电路。资源预留协议 RSVP 是一种信令协议，它帮助IP创建一条数据流通路，从而实现资源预留。在讨论 RSVP 之前，需要指出的是，它是一种与综合业务模型分开的独立协议，可以用于其他模型中。

1. 多播树

RSVP 不同于以前看到的一些其他信令系统，因为它是一种用于多播的信令系统。但是，RSVP 也能用于单播，因为单播仅仅是在多播组中只有一个成员的多播的一个特例。这样设计的原因是，使RSVP能够为各种通信量提供资源预留，包括经常使用多播的多媒体。

2. 基于接收方的预留

在 RSVP 中，由接收方（而不是发送方）建立预留。这种策略和其他多播协议相匹配。例如，根据多播路由选择协议，由接收方而非发送方来决定加入或离开多播组。

3. RSVP报文

RSVP 有多种类型的报文。然而根据需要，下面只讨论其中的两种：路径 Path 和预留 Resv 。

• 路径 Path 报文：回想一下，在 RSVP 中数据流中的接收方预留资源。但在预留资源之前，接收方并不知道分组经过的路径，而预留资源是需要知道路径的。为了解决这个问题，RSVP 使用路径报文。路径报文从发送方传送出来，到达多播路径中的所有接收方。在整个路径中，路径报文为接收方存储必要的信息。在多播环境中，将路径报文发送出去，并且在路径分叉时会产生新的报文。图24.22说明了路径报文。
  
• 预留 Resv 报文：在接收方已经收到路径报文之后，它发送预留报文。预留报文朝着发送方传送（上行），并且在支持 RSVP 的路由器上预留资源。如果路由器不支持路径中的 RSVP ，它将使用以前所讨论的尽力传递方法对分组进行路由。图24.23说明了预留报文。
  

4. 预留合并

在 RSVP 中，并没有为数据流中的每个接收方预留资源，而是将资源预留进行了合并 reservation merge 。在图24.24中，$Rc3$ 请求 $2\text{Mbps}$ 带宽，而 $Rc2$ 请求 $1\text{Mbps}$ 的带宽，需要建立带宽预留的路由器 $R3$ 将这两个请求合并，只对 $2\text{Mbps}$ 带宽的那个请求（即两个中较大的那个请求）做预留，这是因为 $2\text{Mbps}$ 的输入预留就能处理这两个请求。这种情况对 $R2$ 也是适用的。

可能问，为什么 $Rc2$ 和 $Rc3$（两者都属于一个单一数据流）要请求不同的带宽值呢？答案是，在多媒体环境中，不同的接收方可以处理不同的质量等级。例如，$Rc2$ 或许只能以 $1\text{Mbps}$（较低质量）的速率接收视频信息，而 $Rc3$ 或许可以 $2\text{Mbps}$（较高质量）的速率接收视频信息。

5. 预留方式

当存在多条数据流通路时，路由器需要预留资源来接收所有的数据流。RSVP 定义了三种预留方式，如图24.25所示。

• 通配过滤器方式 Wild Card Filter Style ：在这种方式中，路由器为所有发送方创建一个预留。这个预留是基于最大的请求。这种方式用于「来自不同发送方的数据流不同时出现」的情况。
• 固定过滤器方式 Fixed Filter Style ：在这种方式中，路由器为每个数据流创建一个不同的预留。这意味着如果有 $n$ 个数据流，就要建立 $n$ 个不同的预留。这种方式用于「来自不同发送方的数据流同时出现的概率很高」的情况。
• 共享显式方式 Shared Explicit Style ：在这种方式中，路由器只创建一个预留，该预留可以被一组数据流共享。
  

软状态 soft state ：为数据流而存储在每个节点中的预留信息（状态），需要定期进行刷新。与用于其他诸如ATM或帧中继这类虚电路协议的硬状态 hard state 相比，这种状态称为软状态。在硬状态中，有关数据流的信息被一直保留着，直到这些信息被擦除为止。目前默认的刷新间隔是 $30$ 秒。

24.7.6 综合业务所存在的问题

在综合业务中至少存在两个问题，这可能会妨碍它在因特网中的实现。它们是可伸缩性和服务类型限制。

• 可伸缩性 scalability ：综合业务模型要求每台路由器都要为每个数据流保存信息。但随着因特网规模的日益增长，这是一个严重的问题。
• 业务类型限制 service-type limitation ：综合业务只提供了两种类型的业务，即保证型业务和受控载荷型业务。那些反对该模型的人指出，应用可能需要比这两种业务类型更多的业务类型。

---

24.8 差分业务

差分业务 Differentiated Services, DS or Diffserv 是由因特网工程任务组 Internet Engineering Task Force , IETF 提出的用于弥补综合业务缺陷的一种业务。与综合业务相比，它有两个基本变化：

1. 主要处理过程从网络核心转移到网络边缘。这就解决了可伸缩性的问题，路由器不需要存储有关数据流的信息。每次发送分组时，应用程序或主机定义它们所需要的业务类型。
2. 将「针对每条数据流的业务 per-flow service 」改变为「针对每种类型的业务 per-class service 」。路由器根据在分组中定义的业务类型、而非根据数据流来发送分组 The router routes the packet based on the class of service defined in the packet, not the flow 。这就解决了业务类型限制的问题，可根据应用程序的需要定义不同的业务类型。

差分业务是用于IP的、基于类的QoS模型 class-based QoS model designed for IP 。

1. DS字段

在 Diffserv 中，每个分组都包含一个称为 DS 的字段。该字段的值是在网络边界，由主机或用作边界路由器的第一台路由器来设置的。

IETF提议用 DS 字段，替换现存的IPv4中的服务类型 type of service, TOS 字段或IPV6中的类字段，如图24.26所示。

DS 字段包含两个子字段：DSCP 和 CU 。差分业务编码点 Differentiated Services Code Point , DSCP 是一个 $6$ 位的子字段，它定义了逐跳行为 per­hop behavior, PHB 。长度为 $2$ 位的当前未用 currently unused , CU 子字段，当前还未使用。

支持 Diffserv 的节点（路由器）使用 DSCP 的 $6$ 位作为一个表的索引，该表定义了分组处理机制 packet-handling mechanism ，用于当前正在处理的分组。

2. 逐跳行为

Diffserv 模型为接收到分组的每个节点定义了逐跳行为 PHB 。到目前为止已定义了三种 PHB ： 默认逐跳行为 default PHB, DE PHB 、加速转发逐跳行为 expedited forwarding PHB, EF PHB 和保证转发逐跳行为 assured forwarding PHB, AF PHB 。

• DE PHB ：默认 PHB 和尽力传递是相同的，它与 TOS 相兼容。
• EF PHB ：加速转发 PNB 提供如下的服务：低丢失率；低等待时间；可保证的带宽。这与源端和目的端之间使用的虚连接是相同的。
• AF PHB ：只要类通信量 class traffic 不超过节点的通信量规范，AF PHB 就能以较高可靠性传送分组。网络用户要意识到一些分组可能会丢失。

3. 通信量调节器

为了实现 Diffserv ，DS 节点使用了几种调节器，如测量器 meters 、标记器 markers 、整形器 shapers 和丢弃器 droppers 。如图24.27所示。

• 测量器： 测量器检查输入数据流和协商的通信量规范是否匹配，并将这个结果发送给其他组件。测量器也能利用「诸如令牌桶之类的工具」来检查配置文件。
• 标记器：标记器能重新标记正使用尽力传递的分组（DSCP: 000000），或依据接收自测量器的信息给分组作降标记 down-mark 。如果数据流与其对应的规范不匹配，就会对其作降标记（降低数据流的等级）。标记器不对分组作升标记（提升等级）。
• 整形器：当通信量与协商的规范不匹配时，整形器使用接收自测量器的信息，对该通信量进行重新整形。
• 丢弃器：丢弃器的运作过程就像没有缓冲区的整形器。 如果数据流严重违反协商的规范，那么丢弃器就要丢弃这些分组。

---

24.9 交换网络中的QoS

讨论了IP协议中提出的QoS模型之后，现在来讨论一下用于两个交换网络中的QoS：帧中继和ATM。 这两个网络都是虚电路网络，它们需要一个诸如 RSVP 的信令协议。

24.9.1 帧中继中的QoS

在帧中继中已经设计了控制通信量的四个不同的属性指标：访问速率、提交突发业务量 $B_c$ 、 提交信息速率 $CIR$ 和超突发长度 $B_e$ 。它们是在用户和网络进行协商期间设置的。对于 PVC 连接而言，它们需协商一次，而对于 SVC 连接而言，要为每个连接在（它的）连接建立期间进行协商。图24.28说明了这四个属性指标间的关系。

1. 访问速率

每个连接都要定义访问速率 access rate（以每秒位为单位）。访问速率实际上是由「连接用户与网络的通道的带宽」来决定的，用户永远不能超过这个速率。例如，如果用T-1线路将用户连接到帧中继网络，则访问速率是 $1.544\text{Mbps}$ ，并且用户永远无法超过这个速率。

2. 提交突发业务量

对于每个连接而言，帧中继定义了提交突发业务量 committed burst size $B_c$ 。该值是在一段预定义的时间内，在没有丢弃任何帧或设置 DE 位的条件下，网络所传输的最大比特数。

例如，在 $4$ 秒的时间段内 $B_c$ 的值为 $400\text{kbit}$ 是可以的，因为用户能在 $4$ 秒的间隔内传送 $400$ 千位的数据，而不用担心会出现任何帧丢失的情况。注意这个量并不是针对每 $1$ 秒而定义的速率，而是一个累积的度量。用户可以在第一个 $1$ 秒发送 $300\text{kbit}$ ，在第二个和第三个 $1$ 秒期间不发送任何数据，而最后在第四个 $1$ 秒期间发送 $100\text{kbit}$ 。

3. 提交信息速率

提交信息速率 committed information rate, CIR 除了定义了以每秒比特为单位的平均速率之外，它和提交突发业务量在概念上类似。如果用户持续地以该速率发送数据，那么网络就能一直发送帧。但是，因为它是一个平均度量，因此用户有时可以发送高于 $CIR$ 的数据、而在其他时间里发送低于 $CIR$ 的数据。只要预定义期间的平均速率符合要求，就会发送这些帧。

在预定义期间，发送的累积比特数不能够超过 $B_c$ 。注意，CIR不是一个独立的度量，可使用如下的公式对它进行计算：
$$CIR=\frac{B_c}{T}(\text{bps})$$

例如，如果在 $5$ 秒内，$B_c$ 是 $5\text{kbit}$ ，那么 $CIR$ 就是 $5000/5=1\text{kbps}$ 。

4. 超突发长度

对于每个连接而言，帧中继都定义了超突发长度 excess burst size $B_e$ 。该值是在一段预定义的时间内，用户发送的超过 $B_c$ 的最大位数。如果网络中没有拥塞，网络就保证传输这些比特。注意，这种约定实现的可能性比在 $B_c$ 情况下要低，因为网络本身实现这种约定是有条件的。

5. 用户速率

图24.29说明了用户如何才能发送突发性数据。如果用户发送的数据没超过 $B_c$ ，那么网络就能保证传送帧、而不会出现丢弃帧的情况。如果用户发送的数据超过了 $B_c$ 而小于 $B$（也就是全部比特数小于 $B_c+B_e$）， 那么在网络中没有拥塞的条件下，它就能保证传送所有的帧。如果出现拥塞情况，将会丢失一些帧。

从用户接收帧的第一台交换机有一个计数器，它可为超过 $B_c$ 的帧设置 DE 位。如果网络出现拥塞情况，那么其余的交换机将会丢弃这些帧。注意，需要较快发送数据的用户可能超过 $B_c$ 。只要该指标不超过 $B_c+B_e$ ，那么这些帧就有可能到达目的端而不丢失。然而，要记住的是，当在某一时刻用户发送的数据超过了 $B_c+B_e$ ，那么第一台交换机就会丢弃此后用户所发送的所有帧。

24.9.2 ATM 中的QoS

ATM中的QoS是基于类、与用户相关的属性和与网络相关的属性 based on the class, user-related attributes, and network-related attributes 。

1. 类

ATM论坛定义四种服务类型：恒定比特率 CBR 、可变比特率 VBR 、可用比特率 ABR 和未指定比特率 UBR 。见图24.30所示。

• 恒定比特率 constant-bit-rate, CBR ， CBR类用于需要实时音频或视频服务的客户。这个服务与诸如T线之类的专线提供的服务类似。
• 可变比特率variable-bit-rate, VBR 类分为两个子类：实时 VBR-RT 和非实时 VBR-NRT 。VBR-RT用于需要实时服务（如声音和视频传输）和使用压缩技术来生成可变比特率的用户 。VBR-NRT用于不需要实时服务，但是使用压缩技术生成可变比特率的那些用户。
• 可用比特率 available-bit-rate, ABR 类以最小的速率发送信元。如果有更多的网络资源可用的话，那么就能突破这个最小比特率。ABR特别适用于突发性的应用。
• 未指定比特率 unspecified-bit-rate, UBR 类是一种尽力传递、但没有任何保证的服务。
  

图24.31说明了不同类的服务与网络总容量的关系。

2. 用户相关属性

ATM定义了两组属性。用户相关属性是定义用户要以多快的速率发送数据的属性，是在用户和网络之间约定时协商而定的。下面是一些用户相关属性：

• 持续信元速率 sustained cell rate, SCR 是一段较长时间间隔的平均信元速率。实际信元速率可能低于或高于这个值，但是平均值应该等于或小于 SCR 。
• 峰值信元速率 peak cell rate, PCR 定义了发送方的最大信元速率。只要能维持 SCR ，用户的信元速率有时就能达到该峰值。
• 最小信元速率 minimum cell rate, MCR 定义了发送方能接受的最小信元速率。例如，如果 MCR 是 $50000$ ，那么网络必须保证发送方至少每秒发送 $50000$ 个信元。
• 信元可变延迟极值 cell variation delay tolerance, CVDT 是表示信元传输时间变化量的一个量。例如，如果CVDT是 $5\text{ns}$ ，则表示在传递信元的过程中，最大延迟和最小延迟之差不能超过 $5\text{ns}$ 。

3. 网络相关属性

网络相关属性定义了网络的特性。下面是一些网络相关属性：

• 信元丢失率 cell ross ratio, CLR 定义的是在传输期间信元丢失（或传递得太迟、以致于它们被视为丢失）的比率。例如，如果发送方发送了 $100$ 个信元，丢失了 $1$ 个信元，则 CLR 是 $\frac{1}{100}$ 。
• 信元传送延迟 cell transfer delay, CTD 是一个信元从源端传输到目的端所需要的平均时间。最大 CTD 和最小 CTD 也属于网络相关属性。
• 信元延迟变化量 cell delay variation, CDV 是 CTD 的最大值和最小值之差。
• 信元差错率 cell eπor ratio, CER 定义错误传递信元的比率。

最后

以上就是无私战斗机为你收集整理的【计算机网络】第五部分 传输层(24) 拥塞控制和服务质量24.1 数据通信量24.2 拥塞24.3 拥塞控制24.4 两个示例24.5 服务质量24.6 改进QoS的技术24.7 综合业务24.8 差分业务24.9 交换网络中的QoS的全部内容，希望文章能够帮你解决【计算机网络】第五部分 传输层(24) 拥塞控制和服务质量24.1 数据通信量24.2 拥塞24.3 拥塞控制24.4 两个示例24.5 服务质量24.6 改进QoS的技术24.7 综合业务24.8 差分业务24.9 交换网络中的QoS所遇到的程序开发问题。

如果觉得靠谱客网站的内容还不错，欢迎将靠谱客网站推荐给程序员好友。