自研 P2P 服务架构设计
前言
在物联网和实时通信领域，P2P（点对点）连接是实现低延迟、高质量音视频传输的关键技术。然而，很多团队在起步阶段会选择依赖第三方 WebRTC 服务，随着业务规模扩大，逐渐会遇到以下痛点：
- 问题排查困难：第三方服务黑盒化，日志和错误信息不透明
- 生态闭塞：功能扩展和定制化受限
- 成本不可控：按流量计费，用户规模增长后成本激增
在我们的物联网平台上，摄像头设备需要与 App 建立实时视频连接。经过技术调研和成本分析，我们决定自研 P2P 服务。本文将分享完整的架构设计思路，包括 STUN、TURN、信令服务的实现方案。
一、技术背景与目标
1.1 为什么要自研？
| 对比维度 | 第三方服务 | 自研服务 |
|---|---|---|
| 成本 | 按流量计费，规模大后成本高 | 固定服务器成本，边际成本低 |
| 可控性 | 黑盒，难以定制 | 完全可控，按需扩展 |
| 问题排查 | 日志不透明 | 全链路可追踪 |
| 数据安全 | 数据经过第三方 | 数据自主可控 |
| 延迟优化 | 受限于服务商节点 | 可自建边缘节点 |
1.2 业务目标
基于实际需求，我们设定了以下目标：
- P2P 连接成功率：> 95%
- 端到端延迟：< 500ms
- 并发连接数：支持 10 万级
- 高可用性：99.9% SLA
1.3 技术选型
经过调研，我们选择了以下技术栈：
| 组件 | 选型 | 理由 |
|---|---|---|
| 编程语言 | Go | 高并发支持好，适合网络服务 |
| WebRTC 库 | Pion | 纯 Go 实现，无 CGO 依赖 |
| 信令协议 | MQTT | 已有基础设施，设备端友好 |
| 状态存储 | Redis | 高性能，支持 TTL 和 Pub/Sub |
| 部署方式 | Kubernetes | 容器化，支持横向扩展 |
二、整体架构设计
2.1 架构概览
┌─────────────────────────────────────────────────────────────────────┐
│ 客户端层 │
│ ┌─────────────┐ ┌─────────────┐ │
│ │ App 端 │ │ 设备端 │ │
│ └──────┬──────┘ └──────┬──────┘ │
└─────────┼────────────────────────────────────────────┼──────────────┘
│ │
│ MQTT 信令 MQTT 信令 │
▼ ▼
┌─────────────────────────────────────────────────────────────────────┐
│ 信令服务层 │
│ ┌─────────────────────────────────────────────────────────────┐ │
│ │ MQTT Broker (EMQ X) │ │
│ │ Topic: p2p/signal/{device_id}/{app_id} │ │
│ └─────────────────────────────────────────────────────────────┘ │
└─────────────────────────────────────────────────────────────────────┘
│ │
│ ICE 候选交换 │
▼ ▼
┌─────────────────────────────────────────────────────────────────────┐
│ NAT 穿透服务层 │
│ ┌─────────────────┐ ┌─────────────────┐ │
│ │ STUN 服务器 │ │ TURN 服务器 │ │
│ │ (NAT 探测) │ │ (中继转发) │ │
│ └─────────────────┘ └─────────────────┘ │
└─────────────────────────────────────────────────────────────────────┘
│ │
│ P2P 直连 / TURN 中继 │
▼ ▼
┌─────────────────────────────────────────────────────────────────────┐
│ 媒体传输层 │
│ RTP/RTCP 音视频流（加密传输） │
└─────────────────────────────────────────────────────────────────────┘
2.2 核心组件
| 组件 | 职责 | 关键指标 |
|---|---|---|
| STUN 服务器 | NAT 类型探测，获取公网 IP/端口 | 1000 QPS/节点 |
| TURN 服务器 | NAT 穿透失败时提供中继 | 5000 并发会话/节点 |
| 信令服务器 | 协调连接信息交换 | 10 万并发连接 |
| 状态管理 | 会话状态存储与同步 | Redis 集群 |
2.3 高可用设计
- 分区部署：按地理区域（亚洲、欧洲、北美）部署，减少跨区延迟
- 负载均衡：基于 GeoIP 自动路由到最近节点
- 无状态设计：服务节点无状态，状态存储在 Redis
- 自动扩缩容：Kubernetes HPA 根据负载动态调整
三、STUN 服务器设计
3.1 STUN 的作用
STUN（Session Traversal Utilities for NAT）帮助客户端发现自己的公网 IP 和端口，是 NAT 穿透的第一步。
┌─────────────┐ ┌─────────────┐
│ 客户端 │ Binding Request │ STUN │
│ (内网) │ ─────────────────> │ 服务器 │
│ │ │ (公网) │
│ │ Binding Response │ │
│ 获取公网 │ <───────────────── │ 返回客户端 │
│ IP:Port │ (公网 IP:Port) │ 的公网地址 │
└─────────────┘ └─────────────┘
3.2 基于 Pion 实现
package main
import (
"net"
"github.com/pion/stun"
"github.com/pion/turn/v2"
)
func main() {
// 创建 UDP 监听
udpListener, err := net.ListenPacket("udp4", "0.0.0.0:3478")
if err != nil {
panic(err)
}
// 创建 STUN 服务器
server, err := turn.NewServer(turn.ServerConfig{
Realm: "p2p.example.com",
// 认证处理
AuthHandler: func(username string, realm string, srcAddr net.Addr) ([]byte, bool) {
// 从 Redis 验证 Token
return validateToken(username)
},
// 监听器
PacketConnConfigs: []turn.PacketConnConfig{
{
PacketConn: udpListener,
RelayAddressGenerator: &turn.RelayAddressGeneratorStatic{
RelayAddress: net.ParseIP("公网IP"),
Address: "0.0.0.0",
},
},
},
})
if err != nil {
panic(err)
}
// 启动服务
select {}
}
3.3 关键设计点
- 分区管理：基于 GeoIP 自动分配最近的 STUN 节点
- Session 绑定：将 STUN 请求与 sessionId 关联，便于追踪
- 鉴权（可选）：支持 Token 验证，防止滥用
- 性能优化：
- 连接池管理 UDP socket
- 缓存 GeoIP 查询结果
- 使用 goroutine 池处理并发
四、TURN 服务器设计
4.1 TURN 的作用
当 NAT 类型为对称 NAT 或防火墙限制严格时，STUN 无法穿透，需要 TURN 服务器作为中继。
┌─────────────┐ ┌─────────────┐ ┌─────────────┐
│ 客户端 A │ │ TURN │ │ 客户端 B │
│ (对称NAT) │ ═══════════════════│ 服务器 │═══════════════════ │ (对称NAT) │
│ │ 媒体流中继转发 │ (公网) │ 媒体流中继转发 │ │
└─────────────┘ └─────────────┘ └─────────────┘
4.2 关键设计点
- 强制鉴权：防止资源滥用
- 带宽限制：每个会话限制带宽（如 2Mbps）
- 一致性哈希：同一会话始终路由到同一节点
- 资源回收：定期清理过期 Allocation
4.3 性能优化
// 零拷贝转发优化
func relayPacket(src, dst *net.UDPConn, buf []byte) {
// 使用 sendmmsg 批量发送，减少系统调用
// 避免内存拷贝，直接转发
}
// 带宽限制
type RateLimiter struct {
bucket *rate.Limiter
maxBitrate int64
}
func (r *RateLimiter) Allow(size int) bool {
return r.bucket.AllowN(time.Now(), size)
}
五、信令服务设计
5.1 信令的作用
信令服务负责在 P2P 连接建立前，交换双方的连接信息（SDP、ICE 候选）。
5.2 基于 MQTT 的信令协议
我们选择复用已有的 MQTT 基础设施，设计了轻量级的信令协议：
{
"type": "offer | answer | candidate | bye | keepalive | error",
"sessionId": "550e8400-e29b-41d4-a716-446655440000",
"from": "device_xxx",
"to": "app_yyy",
"payload": {
"sdp": "v=0\r\no=- 123456789...",
"candidate": "candidate:1 1 UDP 2130706431..."
},
"timestamp": 1750929836097
}
5.3 消息类型说明
| 类型 | 描述 | 使用场景 |
|---|---|---|
offer |
发起方的 SDP | 发起 P2P 连接 |
answer |
接收方的 SDP | 响应连接请求 |
candidate |
ICE 候选地址 | NAT 穿透 |
bye |
主动断开连接 | 结束会话 |
keepalive |
心跳保活 | 维持会话 |
error |
错误通知 | 异常处理 |
5.4 Topic 设计
# App 订阅自己的信令通道
p2p/signal/app/{app_id}
# 设备订阅自己的信令通道
p2p/signal/device/{device_sn}
# App 发送消息给设备
p2p/signal/device/{device_sn}
# 设备发送消息给 App
p2p/signal/app/{app_id}
5.5 连接建立流程
App MQTT Broker Device
│ │ │
│ 1. 创建 Session │ │
│ ─────────────────────────────>│ │
│ (获取 sessionId, STUN/TURN 地址) │
│ │ │
│ 2. 发送 Offer │ │
│ ─────────────────────────────>│ 转发 Offer │
│ │ ──────────────────────────────>│
│ │ │
│ │ 3. 返回 Answer │
│ 收到 Answer │<───────────────────────────────│
│<───────────────────────────────│ │
│ │ │
│ 4. 交换 ICE Candidate（双向） │ │
│<═══════════════════════════════│═══════════════════════════════>│
│ │ │
│ 5. P2P 连接建立，媒体直接传输 │ │
│<════════════════════════════════════════════════════════════════>│
六、状态管理设计
6.1 状态存储结构
使用 Redis 存储会话状态：
// Key: session:{sessionId}
{
"sessionId": "550e8400-e29b-41d4-a716-446655440000",
"deviceId": "device_xxx",
"appId": "app_yyy",
"status": "connecting | connected | closed",
"stunServer": "stun:region1.example.com:3478",
"turnAllocation": "allocation_id_789",
"createdAt": 1698765432,
"updatedAt": 1698765432,
"ttl": 86400
}
6.2 状态同步
// 使用 Redis Pub/Sub 通知状态变更
func notifyStateChange(sessionId string, newState string) {
channel := fmt.Sprintf("session_updates:%s", sessionId)
redis.Publish(channel, newState)
}
// 订阅状态变更
func subscribeStateChanges(sessionId string) <-chan string {
channel := fmt.Sprintf("session_updates:%s", sessionId)
return redis.Subscribe(channel)
}
6.3 清理机制
- TTL 自动过期：会话默认 24 小时过期
- 定时扫描：每 5 分钟扫描异常会话，释放资源
- 资源回收：释放 TURN Allocation，更新带宽分配
七、监控指标设计
7.1 核心指标
| 指标 | 描述 | 目标值 |
|---|---|---|
| NAT 穿透成功率 | STUN 直连成功 / 总连接 | > 60-80% |
| TURN 中继比例 | TURN 会话 / 总连接 | < 20% |
| 端到端延迟 | P2P 连接延迟 P95 | < 500ms |
| 信令延迟 | 信令交换延迟 P95 | < 50ms |
| 并发连接数 | 活跃 P2P 会话数 | 10 万 |
| 连接成功率 | 成功建立 / 总尝试 | > 95% |
7.2 Prometheus 指标示例
var (
stunRequestsTotal = prometheus.NewCounterVec(
prometheus.CounterOpts{
Name: "stun_requests_total",
Help: "Total STUN requests",
},
[]string{"status", "region"},
)
turnSessionsActive = prometheus.NewGauge(
prometheus.GaugeOpts{
Name: "turn_sessions_active",
Help: "Active TURN sessions",
},
)
p2pLatencySeconds = prometheus.NewHistogram(
prometheus.HistogramOpts{
Name: "p2p_latency_seconds",
Help: "P2P connection latency",
Buckets: []float64{0.1, 0.25, 0.5, 1, 2.5, 5},
},
)
)
7.3 告警规则
groups:
- name: p2p-alerts
rules:
- alert: HighTurnRatio
expr: turn_sessions_total / p2p_connections_total > 0.3
for: 5m
labels:
severity: warning
annotations:
summary: "TURN 中继比例过高"
- alert: LowConnectionSuccessRate
expr: p2p_connection_success_total / p2p_connection_attempts_total < 0.9
for: 5m
labels:
severity: critical
annotations:
summary: "P2P 连接成功率低于 90%"
八、实践经验与踩坑
8.1 NAT 类型分布
在实际部署中，我们统计了不同 NAT 类型的分布：
| NAT 类型 | 比例 | 穿透难度 |
|---|---|---|
| Full Cone | 15% | 容易 |
| Restricted Cone | 25% | 中等 |
| Port Restricted | 35% | 中等 |
| Symmetric | 25% | 困难，需要 TURN |
结论：约 75% 的连接可以通过 STUN 直连，25% 需要 TURN 中继。
8.2 常见问题
ICE 候选收集超时
- 原因：STUN 服务器不可达或网络延迟高
- 解决：增加超时时间，部署多区域 STUN 节点
TURN 带宽耗尽
- 原因：未设置带宽限制，单用户占用过多资源
- 解决：每会话限制带宽（如 2Mbps）
信令消息丢失
- 原因：MQTT QoS 0 不保证送达
- 解决：关键消息使用 QoS 1，应用层重试
8.3 性能优化要点
- 减少 GC 压力：使用对象池复用内存
- 批量处理：Redis Pipeline 批量操作
- 异步化：信令消息异步分发
- 边缘部署：STUN/TURN 服务器部署在边缘节点
九、总结
自研 P2P 服务是一个复杂但值得的投入。通过这个项目，我们获得了以下收益：
- 成本下降：流量成本降低 70%+
- 问题可追踪：全链路日志，问题定位从小时级降到分钟级
- 功能可扩展：可以根据业务需求灵活调整
- 数据可控：用户数据不经过第三方
关键技术选型：
- Pion 是优秀的 Go WebRTC 库，适合自研
- MQTT 作为信令协议，复用已有基础设施
- Redis 存储会话状态，支持高并发
核心设计原则：
- 无状态服务，状态外置到 Redis
- 分区部署，就近接入
- 完善的监控告警，快速发现问题
希望这篇文章能帮助正在考虑自研 P2P 服务的团队。如有问题，欢迎交流！
相关文章：
参考资料：
更新时间：2025年12月24日