跳到主要内容

5. SCTP over DTLS over UDP 考量

在 WebRTC 上下文中, SCTP 的重要特性如下:

  • 使用 TCP 友好的拥塞控制.
  • 可修改的拥塞控制, 以便与 SRTP 媒体流拥塞控制集成.
  • 支持多个单向流, 每个流都提供自己的有序消息递送概念.
  • 支持有序和乱序消息递送.
  • 通过提供分片和重组来支持任意大的用户消息.
  • 支持 PMTU 发现.
  • 支持可靠或部分可靠的消息传输.

WebRTC 数据通道机制不支持 SCTP 多宿主. SCTP 层会像运行在单宿主主机上一样工作, 因为这正是 DTLS 层 (面向连接的不可靠数据报服务) 暴露的抽象.

[RFC8261] 中定义的 SCTP over DTLS 封装提供机密性, 源认证和完整性保护传输. 将 DTLS over UDP 与 Interactive Connectivity Establishment (ICE) [RFC8445] 结合使用, 可在基于 IPv4 和 IPv6 的网络中实现中间盒穿越. [RFC4960] 中指定的 SCTP 必须与 [RFC3758] 中定义的扩展结合使用, 并为浏览器之间传输非媒体数据提供以下特性:

  • 支持多个单向流.
  • 用户消息的有序和无序递送.
  • 用户消息的可靠和部分可靠传输.

每个 SCTP 用户消息都包含 Payload Protocol Identifier (PPID), 该标识符在发送侧由上层传递给 SCTP, 并在接收侧提供给上层. PPID 可用于在单个 SCTP 关联上复用/解复用多个上层. 在 WebRTC 上下文中, PPID 用于区分 UTF-8 编码用户数据, 二进制编码用户数据, 以及 [RFC8832] 中定义的 Data Channel Establishment Protocol (DCEP). 请注意, JavaScript API 无法访问 PPID.

SCTP over DTLS 封装以及上面列出的 SCTP 特性满足第 4 节列出的所有要求.

WebRTC 的协议分层如图 2 所示.

              +------+------+------+
              | DCEP | UTF-8|Binary|
              |      | Data | Data |
              +------+------+------+
              |        SCTP        |
+----------------------------------+
| STUN | SRTP |        DTLS        |
+----------------------------------+
|                ICE               |
+----------------------------------+
| UDP1 | UDP2 | UDP3 | ...         |
+----------------------------------+

图 2: WebRTC 协议层

选择此栈 (特别是相对于 DTLS over SCTP [RFC6083], 并结合 SCTP over UDP [RFC6951] 来看) 的原因如下:

  • 支持传输任意大的用户消息;
  • 与 PeerConnection 的 SRTP 媒体通道共享 DTLS 连接; 并且
  • 为 SCTP 控制信息提供隐私保护.

参照图 2 所示协议栈:

  • DTLS 1.0 over UDP 的使用在 [RFC4347] 中规定;
  • DTLS 1.2 over UDP 的使用在 [RFC6347] 中规定;
  • DTLS 1.3 over UDP 的使用在即将发布的文档 [TLS-DTLS13] 中规定; 并且
  • DTLS 之上的 SCTP 使用在 [RFC8261] 中规定.

请注意, Session Traversal Utilities for NAT (STUN) [RFC5389], SRTP 和 DTLS 之间的解复用按 [RFC5764] 第 5.1.2 节所述完成, 且 SCTP 是 DTLS 的唯一载荷.

由于 DTLS 通常在用户应用空间中实现, SCTP 栈也需要是用户应用空间栈.

ICE/UDP 层可以在会话期间处理 IP 地址变化, 无需与 DTLS 和 SCTP 层交互. 但是, 当地址发生变化时, 应当通知 SCTP. 在这种情况下, SCTP 应当重新测试 Path MTU, 并将拥塞状态重置为初始状态. 对于 [RFC4960] 中规定的基于窗口的拥塞控制, 这意味着将拥塞窗口和慢启动阈值设置为其初始值.

传入的 ICMP 或 ICMPv6 消息无法由 SCTP 层处理, 因为没有办法识别对应的关联. 因此, SCTP 必须支持按 [RFC4821] 所规定, 使用 [RFC4820] 中指定的探测消息, 在不依赖 ICMP 或 ICMPv6 的情况下执行 Path MTU 发现. IP 层的初始 Path MTU 对 IPv4 不应超过 1200 字节, 对 IPv6 不应超过 1280 字节.

一般而言, SCTP 实现的下层接口应进行适配, 以处理 IPv4 和 IPv6 (无连接) 与 DTLS (面向连接) 之间的差异.

使用图 2 所示协议栈时, DTLS 保护完整的 SCTP 分组, 因而为完整 SCTP 分组提供机密性, 完整性和源认证.

SCTP 以每个关联为单位提供拥塞控制. 这意味着单个 SCTP 关联内的所有 SCTP 流共享同一拥塞窗口. 未通过 SCTP 发送的流量不受 SCTP 拥塞控制覆盖. 使用不同于标准拥塞控制的机制可能改善其对并行 SRTP 媒体流的影响.

SCTP 使用与 TCP 和 UDP 相同的端口号概念. 因此, 一个 SCTP 关联使用两个端口号, 每个 SCTP 端点各一个.

最后于 更新