简介：这是用于搭建WebRTC会议服务器端的PeerServer v4.1.1资源包，面向需要实现浏览器端到端实时音视频通信的开发者与运维人员。包内含8个文件，以JavaScript核心服务（peerserver.js、vendermodule.js）、证书文件（cert.pem、key.pem）、JSON配置（package.json、config.json）为主，另有安装脚本installserver.sh和第三方许可说明，整体仅16KB，结构紧凑。已有285人学习下载。借助该包可快速了解PeerServer 4.1.1的目录组成与部署方式：通过服务端脚本启动信令协调，配合证书与配置文件完成TLS/安全接入，适用于小型会议系统或WebRTC学习验证场景。结合描述中的WebRTC架构知识，可进一步理解RTCPeerConnection、ICE建连与RTCDataChannel在端到端通信中的实际落地。 搞 WebRTC 会议服务器的人应该都有这种感觉：信令、推流、拉流、NAT 穿透这些模块，单独拿出来都能讲一堆，串起来才真正考验工程能力。最近我把项目里的会议服务端 Peer 模块升到了 CS_WebRTC_Conference_Server_Peer.v4.1.1，这版本在媒体协商和弱网处理上的变化比较大，正好把这几天的排查过程整理一下。这个 Peer 模块是会议服务器里负责每个参会者对等连接的核心，主要管推流、拉流、ICE 协商和码率控制，适合正在自建会议系统、音视频网关或者 SFU 服务的开发者参考。下面内容偏实战，不会把所有 WebRTC 概念都讲一遍，重点说 v4.1.1 在会议场景下怎么用、怎么调、怎么排查问题。

1. 先把这个版本的角色看明白：Peer 模块到底在会议系统里干嘛

1.1 从会议系统架构看 Peer 的定位

正常的多方会议不会让所有终端两两直连，那样网络复杂度和客户端压力都扛不住。主流方案是走 SFU 或者 MCU 路由，每个参会者和服务器建一条 WebRTC PeerConnection。服务端需要有人维护这条连接的完整生命周期，包括接收发布者的媒体流、给订阅者发送媒体流、处理 ICE 状态变化、上报质量数据。v4.1.1 里的这个 Peer 模块，干的就是这件事。

这个模块边界很清晰，它不碰房间人数、聊天记录、权限控制这些业务逻辑。上层信令服务把“谁要发流”“谁要收流”的意图告诉 Peer 模块，Peer 模块负责把 PeerConnection 建起来、把 RTP 流转起来，然后把状态回调给上层。拆开设计的好处是：升级、扩容、单测都方便。我做多区域部署时，可以直接把 Peer 模块单独拉出来横向扩容，不需要连带重启业务服务。

之前我见过有人把房间逻辑和 PeerConnection 写在一起，并发一高，信令线程一卡，媒体线程也被拖住。拆开之后，Peer 模块可以独立控制调度优先级，即使某个房间消息量很大，也不会影响其他房间的媒体转发。这算是我见过比较实用的服务端设计。

1.2 v4.1.1 这个版本解决的核心痛点

升级前我特意看过 changelog，里面列了三个重点：推流和拉流的信令交互更稳定、弱网下的码率决策更平滑、Peer 关闭后的资源回收更干净。实际跑下来，前两个提升最明显。

先说信令交互。v4.1.1 在收到 SDP Offer 后会先做格式校验，再创建 PeerConnection，避免因为畸形 SDP 导致进程崩溃。之前线上出过一条恶意 SDP 打崩 Worker 的情况，升级后这个入口稳了很多。

再说弱网。这个版本把音视频轨道的接收和发送拆成了独立传输通道，视频重传不会挤压音频 RTP。很多会议卡顿并不是带宽不够，而是音频和视频在一个通道里互相争抢。v4.1.1 做了优先级隔离后，实测 30% 丢包下语音还能基本连续，这对我来说已经算惊喜了。

提示：不要小看音视频通道隔离。如果你遇到音频断断续续，先别怀疑带宽，检查是不是视频重传把 audio RTP 挤掉了。用抓包看一下重传包占的比例，比瞎调码率快得多。

2. WebRTC 推流和拉流在 Peer 里是怎么跑的

2.1 推流链路：采集、编码、RTP 发送

终端推流给会议服务器，服务器 Peer 模块收到一路或多路音视频流。以视频为例，浏览器端用摄像头或者屏幕分享采集画面，经过编码器生成 H.264、VP8 或 VP9 码流，封装成 RTP 包通过 UDP 发到服务端。Peer 模块收到 RTP 后并不只是转发，而是先解包，检查序列号、时间戳、负载类型，统计丢包情况，再决定要不要向上层请求重传。

这里有个容易忽略的点：服务端 Peer 模块作为接收端，也必须定期发送 RTCP Receiver Report，告诉发送端当前的丢包率、抖动和往返时延。发送端依赖这些反馈做码率自适应。如果你在抓包里看不到 RTCP RR，说明反馈链路没建立，拥塞控制就是空中楼阁。

我排查过一个诡异问题：只有部分用户推流码率始终很低，后来抓包发现是 Peer 模块所在服务器把 RTCP 的 UDP 包丢了，发送端收不到反馈，只能把码率降到一个保守值。把防火墙的 UDP 端口段放开后，码率立刻恢复正常。

2.2 拉流链路：SDP 协商、ICE 候选、播放缓冲

服务器把某个参会者的媒体流分发给其他参会者时，Peer 模块作为发送端，需要为每个订阅者创建独立的 PeerConnection，完成 SDP Offer/Answer 和 ICE 协商。协商成功后开始推流，接收端根据自己的显示能力和网络状况反馈 REMB 或 Transport-cc，服务器再决定这一路推流的码率档位。

播放缓冲同样值得关注。v4.1.1 给每个拉流轨道都管理了独立的 jitter buffer，不会因为某个订阅者网络差，拖慢其他人的转发。以前出现过一个人网络抖动，整个房间画面跟着卡的情况，多半就是 jitter buffer 和推流侧混在同一个循环里了。拆成每 Peer 独立调度后，问题定位就简单了。

实际调参时，视频 jitter buffer 我一般设置在 200 到 400ms，设置太短容易在弱网下连续丢帧，太长又会增加端到端延迟，视频会议里超过 500ms 就明显感觉“跟不上说话”了。音频 jitter buffer 更敏感，我习惯放在 60 到 120ms，特殊情况放宽到 150ms。

2.3 为什么 Peer 模块不能只当成 WebRTC 客户端封装

很多人写服务端 WebRTC，直接拿浏览器的 WebRTC 客户端库改一改，以为能用就行。但服务端场景下 Peer 模块要同时管理几百上千条连接，客户端的 UI 驱动逻辑、自动播放策略、设备中断恢复逻辑都不适用，反而会拖垮性能。正确做法是去掉所有和 UI 相关的依赖，直接用底层库封装出可并发复用的 Peer 对象。

v4.1.1 把 Peer 对象做成了池化设计，连接关闭后不会立刻销毁底层传输，而是把内存池和缓冲区标记为可用状态，下一条连接来了直接复用。这样做的好处是减少频繁创建和销毁带来的 GC 压力，也可以避免端口碎片化。在长连接高并发的会议场景里，这个设计非常适合抄作业。

如果你的项目还在用客户端 SDK 做服务端连接管理，建议尽早评估重构。不是不能用，而是并发到一定程度后，线程模型和内存分配都会成为瓶颈。

3. 弱网卡顿优化：我在 v4.1.1 里实际调过的几个参数

3.1 先理解 WebRTC 的拥塞控制与码率自适应

WebRTC 默认的拥塞控制算法会综合考虑丢包率、延迟和带宽估计，动态调整发送码率。但会议场景有个特殊点：上行推流和下行拉流同时存在，如果只靠默认算法，面对语音、视频、屏幕共享混合流量时会反应偏慢。

我在部署里会把 Peer 模块的码率调整周期从默认 500ms 改到 200ms，同时限制单次码率下降幅度不超过 15%。这样网络波动时码率是阶梯式下降，不会一下从 2Mbps 掉到 200kbps。为什么这样做？因为拥塞控制默认偏向流量公平，但会议场景更看重连续可用，宁可牺牲一点清晰度，也不要频繁断流重协商。

这个思路只适用于会议服务器内部转发场景。如果你是在做直播场景，可能更看重画质稳定性，参数取向会完全不同。一定要结合自己的业务属性去调。

3.2 关键参数配置清单：Jitter Buffer、FEC、重传

下面是我在 v4.1.1 里实际用下来比较稳的一组参数。不同版本不一定完全一致，但思路是通用的：

参数	推荐值	说明
video jitter buffer	200–400ms	太大增加延迟，太小在弱网下容易连续丢帧
audio jitter buffer	60–120ms	语音对延迟敏感，可放宽到 150ms 应对极端抖动
FEC 冗余率	动态 20%–50%	丢包超 10% 开启，超 30% 加强冗余
NACK 重传次数上限	3 次	过多重传会加剧拥塞，过少则弱网恢复慢
发送码率下限	150kbps	保证会议画面基本可用，不直接黑屏

FEC 这块想多说一句。FEC 会额外占用带宽，所以在带宽充足时我建议关掉，等检测到丢包持续超过 10% 再动态开启。v4.1.1 支持这种按需冗余，实际测试中 30% 丢包时，画面还能马赛克式保持，不会彻底断掉。

3.3 部署侧注意：防火墙端口、NAT 穿透和带宽规划

WebRTC 媒体流走 UDP，默认端口范围可以配置。Peer 模块通常会监听一段 UDP 端口，比如 8000-9000，同时需要配置 STUN/TURN 服务。很多“connection reset by peer”根本不是程序 bug，而是 UDP 端口被防火墙静默丢弃，客户端等不到响应就主动断开。

生产环境我建议至少准备一台 TURN 服务器。虽然 TURN 会带来额外的转发开销，但在大多数办公网络、校园网、运营商 NAT 下，它能救命。STUN 只能拿到公网地址，穿透失败时没有 TURN 就彻底连不上。

带宽规划也要注意。SFU 模式下，每个参会者的下行带宽取决于他订阅了几路流，不是简单的上下行对称。假设视频平均码率 1Mbps，一个用户订阅 4 路视频，就需要 4Mbps 下行。Peer 模块最好支持 Simulcast 或 SVC，这样窄带用户可以只订阅低清晰度层，避免服务端强制降低所有人的清晰度。

4. 实操过程：从源码构建到对接 Peer 服务的完整步骤

4.1 环境准备与依赖安装

v4.1.1 源码拉下来后，先确认编译环境。我是在 Ubuntu 22.04 上构建的，主要依赖包括 libwebrtc 对应版本、jsoncpp、libsrtp2、openssl。如果只做媒体流处理，不需要装整个浏览器内核，编译产物是一个动态库和一个可执行文件。

构建命令大致是这样：

./build.sh -version=4.1.1 -enable-opus=true -enable-h264=true

如果需要屏幕共享或分层编码，建议加上 -enable-simulcast ，否则后面的 Simulcast 订阅配置不会被编译进去。构建时间取决于机器，四核以上服务器会快很多，我最初在双核虚拟机上编译，光 libwebrtc 就等了快一个小时，属实痛苦。

4.2 配置信令服务和 Peer 连接参数

Peer 模块不处理业务信令，但需要和信令服务对接。常用消息有 join、publish、subscribe、leave。我的对接方式是在信令服务里维护一张 Session 表，把 PeerId 和会议号绑定。当终端请求推流时，信令服务装配一条 publish 消息，带上 SDP Offer 转给 Peer 模块，Peer 模块创建 PeerConnection，处理完返回 Answer。

这里要注意 ICE 配置。下面是一份 v4.1.1 能识别的 PeerConfig 示例：

{
  "iceServers": [
    {"urls": "stun:stun.example.com:3478"},
    {"urls": "turn:turn.example.com:3478", "username": "meeting", "credential": "secret"}
  ],
  "bundlePolicy": "max-bundle",
  "rtcpMuxPolicy": "require",
  "iceCandidatePoolSize": 10
}

iceCandidatePoolSize 建议至少设成 8，让 Peer 对象提前收集 ICE 候选，可以明显缩短呼叫建立时间。 bundlePolicy 设为 max-bundle 会把音视频都复用同一条传输通道，减少 NAT 映射数量和握手开销，会议场景基本都这么配。

4.3 验证推流/拉流是否正常

对接完成后，先用两个浏览器实例做自测。一个页面推流，另一个页面订阅，观察 SDP 协商是否成功、ICE 状态是否变成 connected、音视频是否正常播放。

查看 Peer 模块日志时，重点关注 onIceConnectionChange 、 onTrack 、 onRtpPacket 这几个回调。正常情况下日志里应该出现 ICE connected 和 Recv video track 。如果出现 failed，先抓包看 STUN/TURN 流量，判断是 NAT 穿透失败还是配置不对。我一般用 tcpdump 抓 UDP 8000-9000 段：

tcpdump -i eth0 -nn udp portrange 8000-9000 -w webrtc.pcap

然后用 Wireshark 过滤 RTP 流，看序列号和重传包占比。重传比例过高，基本就能确认是对端反馈不准或者 FEC 没生效。

5. 常见问题与排查技巧实录

5.1 connection reset by peer 到底是谁先断的

日志里看到 connection reset by peer ，很多人的第一反应是改代码，但我建议先搞清这是 TCP 层的概念。WebRTC 媒体流走 UDP，所以这个报错往往来自信令连接、TURN/TLS 连接。也就是说，TCP 层对端直接回了 RST，而不是正常的 FIN。常见原因有三个：一是服务端程序崩溃或主动关闭 socket，二是中间防火墙主动发 RST，三是 TURN 鉴权失败被对端断开。

排查第一步是看报错时间点。如果 RST 出现在 join 阶段，重点查信令服务和 TURN 的鉴权配置；如果出现在推流几秒后，重点查媒体端口范围是不是被其他进程占用，或者 Peer 模块缓冲区溢出触发了保护性断开。不要急着改代码，先抓包看 RST 包的来源 IP，是终端 IP 还是中间设备 IP，定位会快很多。

我遇到过最典型的一次：公司出口防火墙对长时间空闲的 TCP 连接发了 RST，导致信令连接每隔 30 分钟断一次。解决方式是启用 TCP keepalive，并把间隔调成 15 秒，防火墙就不再误杀。

5.2 stream disconnected before completion 的定位思路

日志里出现 stream disconnected before completion: io error: peer closed connection with ，说明 PeerConnection 在媒体流完成前就断了。多数情况是接收端长时间没有发送 RTCP 反馈，被发送端判定为不可达，主动关闭了数据流。Pion WebRTC 这类库经常报这个错。

遇到这种日志，先看对端网络的 RTT 和丢包，再看本端有没有触发 ICE restart。我遇到过一个移动端场景：手机熄屏后系统自动暂停 RTP 发送，但 PeerConnection 没有立刻断开，等亮屏恢复时已经积累了上千个重传包，媒体线程直接卡死。解决方式是在 App 侧监听前后台切换，进入后台前主动发 DTLS close_notify，恢复回来后再重新协商，比让服务器一直等 RTCP 超时高效得多。

如果服务端日志显示 RTCP 一直没有回流，但抓包又看不到主动断开包，大概率是客户端被系统挂起，可以联系客户端同学一起排查，单纯看服务端日志容易误判。

5.3 一份可以直接用的排查速查表

我把最近遇到的几类问题整理成表格，排查时可以对照着看：

现象	可能原因	处理方式
join 时 connection reset	TURN 鉴权失败或票据过期	检查 username/credential 和有效期
推流正常，拉流黑屏	SDP 里视频方向错误	检查 answer 中 recvonly/sendonly 是否对应
高丢包，但 CPU 不高	弱网拥塞控制参数太保守	调整码率下降周期和 FEC 冗余率
定时断流	NAT 映射超时	开启 ICE 续期，缩短连通性检查间隔
stream disconnected before completion	对端没有 RTCP 反馈	抓包确认 RR 是否返回，排查终端策略

注意：很多报错是网络路径和终端行为叠加出来的，服务端日志只能说明结果。抓包数据最好保存 24 小时，回溯时直接找对端 IP 和 RTP 流方向，能少走很多弯路。

最后再分享一个我自己的习惯：每次升级 Peer 版本后，我不会立刻全量替换线上节点，而是先拉一台测试机跑 24 小时，重点看 ICE 连接成功率、丢包率、重传率和 CPU 占用。这个习惯帮我躲过好几次版本兼容问题，尤其是不同 libwebrtc 版本之间的 SDP 格式差异，单测根本覆盖不到。不管你是刚开始接触 WebRTC 会议服务，还是已经在维护线上 SFU，建议都保留一条稳定回滚路径。

本文还有配套的精品资源，点击获取