实时音视频与远程协作：WebRTC、SFU、TURN 与 QoS
AR 眼镜在很多场景里天然适合“远程协作”：专家远程指导、现场巡检、培训与质检。但只要开始做 RTC（Real-Time Communication），你会迅速遇到一堆“看起来像网络问题，实际是系统工程”的坑：弱网抖动、NAT 穿透、延迟与卡顿、录制与回放、权限与审计。
核心判断：AR 场景的 RTC 目标不是“画质极致”，而是“可用性极致”：在复杂网络与复杂设备状态下，尽量不断线、尽量能听清、尽量能看懂。
1. WebRTC 的三件套：信令、媒体、ICE
WebRTC 经常被误解为“浏览器自带的视频通话”。实际它是一套标准化组件，至少包括：
- 信令（Signaling）：交换 offer/answer 与 ICE candidates，本身不规定用什么协议（HTTP/WebSocket 都行）。
- 媒体传输：SRTP（加密的 RTP），承载音视频数据。
- ICE/STUN/TURN：解决 NAT 穿透与网络路径选择。
理解这三层，就能解释很多现象：比如“信令连上了但没画面”，往往是 ICE 路径选不到可用的媒体通路；而“有画面但卡”，往往是拥塞控制与编码策略问题。
2. SFU 为什么几乎是默认选项？
多人通话时，P2P 网状连接很快就会崩：每个端要同时给 N 个人发上行，带宽和功耗都会爆。SFU（Selective Forwarding Unit）把媒体集中到服务器转发，端上只要发一份上行，服务器做转发与订阅管理。
- 优点：更适合多人；更易做录制与监管；更易做带宽自适应（Simulcast/SVC）。
- 代价：需要部署与运维；对服务器带宽与成本有要求；需要处理跨地域延迟。
AR 场景下，SFU 还带来一个好处：可以把“复杂网络环境的成功率”放到服务端统一兜底，而不是指望每个端都能 P2P 成功。
3. TURN 不是“锦上添花”，而是“能不能用”的保险丝
如果用户在企业网络、校园网、酒店 Wi-Fi、甚至运营商 CGNAT 环境里，直连经常失败。TURN 会把媒体中继到服务器，成功率显著提升，但代价是：
- 带宽成本上升（所有媒体要过 TURN）。
- 延迟略上升（绕路）。
工程上更稳的做法是：默认尝试直连，直连失败再走 TURN，并且用短期凭据（临时用户名/密码）降低泄露风险。
4. QoS 不是一个指标，而是一整套“降级策略”
在弱网下“不卡”几乎不可能，能做的是“卡得有意义”。常见 QoS 策略：
- 音频优先：先保音频连续，再保视频清晰。
- 动态码率：根据丢包/RTT/抖动调整编码码率与帧率。
- 分辨率阶梯：不要在 1080p 和 240p 之间来回跳，建立可预测的档位。
- 关键帧控制：在网络恢复时快速打关键帧，让画面尽快“恢复可看”。
对 AR 眼镜而言，QoS 还要考虑功耗：编码器持续满负载会导致发热与降频，反过来又会拖垮体验。
5. 录制与回放：把实时流变成“可复盘的证据”
AR 的远程协作往往需要留痕：培训回放、质检审计、病例讨论等。工程上建议把录制作为一等能力：
- 录制由服务端完成更可控（画面布局、权限、存储）。
- 对“标注/事件”做时间轴对齐，回放时才能复现现场决策过程。
- 把对象存储（S3/MinIO）与签名 URL 结合，做到“可访问但可控”。
一句话总结：AR 场景的 RTC 成功，不在于某个参数最强，而在于：穿透成功率高、弱网可降级、录制可回放、权限可审计。