English version: P2P vs Relay-Based Remote Desktop: A Technical Deep Dive
当你在远程桌面工具上点"连接"那一刻，底层只有两种走法：要么直连远端机器，要么绕一圈厂商的服务器。P2P 与服务器中转这一个选择，决定了你关心的一切：延迟、隐私、成本、可靠性。
这是一篇工程视角的文章。如果你想先看大方向上的"为什么 P2P"，请先读《P2P 远程桌面完全指南》。
中转架构实际是怎么跑的
┌────────┐ ┌─────────────────┐ ┌─────────┐
│ 客户端 │ ◄───► │ 厂商中转服务器 │ ◄───► │ 远端机器│
│ (你) │ │ (数据中心) │ │ │
└────────┘ └─────────────────┘ └─────────┘
TLS TLS
每一帧画面、每一次按键都是：先加密到中转，在中转解密，再次加密发到对端。除非工具实现了真正的端到端加密（老牌产品很少有），否则中转能看到明文。
往返时间 = 客户端→中转 + 中转→远端。如果中转跟其中一端不在同一个大陆，你要为这段地理绕路付两次代价。
P2P 架构实际是怎么跑的
┌────────┐ ┌─────────┐
│ 客户端 │ ◄──── 直连，端到端加密 ──────► │ 远端机器│
└────┬───┘ └────┬────┘
│ │
└────► 信令服务器 ◄────────────────────────┘
（只在建立会话时用）
一台小小的信令服务器（常见做法是 WebSocket 上跑 WebRTC）帮两端交换：
- 网络地址（来自 ICE 的候选地址）
- 会话的共享密钥
- 需要时分配的 STUN/TURN 凭据
握手完成后，信令服务器就退出数据通路。画面帧走 UDP（DTLS-SRTP 之类），在两端之间直接传输。
网络层上的真实差异
| 维度 | 中转 | P2P |
|---|---|---|
| 延迟 | 客户端→中转 + 中转→远端 |
客户端→远端（公网上单跳） |
| 带宽成本 | 厂商按会话付费，转嫁给你 | 你付自己 ISP 的钱，流量不过厂商 |
| 明文暴露面 | 没 E2EE 时中转看得到 | 只有两端能看到明文 |
| 故障影响范围 | 中转挂 = 所有客户挂 | 信令挂 = 起不了新会话，已有会话继续 |
| 审计轨迹 | 厂商可记录全部内容 | 厂商只能记录元数据（谁连了谁、什么时候） |
| 建立速度 | 更快 — 不需要 NAT 穿透 | 稍慢 — NAT 穿透要 1-3 秒 |
中转赢的场景
说句公道话，中转不是永远更差：
- 两端都在对称 NAT 后面且不允许 UDP。P2P 会失败，中转直接能用。
- 需要流量审查的合规环境。某些受监管的场景要求所有远程会话经过一个集中检查点。
- 一次性的临时支持。客户不懂技术，你要 5 秒内连上 —— 中转更快的建立速度有价值。
正经的 P2P 工具永远都带中转回退来兜底第一种情况。关键差异是：中转是例外，不是默认。
现实里的混合模式
生产环境里，每一款靠谱的远程桌面产品都是混合架构：
- 先尝试 P2P 直连
- 两端能通过 ICE 候选地址互相找到，就保持直连
- 找不到，回退到加密中转（TURN）
真正有趣的问题是 多少比例的会话能保持直连。公网上的 WebRTC 部署数据显示，好的 ICE 实现能做到 80-90% 直连率。低于 70% 说明 NAT 穿透实现得弱 —— 用起来你能感受到。
评估时该测的指标
挑工具时，让厂商给你：
- 会话 RTT 的中位数和 p95 —— 在你能控制的公网路径上测
- 直连率（P2P 直连的会话占比）
- TURN 回退率（走中转的会话占比）
- 首帧时间（握手 + 流媒体起播）
报不出这些数字的厂商，说明他们自己也没量过。
接下来读什么
- 背景：《P2P 远程桌面完全指南》
- 产品对比：EasyRemote vs TeamViewer vs AnyDesk
- 延迟为什么重要：远程工作中延迟到底意味着什么
- P2P 失败时：NAT 穿透失败？P2P 连接问题排查