NVR 远程访问 P2P 技术方案全面调研

NVR（Network Video Recorder，网络视频录像机）系统如何让手机 App 在任意网络下远程查看监控画面？这是安防行业和智能家居的核心需求。本文系统调研了三个层面的方案：开源 NVR 项目（Frigate、go2rtc、Kerberos.io、Agent DVR 等）、商业安防厂商（海康、大华、萤石、Ubiquiti、Synology、Reolink 等）、以及第三方 P2P 平台与安全研究（TUTK Kalay、iLnkP2P/PPPP、GB/T 28181、关键 CVE）。

所有技术描述均基于官方文档、安全公告、学术论文的一手来源核实，关键统计数据标注出处。

核心概念速查

远程访问的四种模式

NVR 行业的远程访问方案可归纳为四种模式：

flowchart TD
    A["NVR 远程访问"] --> B["A. 闭源云中继<br/>Agent DVR · Shinobi<br/>海康 · 大华 · Reolink"]
    A --> C["B. 中心化 Hub 中继<br/>Kerberos.io<br/>（Hub 可自部署）"]
    A --> D["C. 纯 P2P + 自建中继<br/>go2rtc · Frigate<br/>UniFi Protect"]
    A --> E["D. 无远程方案<br/>ZoneMinder · MotionEye<br/>（纯用户自建）"]
    style B fill:#fce4ec,stroke:#f44336
    style C fill:#fff3e0,stroke:#FF9800
    style D fill:#e8f5e9,stroke:#4CAF50
    style E fill:#e3f2fd,stroke:#2196F3

• 模式 A（闭源云中继）：最接近消费级 NVR P2P——WebRTC 或私有协议 + 厂商自有的 STUN/TURN/relay，订阅制或厂商托管
• 模式 B（中心化 Hub 可自建）：Agent→Hub→浏览器，MQTT 信令 + WebRTC 流，Hub 闭源但可自部署
• 模式 C（纯 P2P + 自建中继）：标准 WebRTC + STUN 打洞，TURN 由用户自建 coturn 或用 Twilio 等公共服务
• 模式 D（无远程方案）：端口转发/反代/VPN，完全靠用户自行解决

开源 NVR 远程访问方案

go2rtc：事实标准底座

go2rtc 是一个零依赖的流媒体网关，支持几十种协议互转（RTSP↔WebRTC↔HLS↔HomeKit 等）。它是 Frigate、Home Assistant 等项目的底层流引擎，MIT 协议，本身可独立运行。

go2rtc 的 WebRTC 架构哲学清晰地阐述了所有决策点：

1. 几乎总是直连 P2P：浏览器到 go2rtc 之间是直接 peer-to-peer 连接
2. 中间件只做信令：Home Assistant、Frigate、Nginx、Nabu Casa 等只参与连接建立，不参与媒体数据传输
3. STUN 打洞：默认使用公共 STUN 服务器（如 stun.l.google.com:19302），通过 UDP 打洞绕过 NAT
4. Symmetric NAT 限制：约 20% 用户因对称型 NAT 无法 P2P，需要 TURN 中继
5. 支持自建 TURN：可配置 coturn 等自建 TURN 服务器

1
2
3
4
5
6

webrtc:
  ice_servers:
    - urls: [stun:stun1.l.google.com:19302]
    - urls: [turn:123.123.123.123:3478]
      username: your_user
      credential: your_pass

ICE Servers 是 WebRTC 中 STUN/TURN 服务器的配置列表。客户端按顺序尝试：先用 STUN 发现公网地址并打洞，失败则回退到 TURN 中继。

go2rtc 没有官方云中继，完全依赖标准 WebRTC 生态。它把 P2P 打洞能力以最纯粹的形式提供给上层应用——远程访问的"硬核"方式包括：静态公网 IP + 端口转发、动态公网 IP + stun:8555 自动探测、自建 TCP 隧道、自建 TURN 服务器。

Frigate：依赖 go2rtc 的现代 NVR

Frigate 是开源 AI 目标检测 NVR（MIT 协议），内置 go2rtc 实例作为流引擎。Frigate 本身不提供官方云中继或 P2P 打洞服务，远程访问完全依赖用户自建：

• Nabu Casa 云（Home Assistant 官方订阅服务）：作为反向代理 + WebRTC 信令代理
• 反向代理：Nginx Proxy Manager、Caddy、Cloudflare Tunnel
• VPN：Tailscale / WireGuard，需将 Tailscale IP 加入 WebRTC candidates
• 端口转发 + STUN：转发 8555 端口，配合 stun:8555 自动探测公网 IP

Frigate 没有官方手机 App，社区以第三方为主（如 Lumen for Frigate、ViewPane），这些 App 远程访问依赖用户自建的反向代理/VPN。

Kerberos.io：双通道架构典范

Kerberos.io 是架构最完整的中继模型参考。它采用三层架构：

flowchart TD
    A["Kerberos Agent<br/>（边缘·MIT 开源）"] -->|"低清：MQTT 快照"| B["Kerberos Hub<br/>（中心·闭源商业）"]
    A -->|"高清：WebRTC 流"| B
    B -->|"WSS 推送到浏览器"| C["用户浏览器"]
    B -->|"WebRTC 实时流"| C
    style A fill:#e3f2fd,stroke:#2196F3
    style B fill:#fff3e0,stroke:#FF9800
    style C fill:#e8f5e9,stroke:#4CAF50

关键设计——双通道流媒体：

• 低分辨率（JPEG 快照流）：Agent 通过 MQTT（TCP）把 JPEG 快照推送到 Hub，Hub 通过 WSS 显示给浏览器——信令友好、穿透性好
• 高分辨率（WebRTC）：Agent 通过 WebRTC 把全分辨率 + 高帧率流推送到 Hub，经 STUN + TURN 穿越 NAT——实时性好

Hub 依赖的开源组件包括 MongoDB、Kafka、Pion Turn/Coturn（TURN 服务器）、Vernemq（MQTT broker）。Hub 通过 Helm + Kubernetes 部署，可在用户自己的集群上自建（但 Hub 本身闭源且需要企业 license）。

Pion Turn 是 Go 语言实现的 TURN 服务器，Kerberos 官方选用。coturn 是 C 语言实现的老牌 TURN 服务器，功能更全面。

Agent DVR / Shinobi：闭源云中继

Agent DVR（iSpy 系列）主体闭源，仅插件 SDK 开源（GPL）。采用典型的"厂商云中继"模式：

“Agent DVR leverages WebRTC for setting up remote connections… all of which we provide through ispyconnect.com.”

• ispyconnect.com 闭源云中继：提供 SSL + STUN + TURN + relay 全套
• SignalR 信令：用于建立远程连接。SignalR 是 ASP.NET 的实时通信库，提供服务器到客户端的双向通信
• 订阅制：远程访问需要付费
• 内置 TURN 服务器：Agent DVR 自带 TURN server 并自动配置

Shinobi（GPL CE）的"P2P"实质是 Shinobi Systems 运营的闭源中继服务，需购买 Mobile License。技术文档未公开底层协议细节。

ZoneMinder / MotionEye：前云时代模式

ZoneMinder（GPL-2.0，2002 年立项）和 MotionEye（GPLv3）代表了最传统的 NVR 远程访问模式——没有任何云中继或 P2P：

• 端口转发 / 反向代理（Nginx + TLS）
• VPN（WireGuard / Tailscale）
• 没有 WebRTC 支持，主要通过 MJPEG / HLS / 单帧 JPEG

它们是"反面参照"——展示了无远程方案时用户的痛点。

开源项目横向对比

商业厂商的 P2P 方案

行业通用架构

所有主流厂商都遵循同一架构模式：

flowchart TD
    D["NVR/IPC 设备<br/>（内网）"] -->|"注册 UID"| S["厂商信令服务器<br/>（公网）"]
    C["手机 App<br/>（任意网络）"] -->|"查询 UID"| S
    S -.->|"交换 NAT 映射"| D
    S -.->|"交换 NAT 映射"| C
    D -->|"P2P 直连<br/>（打洞成功）"| C
    D -.->|"中继 fallback<br/>（打洞失败）"| R["厂商 Relay 服务器"]
    R -.-> C
    style S fill:#fff3e0,stroke:#FF9800
    style D fill:#e3f2fd,stroke:#2196F3
    style C fill:#e3f2fd,stroke:#2196F3
    style R fill:#fce4ec,stroke:#f44336

设备向厂商信令服务器注册 UID → App 通过 UID 查询设备 → 服务器交换双方的 NAT 映射信息 → 尝试 P2P 打洞 → 失败则经 Relay 中继。

海康威视 Hik-Connect

海康采用自研轻量级私有 P2P 协议（非标准 STUN/TURN/ICE），原因是为节省嵌入式 IPC 上的资源与授权费。协议特征包括固定端口预协商、缺乏动态 NAT 类型适配。

实测成功率（来自第三方技术分析）：家庭宽带约 95%，企业 Cisco ASA 防火墙后低于 30%，中国移动 4G 下穿透失败率高达 98%。

大华 DMSS / 乐橙云

大华采用 mediator server（中介服务器） 评估网络拓扑，自动选择连接方式：

1. 同局域网 → 直连
2. 单端 NAT → NAT 后一端主动出站连接
3. 双端 NAT → 双方出站连接到 Dahua relay server

P2P 连接使用随机 UDP 端口，必须放行所有出站 UDP。

萤石云 EZVIZ

海康旗下消费品牌。关键发现：官方文档明确说明 P2P 默认尝试，成功率仅约 20%。开放平台提供完整 SDK（Android/iOS/C++/Web），商业化按带宽/设备数分档。

Ubiquiti UniFi Protect：唯一的 WebRTC 标准派

Ubiquiti 是唯一完全采用标准 WebRTC + STUN/TURN 的厂商：

• 核心技术：标准 WebRTC
• STUN/TURN：使用 Twilio 公共服务（global.stun.twilio.com、global.turn.twilio.com）
• 不需要端口转发
• 对称型 NAT 时自动尝试 TURN relay
• 云服务（unifi.ui.com）仅提供信令/集中远程访问，不存储视频数据

Synology Surveillance Station：三步降级

群晖 QuickConnect 提供最清晰的官方架构描述——三步降级策略：

1. LAN/WAN 检测：客户端查询 NAS 注册信息，尝试直连
2. Hole Punching（打洞）：通过 QuickConnect Server 协助双方在各自 NAT 上打洞
3. Relay Service（中继）：最终 fallback，流量经 Synology Relay Server 中转

当直连失败时，用 WebRTC 实现 hole punching。URL 格式区分连接类型：[alias].direct.quickconnect.to（直连）vs [alias].[relay_id].quickconnect.to（中继）。

Reolink：逆向最完整的厂商

Reolink 的 P2P 协议被 Nozomi Networks 完整逆向。协议流程为：NVR 注册到 p2p.reolink.com:9999 → 服务器返回 reg/log/relay 端点 → 客户端查询 UID → 服务器返回设备公网映射 → 客户端直连 NVR。

加密使用 8 字节硬编码 key 的简单混淆（非真正加密），存在严重安全漏洞（CVE-2020-25169/25173）。

白牌方案：iLnkP2P / PPPP

这是理解消费级安防 P2P 生态的最重要研究。Paul Marrapese 的 DEF CON 28 演讲 “Abusing P2P to Hack 3 Million Cameras” 影响超过 360 万 IoT 设备（演讲数据），涉及 HiChip、TENVIS、SV3C、VStarcam 等品牌。

PPPP/CS2 协议（影响 5000 万+ 设备）的技术细节：UDP 端口 32100 为主通信端口，消息含 Magic 0xF1、消息类型（HELLO/PUNCH_TO/P2P_RDY/DEV_LGN 等）。加密使用 XOR 混淆（硬编码 key 如 BBAA、FFFF），非真正加密。

UID 验证码仅用 22 字母（排除 A/I/O/Q），约 500 万组合可暴力破解。

穿透成功率现实基线

不同方案的 P2P 穿透成功率差异巨大：

flowchart TD
    A["P2P 穿透成功率"] --> B["TUTK Kalay<br/>~92%"]
    A --> C["标准 WebRTC<br/>~80%"]
    A --> D["DCUtR 去中心化<br/>~70%"]
    A --> E["萤石 SDK<br/>~20%"]
    style B fill:#e8f5e9,stroke:#4CAF50
    style C fill:#e8f5e9,stroke:#4CAF50
    style D fill:#fff3e0,stroke:#FF9800
    style E fill:#fce4ec,stroke:#f44336

结论：对称型 NAT（CGNAT 常见）几乎必降级 relay。NVR 中继服务器容量规划需按约 30% 流量走 relay 估算。

CGNAT（运营商级 NAT） 是国内远程访问的核心痛点——>95% 宽带用户无固定公网 IP，在 CGNAT 之后。这使得 P2P 穿透成为刚需，而非可选方案。

安全教训：三大致命缺陷

P2P 协议的安全问题触目惊心。基于已披露的 CVE，总结三大致命缺陷：

flowchart TD
    A["P2P 协议<br/>三大致命缺陷"] --> B["硬编码密钥<br/>TUTK: Charlie...<br/>Reolink: 8字节key<br/>PPPP: BBAA/FFFF"]
    A --> C["明文传输<br/>无端到端加密<br/>音视频流可重建<br/>CVE-2020-25169"]
    A --> D["无认证/弱认证<br/>UID 可枚举<br/>可绕过防火墙<br/>CVE-2019-11219"]
    style A fill:#f44336,stroke:#c62828,color:#fff
    style B fill:#fce4ec,stroke:#f44336
    style C fill:#fce4ec,stroke:#f44336
    style D fill:#fce4ec,stroke:#f44336

关键 CVE 汇总

Paul Marrapese 的 iLnkP2P 研究（DEF CON 28, 2020）是该领域最权威的学术级安全研究。演讲标题 “Ain’t Nobody Got Time for NAT” 一针见血——厂商为了绕过 NAT 而牺牲了安全性。

安全红线

基于上述漏洞教训，自建系统必须遵守：

1. 禁止硬编码密钥——TUTK 的 "Charlie is the designer of P2P!!"、Reolink 的 8 字节 key 均已被破
2. 必须启用 AuthKey + DTLS/SRTP 端到端加密——避免 AES 误用（IV 当 key、ECB + 硬编码）
3. 云服务器指令必须验证来源真实性——防伪造（TUTK 0x1008 重定向攻击）
4. OTA/命令处理必须输入校验——防注入
5. 不得向云服务器上传本地用户明文密码——Reolink CVE-2020-25173 反例
6. UID 验证码熵必须足够——iLnkP2P 仅 ~500 万组合可暴力破解

第三方 P2P 平台与协议标准

TUTK Kalay：供应链 P2P SDK 之王

TUTK（达发科技） 2008 年成立于台北，核心平台 Kalay（即 IOTC 平台）是 IPC/NVR 领域最广泛的第三方 P2P 供应链 SDK。受影响的固件覆盖众多厂商：QNAP、LiLin 利凌、Tenvis、KGuard、小米、TRENDnet 等。

IOTC 平台核心信令流程：设备 IOTC_Initialize 连接 Master 服务器 → 设备 IOTC_Device_Login(UID) 登录（UID 是 20 字节唯一标识）→ 客户端 IOTC_Connect_ByUID(UID) 请求连接 → 服务器返回设备 IP/端口 → 双方 P2P 通讯。

安全演进：旧版（≤3.1.10）使用简单 XOR+ROL 混淆（密钥硬编码 "Charlie is the designer of P2P!!"）；新版引入 AuthKey（每设备随机密钥）+ DTLS 双层保护。

国内 P2P IoT 云平台

GB/T 28181：中国国标 SIP 信令

GB/T 28181-2022 是中国公共安全视频监控联网国标，基于 SIP（Session Initiation Protocol）。协议栈包括会话通道（SDP/SIP/MANSCDP）和媒体流通道（RTP/RTCP，H.264/SVAC）。

GB/T 28181 本质是中心化信令架构——设备向 SIP 服务器 REGISTER 注册，平台通过 INVITE 拉流，媒体经流媒体服务器转发。它不提供 P2P 穿透机制。但可与 WebRTC 互通：通过 SIP-over-WebSocket 代理转换，把 SIP 信令映射为 WebRTC 消息，再用 ICE/STUN/TURN 实现 P2P。

ONVIF：局域网标准化对接

ONVIF（Open Network Video Interface Forum）不涉及真正的 P2P 远程穿透，主要面向局域网内标准化对接。设备发现基于 WS-Discovery（UDP 多播 239.255.255.250:3702）。Profile S 定义 RTSP 实时音视频流是最广泛实现的 profile。远程访问仍需 VPN/端口映射/P2P 隧道。

WebRTC 用于监控：SFU vs P2P

flowchart TD
    A["WebRTC 监控架构"] --> B["纯 P2P（Mesh）<br/>1对1 可行<br/>多端观看：带宽/CPU 倍增"]
    A --> C["SFU<br/>服务器只转发不转码<br/>1路上行多路下行<br/>✅ 监控主流"]
    A --> D["MCU<br/>混流转码<br/>CPU 开销大<br/>监控少用"]
    style C fill:#e8f5e9,stroke:#4CAF50
    style B fill:#fff3e0,stroke:#FF9800
    style D fill:#fce4ec,stroke:#f44336

SFU（Selective Forwarding Unit） 是监控场景的主流方案——开源实现包括 Mediasoup、Janus、LiveKit、Pion。go2rtc 将 IPC 的 RTSP 流转为 WebRTC 输出，延迟可低至约 0.5 秒（vs RTSP/HLS 的 5-10 秒）。

用户侧：App 还是 Web？

前面几节都在讲"供给侧"——设备、厂商、平台如何实现 P2P。但 P2P 通路打通之后，最终用户怎么看到画面？这是远程访问闭环的"最后一公里"。

三种客户端形态

设备接入 P2P 之后，用户侧的观看入口主要有三种：原生 App、Web 浏览器、桌面客户端。

flowchart TD
    A["用户如何观看"] --> B["原生 App<br/>日常·报警"]
    A --> C["Web 浏览器<br/>临时·跨端"]
    A --> D["桌面客户端<br/>集中值守"]
    style A fill:#9C27B0,stroke:#6A1B9A,color:#fff
    style B fill:#e8f5e9,stroke:#4CAF50
    style C fill:#e3f2fd,stroke:#2196F3
    style D fill:#fff3e0,stroke:#FF9800

商业厂商几乎都自带原生 App，开源自建方案则主打 Web 端。两者并不互斥——主流方案通常同时提供 App 和 Web 两种入口。

• 原生 App 是消费级 P2P 的标配：扫码绑定 UID 后即可远程观看，APNs/FCM 推送报警，支持双向语音对讲、云台控制、消息中心
• Web 端是开源自建方案的核心：go2rtc / Frigate 通过浏览器原生 WebRTC 直接拉流，无需安装任何客户端，跨平台即开即看
• 桌面客户端面向专业值守：海康 iVMS-4200、大华 DSS Client，多屏轮巡、电子地图、集中录像管理

用户侧接入步骤

无论 App 还是 Web，用户侧的接入流程都可归纳为三步：

flowchart TD
    A["1. 获取客户端<br/>App / 浏览器"] --> B["2. 绑定设备<br/>扫码 UID / 登录"]
    B --> C["3. 观看与控制<br/>预览·对讲·回放"]
    style A fill:#fff3e0,stroke:#FF9800
    style B fill:#e3f2fd,stroke:#2196F3
    style C fill:#e8f5e9,stroke:#4CAF50

商业厂商路径（如海康 / 萤石 / Reolink）：用户在 App Store / Google Play 下载官方 App → 注册账号 → 扫描设备底部或包装上的二维码（即 UID）→ 设备自动绑定到账号 → 后续任意网络下打开 App 即可观看。整个过程对用户零配置，P2P 打洞 / 中继由厂商云端自动完成，用户感知不到 NAT 类型、STUN/TURN 这些细节。

开源自建路径（如 Frigate / go2rtc）：用户需自行解决"客户端如何触达自建服务"——要么配置反向代理（Nginx Proxy Manager / Caddy / Cloudflare Tunnel）把 Web 端安全地暴露到公网，要么用 VPN（Tailscale / WireGuard）打通网络，要么订阅 Nabu Casa 这类托管信令服务。绑定完成后，浏览器打开域名即看，无需安装 App。

智能家居生态集成

现代 NVR 的用户侧早已不限于 App 和 Web——监控画面被进一步集成进更大的智能家居生态：

• Apple HomeKit：go2rtc / Home Assistant 可把 RTSP 流桥接为 HomeKit 摄像头，Siri / 家庭 App 直接观看，支持 Apple TV / Apple Watch
• Google Assistant / Alexa：主流厂商云（萤石 / Reolink / Ubiquiti）官方对接，语音调阅画面、报警广播
• 米家 / 涂鸦 Tuya：国产 IoT 平台整合，监控与门锁、传感器、灯光联动
• Home Assistant：开源中枢，统一管理不同品牌的摄像头，把厂商私有的 P2P 重新拉回本地控制

多端观看：纯 P2P 够用吗？

P2P 是点对点——1 路上行对应 1 路下行。当多人同时观看同一台 IPC 时，要重新评估架构：

flowchart TD
    A["多端观看场景"] --> B["1-2 路<br/>家庭场景"]
    A --> C["3+ 路<br/>商业/共享"]
    B --> D["纯 P2P 可行<br/>带宽线性增长"]
    C --> E["需 SFU 汇聚<br/>1 上行多下行"]
    style A fill:#9C27B0,stroke:#6A1B9A,color:#fff
    style B fill:#e8f5e9,stroke:#4CAF50
    style C fill:#fff3e0,stroke:#FF9800
    style D fill:#e8f5e9,stroke:#4CAF50
    style E fill:#e3f2fd,stroke:#2196F3

• 家庭场景（1-2 路同时观看）：纯 P2P 完全够用，设备侧带宽压力可控
• 商业 / 共享场景（3+ 路同时观看）：IPC 上行带宽会成为瓶颈（多数 IPC 只有 1 路编码能力），必须引入 SFU（go2rtc / Mediasoup / Janus）做 1 路上行、多路下发，否则画面会卡顿或断流

这也是商业厂商云中继普遍采用 SFU 架构的原因——并非只为 P2P 打洞失败兜底，更是为多端观看做流量汇聚。

工程启示

架构设计启示

1. 信令层中心化是行业主流——TUTK Master、Hik-Connect、萤石/乐橙云均采用"设备→公网信令服务器→客户端"的中心化信令，P2P 仅作用于媒体层
2. 典型架构三要素：UID 标识设备 → 信令服务器中介 → 打洞失败时 relay 中转
3. Kerberos Hub 双通道架构值得学习：低清用 MQTT+WSS（信令友好），高清用 WebRTC+STUN/TURN（实时性好）
4. go2rtc 是最值得深读的代码库：它的 WebRTC 模块文档完整阐述了所有决策点，MIT 协议可直接借鉴

协议选型建议

中继容量规划

对称型 NAT（CGNAT 常见）几乎必降级 relay。中继服务器容量规划需按约 30% 流量走 relay 估算。EZVIZ 官方承认 P2P 成功率仅约 20%，go2rtc 文档指出约 20% 用户因 Symmetric NAT 无法 P2P——这些数据高度一致。

参考来源

开源项目

安全研究与 CVE

学术论文

商业厂商文档