# RTCP 反馈 · NACK / PLI / REMB
> 除了周期性报告，RTCP 还有一类主动的反馈报文：请求重传（NACK）、请求关键帧（PLI/FIR）、报告估计带宽（REMB）。这一章读 rtcp_packet/ 下的 Nack/Pli/TransportFeedback，讲清 RTPFB 与 PSFB 两大类反馈，它们是让接收端「指挥」发送端的通道。
- 作者：David（道雾轩）
- 专栏：音视频与 WebRTC 详解（https://daiw.org/manual/webrtc.md）
- 最后更新：2026-07-14
- 原文：https://daiw.org/manual/webrtc/rtcp-feedback
- 转载与引用：请注明出处并附原文链接（https://daiw.org/about/copyright）
# RTCP 反馈 · NACK / PLI / REMB
[SR/RR](https://daiw.org/manual/webrtc/rtcp-reports) 是周期性的统计报告，但 RTCP 还有一类更**主动**的报文——**反馈（feedback）**：接收端用它**实时指挥**发送端「重发那个丢了的包」「给我一个关键帧」「你最多发这么快」。这一章看这些反馈报文，它们是接收端影响发送端行为的通道。
## 两大类：RTPFB 与 PSFB
RTCP 反馈报文分两大类（RFC 4585），`modules/rtp_rtcp/source/rtcp_packet/` 下的类名直接体现了这个分类：
**反馈分两类：传输层反馈（RTPFB）和负载相关反馈（PSFB）。**
- **RTPFB（Transport-layer Feedback，`Rtpfb` 基类）** —— 和**传输**有关，不关心媒体内容。典型：**[NACK](https://daiw.org/manual/webrtc/nack-rtx)**（某些[序号](https://daiw.org/manual/webrtc/rtp-packet)的包丢了，请重传）、**[Transport-CC 反馈](https://daiw.org/manual/webrtc/transport-cc)**（报告每个包的到达时间）。
- **PSFB（Payload-Specific Feedback，`Psfb` 基类）** —— 和**媒体负载**有关，通常是[视频](https://daiw.org/manual/webrtc/source-map)特有。典型：**PLI / FIR**（请求一个[关键帧](https://daiw.org/manual/webrtc/source-map)）、**REMB**（报告接收端估计的最大码率）。
源码里看得清清楚楚（`modules/rtp_rtcp/source/rtcp_packet/`）：
```cpp
class Nack : public Rtpfb { ... }; // 传输层:请求重传
class TransportFeedback : public Rtpfb { ... }; // 传输层:到达时间反馈
class Pli : public Psfb { ... }; // 负载相关:请求关键帧
```
分类的意义：RTPFB 是[拥塞控制、可靠性](https://daiw.org/manual/webrtc/nack-rtx)的通道，PSFB 是[编解码器控制](https://daiw.org/manual/webrtc/source-map)的通道。
## 三个最重要的反馈
具体到 WebRTC 天天在用的：
| 反馈 | 类 | 接收端想说 | 发送端的反应 |
| --- | --- | --- | --- |
| **NACK** | `Nack`(RTPFB) | 「序号 X 的包我没收到」 | 从[历史](https://daiw.org/manual/webrtc/rtp-sender)[重传](https://daiw.org/manual/webrtc/nack-rtx)那个包 |
| **PLI** | `Pli`(PSFB) | 「我解不了了，给个[关键帧](https://daiw.org/manual/webrtc/source-map)」 | 让[编码器](https://daiw.org/manual/webrtc/source-map)立即产一个关键帧 |
| **Transport-CC** | `TransportFeedback`(RTPFB) | 「这些包我在这些时刻收到了」 | 喂给[拥塞控制估带宽](https://daiw.org/manual/webrtc/transport-cc) |
- **NACK**（下一章细讲）是**丢包重传**的触发器：接收端发现[序号](https://daiw.org/manual/webrtc/rtp-packet)缺了，发 NACK，发送端[重发](https://daiw.org/manual/webrtc/nack-rtx)。
- **PLI（Picture Loss Indication）** 是[视频](https://daiw.org/manual/webrtc/source-map)特有的救命稻草：视频靠帧间预测，一旦丢包导致[后续帧解不出](https://daiw.org/manual/webrtc/source-map)（参考帧没了），接收端发 PLI 请求一个**不依赖任何历史的关键帧**，从它开始重新解码。FIR（Full Intra Request）类似。
- **Transport-CC**（[第 5 部分](https://daiw.org/manual/webrtc/source-map)详解）是现代[拥塞控制](https://daiw.org/manual/webrtc/source-map)的反馈通道，报告[每个包](https://daiw.org/manual/webrtc/rtp-header-extensions)的精确到达时间。
## REMB 与 Transport-CC：两代带宽反馈
带宽反馈有过两代，读老代码会都见到：
- **REMB(Receiver Estimated Max Bitrate)** —— **老**方案。**接收端**自己估算「我这边看能收多快」，通过 REMB（一种 PSFB）把这个数字告诉发送端，发送端照着发。带宽估计在**接收端**做。
- **Transport-CC** —— **新**方案。接收端**只报原始数据**（每个包何时到达），把**带宽估计的活儿挪到发送端**做（[第 5 部分](https://daiw.org/manual/webrtc/transport-cc)）。发送端信息更全（它知道自己何时发的），估得更准。
**从 REMB 到 Transport-CC，是 WebRTC 拥塞控制的一次重要演进：把「估带宽」从接收端搬到了发送端。** 为什么？因为发送端**同时掌握发送时间和（经反馈得到的）到达时间**，能算出精确的**单向延迟变化**——这是[延迟based 带宽估计](https://daiw.org/manual/webrtc/source-map)的核心信号；而接收端只知道到达时间，信息不全。这个「让信息最全的一方做决策」的思路，是分布式系统设计的常见智慧。现代 WebRTC 默认 Transport-CC，REMB 仅作兼容退路。这也是为什么 [transport-cc 序号那个头扩展](https://daiw.org/manual/webrtc/rtp-header-extensions)如此关键——它是这套新反馈的载体。
## 小结与下一章
RTCP **反馈**让接收端**主动指挥**发送端，分两类：**RTPFB**（传输层，`Rtpfb` 基类：[NACK](https://daiw.org/manual/webrtc/nack-rtx) 请求重传、[Transport-CC](https://daiw.org/manual/webrtc/transport-cc) 报到达时间）和 **PSFB**（负载相关，`Psfb` 基类：PLI/FIR 请求[关键帧](https://daiw.org/manual/webrtc/source-map)、REMB 报码率）。三个最常用：**NACK**（重传）、**PLI**（要关键帧）、**Transport-CC**（带宽反馈）。带宽反馈从 **REMB**（接收端估）演进到 **Transport-CC**（发送端估，信息更全）。
NACK 是可靠性的核心——它触发的**重传**怎么做？为什么常走独立的 RTX 流？下一章专讲。👉 [NACK 与 RTX 重传](https://daiw.org/manual/webrtc/nack-rtx)。
## 参考资料
- [1] libwebrtc 源码.`modules/rtp_rtcp/source/rtcp_packet/nack.h`、`pli.h`、`transport_feedback.h`、`remb.h`（`Rtpfb` / `Psfb` 基类）。
- [2] IETF RFC 4585「RTP/AVPF 反馈」、RFC 5104「Codec Control Messages（PLI/FIR）」。
- [3] IETF「transport-wide-cc」草案、REMB 草案。