Skip to main content

3. Transport and Middlebox Specification (传输和中间盒规范)

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

3.1. System-Provided Interfaces (系统提供的接口)​

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

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

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

对于这两种协议,都假定支持IPv4和IPv6.

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

不提供对这些接口访问的平台将无法支持符合标准的WebRTC端点 (Conforming WebRTC Endpoint).

本规范不假定实现将具有对ICMP或原始IP的访问权限.

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

  • TURN: Traversal Using Relays Around NAT [RFC8656]
  • STUN: Session Traversal Utilities for NAT [RFC5389]
  • ICE: Interactive Connectivity Establishment [RFC8445]
  • TLS: Transport Layer Security [RFC8446]
  • DTLS: Datagram Transport Layer Security [RFC6347]

3.2. Ability to Use IPv4 and IPv6 (使用IPv4和IPv6的能力)​

在WebRTC浏览器中运行的Web应用程序必须 (MUST) 能够在可用的情况下同时使用IPv4和IPv6 -- 也就是说,当两个对等方仅具有彼此的IPv4连接时,或者它们仅具有彼此的IPv6连接时,在WebRTC浏览器中运行的应用程序必须 (MUST) 能够通信.

当使用TURN时,如果TURN服务器具有与对等方或对等方的TURN服务器的IPv4或IPv6连接,则必须 (MUST) 支持适当类型的候选地址. 应该 (SHOULD) 支持ICE的"Happy Eyeballs"规范 [RFC8421].

3.3. Usage of Temporary IPv6 Addresses (临时IPv6地址的使用)​

IPv6默认地址选择规范 [RFC6724] 规定临时地址 [RFC4941] 优先于永久地址. 这是对 [RFC3484] 规定规则的更改. 对于选择单个地址的应用程序,这通常通过 [RFC5014] 中指定的IPV6_PREFER_SRC_TMP偏好标志来完成. 但是,此规则旨在确保隐私增强地址优先于静态地址使用,在ICE中没有正确的效果,因为在ICE中会收集所有地址,因此会向应用程序透露. 因此,改为应用以下规则:

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

如果部分(但不是全部)临时IPv6地址被标记为已弃用,则WebRTC端点应该 (SHOULD) 丢弃已弃用的地址,除非它们被正在进行的连接使用. 在ICE重启中,当前正在使用的已弃用地址可以 (MAY) 被保留.

处理中间盒的主要机制是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候选地址,其中从WebRTC端点的TURN服务器到对等方的连接是TCP连接 [RFC6062].

但是,此类候选地址不被认为提供任何显著的好处,原因如下.

首先,TURN TCP候选地址的使用仅在双方都需要使用TCP建立连接的情况下才相关.

其次,该用例以不同的方式得到支持,即双方使用通过TCP的TURN建立UDP中继候选地址以连接到各自的中继服务器.

第三,在WebRTC端点的TURN服务器和对等方之间使用TCP可能导致比使用UDP更多的性能问题,例如,由于队头阻塞 (Head of Line Blocking).

必须 (MUST) 支持ICE-TCP候选地址 [RFC6544]; 这可能允许应用程序在不使用TURN服务器的情况下通过阻止UDP的防火墙与具有公共IP地址的对等方通信.

如果使用TCP连接,则必须 (MUST) 对所有数据包使用根据 [RFC4571] 的RTP帧. 这包括RTP数据包、用于承载数据通道的DTLS数据包和STUN连接性检查数据包.

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

WebRTC端点可以 (MAY) 支持通过HTTP代理访问互联网. 如果这样做,它必须 (MUST) 包含 [RFC7639] 中指定的"ALPN"标头,并且还必须 (MUST) 支持 [RFC7231] 第4.3.6节和 [RFC7235] 中描述的代理身份验证.

3.5. Transport Protocols Implemented (实现的传输协议)​

对于媒体传输,使用安全RTP. 所使用的RTP配置文件的详细信息在"Media Transport and Use of RTP in WebRTC" [RFC8834] 中描述,该文档强制使用断路器 (Circuit Breaker) [RFC8083] 和拥塞控制(有关进一步指导,请参阅 [RFC8836]).

必须 (MUST) 使用DTLS-SRTP进行密钥交换,如 [RFC8827] 中所述.

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

必须 (MUST) 支持 [RFC8832] 中描述的WebRTC数据通道的设置协议.

注意: [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] 中所指定.

Last updated on