构建浏览器多人游戏：REST信令对比WebSocket信令的WebRTC劣势

针对你想用 REST API 替代 WebSocket 做 WebRTC 信令的方案，相比长连接的 WebSocket，主要存在以下几个核心劣势：

• 实时性缺失，信令传输延迟高
  WebRTC 信令不止 SDP Offer/Answer 这一步，还需要实时交换分批生成的 ICE 候选。REST 是请求-响应模式，客户端无法实时获取服务端收到的新信令（比如对方的 ICE 候选、重新协商请求），要么只能通过频繁轮询拉取，增加额外延迟；要么服务端只能一次性返回所有信令，这会错过后续生成的 ICE 候选，导致连接建立成功率下降、质量变差。而 WebSocket 是全双工长连接，服务端可以实时推送所有信令消息，ICE 候选一生成就能立刻传给对方，大幅缩短连接建立时间，这对低延迟要求的游戏至关重要。

• 连接状态感知被动，游戏体验受影响
  WebSocket 长连接让服务端能实时感知客户端的在线状态，一旦对方断开或者网络异常，服务端可以立刻通知其他客户端。但 REST 是无状态的，客户端只能通过主动请求确认对方状态，这会导致游戏中无法及时处理队友离线、连接中断等情况，比如玩家已经掉线，本地还显示在线，直到下次轮询才发现，严重影响游戏体验。

• 信令流程复杂度飙升
  WebRTC 不是一次性建立连接就完事，网络切换、设备变更时需要重新协商信令（比如重新发送 SDP、ICE 候选）。用 REST 的话，每次信令交互都要发起 POST 请求，还要处理多次请求的时序问题（比如先收 Answer 还是先收 ICE 候选），容易出现信令丢失、顺序错乱的情况。而 WebSocket 可以按顺序实时推送所有信令消息，流程更清晰，出错概率更低。

• 额外的资源开销
  REST 每次请求都要携带 HTTP 头部信息，即使开启 Keep-Alive，多次请求的开销也远大于 WebSocket 长连接的单次握手开销。对于需要频繁重新协商信令的游戏场景，这种开销会累积，增加客户端和服务端的带宽、CPU 负担。

• 无法主动触发信令交互
  当服务端需要主动通知客户端某些信令事件（比如匹配到新玩家、强制重新协商）时，REST 没有主动推送能力，只能等客户端发起请求。这会导致游戏中的关键信令延迟，比如匹配成功后不能立刻开始连接建立，必须等客户端下次请求才能拿到对方的 SDP，拖慢游戏启动速度。

内容的提问来源于stack exchange，提问作者user3207838