MiroTalk P2P
更新于 2026-09-18 17:55:45
它是什么
MiroTalk P2P 是一个开源的自托管 WebRTC 视频会议平台，媒体流走真正的 P2P（mesh）直连，服务器只承担「初次建链」的信令角色。浏览器打开房间链接即用，不需要装客户端，没有时长限制，房间数不限。
一句话理解它的架构：Node 信令服务只负责交换 SDP / ICE 候选，握手完成后音视频不再经过服务器。这正是「中央服务器依赖很小、只用于建立初期连接」这一类需求的典型实现。
它到底是「多大的 P2P」
这点要说得非常清楚，因为它决定了能用在哪：
| 组件 | 作用 | 服务器压力 |
|---|---|---|
| Node 信令服务（Socket.IO） | 交换 SDP / ICE，通知谁进了房间 | 极小，只转发信令，不碰媒体流 |
| STUN | 帮双方发现自己的公网地址 | 可用公共 STUN |
| TURN（可选，仅必要时） | 对称 NAT / 严格防火墙下无法直连时中转 | 这里会中转流量，此时不再是纯 P2P |
| 媒体流 | 每个参与者直接发给其他所有人（mesh） | 服务器 0 负载 |
关键结论：
- 信令服务挂掉，已经建立的连接会继续工作，但新加入的人无法建链——这就是 P2P 架构的实际收益。
- 4 人以内体验很好；参与者越多，每人的上行带宽 = (N-1) 路视频，8 人以上 CPU 和带宽会明显吃紧。超过这个规模就该换 SFU 版（同作者的 MiroTalk SFU）。
- 想完全绕过自建服务器，可以直接用官方 demo
p2p.mirotalk.com起个房间试试；想完全自持，docker-compose up几分钟就能跑起来。
功能
- 🎥 视频最高 8K @ 60fps、屏幕共享、录制、画中画
- 💬 支持 Markdown 与 emoji 的聊天、协作白板、文件传输
- 🤖 ChatGPT（OpenAI）集成、语音识别
- 🔒 OIDC 认证、Host Protection（主持人保护模式）、JWT 凭据、房间密码、P2P 加密
- 🔌 完整 REST API、Slack 与 Mattermost 集成、iframe / widget 嵌入、133 种语言
- 🧩 全量源码、可白标（rebrand）
部署（真的很快）
源码跑：
git clone https://github.com/miroslavpejic85/mirotalk.git
cd mirotalk
cp .env.template .env
cp app/src/config.template.js app/src/config.js
npm install
npm start
访问 http://localhost:3000 即可。
Docker Compose：
git clone https://github.com/miroslavpejic85/mirotalk.git && cd mirotalk
cp .env.template .env
cp app/src/config.template.js app/src/config.js
cp docker-compose.template.yml docker-compose.yml
docker-compose pull && docker-compose up -d
官方镜像在 Docker Hub：mirotalk/p2p。Cloudron 应用商店也有一键部署。
上手前必须知道的几个坑
- 生产必须 HTTPS。浏览器
getUserMedia（摄像头/麦克风）只在 secure context 下可用，http://IP:3000除 localhost 外拿不到设备权限。要么配域名 + 证书，要么用文档里的 Ngrok 方案。 - NAT 穿透失败就得有 TURN。严格的对称 NAT、部分企业防火墙、跨国链路上直连会失败，必须部署 coturn，否则表现为「能看到对方名字但一直没有画面」。这时候流量走 TURN 中转，就不再是纯 P2P 了，选型时要接受这个降级。
- 房间链接本身就是入口。公开实例上房间名可猜（
/join/xxx），务必要开房间密码、JWT 凭据或 Host Protection，不然容易被陌生人闯进会议室。 - 不要真的指望它开 10 人以上的会。mesh 架构的物理限制，人多了全员卡；这种场景请直接上 SFU 版本。
- 移动端能用但不优雅。手机浏览器可以入会，体验不如原生 App，别把它当 Zoom 的移动端替代。
适用场景
- 小团队站会 / 内部讨论（3-5 人，需求是「私有 + 快 + 不用注册」）
- 1v1 客户咨询、远程支持、问诊、面试——同作者的 C2C 版本更专注 1v1
- 嵌入到自己的系统里：iframe / widget 直接嵌进工单系统、CRM、内网门户
- 白板讨论 / 临时会议间：房间数不限，用完即弃，不产生任何持久数据
- 不想让会议内容经过任何第三方 SaaS 的团队：自建 + P2P，媒体流不落服务器
同类方案横向对比
| 需求 | 推荐 |
|---|---|
| 浏览器开会、只依赖信令服务器、上手最快 | MiroTalk P2P（本项目） |
| 连信令都不想自建，打开网页就用（公共 tracker 做信令） | Chitchatter（Trystero + WebTorrent/Nostr 等信道，serverless、无账号、临时房间） |
| 想要真正去中心化、DHT、无服务器、有桌面/移动客户端 | Jami（OpenDHT，bootstrap 节点只用于首次入网，支持群组会议） |
| 超过 8 人、要大规模稳定 | MiroTalk SFU（mediasoup）或 Jitsi Meet（SFU 模式） |
| Go 技术栈、mesh + SFU 双模自托管 | peer-calls |
选择逻辑很简单：人数少 → mesh（P2P 直连，隐私与延迟最优）；人数多 → SFU（必须有服务器转发）。MiroTalk 系列把这两种形态拆成了两个仓库，选之前先确认自己的会议规模。
上手评价
- 部署体验是同类里最顺的之一：6 条命令或一个 compose 文件，没有复杂的信令/TURN 编排，
npm start完就能开房。 - 功能密度超出预期：白板、录制、文件传输、REST API、嵌入、133 语言——很多商用方案把这些拆成付费项。
- 代码结构对二开友好：前端配置集中在
app/src/config.js，服务端在.env，改品牌、改 UI、加自定义按钮都不难。 - 需要注意维护模式：作者同时维护 P2P / SFU / C2C / WEB / CME / ADM 多个仓库，迭代分散在多个产品线上，单仓库的 issue 响应不一定快（当前 open issues 显示为 0，issue 关闭较积极）。
- AGPLv3 是硬约束：改了要开源（含通过网页提供服务的情形）；要闭源商用得去 CodeCanyon 买授权。企业接入前务必让法务过一遍。
二开与集成建议
- 先决定许可路线：内部自用 / 开源项目 → 直接 AGPLv3；要做闭源商业产品 → 买授权或考虑 Apache-2.0 的 peer-calls。
- 接 REST API 做预约与鉴权：用 API 生成带 JWT 的房间链接，和自己系统的账号体系打通，避免裸房间名。
- iframe / widget 嵌入：适合把视频能力加到已有系统里，比自研 WebRTC 前端省几个月。
- 部署 coturn 并只对需要的用户开放：TURN 是带宽消耗方，按需分发凭据，别让公网随便刷。
- 容器化 + 反向代理：Nginx/Caddy 终结 TLS，信令服务放内网；
config.js里按需关闭不需要的功能（录制、ChatGPT 等）以减少攻击面。 - 白标改造：
docs.mirotalk.com有专门的 Rebranding 文档，改 logo/名称/主题都在配置层，别去改核心逻辑以免后续合并困难。
一句话总结
想在浏览器里开一场「媒体流不经过任何服务器」的会，MiroTalk P2P 是当下最省事的选择：信令服务只负责牵线搭桥，建链之后音视频就是端到端直连，房间无限制、部署只要六条命令；代价是 mesh 架构决定它适合 4-8 人以内，再大就该换 SFU——以及别忘了 AGPLv3 的许可义务。