WebRTC-Streamer跨内网视频传输的Docker网络配置实践

在基于WebRTC技术的视频流传输场景中，mpromonet/webrtc-streamer是一个将RTSP流转换为WebRTC格式的优秀工具。但在实际部署时，特别是在需要跨越不同内部网络进行P2P直连的场景下，网络配置往往成为技术实现的难点。本文将深入分析典型的内网穿透方案及其优化实践。

典型网络架构分析

在常见的跨网络视频传输架构中，通常会部署以下组件：

1. 内网侧的webrtc-streamer服务，负责RTSP到WebRTC的协议转换
2. 内网代理程序（streamer-proxy），通过HTTP与webrtc-streamer交互
3. 公网信令服务器，协调两端建立WebRTC连接
4. STUN/TURN服务器，用于NAT穿透和中继

这种架构理论上可以通过STUN服务器实现P2P直连，但在实际测试中发现只能通过TURN中继建立连接，这表明NAT穿透失败。

关键问题定位

经过技术分析，发现问题根源在于Docker默认的网络隔离特性。当使用常规的端口映射参数（如-p 8000:8000）时：

• Docker会创建虚拟网络接口
• 流量经过NAT转换
• 导致STUN服务器获取的是Docker内部的IP地址
• 外部客户端无法直接访问该地址

这种网络隔离破坏了WebRTC建立P2P连接所需的真实IP/端口信息交换。

解决方案：Host网络模式

通过改用Docker的host网络模式启动容器：

docker run --net=host -it mpromonet/webrtc-streamer

这种配置的优势在于：

1. 容器直接使用宿主机的网络栈
2. 不再有额外的NAT转换层
3. STUN服务器可以获取真实的公网IP和端口
4. 保持UDP端口的直接可达性

技术原理深入

WebRTC的NAT穿透依赖于ICE框架，其工作流程包括：

1. 通过STUN服务器发现自身公网映射地址
2. 通过信令通道交换候选地址
3. 尝试按优先级建立连接（主机候选 > 反射候选 > 中继候选）

当使用默认Docker网络时，由于网络地址转换，STUN服务器获取的是Docker内部的私有地址，导致P2P连接失败。而host网络模式保持了网络拓扑的透明性，使得ICE协议能够正常工作。

部署建议

对于生产环境部署，建议：

1. 评估网络安全策略，host模式会降低隔离性
2. 考虑结合防火墙规则限制访问
3. 对于云环境，注意安全组配置需要开放相关UDP端口
4. 仍建议保留TURN服务器作为备用方案

通过正确的网络配置，webrtc-streamer可以充分发挥WebRTC的技术优势，实现高效的跨网络视频传输方案。