低延时直播的协议webrtc部署方法

说实话，之前被问到"怎么部署webrtc实现低延时直播"的时候，我第一反应是这事儿说简单也简单，说复杂也真够复杂的。简单在于WebRTC本身是开源的技术，框架搭起来不难；复杂在于真正把它用到生产环境，要考虑的事情太多了——网络穿透、音视频编码、服务器架构、客户端兼容……每一块都能单独写一篇文章。

但既然你问到了，我先把我实际部署过程中踩过的坑、总结的经验都分享出来，尽量用大白话把这个事情讲清楚。

为什么低延时直播要用WebRTC

在说部署之前，先聊聊为什么要用WebRTC。传统的直播协议比如RTMP或者HTTP-FLV，大家应该都接触过。这些协议有个共同特点，就是延迟基本在2到5秒这个区间。正常看看直播、刷刷短视频，这个延迟其实感知不强，但如果是互动直播呢？比如打赏主播求连麦、直播带货抢库存、线上教学实时问答，延迟个两三秒，体验就完全不一样了。

WebRTC的出现就是为了解决这个问题。它最初是Google收购GIPS后开源的技术，专门为实时音视频通信设计。我自己测过，在理想网络环境下，端到端延迟可以控制在500毫秒以内，这对需要强互动的直播场景来说简直是刚需。

WebRTC的核心工作原理

既然要用WebRTC，总得知道它是怎么运作的吧。我尽量用简单的语言解释一下。

WebRTC的工作流程大概是这样的：首先要建立连接，这个过程需要信令服务器帮忙；连接建立后，两个客户端可以直接点对点传输数据，这就是它低延迟的关键。不过现实网络没那么理想，大多数设备都在NAT后面，也就是大家常说的内网ip直接访问不了的情况。

这时候就需要STUN服务器和TURN服务器来帮忙了。STUN服务器帮你发现自己公网地址，如果两个客户端都在普通NAT后面，STUN基本能解决连接问题。但如果遇到对称NAT或者更复杂的网络环境，就需要TURN服务器来中转数据了。当然TURN中转会增加延迟和服务器成本，但稳定性会好很多。

部署环境准备

聊完原理，正式开始部署。我自己的习惯是先在测试环境跑通所有流程，然后再上生产环境。

服务器选择与系统配置

服务器这块，建议选择CPU性能好、网络带宽充足的机器。如果你预计并发量比较大，CPU核心数最好多一点，因为WebRTC的媒体处理和转发还是比较吃CPU的。

系统方面，Ubuntu 20.04 LTS或者CentOS 8都是比较稳妥的选择。这两个系统我都用过，稳定性没问题，软件包管理也方便。内存方面，建议至少4GB起步，如果是小规模部署2GB也能跑，但运行一段时间后可能会出现内存紧张的情况。

网络这块要特别注意，WebRTC需要用到特定的端口范围。UDP端口通常在10000到60000之间，TCP端口看你用什么信令方案。我建议在部署前先把防火墙规则配置好，避免服务启动后连不上。

依赖组件安装

以Ubuntu为例，需要安装的依赖大概有这些：

组件	用途说明
OpenSSL	数据加密，WebRTC强制使用DTLS/SRTP
libsrtp2	SRTP协议支持，媒体数据加密
libnice	NICE库，负责ICE协议实现，也就是NAT穿透
usrsctp	SCTP协议支持，用于数据传输

安装命令大概是这几行：

• apt-get update && apt-get install -y openssl libsrtp2-dev libnice-dev usrsctp-dev

如果是CentOS，用yum安装对应的包就行，名字差不多。装完之后可以写个小程序验证一下依赖是否正常，比如编译官方的示例程序，能编译通过说明环境没问题。

信令服务器搭建

这里要澄清一个常见的误解：WebRTC规范本身只定义了媒体传输的流程，连接建立的管理是另一回事，需要自己实现信令服务器。什么意思呢？就是两端得先通过某种方式商量好"咱们连一下"，交换一下基本信息，才能开始传输。这个"商量"的过程就是信令，而承载这个过程的就是信令服务器。

常见的信令方案有两种。第一种是用WebSocket，这个比较主流，实时性好，客户端支持也成熟。第二种是用HTTP轮询，虽然也能用，但延迟和资源消耗都不如WebSocket，适合对实时性要求不高的场景。

信令服务器要处理的事情其实不少：用户登录管理、房间创建、候选人信息交换、连接状态监控。我见过很多团队为了省事直接用现成的开源方案，比如janus-gateway或者mediasoup，这些框架把信令服务器和媒体服务器打包在一起了，部署起来比自己写省事很多。

如果你选择自己写信令服务器，消息格式建议用JSON，结构清晰、解析方便。核心消息类型大概有这几种：

消息类型	用途
join	用户加入房间
offer/answer	SDP交换，建立连接的核心消息
ice-candidate	ICE候选人信息，网络路径探测结果
leave	用户离开房间

NAT穿透配置

NAT穿透是WebRTC部署中最容易出问题的环节。我自己踩过很多坑，这里重点说说。

前面提到STUN和TURN，先说STUN。STUN服务器的作用是让客户端知道自己公网IP和端口。部署STUN服务推荐用coturn这个开源项目，它同时支持STUN和TURN，一套部署两个功能都用上了。

coturn的配置文件中，有几个参数要特别注意：listening-ip填你的服务器内网IP，external-ip填公网IP，realm建议设一个域名。验证码的部分，生产环境一定要改掉默认的，不然容易被扫描攻击。

TURN服务器的配置和STUN类似，但多了一个用户认证的环节。coturn支持两种认证方式：长期凭证和短期凭证。短期凭证适合临时会议场景，长期凭证适合长期运行的直播服务。认证的用户名和密码建议用强密码，不要用弱口令。

部署完成后，可以用在线的STUN测试工具验证一下。输入你的STUN服务器地址，如果返回了你服务器的公网IP和端口，说明STUN服务正常。

媒体服务器部署

如果只是两人通话，点对点直接连就行。但直播场景通常是一对多或者多对多，一个人开播可能几千上万人看，这时候就需要媒体服务器来转发数据了。

媒体服务器的选择主要有两种策略。第一种是MCU（多点控制单元），把所有参与方的数据汇集到服务器，混合后再转发给其他人。这种方式优点是客户端实现简单，缺点是服务器压力大，适合小规模场景。

第二种是SFU（选择性转发单元），服务器只负责转发数据，不做混合处理。哪个客户端要接收谁的数据，由客户端自己决定。这种方式对服务器带宽要求高，但扩展性好，大规模直播场景通常选这个。

开源的媒体服务器方案我接触过几个。mediasoup是SFU架构，Node.js开发，性能不错，文档也算清晰。janus-gateway功能更全面，除了SFU还有MCU模式，但配置起来稍微复杂一点。如果你用人家的实时音视频云服务，这些底层细节就不用操心了，直接调SDK就行。

编码与传输参数调优

WebRTC默认的编解码器选择也要了解一下。视频方面，VP8、VP9和H.264都支持，这三个里面H.264的兼容性最好，几乎所有设备都支持。VP9压缩效率更高，但老设备可能不支持。VP8夹在中间，兼容性不如H.264但比VP9好。

音频方面，Opus是首选。这个编码器很神奇，音乐和语音都能处理，压缩率高，网络抗丢包能力强。除非你有特殊需求，否则直接用Opus就行。

码率控制这块，我建议动态调整。网络好的时候推高清，网络差的时候自动降码率，保证流畅度。WebRTC本身有拥塞控制算法，但参数可能需要根据你的场景微调。比如直播场景和视频通话场景的最优参数可能不一样。

分辨率和帧率 тоже需要权衡。帧率越高画面越流畅，但带宽消耗也越大。我个人的经验是直播场景30帧够了，帧率太高不仅带宽压力大，对解码性能要求也高，低端机可能会卡顿。

常见问题排查

部署过程中遇到问题是很正常的，我把常见问题整理了一下。

连不上？首先检查网络连通性，用telnet或者nc命令测试STUN和TURN端口通不通。然后看看是不是防火墙的问题，很多云服务器有安全组规则，容易漏掉。然后检查证书配置，DTLS握手对证书要求挺严格的，证书过期或者不匹配都会导致连接失败。

有延迟但能连上：这种情况通常不是WebRTC本身的问题，可能是服务器带宽不够，或者编码参数设得太高。可以用Chrome的webrtc-internals工具看看具体的延迟和丢包数据，分析瓶颈在哪里。

只有某些用户连不上：这基本是NAT类型的问题。可以让用户访问一些在线的NAT类型检测工具，看看自己是什么类型的NAT。对称NAT的话，STUN基本没用，必须用TURN中转。

写在最后

WebRTC部署这件事，说到底还是要结合自己的业务场景来调。参数怎么设、架构怎么搭，都要根据实际需求来。我这篇文章只能给你一个基本的框架，真正的生产环境比这复杂得多。

如果你觉得自建WebRTC服务太耗费精力，用成熟的云服务确实是个选择。毕竟术业有专攻，专业团队在音视频领域的积累，不是看几篇文章就能赶上的。像我们声网在实时音视频这块深耕多年，底层网络优化、抗弱网能力、全球节点覆盖这些，都是实打实积累出来的。