メインコンテンツまでスキップ

5. SCTP over DTLS over UDP Considerations (SCTP在DTLS之上在UDP之上的考虑)

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

  • 使用TCP友好的拥塞控制 (TCP-friendly Congestion Control)。

  • 可修改的拥塞控制,用于与SRTP媒体流拥塞控制集成。

  • 支持多个单向流 (Unidirectional Streams),每个流提供其自己的有序消息传递概念。

  • 支持有序和无序消息传递。

  • 通过提供分片和重组来支持任意大的用户消息。

  • 支持PMTU发现。

  • 支持可靠或部分可靠的消息传输。

WebRTC数据通道机制不支持SCTP多宿主 (Multihoming)。SCTP层将简单地表现为在单宿主主机上运行,因为这是DTLS层 (面向连接的不可靠数据报服务) 所暴露的抽象。

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

  • 支持多个单向流。

  • 用户消息的有序和无序传递。

  • 用户消息的可靠和部分可靠传输。

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

SCTP在DTLS之上的封装,连同上面列出的SCTP特性,满足第4节中列出的所有需求。

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

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

图2: WebRTC协议层

选择此协议栈 (特别是与DTLS在SCTP之上 [RFC6083] 相比,以及与SCTP在UDP之上 [RFC6951] 结合) 的原因如下:

  • 支持任意大的用户消息的传输。

  • 与PeerConnection的SRTP媒体通道共享DTLS连接。

  • 为SCTP控制信息提供隐私。

参考图2所示的协议栈:

  • DTLS 1.0在UDP之上的使用在 [RFC4347] 中指定。

  • DTLS 1.2在UDP之上的使用在 [RFC6347] 中指定。

  • DTLS 1.3在UDP之上的使用在即将发布的文档 [TLS-DTLS13] 中指定。

  • SCTP在DTLS之上的使用在 [RFC8261] 中指定。

请注意,NAT会话穿越实用程序 (Session Traversal Utilities for NAT, STUN) [RFC5389] 与SRTP与DTLS的解复用如 [RFC5764] 的第5.1.2节所述完成,并且SCTP是DTLS的唯一有效载荷。

由于DTLS通常在用户应用程序空间中实现,因此SCTP协议栈也需要是用户应用程序空间协议栈。

ICE/UDP层可以在会话期间处理IP地址更改,而无需与DTLS和SCTP层交互。但是,当地址更改发生时,应该 (SHOULD) 通知SCTP。在这种情况下,SCTP应该 (SHOULD) 重新测试路径MTU并将拥塞状态重置为初始状态。在基于窗口的拥塞控制 (如 [RFC4960] 中指定的那样) 的情况下,这意味着将拥塞窗口和慢启动阈值设置为其初始值。

传入的ICMP或ICMPv6消息无法由SCTP层处理,因为无法识别相应的关联。因此,SCTP必须 (MUST) 支持在不依赖ICMP或ICMPv6的情况下执行路径MTU发现,如 [RFC4821] 中所述,通过使用 [RFC4820] 中指定的探测消息。IP层的初始路径MTU对于IPv4不应该 (SHOULD NOT) 超过1200字节,对于IPv6不应该 (SHOULD NOT) 超过1280字节。

通常,SCTP实现的下层接口应该适应IPv4和IPv6 (无连接) 或DTLS (面向连接) 之间的差异。

当使用图2所示的协议栈时,DTLS保护完整的SCTP数据包,因此它提供完整SCTP数据包的机密性,完整性和源认证。

SCTP在每个关联的基础上提供拥塞控制。这意味着单个SCTP关联内的所有SCTP流共享相同的拥塞窗口。未通过SCTP发送的流量不受SCTP拥塞控制的覆盖。使用与标准不同的拥塞控制可能会改善对并行SRTP媒体流的影响。

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

に最終更新