【ZeroRange WebRTC】HTTPS 与 WSS 在 WebRTC 场景中的应用

HTTPS 与 WSS 在 WebRTC 场景中的应用

本文以工程视角解释 HTTPS（HTTP over TLS）与 WSS（WebSocket over TLS）的差异、协议栈与典型用途，并结合 WebRTC 架构说明两者在实际项目中的分工与选择策略。

---

一、概念与协议栈

• HTTPS：基于 HTTP/1.1 或 HTTP/2 的请求/响应模型，承载于 TLS 之上，具备服务端与可选客户端认证、会话加密、请求级方法与头部（GET/POST/PUT 等）。适合“管理/查询/配置”类接口与一次性任务。
• WSS：WebSocket 的安全版本，建立在 HTTPS/TLS 之上，通过握手从 HTTP/1.1 升级为双向的消息通道（无请求/响应的限制），适合“实时、双向、低延迟”的信令或数据消息。

HTTP 协议要点（帮助理解）

• 请求/响应结构：请求行（方法、路径、版本）+ 头部 + 可选正文；服务端返回状态行（版本、状态码）+ 头部 + 可选正文。
• 方法与语义：GET（读取）、POST（提交）、PUT/PATCH（更新）、DELETE（删除）等；幂等性与缓存策略由方法与头部共同约束。
• 状态码分层：2xx 成功、3xx 重定向、4xx 客户端错误、5xx 服务端错误；结合 Location、Retry-After 等头部进行控制。
• 连接复用与版本：
  • HTTP/1.1 支持 keep-alive，但同一连接上请求串行化；
  • HTTP/2 基于二进制帧与多路复用、头部压缩（HPACK），吞吐与并发更优；
  • HTTP/3 基于 QUIC（UDP），进一步降低队头阻塞，改善弱网下体验（但 WebSocket 在 h3 的支持需依赖扩展与实现）。
• 安全与握手：TLS 握手（证书校验、SNI、ALPN 选择 h2/h1.1），可选双向认证（客户端证书）；完成后 HTTP 报文在 TLS 信道内传输。
• 典型适用：资源查询/配置、审计与计费、短事务与一次性任务、与第三方生态的接口对接。

WebSocket 协议要点（帮助理解）

• 升级握手：在 HTTP/1.1 上发起 Upgrade: websocket 与 Connection: Upgrade，携带 Sec-WebSocket-Key/Version；服务端返回 101 Switching Protocols 并给出 Sec-WebSocket-Accept。
• 帧与控制：文本帧（opcode 0x1）、二进制帧（0x2）、关闭（0x8）、Ping（0x9）/Pong（0xA）；客户端到服务端帧必须掩码，服务端到客户端不掩码。
• 分片与重组：一个消息可被分片为多帧发送，接收端需重组；消息边界天然保留，适合事件流。
• 心跳与存活：通过 Ping/Pong 保活与延迟测量；需要结合负载均衡/代理的闲置超时策略发送心跳以维持连接。
• 子协议与协商：Sec-WebSocket-Protocol 可协商子协议（如 JSON-RPC、自定义信令格式）；应用层需定义消息结构与错误语义。
• 典型适用：会话内双向事件、低延迟信令与通知、持续状态同步；不适合承载严格事务审计与大对象传输（需拆分或改用 HTTPS）。

简化握手示例（HTTP/1.1 → WebSocket）

请求：

GET /signaling HTTP/1.1
Host: example.com
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Key: dGhlIHNhbXBsZSBub25jZQ==
Sec-WebSocket-Version: 13
Sec-WebSocket-Protocol: kvs-signaling

响应：

HTTP/1.1 101 Switching Protocols
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Accept: s3pPLMBiTxaQ9kYGzzhZRbK+xOo=
Sec-WebSocket-Protocol: kvs-signaling

---

二、在 WebRTC 中的角色分工

• HTTPS（REST 管理面）：
  • 通常用于 DescribeChannel、GetChannelEndpoint、GetIceServerConfig、Create/DeleteChannel 等服务 API 调用；
  • 具备 SigV4 等请求级认证、审计与限流能力；
  • 适合“查询/创建/获取配置”的非实时操作。
• WSS（信令实时面）：
  • 建立到信令服务的持久连接；
  • 实时交换 Offer/Answer、ICE Candidates、控制消息；
  • 面向低延迟与双向通信，承载长会话的状态与事件驱动。

---

三、为何不“全部使用 WebSocket”

• 服务端接口契合度：REST API 已定义管理面（Describe/GetEndpoint/GetIceConfig 等），无对应的 WSS 指令；强行全部用 WSS 需自建协议与鉴权，复杂且与生态不兼容。
• 认证与审计：HTTPS 请求级签名与请求 ID 有利于审计/限流；WSS 的会话级鉴权难以提供同等粒度的审计与配额管理。
• 端点发现的鸡生蛋问题：需要先通过 REST 获取应连接的 WSS 端点与区域信息。
• 并发与事件循环：将控制操作塞入 WSS 增加事件循环竞争与会话复杂度，降低稳定性。

---

四、协议选择策略（决策树）

1. 是否实时、双向消息？
   • 是 → WSS 信令；
   • 否 → HTTPS（REST）。
2. 是否涉及管理/查询/审计敏感操作？
   • 是 → HTTPS（SigV4、审计、配额）；
   • 否 → 仍优先 WSS，尤其是会话内事件。
3. 是否需与浏览器/客户端保持长会话？
   • 是 → WSS；
   • 否 → HTTPS。

---

五、实践建议

• 保持分层：管理面走 HTTPS，实时信令走 WSS，媒体走 SRTP/DTLS（UDP 优先，必要时 TURN/TCP/TLS）。
• 鉴权与合规：REST 接口用请求级签名；WSS 建链后基于令牌与会话控制，确保日志与审计。
• 稳定性与可达性：在企业网络中 WSS 比 REST 更易被策略限制；准备 TURN/TLS 以保证信令/媒体可达性。
• 成本与延迟的权衡：仅在必要时走中继/长会话；及时释放不再使用的连接与资源。

---