Page 428 - 《软件学报》2024年第4期

2006 软件学报 2024 年第 35 卷第 4 期

Delay 表示接收方收到报文到接收方发出该 ACK Frame 所等待的时间; ACK Range Count 表示该 ACK Frame 中
包含的 ACK Range 数目; ACK Range 指示已接收的报文序号范围或者未接收的报文序号范围. 其中, (i) 表示这个
字段是整型, (..) 表示这个字段是可变长度的整型 (variable-length integer).
3.2.3 RTP/RTCP 的确认机制
RTP/RTCP 是实时传输协议 (real-time transport protocol, RTP) 和实时传输控制协议 (real-time control protocol,
RTCP) 的总称, 广泛使用于视频通话等实时流媒体应用中 [34] . RTP 工作在 UDP 之上, 其确认机制工作在应用层.
RTP 为端到端的实时传输提供时间信息和流同步, 但并不保证服务质量. 服务质量由 RTCP 来提供, 因此, RTCP
协议实现了确认机制的功能. 下面, 我们将通过确认机制三要素对 RTCP 进行简要介绍.
(1) RTCP 报文的触发条件
RTCP 报文本身等价于一种特殊的 ACK 报文. RTCP 报文发送频率与会话参与者的数量成比例变小, 是一种
带宽适应性的体现. RTCP 本质上属于 Bounded ACK 机制, 因此可以根据公式 (5) 计算发送频率 f bounded . RFC
3550 给出了 RTCP 报文的发送频率计算中的参数设定方法. 具体地, L 的取值与数据发送者的数目和会话成员总
数目相关; 根据是否发送过 RTCP 报文, α 的取值分别为 α =5 s 或者 α =2.5 s.
根据 RFC 3550 定义, 实际的 RTCP 报文发送频率 f rtcp 需要在 f bounded 的基础上进行一些随机化处理, 以解决多

个会话参与者之间的意外同步问题. 例如, 规定 f rtcp = λ· f bounded , 其中 λ 为服从均匀分布的系数.
(2) RTCP 报文的类型
RTCP 报文作为控制报文, 不仅可以由数据发送方发出, 还可以由数据接收方发出. 根据功能的不同,
RFC3550 将 RTCP 报文的类型主要分为 SR (源报告报文)、RR (接收方报告报文)、SEDS (源描述报文)、BYE
(离开申明报文) 和 APP (特殊应用报文) 这 5 类. 其中, SR (sender report) 用来使发送方以多播方式向所有接收方
报告发送情况; RR (receiver report) 用于接收方向发送方报告接收情况; SEDS (source description) 用于报告和站点
相关的信息, 包括 CNAME; BYE (goodbye) 用于表示会话参与者离开系统的报告; APP (application) 用于开发新应
用和新特征的实验.
(3) RTCP 报文携带的信息
不同类型的 RTCP 报文, 根据其功能的不同, 携带的信息也有差异. 每个 RTCP 报文携带的信息并非音视频数
据本身, 而是收发双方的统计信息. 统计信息主要包括实时数据的数据报文数目、传输过程中丢失的数据报文数
目、数据报文的抖动和往返时延等.
RTCP 规范没有指定上层应用如何使用 RTCP 报文中反馈的统计信息, 因此, 如何根据这些统计信息进行相
应措施, 完全由上层应用自行决定. 例如, 发送端可根据 RTCP 报文中的信息来修改视频输出码率、丢包是否重传
或者进行拥塞控制, 接收端可以根据 RTCP 报文中的信息进行故障诊断, 网络管理员也可以根据 RTCP 报文中的
信息来评估实时音视频传输的总体性能.
3.2.4 不同协议的确认机制对比
(1) QUIC 与 TCP 的确认机制对比
与经典 TCP 类似, QUIC 协议默认采用 Delayed ACK 机制, 但是赋予了 ACK 更多的灵活性. 具体表现在以下
3 个方面.
第一, ACK 携带的内容更多. 一方面, QUIC 协议的 ACK Frame 相比 TCP ACK 报文, 可以携带更多的 Range
(超过 4 个), 从而比 TCP 具有更好的反馈鲁棒性. 另一方面, QUIC ACK 携带 ACK Delay 字段, 在 ACK 延迟发送
的场景下, 能够使每个报文对应的 RTT 采样值更加准确, 这也是 QUIC 能够支持自定义的 ACK 频率的基本前提.
第二, 支持自定义 ACK 的发送频率. 一方面, QUIC 支持收发双方进行传输参数 (transport parameter) 协商, 其
中传输参数 max_ack_delay 用于指示发送 ACK 之前最长等待的时间 (即 α ). 通过在建连开始时协商 max_
ack_delay, QUIC 支持每个连接采用不同的 ACK 发送频率. 另一方面, Iyengar 等人 [35] 建议扩展 QUIC 协议, 新增
加 ACK-FREQUENCY Frame, 使得发送方能够按需地通知接收方更新 ACK 频率, 具体而言, ACK-FREQUENCY
Frame 支持发送方动态地修改公式 (4) 中的 L 和 α . 显然, 这种扩展仍然属于 Delayed ACK 的范畴.