1. 从“能用”到“懂它”：为什么非要扒开 PeerConnection 的实现层
做 WebRTC 开发的人，基本都会经历三个阶段：第一阶段照着官方 demo 把本地视频 loopback 调通，兴奋得不行；第二阶段开始推流拉流，发现网络一波动画面就花成马赛克，开始疯狂搜“webrtc 弱网卡顿怎么优化”；第三阶段就是你现在这样，觉得 PeerConnection 这个对象像个黑盒，明明就几个 API 调用，底层到底发生了啥，出了问题完全没法定位。
我自己的感觉是，PeerConnection 是 WebRTC 整个体系里最“反直觉”的一层。它上面是 getUserMedia、RTCPeerConnection 这种一看就懂的 JS 接口，下面却是 ICE、DTLS、SRTP、SCTP 这一堆缩写比内容还长的协议栈。你调一下 setRemoteDescription，背后牵扯出信令协商、传输层选路、密钥交换、媒体流复用，随便哪一环出问题，表象都是“黑屏”“卡顿”“连不上”。
这篇文章不打算再从“什么是 WebRTC”开始讲起，网上那种介绍一抓一大把。我想换个角度，直接把你拉到 PeerConnection 的实现层，从源码和协议栈的视角拆一遍：一条流从本地采集到远端播放，中间到底走了哪些路，每一步是在干什么，哪一步最容易被坑，以及当网上流传的“弱网优化”方案真正落到实现层时，改的到底是哪个环节。
适合谁看？如果你已经能跑通 demo，但对“为什么这么写”感到困惑，或者已经被线上诡异问题折腾过几回，这篇文章应该能帮你把脑子里那些零散的知识点串成一张图。看不懂源码也没关系，我会把关键机制用大白话和类比讲清楚，源码部分只作为验证和锚点。
2. PeerConnection 实现层整体架构：一条流的前世今生
2.1 从 RTCPeerConnection 到 Native 层：JS 只是个“传话筒”
先泼一盆冷水：你在浏览器里写的new RTCPeerConnection({...})，本质上只是一张“购物订单”。真正干活的是浏览器底层 C++ 实现的 Native 层，JS API 只是通过 WebIDL 绑定把参数传下去罢了。
以 Chromium 为例，调用链大致是这样：
const pc = new RTCPeerConnection(config);这行代码会经过 Blink 层的RTCPeerConnectionHandler，然后路由到content/public/common/peerconnection_dependencies.h里组装出来的依赖项，最终创建出一个webrtc::PeerConnectionInterface的实现对象。也就是说，从这行 JS 开始，你已经进入了 WebRTC Native 代码库（也就是 Google 开源的src目录）的势力范围。
到了 Native 层，PeerConnection 内部大概由这几个核心模块组成：
- SdpOfferAnswer（会话描述）：负责生成、解析和协商 SDP，决定这条连接里有哪些媒体、用什么编码、走什么传输。
- JsepTransportController（传输控制器）：管理所有传输通道，包括 ICE、DTLS、RTP/RTCP 的收发。
- VideoEngine / AudioEngine（媒体引擎）：真正的音视频编码、解码、前后处理。
- DataChannel 控制器：走 SCTP-over-DTLS 的数据通道，和媒体流共享底层传输。
这些模块之间的协作关系，我建议你用一条“流水线”来理解。本地采集到的每一帧画面，先经过采集器进入编码器，编码器输出的 H.264/VP8/VP9 流被封装进 RTP 包，RTP 包被交给传输层，传输层加一层 SRTP 加密，然后由 ICE 选定的那个 Socket 发出去。远端收到后，流程反过来：Socket 收到包 → ICE 确认是合法对端 → DTLS 解密钥 → SRTP 解密 → RTP 解包 → 丢包检测重排 → 解码器解码 → 渲染上屏。
每个环节你都能往深处挖，但 PeerConnection 实现层的核心价值在于：它把上面这一整套状态机捏合成了一个“连接”，让你上层可以只关注onicecandidate、ontrack这些回调，而不用自己去拼 UDP Socket。
2.2 状态机视角：PeerConnection 一生要过哪些坎
PeerConnection 内部不再是“新建、连接、关闭”这么简单。实现层维护了一个严格的状态机，也就是RTCPeerConnectionState，它由 ICE、DTLS 和连接建立的整体情况共同推导出来。
状态主要有这些：new、connecting、connected、disconnected、failed、closed。
这里有个特别容易迷惑的地方：disconnected不代表断网，它只是 ICE 在一段时间内（默认约 5 秒）没收到任何来自对端的传输层反馈。Wi-Fi 突然走了一个大流量包导致网络拥塞、或者系统休眠被唤醒，都可能导致短暂的disconnected再恢复。如果你在上层一看到disconnected就弹“连接中断”，那体验会很糟糕。
实现层怎么判断对端“还活着”呢？ICE 协议本身有连通性检查机制，默认每Trickle ICE interval发一次 STUN Binding Indication。此外，RTP/RTCP 也会定期收到 RTCP Receiver Report / Sender Report。实现层把两类信号综合起来，用计时器判断是否超时。
我见过不少人在这个状态上栽过跟头，写成聊天室时发现对方关个网页，自己这边要等 30 秒才反应，这是正常的；但如果你等了很久还是connected，那十有八九是忘记设置iceConnectionState的监听，或者只是监听了connectionState，两者不是一回事。
pc.onconnectionstatechange = (e) => { console.log('connectionState:', pc.connectionState); }; pc.oniceconnectionstatechange = (e) => { console.log('iceConnectionState:', pc.iceConnectionState); };connectionState是聚合结果，iceConnectionState是 ICE 层的原始状态，排障时两个都要打出来看。
3. 核心机制拆解：SDP、ICE、DTLS、SRTP 在实现层是如何协作的
3.1 SDP 协商：不是“说好话”，而是一份逐字段较真的合同
很多人以为 SDP 就是交换一下 IP 和端口，实际上它是整个 PeerConnection 实现层最繁琐、最容易出 bug 的部分。SDP 是一个纯文本协议，里面每一行都是一个属性，一个m=video段就代表一路媒体，c=指定连接地址，a=是各种属性行。
举一个实际协商出来的 SDP 片段示例（格式化后）：
v=0 o=- 4611704713517848310 2 IN IP4 127.0.0.1 s=- t=0 0 a=group:BUNDLE 0 1 a=msid-semantic: WMS m=video 9 UDP/TLS/RTP/SAVPF 96 97 98 c=IN IP4 0.0.0.0 a=rtcp:9 IN IP4 0.0.0.0 a=ice-ufrag:kxmE a=ice-pwd:Yc8WZ/nW3spzSJ2e... a=ice-options:trickle a=fingerprint:sha-256 ... a=setup:actpass a=mid:0 a=sendrecv a=rtpmap:96 VP8/90000 a=rtcp-fb:96 goog-remb a=fmtp:96 ...逐行解读一下关键字段的意义：
a=group:BUNDLE 0 1：表示将多个媒体流（音频、视频）聚合到同一条传输通道上。现在浏览器基本都支持 BUNDLE，这也是为什么你抓包只看到一个 5 元组在跑流量。m=video 9 UDP/TLS/RTP/SAVPF：后面的SAVPF代表这套 RTP 流走了 SRTP 加密和 Feedback 反馈机制，9是占位端口，真正的端口要到 ICE 候选里才确定。a=setup:actpass：这是 DTLS 握手角色协商用的。actpass表示“我既可以是 client 也可以是 server”，双方会通过这个字段最终确定谁主动谁被动。a=fingerprint：DTLS 证书的指纹，用于身份认证。这个字段如果被篡改，后续密钥交换就不安全。
在实现层，浏览器会解析 SDP 并生成一个SessionDescription对象，内部转换成cricket::SessionDescription，然后逐段做校验。最容易被忽略的坑是a=rtcp-fb这套反馈机制。goog-remb、transport-cc、nack分别代表不同的码率控制/丢包重传策略。如果两端对 feedback 的支持不一致，弱网下就会出各种“对方没收到关键帧却怎么也不重传”的怪现象。
我自己的习惯是，排障时先把 SDP 里的rtcp-fb行打印出来，如果发现一端只有nack，另一端只有transport-cc，那你们协商出来的是双方交集，可能连nack都没有。这种问题不用担心代码层面修复，但要理解为什么视频一到弱网就卡。
3.2 ICE 候选收集与选路：不是选“最快”路径，而是选“可用”路径
ICE（Interactive Connectivity Establishment）是 PeerConnection 最神奇的部分，也是实现层最绕的模块。它要做的事情就一件：找出两个设备之间能用的网络路径，并且验证这条路径真的可达。
每个 RTCPeerConnection 都会启动一个PortAllocator，分别收集三种候选：
- host 候选：本机网卡上的 IP，比如 192.168.1.100。
- srflx 候选：通过 STUN 服务器反射出来的公网 IP:端口，比如 120.1.2.3:45000。它解决的是 NAT 映射问题，但还没穿过 NAT 的“白名单”限制。
- relay 候选：通过 TURN 服务器中继的地址。这是最保底的方式，当 P2P 打洞失败时只能走这里，代价是带宽和延迟都会变差。
收集完候选后，PeerConnection 会把它们通过信令发送给对方，即onicecandidate回调。双方把所有候选两两配对，形成一个候选对列表，然后互相发 STUN Binding 请求做连通性检查。
连通性检查不是按“网速最快”来选的，而是按“优先级”来的。优先级公式里，候选类型权重占了大头：host 优先级最高，srflx 次之，relay 最低。也就是说，即使 relay 服务器的带宽很好，只要 host 候选能通，实现层会优先走 host。但注意，host 候选往往只在同一局域网内才能直接通，跨互联网时 host 对 host 基本失败，srfx 对 srfx 如果 NAT 类型允许则能成功。
这里我想重点提醒一个实现层细节：ICE 的“可用”和“最佳”不是一回事。一个候选对如果连通性检查成功，就会被标记为“可用”，但并不代表它是当前选中的路径。实现层还会继续做nomination流程，由 controlling agent 决定最终选哪一对。Chrome 通常会把更高优先级的先 nominated，但如果你发现网络明明好却走了 relay，可能是 stun 服务器配置失败，导致 srflx 地址没收集到，只好用 relay 兜底。
弱网优化时，最常被人拿来开刀的就是 ICE 的两个超时参数：iceCheckInterval和iceCheckTimeout。默认值在源码里是cricket::ICE_IMPLEMENTATION相关常量，如果你在做自定义客户端，可以适当缩短连通性检查的时间间隔，让失败路径更早被淘汰。但浏览器端你改不了这些参数，只能在服务端 TURN 部署上做文章，比如增加 TURN 服务器的地域覆盖。
3.3 DTLS 握手：在不可信 UDP 信道上建立可信隧道
ICE 把 UDP 通路打通之后，两个端点虽然能互发数据，但这些数据还是明文，而且没有任何身份验证。PeerConnection 紧接着要做 DTLS 握手，把这条 UDP “管道”升级成“加密隧道”。
DTLS 就是 TLS 在 UDP 上的变种，专门解决丢包和乱序问题。实现层里，每个传输通道都维护一个DtlsTransport对象，它内部持有自己的证书和私钥。握手过程中，双方通过a=fingerprint交换的证书指纹来验证对方身份，防止中间人攻击。
有趣的是，DTLS 握手本身也会走 ICE 选出来的那条路径，也就是说，在握手阶段如果网络抖动导致 DTLS 报文丢失，整个连接会卡在“正在连接”状态，表象就是iceConnectionState已经变成connected，但connectionState一直是connecting。因为 ICE 通了，但 DTLS 没完成，媒体就没法开始传输。
排查这种问题最简单的方式，是看两端是否同时设置了setup角色。如果一端是active，另一端却是active，那两边都会等待对方先发起，导致握手死锁。好在浏览器实现的 SDP 默认是actpass，通过协商最终会有一个主动方，但自定义客户端里这种角色不匹配的坑非常常见。
另外一个很多人不知道的细节：DTLS 证书是每次会话动态生成的，不是固定的。所以你每次new RTCPeerConnection()，指纹都会变。如果上层要固定验证某个设备身份，需要额外机制（比如自签证书并用信令交换公钥），这不是 WebRTC 默认提供的。
3.4 SRTP 与媒体传输：加密、序号、反馈，一个都不能少
DTLS 握手完成后，会产出 SRTP 需要的密钥材料。之后，所有 RTP 包都要经过 SRTP 加密才能发送。为什么不用整个 DTLS 记录去封装所有媒体？因为那样开销太大了，一个 RTP 包多出几十字节 DTLS 头，对实时性不友好。SRTP 只增加少量字节（认证 tag 通常 10 字节左右），却保证了机密性和完整性。
实现层里，RTP 包的处理路径是：VideoStreamSender把编码器输出的EncodedImage封装成 RTP 包，每个包都有递增的sequence number和timestamp。接收端用这两个字段做排序和抖动缓冲。丢包检测也是基于 sequence number 的跳变来完成的。
反馈机制上，现代 WebRTC 主要依赖两种：
- NACK：接收端发现自己缺了某个包，发送
RTCP NACK请求重传。适合重传延迟在可接受范围内的情况。 - Transport-cc：接收端持续汇报每个 RTP 包的到达时间，发送端据此估算带宽并调整码率。这是现在最主流的拥塞控制方案。
弱网卡顿的优化，本质上就是这两套反馈机制和编码器码率控制配合的问题。网上很多人说“WebRTC 弱网优化从修改拥塞控制算法入手”，这句话对，但你得先知道拥塞控制在实现层哪里改。如果是自研 Native 客户端，可以去modules/congestion_controller里替换或者调参；如果只是用浏览器，那你什么都改不了，唯一能做的是让服务端不要成为瓶颈，并合理设置maxBitrate来避免码率忽高忽低造成的主观卡顿。
4. 实操：从源码到线上，围绕 PeerConnection 的完整落地路径
4.1 源码下载与构建：想深入实现层，先准备好战场
分析 PeerConnection 实现层，光靠看文档是不行的，必须拿到源码。官方 WebRTC Native 代码库位于https://webrtc.googlesource.com/src，它需要配合 depot_tools 使用。
下载步骤简洁版如下：
- 安装
depot_tools并加入 PATH。 - 创建目录，执行
fetch --nohooks webrtc。 - 同步依赖：
gclient sync。
这个流程我的经验是：网络顺畅时半小时到一个小时能完成，网络差的时候可能在中途反复重试。注意别只拉主干分支，建议直接切到某个稳定 tag，比如branch-heads/...，因为主干经常会有构建 breakage。
Windows 上构建需要 Visual Studio 和 Windows SDK，Linux 上需要 clang 和系统依赖，macOS 相对省心一些。构建命令一般是：
gn gen out/Default --args="is_debug=false" ninja -C out/Default如果你是第一次搞，我强烈建议先构建一个最小目标，比如peerconnection_client或者peerconnection_server示例，确认整个工具链没问题。这两个示例在examples/peerconnection目录下，是两个很经典的控制台应用，一个负责发流，一个负责收流，可以拿来做协议分析。
4.2 用日志和抓包验证实现层的关键节点
源码拿到手，构建跑通之后，下一步就是真正“看”实现层在做什么。WebRTC 内置了非常完善的日志系统，用RTC_LOG宏输出，可以指定日志级别和过滤条件。
在 Chromium 内核里，你可以通过命令行开关开启 WebRTC 日志：
chrome --enable-logging=stderr --v=3--v=3代表输出 INFO 级别以上的日志，其中会包含大量传输层信息。在 Native 示例程序里，可以通过环境变量设置WEBRTC_LOG_FILE把日志写到文件，方便事后分析。
日志里最值得关注的有几类：
- ICE 状态切换：能够看到候选收集完成、连通性检查发出的 STUN 请求是否收到响应。
- DTLS 握手进度：出现
DTLS handshake completed说明密钥协商完成。 - 丢包统计：会周期性打印 RTCP 统计，比如
packets_lost、fraction_lost。 - BWE 调整：
bwe_rtp.cc相关日志会显示估计带宽值的变化。
除了日志，用 Wireshark 抓包分析传输流量也很重要。抓包时选择你正在使用的 UDP 端口，然后设置udp.port == xxx过滤。WebRTC 的 SRTP 流量是加密的，但你仍然能看到 RTP 包的大小和到达节奏，判断是否存在突发性丢包。更高级的做法是，在out/Default构建时启用调试符号，然后让 Wireshark 导入 DTLS 密钥日志文件，这样就可以解密 SRTP，看到具体的 RTP 序号和时间戳，排查丢包重传的每个细节。
导出密钥日志需要在构建时增加参数：
gn gen out/Debug --args='is_debug=true enable_dtls_srtp_logging=true'程序运行时设置环境变量SSLKEYLOGFILE=/path/to/keylog。Wireshark 里在Preferences -> Protocols -> TLS里指定 key log 文件即可。这一步做完，你基本可以对 PeerConnection 的每条流做“显微”级别分析。
4.3 一个最小可复现的推拉流场景搭建
纸上谈兵终觉浅，我建议你搭一个最小场景来观察实现层行为。不需要复杂的信令服务器，就两台机器（或者同一台机器的两个页面也行，但跨机更接近真实网络）。
信令服务器我用 Node.js 写了个最小的 WebSocket 中转，只负责转发 SDP 和 ICE 候选：
const WebSocket = require('ws'); const wss = new WebSocket.Server({ port: 8080 }); const clients = new Set(); wss.on('connection', (ws) => { clients.add(ws); ws.on('message', (msg) => { // 如果已经有两个客户端了，就把消息转发给对方 clients.forEach((client) => { if (client !== ws && client.readyState === WebSocket.OPEN) { client.send(msg); } }); }); ws.on('close', () => clients.delete(ws)); });两个页面都连到这个信令服务器，分别执行“推流端”和“拉流端”逻辑。推流端通过getUserMedia采集摄像头，然后pc.addTrack；拉流端响应ontrack播放即可。
这个场景的价值在于：你可以人为制造链路问题，比如用 Linux 的tc命令模拟丢包和延迟：
# 模拟 5% 丢包和 200ms 延迟 tc qdisc add dev eth0 root netem loss 5% delay 200ms然后观察两端的 WebRTC 内部统计（pc.getStats()），看framesSent、packetsLost、jitter、nackCount这几个指标的变化。你会发现，在 5% 丢包下，NACK 会显著增加，但如果 RTT 很大（比如 200ms），NACK 重传可能来不及，画面就会等你收到下一个关键帧才能恢复，主观表现就是卡顿数秒。
实际上，企业级的推流和拉流场景比这种纯浏览器 demo 复杂得多，因为单台服务器承载的并发连接数、转码、合流、录制等需求都会影响 PeerConnection 的实际表现。但无论架构多复杂，PeerConnection 作为传输和协商的核心，其实现层的行为模式是共通的。
5. 弱网优化到底动的是哪一层？分享几条经过验证的经验
5.1 别一上来就改拥塞控制算法，先看丢包发生在哪
“webrtc 弱网卡顿怎么优化”是个搜索量特别高的词，我见过太多人一上来就准备去改 GoogCC（Google Congestion Control）的代码。我的建议是，先分清问题到底出在接入网、公网还是服务端。
怎么分清？在推流端和拉流端分别执行ping很难，因为 QoS 策略不同，更可靠的是看getStats()里的指标分布。如果推流端packetsSent很多但packetsLost很少，而拉流端packetsLost很高，说明丢包可能发生在推流端到服务器的链路，或者服务器到拉流端的链路。如果两端丢包都低但卡顿，那要怀疑是否拥塞控制把码率降得太狠，导致视频分辨率突然从 720p 掉到 320p，主观感受还不如稳定保持 360p。
一个简单的排查思路是这样的：
| 现象 | 可能原因 | 先查哪项 |
|---|---|---|
| 高丢包 + 高延迟 | 网络链路拥塞或无线信号差 | 丢包率、RTT |
| 低丢包 + 卡顿 | 码率波动过大，编码器频繁掉帧 | 码率、帧率曲线 |
| 短暂黑屏后恢复 | 关键帧丢失且没有及时申请新关键帧 | 关键帧间隔、PLI 计数 |
| 音频正常视频卡 | 视频带宽估计不足或编码卡顿 | 视频码率、编码耗时 |
在这个基础上再谈优化才有意义。浏览器端你改不了拥塞控制，但你可以：
- 限制视频码率上限，避免网速好时冲到 2.5Mbps，波动后断崖式下跌到 200kbps。
- 使用 Simulcast（多播流），让接收端根据自身网络选择合适的一路流。
- 增大丢包重传容忍度，同时开启
x-google-start-bitrate等启动码率配置（仅部分场景生效）。
5.2 实现层参数调优：在 Native 客户端里真正能改的东西
如果你是做 Native 客户端（比如 Windows/macOS 上的软硬件终端），那你可以直接改实现层的参数。分享几个我实际调过并有效果的例子。
第一个是RtcpReportInterval。默认的 RTCP 发送间隔较长，导致接收端的丢包反馈不够及时。在webrtc::RtcpConfig里可以减小video_report_interval和audio_report_interval，适当地把反馈周期缩短到 100ms 左右，可以更快触发 NACK 和码率调整。但注意不能太短，否则 RTCP 本身会占用过多带宽。
第二个是 NACK 历史缓冲区的长度。默认RtpVideoSender会缓存最近发送的 RTP 包，用于响应重传。如果缓存太短，接收端 NACK 一个很老的包时，发送端已经丢弃了，重传失败。这个参数在RtpRtxConfig里，可以设置最大重传次数（max_retransmits），超过这个次数就放弃，避免无限重传加剧拥塞。
第三个是 JitterBuffer 的深度。NetEq负责音频抖动缓冲，VideoJitterBuffer负责视频。深度越大抗抖动能力越强，但会增加延迟。实时通话场景下延迟敏感，需要平衡。我在做自定义播放器时就遇到过，默认缓冲大小在 8% 丢包下会频繁进入“rebuffer”状态，把底部层次的接收窗口稍微调大之后，主观流畅度明显改善，代价是延迟增加了 60ms 左右，这通常是值得的。
5.3 用 Simulcast 和关键帧策略解决弱网下的“马赛克”
还有一个我非常推荐优先实施的方案：开启 Simulcast。它让发送端同时编码多路不同分辨率和码率的视频流，接收端根据网络状况选择合适的那一路去请求。这在多人会议场景里几乎是标配，但很多做直播推流的朋友还没意识到它的价值，因为他们用的是单流模式。
在 SDP 中开启 Simulcast 后，你会看到这样的行：
a=simulcast:send 0,1,2对应三路编码。接收端通过setParameters选择需要解码的 encoding index。弱网时，拉流端可以自动切到低分辨率那一路，而不需要发送端重新编码或收端做超分辨率重建。
关键帧策略方面，常见做法是：
- 周期性发送--强制插入关键帧，让新加入的接收端能快速秒开。
- 检测到连续 NACK 丢失过多时，主动申请 PLI（Picture Loss Indication），让发送端立即重发一个关键帧。
在 Native 实现层，你可以通过编码器的RequestKeyFrame接口触发，也可以通过VideoStreamEncoder的内部逻辑自动触发。调试时观察pliCount指标，如果这个数字在正常网络下就很高，说明关键帧策略不够智能，接收端长时间未能恢复，需要调整丢包检测阈值。
6. 常见问题与排查技巧实录：PeerConnection 实现层的“疑难杂症”手册
6.1 为什么iceConnectionState一直是checking？
这是新手最常碰到的状态。首先是候选还没交换完，尤其是使用了 Trickle ICE——候选是一个一个通过onicecandidate上报的，但上层信令转发如果积压，对端可能没收到完整候选集，导致连通性检查永远找不到可用路径。
排查步骤：
- 在
onicecandidate里打印并完整转发候选，看对端是否收到全部候选。 - 检查 STUN/TURN 服务器配置是否正确。
iceServers里 URL 写错或者协议（stun:、turn:、turns:）写错都会导致 srflx/relay 候选收集失败。 - 打开 WebRTC 内部日志，过滤
portallocator，看是否有No address returned等错误。
我遇到过一次很隐蔽的问题：服务端部署了 TURN 但用的是turns（TLS 加密的 TURN），客户端自签证书没被信任，导致 TURN 分配请求一直失败，最终只能依赖 srflx 打洞。解决方式是改用turn:（明文 UDP 传输），或者把自签证书导入信任库。
6.2 为什么两端都在播放，但画面延迟越来越大？
延迟增大多半是接收端排队缓冲太长，或者发送端码率远高于网络带宽，导致拥塞窗口持续被填满。看getStats()里的jitterBufferDelay和totalProcessingDelay如果持续上升，说明接收端缓存的待播数据越来越多。
这时优先检查两点：
- 接收端是否开启了自适应抖动缓冲，如果是自定义播放器，可能你把它固定成了一个较大的值。
- 发送端是否开启了
maxBitrate限制。如果没设上限，发送端会用默认最大码率，在低带宽链路上形成持续拥塞，延迟自然越来越大。
另外，RTP 时间戳和播放时钟的同步也是关键。如果上层拿本地时钟去映射 RTP 时间戳而不是用ntp_time校准，经过长时间运行后会有累积漂移，表现的也是延迟慢慢变大。
6.3 视频经常黑屏但音频正常，怎么定位？
音频正常说明网络链路和 PeerConnection 基本是通的，问题多半出在视频的编码/解码链路上。这时候重点看这些：
- 编码器是否因 CPU 占用过高而丢帧，
getStats()里framesEncoded长时间不增长，encoderImplementation显示占用高的编码器。 - 是不是没有收到解码所需的关键帧。可以看接收端
keyFramesDecoded和framesDecoded的差值。如果framesDecoded一直停在同一数值，说明接收端没有可解码的数据。 - RTP 的 SSRC 是否对应正确。
m=段的 SSRC 在 SDP 里有写，收到流后可以用 Wireshark 比对，如果发的是音频 SSRC 却标成视频轨道，接收端就会拒绝解码。
6.4 用getStats()定位问题的最快路径
getStats()是浏览器暴露的官方诊断 API，信息量很大，但你没时间全看。我总结了一个最低限度的排查顺序：
总的来说，看到高丢包先看 RTT，看到高延迟先看 buffer，看到低码率先看拥塞控制的targetBitrate是不是在往下压。别一上来就怀疑浏览器实现，大多数弱网卡顿问题都是网络路径质量或参数配置造成的，真正需要你修改 Native 实现层的场景并不多。
const stats = await pc.getStats(); stats.forEach((report) => { if (report.type === 'inbound-rtp' && report.kind === 'video') { console.log('丢包率:', report.packetsLost / report.packetsReceived); console.log('抖动:', report.jitter); console.log('NACK数量:', report.nackCount); console.log('PLI数量:', report.pliCount); } if (report.type === 'candidate-pair' && report.selected) { console.log('当前路径 RTT:', report.currentRoundTripTime); console.log('带宽估计:', report.availableOutgoingBitrate); } });7. 最后再分享一点个人体会
对 PeerConnection 实现层研究得越深，你会越觉得它像一套精密的钟表：SDP 是图纸，ICE 是螺丝刀，DTLS 是安全锁，SRTP 是传送带，拥塞控制是调速器。每个模块单独看都有不少数学和协议知识，组合在一起却能以非常优雅的方式解决“两个陌生设备在不可控网络中实时互通”这个难题。
其实很多“优化方案”并没有那么神秘。Socket 层调不通，改多少拥塞控制参数都没用；编码器参数没配对，换多高级的服务器也白搭。所以我的习惯是，遇到问题先从实现层的状态机开始看，用日志和抓包把链路分段定位，找到瓶颈后小步调整、一步一验证。
如果你也想深入这套代码，建议从pc/peer_connection.cc入手，顺着CreateOffer、SetLocalDescription的调用栈往下读，每碰到一个类就在源码里搜它的名字，不用刻意去记，看得多了，实现层那层“黑盒”感自然就消退了。
