计算机网络第八章：互联网上的音频视频服务总结

计算机网络第八章：互联网上的音频/视频服务 学习总结

本章深入探讨了在互联网上提供实时音频和视频服务所面临的挑战、关键技术和协议。随着多媒体应用的普及，理解这些技术对于构建高效、可靠的网络服务至关重要。

1. 多媒体数据特点

多媒体数据（尤其是实时音频和视频）与传统数据（如文件传输、网页浏览）相比，具有以下显著特点：

• 高带宽要求：视频数据量庞大，尤其是高清视频，需要持续的高带宽支持。
• 时延敏感性：实时通信（如视频会议、在线直播）对端到端时延非常敏感，过高的时延会导致用户体验下降。
• 抖动 (Jitter)：数据包在网络中传输时，到达接收端的时间间隔可能不均匀，这种时延的变化称为抖动。抖动会导致播放不流畅。
• 容忍丢失：与文件传输不同，实时多媒体数据可以容忍少量的数据包丢失。通过编码冗余或插值等技术，少量丢失通常不会对感知质量造成严重影响。

2. 流媒体技术

流媒体技术使得用户无需等待整个文件下载完成即可开始播放多媒体内容。

• 播放方式 ：边下载边播放 (Streaming) 是其核心特点。客户端在接收到一部分数据后，即可开始解码和播放，同时继续接收后续数据。
• 缓冲区 (Buffer) ：
  • 作用 ：缓冲区是流媒体播放的关键组件。它在接收端预先存储一部分即将播放的数据，主要用于消除网络抖动 和平滑数据传输速率的不稳定性。
  • 原理：当网络暂时拥塞导致数据到达延迟时，播放器可以从缓冲区中读取预存的数据进行播放，避免播放中断（即"饥饿"）。当网络状况良好时，缓冲区会重新填充。

3. 实时传输协议

为了满足多媒体数据的实时性要求，需要专门的传输协议。

• RTP (Real-time Transport Protocol) ：
  • 定位 ：RTP 运行在 UDP 之上，为实时应用提供端到端的传输服务。它不提供可靠传输、流量控制或拥塞控制，这些功能通常由应用层或更高层协议处理。
  • 首部字段 ：RTP 首部包含关键信息，用于支持实时播放：
    • 序号 (Sequence Number)：用于检测数据包丢失和乱序，接收端可以根据序号重新排序或进行丢包补偿。
    • 时间戳 (Timestamp)：记录数据包中第一个字节的采样时间，用于同步不同媒体流（如音频和视频）以及处理抖动。
    • 同步信源标识符 (SSRC)：唯一标识 RTP 流的源，用于区分来自不同发送者的媒体流。
• RTCP (RTP Control Protocol) ：
  • 定位 ：RTCP 是 RTP 的伴侣协议，与 RTP 协同工作，用于监控和控制 RTP 会话。
  • 功能 ：
    • 提供服务质量 (QoS) 反馈：接收端通过发送 RTCP 报告（如接收者报告 SR/RR）向发送端反馈接收质量信息，包括丢包率、抖动、往返时延等。发送端可以根据这些反馈调整发送策略。
    • 用于同步媒体流：通过 RTCP 报告中的时间戳和 NTP 时间信息，接收端可以精确同步来自不同 RTP 流（如音频和视频）的数据。
    • 参与者管理：提供会话参与者的信息，如 CNAME（规范名称）。

4. 信令与控制

在多媒体通信中，除了数据传输，还需要信令协议来建立、管理和终止会话。

• SIP (Session Initiation Protocol) ：
  • 作用 ：SIP 是一种应用层信令协议 ，用于建立、修改和终止多媒体会话，如 IP 电话、视频会议、即时消息等。
  • 特点 ：
    • 基于文本：SIP 消息采用文本编码，类似 HTTP，易于理解和调试。
    • 客户端-服务器架构：涉及用户代理 (User Agent)、代理服务器 (Proxy Server)、注册服务器 (Registrar Server) 等。
    • 可扩展性强：易于添加新功能和媒体类型。
• H.323 ：
  • 作用 ：H.323 是 ITU-T 制定的早期多媒体通信标准体系，功能强大且复杂。
  • 特点 ：
    • 二进制编码：消息采用二进制编码，解析复杂。
    • 体系庞大：包含多个子协议，如 H.225（呼叫信令）、H.245（控制信令）等。
    • 组件：包括终端 (Terminal)、网关 (Gateway)、网守 (Gatekeeper)、多点控制单元 (MCU) 等。
  • 现状：由于其复杂性和部署难度，在互联网多媒体通信领域逐渐被更轻量、更灵活的 SIP 所取代。

5. 服务质量 QoS (Quality of Service)

QoS 旨在为网络流量提供差异化的服务，以满足不同应用的需求。

• IntServ (Integrated Services，综合服务) ：
  • 原理 ：IntServ 是一种面向流 的 QoS 架构，通过为每个数据流预留资源 来提供端到端的硬 QoS 保证。
  • 协议 ：资源预留协议 (RSVP) 用于在网络路径上的路由器之间协商和预留资源。
  • 特点 ：提供严格的 QoS 保证，但需要网络中的所有路由器维护每个流的状态信息，导致状态复杂、扩展性差，不适合大规模互联网部署。
• DiffServ (Differentiated Services，区分服务) ：
  • 原理 ：DiffServ 是一种面向类 的 QoS 架构，将网络流量划分为不同的类别，并对不同类别的流量提供不同的每跳行为 (PHB, Per-Hop Behavior)。
  • 标记：IP 数据报头部的 DS 字段 (DSCP, Differentiated Services Code Point) 用于标记数据包所属的类别。
  • PHB ：路由器根据 DSCP 标记对数据包进行不同的转发处理，如：
    • 加速转发 (EF, Expedited Forwarding)：提供低时延、低抖动、低丢包的"虚拟专线"服务。
    • 保证转发 (AF, Assured Forwarding)：提供不同等级的转发保证，允许一定程度的丢包。
  • 特点 ：无需维护流状态，可扩展性好 ，实现相对简单，适合大规模互联网部署，但提供的是软 QoS 保证，而非严格的端到端保证。
• 流量整形 (Traffic Shaping) ：
  • 目的：控制数据发送速率，使其符合预设的流量规范，避免突发流量对网络造成冲击，从而改善网络性能和公平性。
  • 漏桶算法 (Leaky Bucket) ：
    • 原理：数据包以恒定速率从"漏桶"中流出。如果数据到达速率超过漏出速率，多余的数据包会被丢弃或排队。
    • 特点：强制输出速率恒定，能够平滑突发流量，但无法充分利用网络带宽的短暂空闲。
  • 令牌桶算法 (Token Bucket) ：
    • 原理：令牌以恒定速率产生并放入桶中，发送数据包需要消耗令牌。桶的容量限制了最大突发量。当桶中有足够的令牌时，数据可以以峰值速率发送；当令牌不足时，数据必须等待令牌产生。
    • 特点：允许一定程度的突发，可以更好地利用网络带宽的短暂空闲，同时限制了平均速率和最大突发量。

---

重点突破

典型例题

例题 1: 令牌桶算法计算

• Problem : 设令牌桶容量为 b b b (bits)，令牌产生速率为 r r r (bits/s)，当前网络接口峰值速率为 M M M (bits/s)。若桶已满，求允许以速率 M M M 发送数据的最大持续时间 S S S (seconds)。推导公式 b + r S = M S b + rS = MS b+rS=MS 并计算。

• Solution :

  在时间 S S S 内，令牌桶中初始有 b b b 个令牌（因为桶已满）。

  在这段时间 S S S 内，令牌桶会以速率 r r r 持续产生新的令牌，所以新产生的令牌数量为 r S rS rS。

  因此，在时间 S S S 内，总共可用的令牌数量为初始令牌数加上新产生的令牌数，即 b + r S b + rS b+rS。

  同时，以峰值速率 M M M 发送数据，在时间 S S S 内需要消耗 M S MS MS 个令牌。

  为了能够持续以速率 M M M 发送数据，消耗的令牌数不能超过可用的令牌数。在最大持续时间 S S S 时，所有可用令牌恰好被消耗完，因此有：
  b + r S = M S b + rS = MS b+rS=MS

  将 S S S 移到等式一边：
  b = M S − r S b = MS - rS b=MS−rS
  b = S ( M − r ) b = S(M - r) b=S(M−r)

  解出 S S S：
  S = b M − r S = \frac{b}{M - r} S=M−rb
  计算示例 : 假设 b = 10000 b = 10000 b=10000 bits， r = 1000 r = 1000 r=1000 bits/s， M = 5000 M = 5000 M=5000 bits/s。
  S = 10000 5000 − 1000 = 10000 4000 = 2.5 S = \frac{10000}{5000 - 1000} = \frac{10000}{4000} = 2.5 S=5000−100010000=400010000=2.5 秒。

• Analysis : 这个公式适用于 M > r M > r M>r 的情况。它表示在令牌桶满的情况下，以峰值速率 M M M 发送数据所能持续的最长时间。如果 M ≤ r M \le r M≤r，则令牌产生速率足以支持发送速率，理论上可以无限期地以速率 M M M 发送数据（只要桶中有足够的令牌，且不考虑其他限制）。

例题 2: 播放时延 (Playout Delay)

• Problem: 假设有三个数据包 P1, P2, P3。

  • P1: 发送时间 T 1 = 0 T_1 = 0 T1=0 ms，网络传播时延 D 1 = 100 D_1 = 100 D1=100 ms。
  • P2: 发送时间 T 2 = 20 T_2 = 20 T2=20 ms，网络传播时延 D 2 = 150 D_2 = 150 D2=150 ms。
  • P3: 发送时间 T 3 = 40 T_3 = 40 T3=40 ms，网络传播时延 D 3 = 80 D_3 = 80 D3=80 ms。
    为了保证不发生丢包（Starvation），接收端缓冲区至少需要设置多大的播放时延 (Playout Delay)？

• Solution :

  首先，计算每个数据包到达接收端的时间 A i = T i + D i A_i = T_i + D_i Ai=Ti+Di：

  • P1 到达时间 A 1 = 0 + 100 = 100 A_1 = 0 + 100 = 100 A1=0+100=100 ms。
  • P2 到达时间 A 2 = 20 + 150 = 170 A_2 = 20 + 150 = 170 A2=20+150=170 ms。
  • P3 到达时间 A 3 = 40 + 80 = 120 A_3 = 40 + 80 = 120 A3=40+80=120 ms。

  播放时延 P P P 是指从数据包发送时间到其在接收端被播放的时间间隔。对于每个数据包 i i i，其播放时间 P l a y i = T i + P Play_i = T_i + P Playi=Ti+P。

  为了保证不发生饥饿（即在需要播放某个数据包时，它已经到达），每个数据包的播放时间必须晚于或等于其到达时间，即 P l a y i ≥ A i Play_i \ge A_i Playi≥Ai。

  代入公式： T i + P ≥ A i T_i + P \ge A_i Ti+P≥Ai。

  这等价于 P ≥ A i − T i P \ge A_i - T_i P≥Ai−Ti。

  我们需要找到一个最小的 P P P，使得所有数据包都满足这个条件。这意味着 P P P 必须大于或等于所有数据包的 ( A i − T i ) (A_i - T_i) (Ai−Ti) 的最大值。

  计算每个数据包的 ( A i − T i ) (A_i - T_i) (Ai−Ti)：

  • P1: A 1 − T 1 = 100 − 0 = 100 A_1 - T_1 = 100 - 0 = 100 A1−T1=100−0=100 ms。
  • P2: A 2 − T 2 = 170 − 20 = 150 A_2 - T_2 = 170 - 20 = 150 A2−T2=170−20=150 ms。
  • P3: A 3 − T 3 = 120 − 40 = 80 A_3 - T_3 = 120 - 40 = 80 A3−T3=120−40=80 ms。

  这些值中的最大值为 150 150 150 ms。

  因此，为了保证不发生饥饿，接收端缓冲区至少需要设置 150 150 150 ms 的播放时延。

• Analysis: 播放时延的设置是流媒体应用中的一个权衡。过小的播放时延可能导致缓冲区欠载（饥饿），造成播放中断；过大的播放时延会增加端到端延迟，影响实时性。实际应用中，播放时延通常会根据网络抖动情况动态调整，以在实时性和流畅性之间取得最佳平衡。

易错点分析

• RTP 的层次：

  • 误区：RTP 承载在 UDP 上，所以它一定是传输层协议。
  • 正解 ：RTP 虽然直接利用 UDP 的服务，但它提供了应用层所需的序号、时间戳、同步信源标识符等功能，这些功能是为实时应用量身定制的。因此，RTP 通常被归类为应用层协议 。在某些语境下，它也被视为传输层子协议 或应用层与传输层之间的中间层协议。关键在于理解其提供的功能是面向应用的，而非通用的传输服务。

• SIP vs RTP：

  • 误区：SIP 和 RTP 都是用于传输媒体数据的协议。
  • 正解 ：
    • SIP (Session Initiation Protocol) 是一种信令协议 ，其职责是建立、修改和终止多媒体会话。它类似于打电话时的"拨号"和"挂断"过程，不负责传输实际的音频/视频数据。
    • RTP (Real-time Transport Protocol) 是一种媒体传输协议 ，其职责是在会话建立后，实际传输实时音频/视频数据。它类似于"通话中的声音和图像"。
    • 两者协同工作：SIP 负责会话的"管理"，RTP 负责会话的"内容传输"。

• QoS 机制：

  • 误区：IntServ 和 DiffServ 都是实现硬 QoS 的机制。
  • 正解 ：
    • IntServ (Integrated Services) 旨在提供硬 QoS 保证。它通过 RSVP 为每个数据流预留资源，能够提供严格的端到端保证，但其复杂性和扩展性使其不适合大规模互联网。
    • DiffServ (Differentiated Services) 旨在提供软 QoS 保证。它通过对数据包进行分类和标记，并根据类别提供不同的转发行为。DiffServ 具有良好的可扩展性，实现相对简单，适合大规模部署，但它不能提供像 IntServ 那样严格的端到端保证，而是一种"尽力而为"基础上的差异化服务。