ZLMediaKit WebRTC外网观看流量异常问题分析与解决方案

问题背景

在使用ZLMediaKit进行WebRTC直播时，开发者发现了一个特殊现象：当外网观看人数达到一定数量时，服务器会出现CPU使用率突然翻倍、网卡下行流量暴增的情况，最终导致路由器崩溃。而内网观看则完全正常，流量增长符合预期。

现象详细描述

测试环境配置：

• 服务器：Ubuntu 22.04.3 LTS系统，双网卡配置
• 推流端：Android设备通过RTSP协议推送5路直播流
• 观看端：PC浏览器通过WebRTC观看

测试数据表现：

• 1-5个外网观看端时，下行流量按预期线性增长（每增加一个观看端增加10Mbps）
• 当第6个观看端加入时，下行流量突然从50Mbps暴增至110Mbps
• 内网观看时，流量增长始终线性，无异常情况

问题分析

1. 网络带宽限制

初步分析表明，公网出口带宽仅有40Mbps，远低于实际需要的流量。当观看端数量达到临界点时，系统无法处理额外的流量需求。

2. NACK重传机制

WebRTC使用NACK(否定确认)机制进行丢包重传。当网络状况不佳时：

• 客户端会发送NACK请求要求重传丢失的数据包
• 服务器需要重复发送相同数据，导致流量倍增
• 重传会消耗额外CPU资源进行包处理

3. UDP传输特性

WebRTC默认使用UDP传输，具有以下特点：

• 无连接、不可靠传输
• 无内置流量控制机制
• 运营商可能对UDP流量进行限制
• 丢包率高时会触发大量重传

解决方案

1. 使用RTC over TCP

通过将WebRTC的传输层改为TCP，可以显著改善网络拥塞情况：

• 在配置中将UDP端口设置为0，强制使用TCP传输
• TCP具有内置的流量控制和拥塞避免机制
• 减少因丢包导致的重传风暴
• 更适合不稳定的公网环境

2. 带宽管理与优化

• 准确评估实际需要的出口带宽
• 考虑使用带宽限制功能，防止流量突发
• 优化视频参数（分辨率、帧率、码率）
• 启用ZLMediaKit的webhook进行流量控制

3. 编码参数调整

• 确保视频流不包含B帧（浏览器对B帧支持不佳）
• 合理设置关键帧间隔
• 使用更高效的编码格式（如H.265）
• 调整音频编码参数（如使用Opus替代AAC）

4. 配置优化建议

• 设置rtsp.direct_proxy=0尝试改善播放体验
• 调整ZLMediaKit的线程模型以适应高并发
• 监控系统日志，关注EventPoller线程负载情况

技术原理深入

WebRTC的NACK机制在丢包率高的网络环境下会成为双刃剑。当网络状况恶化时，客户端会发送大量NACK请求，服务器需要维护重传缓冲区并处理这些请求，这会导致：

1. CPU负载增加：需要额外计算和查找需要重传的包
2. 网络流量倍增：相同数据可能被多次发送
3. 恶性循环：重传进一步加剧网络拥塞

TCP传输虽然避免了NACK风暴，但需要注意：

• TCP的拥塞控制可能导致视频卡顿
• 需要合理设置TCP缓冲区大小
• 在极端网络条件下仍可能出现问题

总结

ZLMediaKit作为优秀的流媒体服务器，其核心功能在内网环境下表现正常。外网环境下出现的问题主要源于网络条件限制和WebRTC协议特性。通过改用TCP传输、优化编码参数和合理配置系统，可以有效解决外网观看时的流量异常问题。对于带宽严格受限的环境，建议实施严格的流量控制策略，确保系统稳定运行。