RTP-Audio-and-Video-for-the-Internet

第二章 分组网络上的语音和视频通信

本章目录

• TCP/IP 参考模型和 OSI 参考模型
• IP 网络性能特征
• 测量 IP 网络性能
• 传输协议的影响
• 分组网络中传输音频/视频的要求

在深入研究 RTP 细节之前，应该了解诸如 Internet 之类的 IP 网络的特性，以及这些特性是如何影响语音/视频通信的。本章回顾了 Internet 体系结构的基础知识，概述了 Internet 的典型运行模式。最后，讨论音频和视频的传输要求，以及网络如何满足这些要求。

!!!IP 网络具有一些影响音频/视频应用和传输协议设计的独特特性。!!!如果你想了解 RTP 设计中所涉及的权衡问题，以及它们如何影响使用 RTP 应用，所以理解这些特征至关重要。

TCP/IP 和 OSI 参考模型

!!!当你考虑计算机网络时，理解协议分层的概念和含义是很重要的。如图 2.1 所示的 OSI 参考模型，为分层系统的讨论和比较提供了基础模型。

OSI 参考模型分为七层，每一层都建立在较低层提供的服务之上，并为上一层提供更抽象的服务。各层的功能如下：

• 物理层 最底层(物理层)包括物理网络连接设备和协议，如电缆、插头、开关和电气标准。

• 数据链路层 数据链路层建立在物理连接的基础上；例如，它将双绞线转换成以太网。这一层为数据传输单元提供帧，定义如何在多个连接的设备之间共享链接，并为每个链接上的设备提供寻址。

• 网络层 网络层连接链接，将它们统一为一个网络。它通过网络提供消息的寻址和路由。它还可以控制交换机中的拥塞、某些消息的优先级、计费等等。网络层设备处理从一个链接接收到的消息，并将其发送到另一个链接，使用与这些链接远端节点交换的路由信息。

• 传输层 传输层是第一个端到端的层。它负责使用网络层提供的服务将消息从一个系统传递到另一个系统。此职责包括在会话层需要时提供网络层没有提供的可靠性和流控制。

• 会话层 会话层以对应用有意义的方式管理传输连接。示例包括用于检索 Web 页面的超文本传输协议 (HTTP)、电子邮件交换期间的简单邮件传输协议 (SMTP) 协商以及管理文件传输协议 (FTP) 中的控制和数据通道。

• 表示层 表示层描述了较低层所传递的数据的格式。示例包括用于描述 Web 页面表示的 HTML（超文本标记语言）、描述电子邮件格式的 MIME（多用途 Internet 邮件扩展）标准，以及更常见的问题，如 FTP 中的文本传输和二进制传输之间的差异。

• 应用层 应用本身—例如 web 浏览器和电子邮件客户机—构成系统的顶层，即应用层。

OSI 参考模型中每一层，跨主机逻辑对等通信。当一端系统上的应用希望与另一端系统上的应用进行通信时，通信将向下通过源主机的各个层，最后通过物理连接的传递，然后向上到达目的地的协议堆栈。

!!! 例如，Web 浏览器使用双绞线在以太网数据链路上，通过 TCP 传输连接，通过 IP 网络，使用 HTTP 表示会话，渲染 HTML 。每个步骤都可以被看作是模型的特定层的实例化，一直到协议栈。其结果是将 Web 页面从应用 (Web 服务器）转移到应用 (Web 浏览器）。

源和目的地之间可能没有直接的物理连接，在这种情况下，连接必须在中间网关系统上提升协议栈。它需要提升到什么程度？这取决于所连接。以下是一些例子：

• 日益流行的 IEEE 802.11b 无线网络使用基站将一个物理层（通常是有线以太网）连接到另一个物理层（无线链路）。

• IP 路由器提供了网关的一个示例，其中多个数据链路在网络级连接。在移动电话上查看 Web 页面通常需要连接一直上升到网关中的表示层，该层将 HTML 转换为无线标记语言 (WML)，并将连接传递到不同的低层。

• 如上所述，我们可以使用 OSI 参考模型来描述互联网。这种契合并不完美：互联网的架构是随着时间的推移而演变的，在一定程度上早于 OSI 的模式，通常来讲，实际分层表现出的严格性比所描述的要低得多。然而，考虑互联网协议套件与 OSI 模型之间的关系，特别是 IP 作为一个通用网络层所扮演的角色，是很有意义的。

OSI 参考模型的最低两层可以直接与 Internet 相关，Internet 可以通过各种链接工作，如拨号调制解调器、DSL、以太网、光纤、无线和卫星。每个链接都可以用 OSI 模型的数据链路/物理层分割来描述。

在网络层，特定的协议将一组完全不同的私有网络转换为全球 Internet。这就是互联网协议，IP 向上层提供的服务很简单：尽最大努力将数据报包传递到指定的目的地。由于这项服务非常简单，IP 可以运行在广泛的链路层上，使得互联网能够快速传播。

简单不是没有代价的：IP协议不能保证任何种类的传输时效性，甚至数据根本不会被正确的传递：数据包可能会丢失、重新排序、延迟或被低层损坏。IP 不会试图纠正这些问题；相反，它将数据报原封不动地传递到上层。不过同时它也提供下列服务：

• 分片，防止数据报大于底层链路层的最大传输单元。
• 一个“TTL”字段，防止循环的包永远循环
• 一种服务类型标签，可用于为某些类型的包提供优先级
• 上层协议标识符，用于将数据包定向到正确的传输层
• 端点的寻址——包括多播来寻址一组接收端——并将数据报路由到正确的目的地

这些服务如何映射到包的 IP 报头的格式呢？如图 2.2 所示。

图 2.2 中当前 Internet 上的标准的 IPv4 标头。目前正在向 IPv6 过渡，IPv6 提供了基本相同的功能，但地址空间大大增加 (128bit 地址，而不是 32bit 地址）。如果这种转变发生ーー这是一个长期的前景，因为它涉及到对连接到互联网的每一台主机和路由器的更改ーー它将使更多的机器能够连接，从而促进网络的增长，但它不会以其他方式对服务进行重大改变。

Internet 协议提供了单一网络的抽象，但这并不改变系统的基本性质。尽管互联网看起来是一个单一的网络，但实际上互联网由许多独立的网络组成，通过网关（现在通常称为路由器）连接，并由 IP 的命名服务和地址空间统一起来。图 2.3 显示了单个网络是如何组成更大的互联网的。不同的因特网服务提供商选择如何运行它们自己的全球网络部分：有些拥有高容量的网络，拥有很少的拥塞和高可靠性；有些则没有

在错综复杂的互联网络中，包含 IP 数据报的数据包被独立路由到各自的目的地。路由器不需要立即发送数据包；如果在发送链路上正在传输另一个包，它们可以将其短暂地排队。它们还可能在拥塞时丢弃数据包。如果底层网络发生变化（例如，由于链接失败），IP 包所采取的路由可能会发生变化，这可能导致上层协议可以观察到传输质量的变化。

在 Internet 体系结构中，传输控制协议 (TCP) 和用户数据报协议 (UDP) 是常见的位于 IP 之上的两种传输协议。TCP 对原始 IP 服务进行调整，以便在每个主机上的服务端口之间提供可靠的、有序的传输，并根据网络的特性改变传输速率。UDP 提供与原始 IP 服务类似的服务，只是增加了服务端口。本章后面将更详细地讨论 TCP 和 UDP。

在这些传输协议之上，是 Internet 中常见的会话协议，例如用于 Web 访问的 HTTP 和用于发送电子邮件的 SMTP。堆栈由各种表示层 (HTML、MIME) 和应用本身完成。

从这个讨论中应该清楚的是，IP 在系统中扮演着关键的角色：它提供了一个抽象层，对应用隐藏了底层网络链接和拓扑的细节，并将底层与应用的需求隔离开来。这种体系结构称为沙漏模型，如图 2.4 所示。

决定跨 Internet 通信系统性能的主要因素是 IP 层。较高层协议可以在一定程度上适应和补偿 IP 层的行为，但若 IP 层性能较差会导致整个系统性能较差。接下来的两个部分将详细讨论 IP 层的性能，指出它的独特特性以及它带来的潜在问题和好处。

IP 网络的性能特征

从 Internet 体系结构的沙漏模型可以明显看出，应用通过抽象隐藏了低层的细节。这意味着应用无法直接确定一个 IP 包所经过的网络类型，从 14.4 kbps的蜂窝无线电连接到kmps的光纤，也不知道该网络的拥塞程度。获取网络性能指标的唯一方法是观察和测量。

那么我们需要测量什么，如何测量呢？幸运的是，IP 层的设计意味着参数的数量是有限的，而且这个数量通常可以根据应用的需要进一步加以限制。我们可以问的最重要的问题是：

• 数据包在网络中丢失的概率是多少？
• 数据包在网络中被破坏的概率是多少？
• 数据包通过网络需要多长时间？传输时间是常数还是变量？
• 可容纳多大的包？
• 我们发送信息包的最大速率是多少？

下一节将介绍关于前四个参数的一些测量样例。最大速率与数据包在网络中丢失的概率密切相关，如第 10 章拥塞控制中讨论的那样。

什么影响这样的测量？最明显的因素是测量站的位置。在局域网上两个系统之间进行的测量将清楚地显示与跨大西洋连接不同的属性！但地理因素并不是唯一的因素；遍历链接的数量（通常称为跃点的数量）、经过运营商的数量以及进行度量的时间都是因素。Internet 是一个大型的、复杂的、动态的系统，因此必须小心确保任何测量都能代表要使用应用的网络部分。

我们还必须考虑所使用的网络类型、其他流量以及其他流量的大小。到目前为止，绝大多数网络路径是固定的、有线的（铜或光纤）连接，绝大多数流量是基于 TCP 的。这些流量模式的影响如下：

• 由于基础设施主要是有线和固定的，所以链路非常可靠，而损耗主要是由路由器的拥塞造成的。
• TCP 传输假定包丢失是一个信号，表明瓶颈带宽已经达到，拥塞正在发生，应该降低它的发送速率。TCP 流将增加它的发送速率，直到观察到丢失，然后返回，这是一种确定特定连接可以支持最大速率的方法。当然，其结果是瓶颈链接临时超载，这可能会影响其他流量。

如果网络基础设施或流量的组成发生变化，其他丢包来源可能变得重要。例如，无线用户数量的大量增加可能会增加丢包比例，这是由于包损坏和对无线链路的干扰而造成的。在另一个例子中，如果使用 TCP 以外的传输的多媒体流量的比例增加了，而这些传输对丢失的反应与 TCP 不同，那么丢失模式可能会因为拥塞控制动态的变化而改变。

当我们开发在 IP 上运行的新应用时，我们必须意识到我们给网络带来的变化，以确保我们不会给其他用户带来问题。第 10 章，拥塞控制，更详细地讨论了这个问题。

测量 IP 网络性能

本节概述有关 IP 网络性能的一些可用数据，包括平均包丢失的公布结果、丢失模式、包损坏和重复、传输时间和多播影响的结果。

有几项研究测量了公共互联网上各种条件下的网络行为。例如，Paxson 报告了 9 个国家 35 个站点之间的 20,000 例转移行为；Handley 和 Bolot 对多播会话行为的研究，Yajnik、Moon、Kurose 和 Towsley 报告了包丢失统计中的时间依赖性。其他数据来源包括 CAIDA（互联网数据分析合作协会）、NLANR（应用网络研究国家实验室）和 ACM（计算机械协会）维护的流量档案。

平均丢包

各种包丢失度量能够被研究。例如，平均丢包率提供了对网络拥塞的一般度量，而丢包模式和相关性提供了对网络动态的观察。

报告的平均丢包率测量显示了一系列情况。例如，由帕克森在 1994 年和 1995 年做的 TCP/IP 流量的测量显示，根据路线和日期，30%到 70%的流量显示没有包丢失，但那些显示有丢包的流量，平均丢包范围从 3%到 17%（这些结果总结在表 2.1)。来自 Bolot 的使用 64kb 的 pcm 编码音频的数据，显示了类似的模式，丢包率在 4%到 16%之间，这取决于一天的时间，尽管这些数据也可以追溯到 1995 年。Yajnik 等人在 1997-1998 年使用模拟音频流量的最新结果显示，丢包率较低，为 1.38%至 11.03%。Handley 的结果——1996 年 5 月和 9 月的两组大约 350 万包数据和多播视频的接收报告统计数据——显示，根据接收位置和时间的不同，每五秒的平均丢包在 0%到 100%之间变化。1996 年 5 月 29 日，一个特定接收端在 10 小时内的样本，如图 2.5 所示，显示了在 5 秒间隔内采样的平均丢失率在 0%到 20%之间变化。

观测到的平均丢包率不一定是恒定的，也不一定是平稳变化的。该样本显示了一个丢包率，尽管在某些点上发生了突然的变化，但总体而言，变化相对平稳。来自 Yajnik 等人的另一个示例如图 2.6 所示。这个案例显示了丢包率的一个更显著的变化：在一个小时的过程中，丢包率从 2.5%缓慢下降到 1%，10 分钟后，丢包率上升到 25%，然后恢复正常——这个过程几分钟后重复。

这些丢包率与目前的网络相比如何？在写这篇文章的时候，传统的观点是，可以对网络主干进行设计，这样就不会发生包丢失，所以人们可以期待最近的数据来说明这一点。在某种程度上这是真的；然而，即使有可能使网络的一部分免于丢包，这种可能性并不意味着整个网络将以同样的方式运行。今天，许多网络路径都出现了丢失，即使丢失的只是一小部分数据包。

《互联网天气报告》(Internet Weather Report) 是对互联网上一系列路由的丢包率进行的月度调查。该报告显示，截至 2001 年 5 月，根据 ISP 的不同，美国境内的平均丢包率从 0%到 16%不等。在美国，每月的平均丢包率约为 2%，但就整个互联网而言，平均丢包率略高，约为 3%。

我们能从中学到什么？即使网络的某些部分得到了很好的设计，其他部分也会有很大的丢包。请记住，如表 2.1 所示，美国境内 70%的网络路径在 1995 年没有丢包，而其他网络的平均丢包率几乎为 5%，这个速率足以导致音频/视频质量的显著下降。

丢包模式

除了研究平均丢包率的变化外，考虑短期的丢包模式也很有意义。如果我们的目标是恢复丢包，那么我们需要了解一个媒体流中丢包是随机分布，还是突发的。

如果丢包在时间上是均匀分布的，那么我们应该期望特定包丢失的概率与前一个包丢失的概率相同。这意味着丢包通常是孤立事件，这是一个理想的结果，因为单个丢包比连续丢包更容易恢复。然而，不幸的是，如果前面的包丢失了，那么丢失特定包的概率通常会增加。也就是说，丢包往往是连续发生的。Vern Paxson 的测量表明，在某些情况下，如果之前的包丢失，特定包的丢失概率会增加 5 到 10 倍，这显然意味着包丢失不是均匀分布的。

其他一些研究——例如，Bolot 在 1995 年、Handley 和 Yajnik 等人在 1996 年和我在 1999 年收集的测量数据——证实了包丢失概率不是独立的。这些研究表明，在所有情况下，绝大多数丢包都是单个数据包，约占丢包的 90%。如图 2.7 所示，较长的突发丢包概率降低；很明显，如果丢包是独立的，较长时间的突发丢包会发生得更频繁。

观察到的丢包模式在某些情况下也显示出明显的周期性。例如，Handley 报告说，在 1996 年的测量中，大约每 30 秒就会发生一次突发丢包（见图 2.8)，2001 年 4 月也报告了类似的问题。这样的报告并不是普遍的，许多迹象表明没有这样的影响。据推测，周期性是由于某些系统路由更新引起的过载导致的，但这一结论并不确定。

数据包重复

如果数据包在网络中会丢失，那么会出现重复吗？答案是肯定的！数据源发送一个包，而接收端可能获得该包的多个副本。出现重复包，最可能的原因是由于网络中的路由/交换设备出现故障，正常操作中不应出现重复。

重复包常见吗？Paxson 的测量结果展示了连续丢包的趋势和少量的包重复。在测量的 20,000 条流中，发现了 66 个重复的包，但他也指出：“我们已经观察到了一些现象，其中超过 10%的重复包，是由于桥接设备配置不当引起的。”我在 1999 年 8 月进行的跟踪中显示，大约 125 万个包有 131 个重复。

只要开发者知道这个问题的存在，并丢弃重复包，那么不应该触发其他问题。重复包过多会浪费带宽，同时这表示存在网络配置错误或设备故障。

包损坏

如果数据包可以丢失和重复，那么它也可能会损坏。IP 包包含一个校验码，校验码保护包报头的完整性，但不保护有效负载。虽然如此，链路层也提供了校验码，TCP 和 UDP 都支持整个数据包的校验码。理论上 协议会检测到大部分损坏的数据包，这些损坏的数据包在到达应用层之前会被丢弃。

数据包损坏频率的统计数据很少被报道。Stone 引用了 Paxson 的观察结果，即大约每 7500 个数据包中就有一个未能通过 TCP 或 UDP 校验，而这些没通过校验的包就是损坏的数据。他们还统计了包损坏的概率： 1 /1100 到 1/31900 不等。注意，这个结果是针对有线网络的；无线网络的包损坏特性很可能不一样，因为无线电干扰造成的损坏可能比电线噪音造成的损坏更严重。

当校验失败时，协议层成会认为这个包已经损坏并丢掉它。应用不会收到损坏的数据包 ，所以包损坏会导致丢包率小幅增加。

在某些情况下，应用可能需要接收损坏的包，或者获得包损坏的明确标识。UDP 为这些情况提供了一种禁用校验码的方法。第 8 章《错误隐藏》和第 10 章《拥塞控制》，更详细地讨论了这个主题。

网络传输时间

数据包通过网络需要多长时间？答案取决于所走的路线，虽然短路线比长路线花费的时间要少，但是我们需要注意对“短”的定义。

影响传输时间的因素包括链路的速度、数据包必经路由器数量，以及每跳路由器造成的排队延迟。在物理距离较短的路径中，数据包的跳数可能较长，而每一跳路由器中的排队延迟，通常是整体延迟的主要因素。在网络术语中，短路径通常是跳数最少的路径，即使它覆盖了较长的物理距离。但卫星链路是一个明显的例外，它的距离会带来显著的无线电传播延迟。表 2.2 提供了 2001 年 5 月平均往返时间的量度数据，以供比较。对电话业务的研究表明存在各种往返延迟的，人们不会注意到少于 300 毫秒的延迟。虽然，显然是一个取决于人和任务的主观度量，但关键是所测量的网络往返时间大多在这个阈值。（从伦敦到悉尼是一个例外，但这里的明显增长可能是由于传输路径上有一跳是卫星。)

对延迟的度量本身很无趣，因为它们很显然取决于源和目的地的位置。需要关注的是网络传输时间是如何随着数据包而变化的：对于应用来说，运行在固定传输延迟的网络上比在传输延迟不断变化的网络上更为轻松，尤其是传输延迟敏感的媒体数据。

传输时间变化 (jitter) 的粗略度量是包的到达率。例如，图 2.9 显示了以恒定速率发送的流的到达率；很明显，到达率变化很大，这表明网络上的传输时间不是恒定的。

更好的测量方法是通过测量每个包的到达时间和离开时间的差值来求出传输时间，而不是假设速率不变。不幸的是，测量绝对传输时间是困难的，因为它需要源和目的地的时钟精确同步，通常是这很难达到的条件。大多数网络传输时间的追踪都包含时钟偏移，而且除了延迟的变化之外，!!! 不可能研究其他任何东西（因为不可能确定有多少偏移是由未同步时钟造成的，有多少是由网络造成的）。

图 2.10 和图 2.11 给出了传输时间变化的一些测量样本（包含由于时钟不同步造成的偏移）。我是在 1999 年 8 月测量的；Ramjee 等人 (1994 年）和 Moon 等人也提出了类似的测量方法。请注意以下几点：

• 测量值的缓慢向下倾斜是由于源和目标之间的时钟倾斜造成的。一台机器的时钟比另一台的稍微快一点，导致感知到传输时间逐渐改变。
• 可以观察到平均传输时间的几个较大的改变，这可能是由于网络中的路由改变所致。
• 传输时间不是常数；相反，它在整个过程中会有显著的变化。

这些都是应用或更高层协议必须处理的问题，如果有需要的话，必须要纠正这种偏差。

在网络中对数据包重排序也是可能发生的。例如，当路由发生了更改并且新路由更短时。Paxon 观察到，总共有 2%的 TCP 数据包是无序传输的，但是在不同的追踪之间，无序传输数据包的比例有很大的差异，其中一条追踪显示 15%的数据包是无序传输的。

网络传输时间中的“峰值”是另一个可以被观察到的特征，如图 2.12 所示。目前还不清楚这些峰值是由于网络内的缓冲还是由于发送系统中的缓冲，但是如果试图平滑数据包的到达时间，那么这些”峰值“也是值得解决的问题。

最后，网络传输时间可以显示周期性，尽管这似乎是一种次要的影响。我们期望这种周期性与前面提到的丢包周期性有相似的原因，除非这些事件不那么严重，只导致路由器中的队列堆积，而不是队列溢出导致丢包。

合适的数据包大小

IP 层数据包度是不固定的, 如链路层的最大传输单元 (MTU) 不加限制，最多可达 65,535 字节。MTU 是链路可以容纳的最大数据包的大小。通常是 1500 字节，这是以太网可以传输的最大数据包。很多应用默认一个包的最大 1500字节，但是一些链路的 MTU 是低于 1500字节的。例如，拨号调制解调器链接的 MTU 普遍为 576 字节。

在大多数情况下，瓶颈在发送端或接收端附近。几乎所有的骨干网 MTU 都是 1500 字节或更多的 。

IPv4 支持数据分段，当一个数据包大小超过一个链路的 MTU 时，就会被分割成更小的片段。然而，这个通常不是好办法，因为任何一个片段的丢失都将使接收端不能重组原始的数据包。由此产生的丢包乘数效应是我们希望避免的。

几乎所有情况下，音频包大小都落在网络一个 MTU 内。对于更大的视频帧，应用需要分包传输，让每个包都适配所在网络的 MTU。

多播的影响

IP 多播允许发送端同时向多个接收端传输数据。它有一个有用的特性，即网络根据需要创建包的副本，这样只需要一个包的副本对应的一个链接。IP 多播提供了非常高效的组通信，前提是网络支持它，这使得向一组接收端发送数据的成本与该组的大小无关。

支持多播是 IP 网络的一个可选的、相对较新的特性。在撰写本文时，它比较广泛地部署在研究和教育环境以及网络主干中，但在许多商业环境和服务提供商中并不常见。

发送到一个组意味着更大的可能出错：接收质量不再受到通过网络的单一路径的影响，而是受到从源到每个单独接收端的路径的影响。在测量组播会话的损耗和延迟特性时，定义因素是均匀性。图 2.13 演示了这个概念，显示了我测量的多播会话中每个接收端的平均丢包率。

多播不会改变网络中丢失或延迟的根本原因。相反，它使每个接收端都能经历这些影响，而源只传输每个包的一个副本。网络的异构性使得源很难满足所有的接收端：有些发送太快，有些发送太慢是很常见的。我们将在后面的章节中进一步讨论这些问题。现在，只需注意多点传送为系统增加了更多的异构性就足够了。

网络技术的影响

!!!到目前为止提出的测量方法是公共的、大范围的。应用大多将在这种环境中运行，但还有大量应用部署在私有内部网、无线网络或支持增强服务质量的网络。这些情况如何影响 IP 层的性能？

许多私有 IP 网络（通常称为内部网）具有与公共互联网非常相似的特性：流量组合通常非常相似，许多内部网覆盖范围很广，链接速度和拥塞程度各不相同。在这种情况下，测试结果很可能与公共互联网上的测试结果相似。然而，如果网络是专门为实时多媒体流量而设计的，就有可能避免许多已经讨论过的问题，并构建一个没有丢包和最小抖动的 IP 网络。

一些网络使用集成服务/RSVP 或差异化服务来支持增强的服务质量 (QoS)。使用增强的 QoS 可以减少应用对丢包和/或抖动恢复的需求，因为它为满足某些性能限制提供了强有力的保证。然而，请注意，在许多情况下，QoS 方案提供的保证本质上是统计意义的，通常它不能完全消除数据包丢失，或者传输时间的变化。

在无线网络中可以观察到显著的性能差异。例如，蜂窝网络可以在短时间内表现出显著的性能变化，包括非阻塞丢包、突发丢包和高误码率。另外，一些蜂窝系统具有高延迟，因为它们在数据链路层使用交织来隐藏突发的丢包或包损坏。

不同网络技术的主要影响是增加了网络的异构性。如果你正在设计一个应用来处理这些技术的一个有限子集，那么你可以利用底层网络的功能来提高应用所看到的连接的质量。在其他情况下，底层网络可能会给健壮应用的设计者带来额外的挑战。

明智的应用开发人员会选择健壮的设计，这样当应用从最初设想的网络转移到新网络时，它仍然可以正确地运行。设计可在 IP 上运行的音视频应用的挑战是使它们在面对网络问题和意外情况时仍旧可靠。

关于测量特性的结论

测量、预测和建模网络行为是有许多微妙之处的复杂的问题。这一讨论只涉及这些问题，但一些重要的结论是显而易见的。

第一点，网络可以而且经常表现得很糟糕。如果一个工程师设计了一个应用，他希望所有的包都能及时到达，那么当这个应用被部署到 Internet 上时，他一定会大吃一惊。虽然更高层的协议（如 tcp) 可以隐藏一些这种缺点，但总有一些方面对应用是可见的。

另一个需要认识的要点是网络中的异构性。网络中某一点的测量结果不能代表另一点的情况，甚至“不寻常”的事件也一直在发生。到 2000 年底，网络上大约有 1 亿个系统，因此，即使发生在不到 1%的主机上的事件也会影响成千上万台机器。作为应用设计人员，你需要了解这种异构性及其可能的影响。

尽管存在这种异构性，试图总结丢包和丢包模式的讨论揭示了几个“典型”特征：

• 虽然有些网络路径可能不会丢包，但这些路径在公共网络中并不常见。一个应用应该被设计来处理少量的数据包丢失——比如说，达到 5%。
• 孤立的丢包组成了大多数观察到的丢包事件。
• 丢包的概率不是均匀的：即使大多数丢包是孤立的包，连续丢包的突发概率也比随机事件更常见。丢包的突发通常是短暂的；一个应用，处理两到三个连续丢失的包将足以满足大多数突发丢包。
• 很少出现长时间的突发丢包。一秒甚至更长的故障时间并不是未知的。
• 包重复很少见，但也可能发生。
• 类似地，在极少数情况下，数据包可能被破坏。其中绝大多数是由 TCP 或 UDP 校验码（如果启用）检测到的，包在到达应用之前会被丢弃。

传输时间变化的特征可以总结如下：

• 网络上的传输时间不是均匀的，而且会观察到抖动。
• 绝大多数抖动是合理有界的，但分布的长尾效应比较明显。
• 虽然重新排序相对较少，但在传输过程中可能会重新排序数据包。应用不应该假定接收数据包的顺序与发送数据包的顺序一致。

这些并不是通用的规则，每一个规则都会有一个网络路径作为反例。然而，它们确实提供了一些我们在设计高层协议和应用时需要注意的一些概念。

传输协议的影响

到目前为止，我们对网络特性的考虑主要集中在 TCP/IP 上。当然，程序员几乎从不使用原始 IP 服务。相反，它们在较高层传输协议（通常是 UDP 或 TCP) 的基础上构建应用。这些协议提供了 IP 协议之外的其他特性。这些添加的特性如何影响应用所看到的网络行为？

UDP/IP

用户数据报协议 (UDP) 提供了一组最小的 IP 扩展。UDP 报头如图 2.14 所示。它包含 64 位附加头，代表源和目标端口标识符、长度和校验码。

源端口和目标端口标识了通信主机内的端点，允许将不同的服务复用到不同的端口上，一些服务使用知名端口上；另一些则使用在调用时动态协商的端口长度字段与IP头中的长度字段冗余。校验和用于检测有效载荷的损坏，是可选的（对于不需要校验和的应用程序，它被设置为零）。

除了增加端口和校验和外，UDP 还提供原始的 IP 服务。它没有增强传输的可靠性（尽管校验码可以检测到 IP 没有检测到的负载错误），也不影响包传输的时间。使用 UDP 的应用向传输层提供数据包，传输层将数据包发送到目标机器上的一个端口（如果使用多播，则发送到一组机器）。这些包可能在传输过程中丢失、延迟或乱序，这与原始 IP 服务的情况完全相同。

TCP/IP

Internet 上最常用的传输协议是 TCP。虽然 UDP 只向 IP 服务提供了一小部分附加功能，但 TCP 添加了大量附加功能：它抽象了不可靠的 IP 包传递服务，从而在源端口和单个目标主机之间提供可靠的、连续的字节流传输。

使用 TCP 的应用向传输层提供一个数据流，传输层将其分割成适当大小的数据包，并以适合网络的速率进行传输。数据包由接收端确认，在传输过程中丢失的数据包由源重新传输。当数据到达时，在接收端进行缓冲，以便按顺序传递。这个过程对应用是透明的，应用只看到一个数据流经网络的“管道”。

只要应用提供足够的数据，TCP 传输层就会增加它的发送速率，直到网络出现数据包丢失。丢包视为已超过瓶颈链路带宽的信号，该连接应降低其发送速率以匹配。相应地，TCP 降低了丢包发生时的发送速率。这个过程会继续下去，TCP 会不断探测整个网络的传输速率；结果是一个如图 2.15 所示的发送速率。

这种重新传输、缓冲和探测可用带宽的组合有以下几个效果：

• TCP 传输是可靠的，如果连接保持打开，所有数据最终都将被传递。如果连接失败，则通知连接端失败。这与 UDP 形成了对比，UDP 不向发送端提供关于数据传输状态的信息。
• 应用对包传输的时间几乎没有控制，因为在源发送数据的时间和接收数据的时间之间没有必然的关系。这种变化与原始 IP 服务显示的传输时间变化不同，因为 TCP 层还必须考虑重新传输和发送速率的变化。发送端可以知道是否所有数据都已发送，这可能使它能够估计平均传输速率。
• 带宽探测可能导致瓶颈链路的短期过载，从而导致数据包丢失。当这种重载导致 TCP 流的丢失，该流将降低其速率；但是这个过程中它也可能给其他流造成损失。

当然，TCP 的行为也有一些微妙之处，关于这个主题已经写了很多。还有一些特性是本讨论还没有涉及到的，比如推送模式和紧急交付，但是这些特性并不影响基本行为。对于我们的目的来说，重要的是注意 TCP 和 UDP 之间的根本区别：可靠性 (TCP) 和实时性 (UDP) 之间的权衡。

分组网络中音频/视频传输的要求

到目前为止，本章已经详细地探讨了 IP 网络的特性，并简要地研究了位于它们之上的传输协议的行为。我们现在可以将此讨论与实时音视频传输联系起来，考虑通过 IP 网络传输媒体流的需求，并确定网络在多大程度上能满足这些需求。

当我们将媒体描述为实时的时候，简单讲就是接收端在接收到媒体流时就播放它，而不是简单地将完整的媒体流存储在一个文件中以供以后回放。在理想的情况下，在接收端的播放是即时和同步的，尽管在实践中网络会造成一些不可避免的传输延迟。

实时媒体对传输协议的主要要求是网络传输时间的可预测变化。例如，考虑一个以 20 毫秒帧传输编码语音的 IP 电话系统：源将每 20 毫秒传输一个数据包，理想情况下，我们希望这些数据包以相同的间隔到达，这样它们包含的语音可以立即播放出来。传输时间的一些变化可以通过在接收端插入额外的延迟缓冲来调节，但是这只有在变化可以被描述并且接收端能够适应变化的情况下才有可能实现（这个过程在第 6 章《媒体采集、播放和时序》中有详细的描述）。

一个较低的要求是通过网络可靠地传递所有数据包。显然，可靠的传输是我们期待的，但许多音频和视频应用可以容忍一些丢包：在我们的 VOIP 示例中，单个数据包的丢失将导致 1 / 50 秒的语音丢失，如果采用适当的错误隐藏方法，则人们几乎无法察觉。由于媒体流的时变特性，一些丢包通常是可以接受的，因为它的影响会随着新数据的到来而迅速得到纠正。可接受的丢包数量取决于应用、使用的编码方法和丢包模式。第 8 章《错误隐藏》，和第 9 章《错误恢复》，讨论丢包容错。

上面这些基本需求会帮我们做出选择。很明显，TCP/IP 是不合适的，因为它更看重可靠性而不是实时性，而且我们的应用需要实时交付。在网络的传输延迟变化可以被量化且丢包率是可以接受的前提下，UDP/IP 应该是合适的。

标准实时传输协议 (RTP) 建立在 UDP/IP 上，提供实时的恢复和丢包检测，以支持健壮系统的开发。RTP 和相关标准将在本书的其余部分详细讨论。

尽管 TCP 对实时应用有限制，但一些音频/视频应用将其用于传输。这样的应用尝试估计 TCP 连接的平均吞吐量，并调整它们的发送速率以匹配。当没有严格的端到端延迟限制，并且应用有几秒钟的缓冲时间来处理由 TCP 重传和拥塞控制引起的传输时间变化时，可以使用这种方法。它对于需要端到端低延迟的交互式应用不可靠，因为 TCP 引起的传输时间变化太大。

使用 TCP/IP 传输的主要理由是许多防火墙传递 TCP 连接，但阻塞 UDP。随着基于 RTP 的系统变得更加流行，防火墙变得更加智能，这种情况正在迅速改变。我强烈建议新的应用基于 UDP/IP 的 RTP。RTP 可以通过允许应用调整以适应实时媒体的方式和通过促进互操作性（因为它是开放标准），来提供更高的质量。

基于分组的音频/视频的好处

在这个阶段，你可能想知道为什么有人会考虑 IP 网络上的基于分组的音频或视频应用。这样的网络显然对实时媒体流的可靠传输提出了挑战。尽管这些挑战是真实存在的，但 IP 网络具有一些独特的优势，可以在效率和灵活性方面获得显著的收益，这可能会超过其缺点。

使用 IP 作为实时音频和视频承载服务的主要优点是，它可以提供一个统一的、聚合的网络。这个网络可以用于语音、音乐和视频，也可以用于电子邮件、Web 访问、文件和文档传输、游戏等等。因此可以显著节省在基础设施、部署、支持和管理方面的成本。

统一的分组网络使流量的统计和复用成为可能。例如，语音活动检测可用于防止分组语音应用在静默期间进行传输，而使用 TCP/IP 作为其传输的流量将适应可用容量的变化。只要谨慎地设计音频和视频应用，减少负面影响。因此，我们可以实现更高的链路利用率，这在资源有限的系统中是很重要的。

另一个重要的好处是 IP 多播，它允许将数据低成本的传递给可能很大的一组接收端。传送的成本不受受众量的影响，IP 多播使人们能够负担得起 Internet 广播和电视以及其他组通信服务。

最后，也许是最引人注目的，基于 IP 的音视频的情况下，IP 支持新的服务。这种融合允许实时音视频和其他应用之间进行丰富的交互，使我们能够开发以前不可能开发的系统。

总结

IP 网络的特性与传统的电话、音视频分发网络有很大的不同。在设计基于 IP 的应用时，你需要了解这些独特的特性，以使你的系统在这些特性的影响下仍旧保持健壮性。

本书的其余部分将描述这种系统的体系结构，解释 RTP 及其模型，这个模型用于时间戳恢复和音视频同步、错误纠正和隐藏、拥塞控制、报头压缩、多路复用和隧道以及安全性。