起手就被坑惨了

那天想着给视频通话加个屏幕共享功能，满心欢喜打开Chrome的webrtc-internals，结果数据哗涌进来跟瀑布似的。眼睛盯着metrics表格看了五分钟——好家伙，比特率上蹿下跳跟抽风一样，帧率直接表演跳水，愣是看不出卡顿在哪个环节。

跟无头苍蝇似的乱撞

第一反应就是掏Wireshark抓包。捏着鼻子过滤了一下午的STUN包，看得脑壳嗡嗡响，突然发现某个候选地址的丢包率飙到30%。赶紧打开终端哐哐敲：netstat -an grep 19302。结果端口显示LISTEN状态，防火墙也没拦着，可接收速率死活是0！气得我差点把键盘砸了。

• 把Linux的tc命令当救命稻草，搞了个tc qdisc add dev eth0 root netem loss 10% 模拟网络波动
• 转头打开测试网页直接黑屏，video标签右上角疯狂转圈圈
• 又折腾testrtc跑模拟丢包测试，报告里红色警告堆成山

蹲在显示器前啃指甲的时候，突然瞄到SDP里的a=rtcp-mux这行鬼东西。掏出SDP解析器把offer/answer糊进去，发现两边根本没协商RTCP复用！音频和视频的控制流量全在抢通道，UDP端口挤得跟早高峰地铁似的。

动手改造传输层

咬牙切齿冲进代码库，把PeerConnection配置里的mandatory参数全给废了，换成这种野路子：

* = "unified-plan";

* = "require";

重启服务再测试，Wireshark立马老实了。原来满屏的RTCP包突然消失八成，音频流和视频流的SSRC整齐排成两队走专用通道。

顺手给性能埋个彩蛋

• 把stats定时器从1秒改成3秒，webrtc-internals页面终于不卡成PPT了
• 把getStats里的video-pcm数值勾选掉，终端再也不吐几十兆的日志了
• 用chrome://webrtc-internals/?flags=legacy-constraints强行开启旧版界面

现在看测试数据可太舒坦了。比特率曲线稳得能当尺子用，帧率波动不超过3帧。喝着咖啡点开拥塞控制面板，把GoogCC参数里的目标延迟从2秒改成500毫秒——好家伙，通话延迟直接从800ms砍到300ms！

踩坑两天的血泪总结

别傻乎乎硬肛原始数据！先把SDP打印出来用解析器过一遍。传输层协商乱七八糟的时候，什么Wireshark、testrtc全是坑爹货。直接暴力锁死RTCP复用策略，比调一万个参数都管用！还有那个破监控页面，记得调采样率，不然Chrome分分钟教你做人的道理。

(现在谁要是问优化WebRTC该从哪入手，我反手就把这篇文章糊他脸上。那些劝人直接读RFC文档的专家，不是蠢就是坏！)