1. 从一次卡顿排查说起：为什么要啃 WebRTC 播放源码
去年帮一个做在线教育的朋友排查直播卡顿问题，场景很典型：老师端推流正常，学生端用浏览器看 WebRTC 流，网络稍微抖一下画面就花，声音断断续续，但换成 HTTP-FLV 播放就稳得多。当时第一反应是网络问题，抓包、看带宽、测延迟，折腾了两天没找到根因。最后硬着头皮把 SRS 的 WebRTC 播放链路源码翻了一遍，才发现问题出在播放端的 jitter buffer 策略和 NACK 重传的配合上——浏览器侧对丢包的容忍度、SRS 侧重传的时机、以及关键帧请求的触发条件，这三者没对齐，网络一抖就雪崩。
这件事让我意识到，WebRTC 播放这条链路，光会调 API 是不够的。SRS 作为国内用得最多的开源流媒体服务器之一，它的 WebRTC 播放实现里藏着大量工程细节：信令怎么协商、SDP 怎么裁剪、RTP 包怎么打包、RTCP 反馈怎么处理、jitter buffer 怎么设计、丢包重传怎么触发。这些东西在官方文档里往往一笔带过，但真出问题时，恰恰是这些细节决定成败。
这篇内容适合三类人看：一是正在用 SRS 做 WebRTC 直播、但遇到播放问题不知道怎么下手的后端或音视频工程师；二是想深入理解 WebRTC 播放全链路、不满足于只会调RTCPeerConnection的前端同学；三是准备做自研流媒体服务器、想参考成熟实现的技术负责人。我会从整体架构讲到关键源码模块，把每个设计决策背后的“为什么”讲清楚，再配上实操中踩过的坑和排查技巧。源码基于 SRS 5.x 分支，WebRTC 播放相关代码主要集中在trunk/src/app/srs_app_rtc_*和trunk/src/protocol/srs_protocol_rtmp_stack这几个文件里。
2. 整体架构拆解：SRS 的 WebRTC 播放链路是怎么跑通的
2.1 播放链路的五个核心阶段
SRS 的 WebRTC 播放，本质上是把服务器上已有的流（可能是 RTMP 推上来的，也可能是 SRT 或 WHIP 推的），转成 WebRTC 能消费的 RTP/RTCP 流，通过 DTLS/SRTP 加密后发给浏览器。整条链路可以拆成五个阶段：
信令协商阶段：浏览器通过 HTTP 接口（通常是/rtc/v1/play/）发一个 SDP Offer 给 SRS，SRS 返回 Answer。这个阶段决定了后续用什么编解码、什么传输方式、哪些扩展头。
媒体协商与轨道绑定阶段：SRS 解析 Offer 里的 m-line，找到要播放的流，把流的音视频轨道和 SDP 里的 track 对应起来。这一步如果对不上，就会出现“连上了但没画面”。
RTP 打包与发送阶段：SRS 从源流（比如 RTMP 的 FLV tag）里取出音视频帧，按 RTP 规范打包成一个个包，加上序列号、时间戳、SSRC，再通过 SRTP 加密发送。
RTCP 反馈处理阶段：浏览器会周期性发 RTCP RR（接收报告）、NACK（丢包重传请求）、PLI（关键帧请求）、REMB（带宽估计）等。SRS 要正确解析这些反馈，并做出响应——重传丢失的包、生成关键帧、调整发送码率。
jitter buffer 与播放阶段：浏览器侧收到 RTP 包后，先放进 jitter buffer 做乱序重排和去抖，再解码播放。SRS 侧虽然不直接管浏览器的 jitter buffer，但发送节奏、包间隔、时间戳连续性会直接影响它的表现。
这五个阶段里，信令和媒体协商是“能不能播”的问题，RTP 打包和 RTCP 处理是“播得好不好”的问题，jitter buffer 是“稳不稳”的问题。大部分线上问题都出在后两个阶段。
2.2 为什么 SRS 选择“RTMP 转 RTC”而不是纯 RTC 链路
SRS 的 WebRTC 播放有个特点：它不要求推流端也是 WebRTC。你可以用 OBS 推 RTMP，用 ffmpeg 推 SRT，甚至用 WHIP 推 WebRTC，播放端统一用 WebRTC 拉。这个设计背后是一个很现实的考量——推流端的生态太分散了，OBS、ffmpeg、各种硬件编码器，它们对 RTMP/SRT 的支持远比 WebRTC 成熟。如果强制推流也用 WebRTC，会劝退大量用户。
所以 SRS 在内部做了一层“媒体桥接”：把 RTMP 的 FLV tag 解析成音视频帧，再按 WebRTC 的规范重新打包。这个桥接层是 SRS WebRTC 播放的核心，也是问题最多的地方。比如 RTMP 的时间戳是毫秒级的 32 位整数，WebRTC 的 RTP 时间戳是采样率级的（音频 48kHz、视频 90kHz），两者转换时如果处理不当，就会出现音视频不同步。再比如 RTMP 的 FLV tag 里，一个视频帧可能包含多个 NALU，打包成 RTP 时要按 MTU 分片，分片策略直接影响丢包时的重传效率。
2.3 关键源码模块地图
在深入细节之前，先把关键源码模块列出来，方便你对照阅读：
| 模块 | 文件路径 | 核心职责 |
|---|---|---|
| 信令处理 | srs_app_rtc_server.cpp | 处理 HTTP 信令请求，生成 SDP Answer |
| SDP 协商 | srs_app_rtc_conn.cpp | 解析 Offer，裁剪 SDP，绑定轨道 |
| RTP 打包 | srs_app_rtc_send.cpp | 音视频帧转 RTP 包，处理分片 |
| RTCP 处理 | srs_app_rtc_conn.cpp | 解析 RR/NACK/PLI/REMB，触发重传和关键帧 |
| 媒体桥接 | srs_app_rtc_source.cpp | 从 RTMP/SRT 源取帧，转成 RTC 帧 |
| DTLS/SRTP | srs_app_rtc_dtls.cpp | 加密传输，密钥协商 |
这几个文件构成了 WebRTC 播放的主干。下面我会挑最关键的几个环节，把源码逻辑和设计意图讲透。
3. 信令与 SDP 协商：播放能不能成功的第一道关
3.1 Offer/Answer 的交互流程与源码入口
浏览器发起播放时，会先创建一个RTCPeerConnection，然后调用createOffer()生成一个 SDP Offer，通过 POST 请求发给 SRS 的/rtc/v1/play/接口。SRS 侧的处理入口在srs_app_rtc_server.cpp的on_rtc_play()方法里。
这个方法做的事情可以概括为四步：解析请求体里的 SDP 和 streamurl，校验流是否存在，调用SrsRtcConnection::negotiate_play_capability()做能力协商，最后生成 Answer 返回。看起来简单，但每一步都有坑。
第一步解析 SDP 时，SRS 用的是自己实现的 SDP 解析器（srs_protocol_sdp.cpp），不是第三方库。这么做的好处是可控性强，能针对 WebRTC 的场景做裁剪；坏处是兼容性要自己保证。我遇到过浏览器升级后 SDP 格式微调，SRS 解析失败的情况，最后是升级 SRS 版本解决的。所以如果你用的是老版本 SRS，遇到“信令返回 200 但连不上”的问题，先检查 SDP 解析日志。
第二步校验流是否存在，这里有个容易忽略的点：SRS 支持多种流源，RTMP 推的流、SRT 推的流、WHIP 推的流，在内部都映射成SrsRtcSource。如果流还没推上来，播放请求会返回错误。但有时候流推上来了，播放还是失败，原因是流的编解码格式不被 WebRTC 支持——比如 RTMP 推的是 H.265，WebRTC 默认只支持 H.264/VP8/VP9/AV1，这时候 SRS 会拒绝播放。这个错误信息在日志里往往不明显，需要你主动去看srs_app_rtc_source.cpp里的编解码检查逻辑。
3.2 SDP 裁剪：为什么 Answer 比 Offer 短那么多
如果你对比过浏览器发的 Offer 和 SRS 返回的 Answer，会发现 Answer 明显短很多。这是因为 SRS 对 SDP 做了大量裁剪，只保留播放必需的部分。
裁剪的逻辑在SrsRtcConnection::negotiate_play_capability()里。核心原则是：只保留服务器实际支持的编解码和扩展，去掉所有浏览器提出但服务器用不上的能力。比如浏览器可能同时支持 H.264、VP8、VP9、AV1，但 SRS 当前配置只开了 H.264，那 Answer 里就只保留 H.264 的 payload type。
这里有个关键细节：payload type 的映射。Offer 里浏览器给 H.264 分配的 payload type 可能是 102，但 SRS 内部有自己的 payload type 表（96-127 动态分配）。协商时要把浏览器的 payload type 映射到 SRS 内部的 payload type，发送 RTP 包时用 SRS 的，接收时再映射回去。这个映射如果出错，表现就是“SDP 协商成功，但收到包解不出来”。
另一个细节是a=ssrc和a=msid的处理。SRS 在 Answer 里会为每个轨道分配一个 SSRC，这个 SSRC 是 SRS 自己生成的，不是浏览器 Offer 里的。浏览器收到 Answer 后，会用这个 SSRC 来识别 RTP 流。如果 SRS 生成的 SSRC 和实际发送的 RTP 包里的 SSRC 不一致，浏览器就会丢弃这些包。我在调试时遇到过这个问题，原因是 SRS 在某个版本里 SSRC 生成逻辑有 bug，升级后修复。
3.3 实操：用 curl 手动走一遍信令流程
想理解信令协商，最好的办法是手动发一次请求。你可以用 curl 模拟浏览器的播放请求：
curl -X POST http://your-srs-server:1985/rtc/v1/play/ \ -H "Content-Type: application/json" \ -d '{ "api": "http://your-srs-server:1985/rtc/v1/play/", "streamurl": "webrtc://your-srs-server/live/test", "sdp": "v=0\r\no=- 123456 2 IN IP4 127.0.0.1\r\n..." }'SDP 部分需要你从浏览器的createOffer()结果里复制。返回的 JSON 里sdp字段就是 Answer。你可以对比 Offer 和 Answer，看看 SRS 裁剪掉了哪些内容。
提示：手动构造 SDP 很容易出错，建议先用浏览器生成一个完整的 Offer，保存下来再改。另外 SRS 的日志级别调到
trace能看到 SDP 解析的详细过程，排查协商问题时非常有用。
4. RTP 打包与发送：从 FLV tag 到 SRTP 包的关键转换
4.1 音视频帧的获取与时间戳转换
SRS 从源流取帧的逻辑在srs_app_rtc_source.cpp。如果源是 RTMP，帧是从 FLV tag 里解析出来的；如果源是 SRT，帧是从 MPEG-TS 里解析的。不管哪种源，最终都会转成统一的SrsRtcFrame结构，包含帧类型、时间戳、数据指针。
时间戳转换是这里最容易出问题的地方。RTMP 的时间戳单位是毫秒，WebRTC 视频 RTP 时间戳单位是 90kHz，音频是采样率（通常是 48kHz）。转换公式是：
rtp_timestamp = rtmp_timestamp * (90000 / 1000) // 视频 rtp_timestamp = rtmp_timestamp * (48000 / 1000) // 音频看起来简单，但实际处理时要考虑两个问题：一是时间戳回绕，32 位时间戳溢出后要从 0 重新开始；二是音视频同步，视频和音频的时间戳基准要一致，否则会出现唇音不同步。SRS 在SrsRtcSource::on_frame()里维护了一个基准时间戳，所有帧的时间戳都相对于这个基准计算。
我踩过的一个坑是：RTMP 推流端如果时间戳不连续（比如 OBS 在某些情况下会跳变），SRS 转换后的 RTP 时间戳也会跳变，浏览器侧 jitter buffer 会认为发生了大的延迟变化，导致播放卡顿。解决办法是在 SRS 侧做时间戳平滑，或者换用时间戳更稳定的推流端。
4.2 H.264 的 RTP 打包：STAP-A 与 FU-A 的选择
H.264 帧打包成 RTP 时，有两种主要模式：STAP-A（Single-Time Aggregation Packet）和FU-A（Fragmentation Unit）。STAP-A 是把多个小的 NALU 聚合到一个 RTP 包里，FU-A 是把一个大的 NALU 分片到多个 RTP 包里。
SRS 的选择逻辑在srs_app_rtc_send.cpp的packet_video()方法里。判断依据是 NALU 的大小和 MTU：如果整个帧（包括所有 NALU）小于 MTU（通常 1200 字节左右），就用 STAP-A 打包成一个 RTP 包；如果大于 MTU，就用 FU-A 分片。
这个选择直接影响丢包重传的效率。STAP-A 模式下，一个 RTP 包丢了，整个帧就废了，必须等下一个关键帧；FU-A 模式下，丢了一个分片，只需要重传那个分片，其他分片还能用。所以对于大帧（比如 I 帧），FU-A 是必须的。
但 FU-A 也有坑：分片太多时，NACK 重传的请求会很多，如果 SRS 的重传策略不够激进，浏览器侧会一直等不齐分片，导致解码失败。SRS 在on_nack()里处理重传请求，它会从发送缓存里找到对应的 RTP 包重新发送。发送缓存的大小和保留时间是可配置的，默认保留最近 1000 个包。如果网络延迟大，重传请求到达时包已经被清出缓存，就重传失败了。
注意：SRS 的
rtc.nack_cache_size参数控制发送缓存大小，默认 1000。在高丢包、高延迟的网络下，建议调大到 2000-3000，代价是内存占用增加。
4.3 SRTP 加密：DTLS 握手与密钥导出
RTP 包打包好后，要通过 SRTP 加密才能发送。SRTP 的密钥来自 DTLS 握手，SRS 的 DTLS 实现在srs_app_rtc_dtls.cpp。
DTLS 握手的过程和 TLS 类似，但跑在 UDP 上。浏览器和 SRS 交换证书、协商密钥，最终导出 SRTP 所需的密钥材料。这里的关键是use_srtp扩展的协商——双方要就 SRTP 的保护 profile 达成一致，通常是SRTP_AES128_CM_HMAC_SHA1_80。
DTLS 握手失败是 WebRTC 播放的常见问题之一。表现是信令成功、ICE 连接建立，但媒体流不通。排查时先看 SRS 日志里有没有 DTLS 握手错误，常见原因包括：证书过期、时钟不同步、UDP 端口被防火墙拦截。SRS 默认用的自签名证书，如果浏览器对证书校验严格，可能需要配置受信任的证书。
4.4 发送节奏控制：pacing 与拥塞控制
RTP 包不是一股脑发出去的，SRS 有一个 pacing 机制控制发送节奏。这个机制在srs_app_rtc_send.cpp的send_packet()里，核心是根据目标码率和当前网络状况，把包均匀地分布在时间轴上发送。
为什么需要 pacing？因为如果一次性把一帧的所有 RTP 包发出去，会在网络中形成突发流量，容易导致路由器队列溢出丢包。pacing 把突发流量摊平，降低丢包率。SRS 的 pacing 实现相对简单，主要是基于定时器的均匀发送，没有做复杂的拥塞控制算法。
拥塞控制方面，SRS 主要依赖浏览器的 REMB 反馈来调整发送码率。浏览器根据接收情况估算可用带宽，通过 RTCP REMB 包告诉 SRS，SRS 据此调整视频编码码率或发送速率。这个闭环如果延迟太大，就会出现“网络已经拥塞了，SRS 还在高速发”的情况，加剧拥塞。所以 REMB 的处理要及时，SRS 在on_rtcp_remb()里会尽快响应。
5. RTCP 反馈处理：丢包重传与关键帧请求的实战逻辑
5.1 NACK 重传：从收到请求到重发包的完整路径
NACK 是 WebRTC 对抗丢包的核心机制。浏览器发现 RTP 序列号不连续时，会发 NACK 包告诉 SRS 哪些包丢了，SRS 从缓存里找到这些包重传。
SRS 处理 NACK 的入口在srs_app_rtc_conn.cpp的on_rtcp_nack()。流程是：解析 NACK 包里的 PID（Packet ID）和 BLP（Bitmask of Following Packets），得到丢失的序列号列表，然后逐个从发送缓存里查找并重传。
这里有几个关键设计点：
缓存管理：SRS 用了一个环形缓冲区存最近发送的 RTP 包，每个包记录序列号、时间戳、数据和发送时间。查找时按序列号索引。缓存大小默认 1000，意味着只能重传最近 1000 个包。如果网络延迟超过缓存覆盖的时间窗口，重传就会失败。
重传限流：如果短时间内收到大量 NACK，SRS 不会无限制重传，而是有限流保护。这是为了防止重传风暴把网络打垮。限流的阈值在代码里是硬编码的，实际使用中如果发现重传不够及时，可能需要调整。
重传优先级：重传的包和正常发送的包共享发送队列，SRS 没有给重传包更高优先级。在网络拥塞时，重传包可能被延迟发送，导致浏览器侧等不及。这是一个可以优化的点，自研时可以考虑给重传包加优先级。
我遇到过一个典型问题：学生端网络抖动，大量 NACK 涌向 SRS，SRS 重传不过来，浏览器侧 jitter buffer 里的包迟迟不齐，播放卡住。后来把nack_cache_size调大，同时优化了推流端的码率，让单帧不要太大，问题缓解了很多。
5.2 PLI 与 FIR：关键帧请求的触发与响应
当浏览器侧丢包太严重，NACK 重传也救不回来时，它会发 PLI（Picture Loss Indication）或 FIR（Full Intra Request），要求 SRS 生成一个新的关键帧。
SRS 收到 PLI 后，不能直接生成关键帧——它只是一个转发服务器，编码是在推流端做的。所以 SRS 的做法是：把 PLI 请求转发给推流端（如果推流端支持），或者从源流里找最近的关键帧缓存，直接发给播放端。
这里有个现实问题：如果推流端是 OBS，OBS 收到 PLI 后会生成关键帧，但生成需要时间（通常几十到几百毫秒），这期间播放端还是黑的。如果推流端不支持 PLI（比如某些硬件编码器），SRS 只能等下一个自然关键帧，间隔可能是几秒。这就是为什么 WebRTC 直播在弱网下容易出现长时间黑屏。
SRS 在on_rtcp_pli()里处理 PLI，它会检查源流是否支持关键帧请求，支持就转发，不支持就返回错误。实际部署时，建议推流端开启关键帧请求支持，并且把关键帧间隔设短一点（比如 1-2 秒），这样即使 PLI 不生效，也能较快恢复。
5.3 REMB 与带宽估计：码率自适应怎么落地
REMB（Receiver Estimated Maximum Bitrate）是浏览器告诉 SRS “我这边最多能收多少码率”的反馈。SRS 收到后，会调整发送策略——如果当前发送码率超过 REMB，就降码率；如果远低于 REMB，可以尝试升码率。
SRS 的 REMB 处理在on_rtcp_remb()里，逻辑相对简单：解析出目标码率，和当前发送码率比较，然后调整。但 SRS 本身不做视频编码，它只能通过丢帧或转发请求给推流端来降码率。丢帧会导致画面不流畅，转发请求给推流端又依赖推流端支持。所以实际效果取决于推流端的配合程度。
一个实用的技巧是：在 SRS 配置里设置一个码率上限，防止推流端推太高码率导致播放端扛不住。同时监控 REMB 反馈，如果发现 REMB 持续低于发送码率，说明网络确实不行，需要考虑降推流码率或换网络。
5.4 常见 RTCP 问题速查表
| 问题现象 | 可能原因 | 排查方法 | 解决思路 |
|---|---|---|---|
| 播放卡顿，日志有大量 NACK | 网络丢包严重 | 抓包看丢包率，看 SRS 重传日志 | 调大 nack_cache_size，降低推流码率 |
| 黑屏，收到 PLI 但不恢复 | 推流端不支持关键帧请求 | 看 SRS 日志是否转发 PLI 成功 | 换支持 PLI 的推流端，或缩短关键帧间隔 |
| 码率降不下来 | REMB 处理延迟大 | 看 REMB 包到达时间和处理时间 | 优化网络，或手动限制推流码率 |
| 音视频不同步 | 时间戳转换错误 | 对比 RTP 时间戳和 RTMP 时间戳 | 检查时间戳基准和转换公式 |
| 连上但无画面 | SSRC 不匹配 | 对比 SDP 里的 SSRC 和 RTP 包里的 SSRC | 升级 SRS 版本，或手动指定 SSRC |
6. 实操排查与性能调优：从日志到参数的全链路技巧
6.1 日志分析：怎么从 SRS 日志里定位播放问题
SRS 的日志是排查问题的第一手资料。WebRTC 播放相关的日志主要在srs_app_rtc_conn.cpp和srs_app_rtc_send.cpp里，关键日志包括：
- 信令协商日志：
RTC play negotiate开头的，能看到 SDP 交换的结果 - DTLS 握手日志：
DTLS handshake开头的，能看到握手是否成功 - RTP 发送日志：
send RTP packet开头的，能看到发送的包数量和序列号 - RTCP 处理日志：
on_rtcp_nack、on_rtcp_pli开头的，能看到反馈处理情况
排查时建议把日志级别调到trace，虽然日志量大，但能看到最详细的信息。如果日志里出现大量NACK但重传失败，说明缓存不够或网络太差；如果出现PLI但没看到关键帧发送，说明推流端没响应。
6.2 关键参数调优：一份可直接抄的配置
SRS 的 WebRTC 播放相关参数主要在srs.conf的rtc_server和vhost段里。下面是一份经过实战验证的配置，适合中等规模（几百路并发）的直播场景：
rtc_server { enabled on; listen 8000; candidate $CANDIDATE; # NACK 缓存大小，高丢包网络建议调大 nack_cache_size 2000; # NACK 缓存保留时间，单位秒 nack_cache_timeout 5; # 是否开启 TWCC 反馈 twcc on; } vhost __defaultVhost__ { rtc { enabled on; # 是否转发 PLI 到推流端 pli on; # 最大发送码率，防止推流端码率过高 max_bitrate 2000; # 关键帧请求间隔，单位毫秒 keyframe_request_interval 1000; } }这份配置的核心思路是：给重传留足缓存，给关键帧请求留足响应时间，给码率设上限。实际使用时根据网络状况微调，比如网络特别差就把nack_cache_size调到 3000，max_bitrate降到 1000。
6.3 弱网模拟与压测：怎么在本地复现线上问题
线上问题往往在弱网下才出现，本地测试时可以用工具模拟弱网。Linux 下用tc命令可以模拟丢包、延迟、抖动：
# 模拟 10% 丢包，100ms 延迟，20ms 抖动 tc qdisc add dev eth0 root netem loss 10% delay 100ms 20ms # 清除规则 tc qdisc del dev eth0 root压测方面，可以用ffmpeg推多路流，用多个浏览器页面同时播放，观察 SRS 的 CPU、内存、网络带宽。SRS 自带了一些监控指标，通过 HTTP 接口/api/v1/summaries可以查看。
我一般会做三组测试：正常网络、10% 丢包、30% 丢包。正常网络下看延迟和流畅度，10% 丢包下看 NACK 重传效果，30% 丢包下看关键帧请求和码率自适应。三组都过了，基本能保证线上稳定。
6.4 踩坑记录：三个真实问题的排查过程
问题一：播放几秒后卡住，日志显示 NACK 重传失败。排查发现是nack_cache_size太小，网络延迟 200ms 时，重传请求到达时包已经被清出缓存。把缓存调到 2000 后解决。
问题二：音视频不同步，视频比音频慢 500ms。排查发现是时间戳转换时，音频和视频用了不同的基准。SRS 在某个版本里音频基准是第一个音频帧的时间戳，视频基准是第一个视频帧的时间戳，两者不一致。升级 SRS 后修复。
问题三：浏览器报ICE connection failed，但信令成功。排查发现是 SRS 的candidate配置写的是内网 IP，浏览器在外网访问不到。改成公网 IP 或域名后解决。这个问题在云服务器部署时特别常见，因为云服务器通常有内网和外网两个 IP。
提示：SRS 的
candidate参数支持配置多个候选地址，格式是candidate $CANDIDATE，可以在环境变量里指定。云服务器部署时，建议同时配置内网和外网地址，让浏览器自己选择。
7. 从源码到实践：几个值得深挖的扩展方向
7.1 自研 jitter buffer 的可能性
SRS 本身不做 jitter buffer，它把包发出去就不管了，去抖和重排是浏览器侧做的。但在某些场景下，比如需要服务端录制、或者需要做服务端转码，服务端也需要一个 jitter buffer 来保证帧的完整性。
自研 jitter buffer 的核心是：维护一个按序列号排序的包队列，收到包后插入队列，按时间戳顺序取出完整的帧。难点在于处理乱序、丢包、重复包，以及控制 buffer 大小——太小了去抖效果差，太大了延迟高。可以参考 WebRTC 的jitter_buffer实现，它用了基于时间戳的排序和动态调整 buffer 大小的策略。
7.2 拥塞控制的优化空间
SRS 的拥塞控制主要依赖 REMB，这个机制在 WebRTC 早期是主流，但现在更推荐用 TWCC（Transport Wide Congestion Control）。TWCC 的反馈更精细，能提供每个包的到达时间，让发送端更准确地估算带宽。SRS 5.x 已经支持 TWCC，但默认没开，需要手动配置。
开启 TWCC 后，SRS 会根据 TWCC 反馈调整发送速率，效果比 REMB 好很多。但 TWCC 的实现复杂度也高，需要处理更多的反馈包和更复杂的带宽估计算法。如果你的场景对弱网表现要求高，建议开启 TWCC 并做针对性调优。
7.3 多轨道与 Simulcast 的支持
SRS 目前对 Simulcast（同一路流推多个质量层，播放端按需选择）的支持还在完善中。Simulcast 的价值在于：弱网时播放端可以切到低质量层，保证流畅；网络好时切到高质量层，保证清晰度。实现 Simulcast 需要在 SDP 协商时处理多个 SSRC 和 rid（RTP Stream ID），在发送时按层管理 RTP 包。
如果你在做大规模直播，Simulcast 是值得投入的方向。SRS 的代码结构对扩展比较友好，SrsRtcConnection里已经预留了多轨道的接口，可以在此基础上做二次开发。
7.4 监控与告警体系的搭建
线上跑 WebRTC 播放，光靠日志不够，需要一套监控体系。核心指标包括：信令成功率、DTLS 握手成功率、RTP 发送码率、NACK 重传率、PLI 触发频率、端到端延迟。这些指标可以通过 SRS 的 HTTP API 采集，推到 Prometheus 或自建监控系统。
告警阈值建议这样设：信令成功率低于 99% 告警，NACK 重传率高于 10% 告警，PLI 触发频率高于每分钟 5 次告警。这些阈值不是绝对的，根据你的业务场景调整。关键是建立基线，知道正常情况是什么样，异常时才能快速发现。
我个人在实际操作中的体会是，WebRTC 播放的问题，80% 出在网络和反馈处理上，20% 出在协商和打包上。所以排查时先看网络质量，再看 RTCP 反馈，最后看 SDP 和 RTP 打包。这个顺序能帮你快速缩小范围，避免在无关的代码里浪费时间。另外，SRS 的版本更新比较快，遇到问题时先确认是不是已知 bug，升级到最新稳定版往往能解决很多莫名其妙的问题。
