第8章 互联网上的音频和视频服务
章节概述
本章解决"尽最大努力交付"的IP网络与音视频实时性需求之间的矛盾。核心挑战：时延、时延抖动（jitter）、分组丢失。解决方案：接收端缓存（消除抖动）、RTP/RTCP协议（实时传输控制）、QoS机制（IntServ/RSVP与DiffServ）。
多媒体数据特点
数据量大（各类标准码率）： - 标准语音：64 kbit/s（PCM，8kHz采样，8位编码） - 高质量立体声CD：1.4 Mbit/s（44.1kHz，16位） - 彩色电视：约250 Mbit/s
两大关键特性： 1. 时延敏感（Delay Sensitive）：端到端时延 + 时延抖动都有限制 2. 丢失容忍（Loss Tolerant）：少量分组丢失对主观感受影响小，可接受
关键问题：互联网分组传输是非等时的（每包到达时间不同），而播放需要等时。
解决方法：接收端设置播放缓存（Playout Buffer）： - 缓存若干分组后，再以恒定速率读出播放 - 消除时延抖动，但增加了端到端总时延 - 缓存过小→分组丢失率高；缓存过大→时延大
8.2 流式存储音频/视频
三种音视频服务类型
| 类型 | 特点 | 例子 |
|---|---|---|
| 流式存储（点播） | 预先录制，边下载边播放，有较大缓存 | YouTube, Netflix |
| 流式实况（直播） | 实时捕获，边录边发，小延迟 | 视频直播平台 |
| 交互式实时 | 严格延迟要求（<250ms），双向实时 | VoIP, 视频会议 |
元文件方案（万维网服务器）
元文件：极小的文件，描述媒体文件的位置、格式等信息（不包含媒体本身）。
TCP vs UDP传输选择
存储流媒体（YouTube/Netflix）：用TCP传送 - TCP接收缓存平滑播放，保证完整性 - 现代高带宽使TCP缓存问题不明显
实况流媒体：优先用UDP - TCP拥塞控制会导致播放暂停，主观效果差 - 丢几个UDP分组比突然暂停体验好
RTSP（实时流式协议）
- 应用层的媒体播放控制协议，不传输数据本身
- 又称"互联网录像机遥控协议"
- 以客户/服务器方式工作，有状态（记录播放状态）
- 支持：暂停/继续（PAUSE/PLAY）、快进/后退（SEEK）
RTSP控制报文：
RTSP控制分组可在TCP或UDP上传送，不规定压缩方案和分组封装格式。
8.3 交互式音频/视频（IP电话）
IP电话概述
- 狭义VoIP：在IP网络上打电话
- 广义IP电话：IP网上实时多媒体通信（话音+视像+IM）
- IP电话网关：公用电话网与IP网络的接口，负责信令转换和话音编码转换
影响通话质量的两个主要因素： 1. 端到端时延和时延抖动（要求 < 250ms） 2. 话音分组丢失率
端到端时延的来源（8个因素）： 模数转换时延 → 打包时延 → 发送时延 → 网络存储转发时延 → 接收端缓存时延 → 解码时延 → 传播时延 → 硬件接入时延
话音编解码标准： | 标准 | 速率 | 算法 | |-----|-----|-----| | G.711 | 64 kbit/s | PCM（最基础）| | G.729 | 8 kbit/s | CS-ACELP | | G.723.1 | 5.3/6.3 kbit/s | LPC |
RTP（实时传输协议）
RTP为实时应用提供端到端运输，运行在UDP之上。
RTP提供（但不保证）： - 序列号：检测分组丢失和乱序（16位，线性递增） - 时间戳：指示媒体数据的采样时刻，用于同步播放（32位） - 荷载类型PT（7位）：标识编码格式（如PCM=0，MP3=14） - SSRC（32位）：同步源标识符，唯一标识RTP流
RTP层次位置：
端口分配： - RTP使用偶数UDP端口（随机选1025-65535） - RTCP使用下一个奇数端口 - 默认端口：RTP=5004，RTCP=5005
RTCP（RTP控制协议）
与RTP配套使用，不传媒体数据，只传控制信息： 1. 服务质量监视：统计丢包率、时延抖动 2. 媒体间同步：音视频同步（用SSRC关联） 3. 成员标识：标识参与者
带宽分配：RTCP占会话总带宽的5%
五种RTCP分组类型：SR（发送方报告）、RR（接收方报告）、SDES（源描述）、BYE（离开）、APP（应用自定义）
H.323 vs SIP
H.323（ITU-T标准）
- 1996年制定，用于局域网上话音/视频会议
- 协议族（不是单一协议），包含：H.225、H.245、H.261等
- 四种构件：终端 + 网关 + 网闸（Gatekeeper）+ MCU
- 网关：连接H.323网络与非H.323网络（如PSTN）
- 网闸：地址转换、授权、带宽管理、计费
- MCU：支持3个以上终端的多点会议
- 优势：与PSTN互通容易；缺点：过于复杂，扩展性差
SIP（会话发起协议，IETF标准）
- 简单、实用，目前已成为互联网建议标准
- 把IP电话视为互联网上的新应用
- 基于文本，借鉴HTTP设计（方法、状态码、首部字段）
- SIP地址格式：
sip:zhangsan@public1.ptt.js.cn（可以是电话号码、IP、邮件）
SIP会话三阶段：建立会话 → 通信 → 终止会话
两种构件： - 用户代理：客户端（发起呼叫）+ 服务器端（接受呼叫） - 网络服务器：代理服务器（转发请求）/ 重定向服务器（告知下一跳）
SIP登记器（Registrar）：跟踪用户位置，每个SIP用户有关联的登记器，UE上线时登记当前IP。
SDP（会话描述协议）：SIP的配套协议，描述媒体类型、编码、端口、多播地址。
8.4 改进"尽最大努力"的服务质量
QoS基础
服务质量 QoS 指标：可用性、差错率、响应时间、吞吐量、分组丢失率、时延、时延抖动
需要的四种机制（顺序引入）： 1. 分类标记：区分实时数据和普通数据（打标签） 2. 优先级排队：实时数据优先入队 3. 管制（Policing）：控制数据流不超过声明速率 4. 呼叫接纳（Call Admission）：新会话预先声明QoS需求，网络评估后决定是否允许
调度机制
FIFO（先进先出）：默认，无法区分数据类型
优先级排队：按优先级分多个队列，高优先级先服务 - 缺点：低优先级队列可能饥饿（长期得不到服务）
公平排队 FQ（Fair Queuing）：轮流服务各队列 - 缺点：长分组得到的时间多（不真正公平），无优先级区分
加权公平排队 WFQ（Weighted Fair Queuing）： - 给队列 \(i\) 权重 \(w_i\) - 队列 \(i\) 获得的平均服务时间 = \(w_i / \sum w_j\) - 保证最低带宽：\(R_i = w_i \cdot C / \sum w_j\)（\(C\)为链路容量）
管制机制
漏桶（Leaky Bucket）管制器： - 以恒定速率 r 允许分组进入网络（令牌速率） - 突发流量被平滑为平稳流量 - 控制平均速率
令牌桶 vs 漏桶： - 漏桶：严格恒定速率输出 - 令牌桶（Token Bucket）：允许一定突发（桶深 b），但平均速率不超过 r
漏桶 + WFQ 结合： - 漏桶参数 \(b_i\) 和 \(r_i\) + WFQ权重 \(w_i\) - 可计算队列中每个分组的最大时延上界
综合服务 IntServ + RSVP
IntServ（Integrated Services）：对每个会话流进行资源预留：
两类服务： - 有保证的服务：分组排队时延有严格上限 - 受控负载的服务：比尽最大努力更可靠，但无严格保证
四个组件：路由选择协议 + RSVP + 接纳控制 + 分类器/调度器
RSVP（资源预留协议）： - 接收方发起预留（多播友好） - 在路径上每个路由器预留资源 - 使用软状态（Soft State）：路由器中预留信息有限时间，需定期刷新
IntServ缺点： - 路由器需为每个流维护状态，可扩展性差 - 所有路由器必须支持RSVP，部署复杂 - 服务等级太少，不灵活
区分服务 DiffServ
比IntServ更实用的QoS方案，当前主流：
核心思想： - 不对每个流单独处理，而是将流聚合为少量服务类别 - 在IP首部的DS字段（IPv4=服务类型字段前6位=DSCP）标记服务类别 - 核心路由器只按DSCP值转发（简单），复杂逻辑在边界路由器
DS域划分： - 边界节点（boundary node）：分类、标记、整形、测定 - 内部节点（interior node）：只按DSCP做简单转发
每跳行为 PHB（Per-Hop Behavior）： - 只涉及本路由器这一跳的行为，不是端到端 - 两种主要PHB： - 加速转发（EF）：低时延、低丢失率，用于实时应用 - 确保转发（AF）：多个优先级类别，有保证但非严格
DiffServ优点：灵活，可扩展，不需要RSVP信令，新旧服务类别可自由增删
参见
- [[05-运输层]] — RTP在UDP之上
- [[04-网络层]] — IntServ/DiffServ在IP层
- [[06-应用层]] — 流媒体是应用层服务
- [[09-无线网络]] — 无线环境的QoS挑战
- [[CSMA_CD|CSMA/CD]] — 有线以太网对比