如何选择服务端 WebRTC 实现

WebRTC 最初是为浏览器而生的，但如今许多 WebRTC 连接都跑在服务端程序里，例如 SFU、网关、云游戏、录制，或者加入通话的 AI 代理。没有浏览器来负责连接，这些程序就各自需要一套 WebRTC 实现，通常是以库的形式内置在服务中。Google 的 libwebrtc 是使用最广泛的实现，但它是为浏览器和原生客户端应用设计的。它的 API 围绕单个用户的采集、编码和渲染展开，把这种实现放进一个需要在多个对端之间路由或桥接媒体的服务里，就显得很别扭。因此，构建这类服务的开发者往往会选择专为服务端设计的库，比如 Pion（Go）、aiortc（Python）、webrtc-rs（Rust），以及 GStreamer 的 webrtcbin。

在这些替代实现之间做选择，代价很高，而且很难反悔。一个库的局限很少在两个对端的演示中暴露出来，它们往往会在路由、录制和扩容都依赖它之后才显现；到那个阶段再绕开这些限制，通常意味着重写。

选择主要取决于你的服务在哪一层处理媒体。SFU 会原封不动地转发已编码的 RTP 包。语音 AI 代理或计算机视觉管线则需要解码后的音频和视频帧。本文说明在什么情况下这个决策才真正落到你头上，比较主流的服务端 WebRTC 库，并把它们对应到各自适合的工作负载。

什么时候这个决策才归你来做

“实现”和“媒体服务器”不是一回事。把这两者分开是第一步。

1. WebRTC 实现指的是协议栈：ICE（Interactive Connectivity Establishment）负责连通性，DTLS-SRTP 负责加密传输，SCTP 负责数据通道，RTP/RTCP 负责媒体；正是这套协议栈让一个进程能够作为对端参与连接。
2. 媒体服务器（SFU 或 MCU）则是一个服务端应用，它使用某个 WebRTC 实现，在多个对端之间路由媒体。

可以把“实现”理解为发动机零件，把“媒体服务器”理解为组装好的整车，本文讲的是零件。

这个区分引出一条界定项目范围的统一规则：几乎所有服务端工作负载都已经有一个更高层的、现成或托管的方案；只有当你的需求超出这一层时，才会下探到实现本身。不过，这一“更高层”在不同工作负载下表现形式并不相同：

• 语音 AI 已有托管框架和平台，例如 Pipecat、LiveKit Agents 或 SignalWire Agents。当其中一个够用时，它会让实现层变得不可见，而这本身就是一项优点。
• SFU 和群组媒体 已有开源媒体服务器，例如 LiveKit、mediasoup 或 Janus。
• 电话网关 已有 SIP 插件。

有些是“已经建好”而不是“托管”，但逻辑完全一样：更高层的方案会把复杂度抽象掉，直到它确实做不到你需要的功能为止。

当出现超出该方案的需求时，比如成本、数据驻留、延迟控制、自定义媒体处理、媒体来源不是采集设备（渲染管线、机器人摄像头）、非常规部署拓扑，或者高层方案给不了的合规控制，项目就变成了一个嵌入你自己 Go、Rust 或 Python 服务里的对端。

不同工作负载的差别在于你多快撞到这个天花板。托管型语音 AI 平台覆盖面很广，所以大多数团队会长期停留在这一层。云游戏、WHIP/WHEP 流媒体的边缘场景、机器人、非设备来源的媒体，以及严格的自托管需求，可能很快撞到天花板——对它们来说，“用哪个实现”是第一天就要回答的问题，对其他人来说则是“哪天再说”的问题。

主流的服务端 WebRTC 库

有三套实现是从底层开始就为服务端而建的，各自有不同的强项。

Pion（Go）

一套纯 Go 的协议栈，没有任何 C 依赖，这意味着静态二进制和轻松的交叉编译。它模块化、成熟、部署广泛，并且让你能以一等公民的方式访问原始 RTP——这正是媒体路由成败所系的能力。Go 语言的 SFU 项目 LiveKit 就构建在它之上。

aiortc（Python）

一套基于 asyncio 的协议栈，是在 Python 代码里得到一个 WebRTC 对端的最短路径。当你服务端的真正工作是机器学习模型、计算机视觉管线或 AI 胶水代码时，aiortc 能把一个对端直接放在它旁边。

webrtc-rs（Rust）

可以说是 Pion 的设计在 Rust 里的重建：模块化的协议 crate、Sans-IO 内核（协议逻辑与 I/O 解耦），以及不依赖垃圾回收的内存安全。它比其他两者更年轻、演进很快，因此适合那些既要性能与安全、又不介意采用较新技术栈的团队。

GStreamer 的 webrtcbin

webrtcbin 是第四个值得放在同一场讨论里的实现，但它来自另一个方向。它实现了 W3C PeerConnection API 的大部分内容（offer、answer、SDP 协商、媒体与数据通道），所以它是一个真正意义上的服务端对端，而不只是一个桥接器。

它最大的不同在于集成模型。Pion、aiortc 和 webrtc-rs 是你主动调用的库：你持有一个 peer-connection 对象，并用自己的控制流去驱动它。而 webrtcbin 是 GStreamer 媒体管线中的一个元素。你在它周围搭起一张元素图，响应它的协商信号，让框架掌握数据流。

当服务端的工作是一条媒体管线（采集、变换、编码，尤其是在使用硬件加速插件时）而不是转发数据包时，它就是自然之选。它同时也是四者中最重的依赖：你引入的是整个 GStreamer，而不只是一个库。

libwebrtc 与 libdatachannel

另外还有两套 WebRTC 实现值得一提。

• libwebrtc 是客户端与互操作的基准。如果你在浏览器里，那你已经在用它了。
• libdatachannel 是一套轻量的 C/C++ 协议栈，适合只想要最小体积、而非整套 libwebrtc 的团队，因此天然适合资源受限的硬件。

语言和成熟度当然重要，但它们很少是决定性因素。有一项能力，比上面任何一项都更能可靠地预示你的工期。

决定性的问题：媒体在你需要的那一层

选择实现时，最具预测力的问题是：你的工作负载在哪一层接触媒体，而该库把这一层交给你时有多干净？ 媒体经过一个对端时处于两个层次：线路上的已编码 RTP 包，以及编解码器运行之后得到的已解码帧（原始 PCM 音频或原始视频帧）。不同工作负载需要不同层次，而最典型的两个例子正好指向相反方向。

SFU 需要已编码的 RTP

SFU 需要的是编码层。它的全部工作就是从某个对端读入一个 RTP 包，再原封不动地写给其他对端——不解码、不重编码。在 Pion 里，这就是一个有两处调用的循环：读包、写包。出站轨道直接接受预编码的 RTP，因此整个过程中根本不会实例化编码器。

// 其他对端订阅的出站轨道。"StaticRTP" 直接接受
// 预编码的 RTP 包 —— 不会实例化任何编解码器。
localTrack, _ := webrtc.NewTrackLocalStaticRTP(
    webrtc.RTPCodecCapability{MimeType: webrtc.MimeTypeVP8}, "video", "pion",
)

// 当发布者的轨道到达时，原样转发它的包。
peerConnection.OnTrack(func(remote *webrtc.TrackRemote, _ *webrtc.RTPReceiver) {
    for {
        pkt, _, err := remote.ReadRTP() // 原始 RTP 进
        if err != nil {
            return
        }
        if err := localTrack.WriteRTP(pkt); err != nil { // 原始 RTP 出
            return
        }
    }
})

AI 与视觉管线需要已解码的帧

解码侧的工作负载需要的正好相反：把每一帧作为原始数据取出来，对它做点什么，然后再把一帧发布回去。语音 AI 代理就是其中一例：入站音频变成 PCM 交给语音识别，语音合成再产生 PCM 送出去。计算机视觉管线是另一例，任何在进程内变换媒体的步骤也都属于这一类。aiortc 直接表达了这个模式：你从轨道上 await 一个已解码帧，把它转成数组，做变换，再通过一条负责产出帧的轨道送出去。整个模式只需几行。

from aiortc import MediaStreamTrack
from av import VideoFrame

class TransformTrack(MediaStreamTrack):
    kind = "video"

    def __init__(self, track):
        super().__init__()
        self.track = track  # 入站的远端轨道

    async def recv(self):
        frame = await self.track.recv()         # 解码后的帧进
        img = frame.to_ndarray(format="bgr24")  # 拿到可处理的原始像素
        img = transform(img)                     # 你的 CV / ML / 叠加步骤
        new_frame = VideoFrame.from_ndarray(img, format="bgr24")  # 帧再送出去
        new_frame.pts = frame.pts                # 保持时间戳
        new_frame.time_base = frame.time_base
        return new_frame

这就是拥有一个服务端对端的全部理念：收到一帧，处理它，发出一帧。这段代码改编自 aiortc 的服务端示例，其中的 VideoTransformTrack 做的几乎就是这件事。那个 transform 调用代表你真正的视觉或机器学习步骤，而生产版本还要在这之上加上信令、TURN 和模型管线。

webrtcbin 从管线一侧回答同一个问题。它不要一个“取一帧再返回一帧”的循环，而是让你声明媒体图，然后让数据自己流动：一个源和编码器向对端供流，或者对端的解码输出接入你的处理元素。媒体处理变成了“接线”，而不是控制流。对于包路由而言这是个负担：在对端之间转发 RTP 意味着要在多个 webrtcbin 实例之间连 pad，而不是一个两处调用的循环，它会跟你较劲。但当媒体本身就是一条管线时——嵌入式摄像头编码后送到浏览器、转码网关、任何依赖 GStreamer 硬件加速元素库的场景，它恰好正确。层次问题仍然是决定因素，只是答案用“图”来表达。

其他所有工作负载都落在同一根轴上。录制和网关需要原始访问，有时还需要解码。云游戏服务器站在编码侧，但帧来自渲染管线而不是摄像头。机器人或 IoT 项目可能几乎不碰媒体，主要活在数据通道上。问题永远是哪一层、多干净，而不只是“它能不能转发一个包”。aiortc 在已解码帧上是一等公民，Pion 和 webrtc-rs 则同时暴露已编码 RTP 和已解码样本，所以它们都直接给你一个可用的层次。一旦你知道了自己的层次，工作负载到实现的映射就自然浮现。

哪套 WebRTC 库适合你的工作负载

对上述任何一种工作负载，都请先考虑托管平台或现成的媒体服务器。当你需求超出那一层、需要为自己的对端挑选库时，再用下面这张表。

负载测试也属于这份清单。负载测试工具会创建大量模拟对端来压测你的媒体基础设施，因此它本身也是一次服务端 WebRTC 构建。

选定你的服务端 WebRTC 实现

一句话规则：先确定你的服务端要对媒体做什么，由此固定你需要的层次，再让这个层次收窄实现的选择范围。围绕这条规则的取舍还包括：语言与你团队运维习惯的匹配度、团队内部技能储备，以及像 Pion 这样久经实战的栈与像 webrtc-rs 这样快速演进的新栈之间的成熟度差距，这些都会影响最终答案。

作者：Hector Zelaya
原文：https://webrtc.ventures/2026/10/how-to-choose-a-server-side-webrtc-implementation/