3. 传输和中间盒规范

本节定义 WebRTC 端点必须支持的传输协议和中间盒处理功能.

3.1. 系统提供的接口

此处使用的协议规范假定 WebRTC 协议实现可以使用以下协议:

UDP [RFC0768]: 这是所描述的大多数协议元素假定使用的协议.

TCP [RFC0793]: 该协议用于 HTTP/WebSockets, 以及 TURN/TLS 和 ICE-TCP.

这两个协议都假定支持 IPv4 和 IPv6.

对于 UDP, 本规范假定能够按数据包设置所打开套接字的区分服务代码点 (Differentiated Services Code Point, DSCP), 以便在复用多种媒体类型时实现 [RFC8837] 中描述的优先级处理 (见本文档第 4.2 节). 本规范不假定 DSCP 会被遵循, 并且假定 DSCP 可能被清零或更改, 因为这是本地配置问题.

不提供这些接口访问能力的平台将无法支持符合规范的 WebRTC 端点.

本规范不假定实现能够访问 ICMP 或原始 IP.

以下协议可以使用, 但它们可以由 WebRTC 端点实现, 因此不被定义为 "系统提供的接口":

• TURN: NAT 中继穿越 (Traversal Using Relays Around NAT) [RFC8656]
• STUN: NAT 会话穿越工具 (Session Traversal Utilities for NAT) [RFC5389]
• ICE: 交互式连接建立 (Interactive Connectivity Establishment) [RFC8445]
• TLS: 传输层安全 (Transport Layer Security) [RFC8446]
• DTLS: 数据报传输层安全 (Datagram Transport Layer Security) [RFC6347]

3.2. 使用 IPv4 和 IPv6 的能力

在 WebRTC 浏览器中运行的 Web 应用程序 MUST 能够在 IPv4 和 IPv6 可用时使用二者. 也就是说, 当两个对等方之间只有 IPv4 连接能力, 或者只有 IPv6 连接能力时, 在 WebRTC 浏览器中运行的应用程序 MUST 能够通信.

使用 TURN 时, 如果 TURN 服务器与对等方或对等方的 TURN 服务器之间具有 IPv4 或 IPv6 连接能力, 则 MUST 支持相应类型的候选. SHOULD 支持面向 ICE 的 "Happy Eyeballs" 规范 [RFC8421].

3.3. 临时 IPv6 地址的使用

IPv6 默认地址选择规范 [RFC6724] 指定, 临时地址 [RFC4941] 应优先于永久地址. 这改变了 [RFC3484] 中指定的规则. 对于选择单个地址的应用程序, 这通常通过 [RFC5014] 中指定的 IPV6_PREFER_SRC_TMP 偏好标志实现. 然而, 此规则旨在确保优先使用增强隐私的地址而不是静态地址, 但在 ICE 中无法产生正确效果, 因为 ICE 会收集所有地址并因此将其暴露给应用程序. 因此, 改为应用以下规则:

当 WebRTC 端点收集其主机上的所有 IPv6 地址时, 如果同时存在同一作用域内的未弃用临时地址和永久地址, 则 WebRTC 端点 SHOULD 在向应用程序暴露地址或在 ICE 中使用地址之前丢弃永久地址. 这与 [RFC6724] 中描述的默认策略一致.

如果部分但并非全部临时 IPv6 地址被标记为已弃用, WebRTC 端点 SHOULD 丢弃这些已弃用地址, 除非它们正被进行中的连接使用. 在 ICE 重启中, 当前正在使用的已弃用地址 MAY 保留.

3.4. 中间盒相关功能

处理中间盒的主要机制是 ICE. ICE 适合处理 NAT 盒和防火墙, 这些设备接受来自内部的流量, 但仅在外部流量是对内部流量的响应时才接受来自外部的流量 (简单有状态防火墙).

MUST 支持 ICE [RFC8445]. 实现 MUST 是完整 ICE 实现, 而不是 ICE-Lite. 在部署适当时, 完整 ICE 实现允许与 ICE 和 ICE-Lite 实现互操作.

为了处理双方都位于执行端点相关映射的 NAT 类型之后的情况 (定义见 [RFC5128] 第 2.4 节), MUST 支持 TURN [RFC8656].

WebRTC 浏览器 MUST 支持从浏览器配置和应用程序两处配置 STUN 与 TURN 服务器.

注意, 围绕 STUN 和 TURN 服务器发现与管理还存在其他工作, 包括用于服务器发现的 [RFC8155] 以及 [RETURN].

为了处理阻塞所有 UDP 流量的防火墙, MUST 支持在 WebRTC 端点和 TURN 服务器之间使用 TCP 的 TURN 模式, 并且 MUST 支持在 WebRTC 端点和 TURN 服务器之间使用基于 TCP 的 TLS 的 TURN 模式. 详情见 [RFC8656] 第 3.1 节.

为了处理一方位于 IPv4 网络而另一方位于 IPv6 网络的情况, MUST 支持用于 IPv6 的 TURN 扩展.

MAY 支持 TURN TCP 候选 [RFC6062], 其中从 WebRTC 端点的 TURN 服务器到对等方的连接是 TCP 连接.

但是, 这类候选不被认为能提供任何显著收益, 原因如下.

首先, 只有在两个对等方都必须使用 TCP 建立连接的情况下, TURN TCP 候选的使用才相关.

其次, 该用例可以通过另一种方式支持: 双方使用基于 TCP 的 TURN 建立 UDP 中继候选, 以连接到各自的中继服务器.

第三, 在 WebRTC 端点的 TURN 服务器与对等方之间使用 TCP 可能比使用 UDP 导致更多性能问题, 例如队首阻塞.

MUST 支持 ICE-TCP 候选 [RFC6544]. 这可以允许应用程序在不使用 TURN 服务器的情况下, 跨越阻塞 UDP 的防火墙与具有公网 IP 地址的对等方通信.

如果使用 TCP 连接, 则所有数据包 MUST 使用符合 [RFC4571] 的 RTP 成帧. 这包括 RTP 数据包, 用于承载数据通道的 DTLS 数据包, 以及 STUN 连接性检查数据包.

MUST 支持 [RFC5389] 第 11 节中指定的 ALTERNATE-SERVER 机制 (300 Try Alternate).

WebRTC 端点 MAY 支持通过 HTTP 代理访问互联网. 如果支持, 则 MUST 包含 [RFC7639] 中指定的 "ALPN" 头部, 并且 MUST 同时支持 [RFC7231] 第 4.3.6 节和 [RFC7235] 中描述的代理认证.

3.5. 实现的传输协议

媒体传输使用安全 RTP. 所用 RTP 配置文件的细节在 "Media Transport and Use of RTP in WebRTC" [RFC8834] 中描述, 该文档要求使用熔断器 (circuit breaker) [RFC8083] 和拥塞控制 (更多指导见 [RFC8836]).

密钥交换 MUST 使用 DTLS-SRTP 完成, 如 [RFC8827] 所述.

对于通过 WebRTC 数据通道 [RFC8831] 进行的数据传输, WebRTC 端点 MUST 支持在 ICE 上承载 DTLS, 并在 DTLS 上承载 SCTP. 这种封装在 [RFC8261] 中指定. 会话描述协议 (Session Description Protocol, SDP) 中对此传输的协商在 [RFC8841] 中定义. MUST 支持用于 I-DATA 的 SCTP 扩展 [RFC8260].

[RFC8832] 中描述的 WebRTC 数据通道建立协议 MUST 被支持.

注意: [RFC5764] 中定义的 DTLS-SRTP 与 [RFC8445] 中定义的 ICE 之间的交互在 [RFC8842] 第 6 节中描述. 该规范的效果是, 与单个组件关联的所有 ICE 候选对都是同一个 DTLS 关联的一部分. 因此, 即使存在多个有效候选对, 也只会有一次 DTLS 握手.

WebRTC 端点 MUST 支持在同一端口对上复用 DTLS 和 RTP, 如 DTLS-SRTP 规范 [RFC5764] 第 5.1.2 节所述, 并由 [RFC7983] 加以澄清. 此 DTLS 连接上的所有应用层协议负载都是 SCTP 数据包.

协议标识 MUST 作为 DTLS 握手的一部分提供, 如 [RFC8833] 所指定.

---