我的书签
添加书签
移除书签WebRTC API
W3C WebRTC 1.0 API 允许 JavaScript 应用程序利用新型浏览器的实时功能。 在浏览器核心中实现的实时浏览器功能（请参见 图1-3）提供了建立必要的音频，视频和数据通道所需的功能。 所有媒体和数据流都使用 DTLS 加密。
::: details DTLS 加密
DTLS 实际上用于密钥派生，而 SRTP 用于线路。 因此，线路上的数据包不是 DTLS（初始握手除外）。
:::
Datagram Transport Layer Security (DTLS)
DTLS（数据报传输层安全性）协议（RFC6347）旨在防止对用户数据报协议（UDP）提供的数据传输进行窃听，篡改或消息伪造。 DTLS 协议基于面向流的传输层安全性（TLS）协议，旨在提供类似的安全性保证。
::: warning 注意
在两个 WebRTC 客户端之间执行的 DTLS 握手依赖于自签名证书。 但是，证书本身无法用于对等方进行身份验证，因为没有明确的信任链可进行验证。
:::
为了确保不同的实时浏览器功能实现之间的互操作性达到基线水平，IETF 正在努力选择支持音频和视频编解码器的最低强制要求集。 已选择 Opus（RFC6716）和 G.711 作为实施音频编解码器的必需项。 但是，在撰写本文时，IETF 尚未就强制实施视频编解码器达成共识。
该 API 围绕三个主要概念进行设计：MediaStream，PeerConnection 和 DataChannel。
MediaStream
MediaStream 是音频和/或视频的实际数据流的抽象表示。 它用作管理媒体流操作的句柄，例如显示媒体流的内容，对其进行记录或将其发送到远程对等方。 MediaStream 可以扩展为表示来自（远程流）或发送到（本地流）远程节点的流。
LocalMediaStream 表示来自本地媒体捕获设备(例如，网络摄像头、麦克风等)的媒体流。要创建和使用本地流，web 应用程序必须通过 getUserMedia() 函数请求用户访问。应用程序指定它需要访问的媒体音频或视频的类型。浏览器接口中的设备选择器用作授予或拒绝访问的机制。一旦应用程序完成，它可以通过调用 LocalMediaStream 上的 stop() 函数来撤销自己的访问权限。
媒体平面信令是在对等点之间的频带上进行的；安全实时传输协议 Secure Real-time Transport Protocol (SRTP)用于将媒体数据与用于监视与数据流相关的传输统计信息的 RTP 控制协议 RTP Control Protocol (RTCP)信息一起传输。DTLS 用于 SRTP 密钥和关联管理。
如 图1-4 所示，在多媒体通信中，每个媒体通常在单独的 RTP 会话中使用自己的 RTCP 包进行传输。但是，为了克服为每个使用的流打开一个新的 NAT 洞的问题，IETF 目前正在研究减少基于 rtp 的实时应用程序所消耗的传输层端口数量的可能性。这个想法是结合。在单个 RTP 会话中的多媒体通信。
图1-4 WebRTC 协议栈
PeerConnection
PeerConnection 允许两个用户在浏览器之间直接通信。然后，它表示与远程对等点的关联，远程对等点通常是在远程端运行的同一JavaScript应用程序的另一个实例。通信通过一个信令通道进行协调，信令通道是通过web服务器中的页面脚本代码提供的，例如使用 XMLHttpRequest 或 WebSocket。一旦建立了对等连接，就可以将媒体流(与临时定义的 MediaStream 对象在本地关联)直接发送到远程浏览器。
STUN and TURN
NAT会话遍历实用程序（STUN）协议（RFC5389）允许主机应用程序发现网络上网络地址转换器的存在，并且在这种情况下，可以为当前连接获取分配的公共IP和端口元组。 为此，该协议需要已配置的第三方STUN服务器的协助，该服务器必须位于公共网络上。
围绕NAT的遍历使用中继（TURN）协议（RFC5766）允许NAT后面的主机从驻留在公用Internet上的中继服务器获取公用IP地址和端口。 由于中继了传输地址，主机可以从任何可以将数据包发送到公共Internet的对等方接收媒体。
PeerConnection 机制将ICE协议（请参阅ICE Candidate Exchanging）与 STUN 和 TURN 服务器一起使用，以使基于UDP的媒体流穿越NAT盒和防火墙。 ICE允许浏览器发现有关部署它们的网络拓扑的足够信息，以找到最佳的可利用通信路径。 使用ICE还提供了一种安全措施，因为它可以防止不受信任的网页和应用程序将数据发送到不希望接收它们的主机。
每个信令消息在到达时就被馈送到接收方 PeerConnection 中。 API发送信令消息，大多数应用程序会将其视为不透明的Blob，但是必须由Web应用程序通过Web服务器安全有效地将其传输到其他对等体。
DataChannel
DataChannel API旨在提供通用传输服务，允许Web浏览器以双向对等方式交换通用数据。
IETF内的标准化工作已就使用封装在DTLS中的流控制传输协议（SCTP）处理非媒体数据类型达成了普遍共识（请参见图1-4）。
通过 UDP 的 DTLS 和 ICE 的 SCTP 封装提供了NAT遍历解决方案以及机密性，源身份验证和完整性受保护的传输。此外，该解决方案允许数据传输与并行媒体传输平滑地互通，并且两者都可能共享一个传输层端口号。之所以选择SCTP，是因为它本地支持具有可靠或部分可靠传送模式的多个流。它提供了在SCTP关联中向对等SCTP端点打开几个独立流的可能性。每个流实际上代表一个单向逻辑通道，提供顺序传送的概念。消息序列可以有序或无序发送。消息传递顺序仅保留给在同一流上发送的所有有序消息。但是，DataChannel API 已被设计为双向的，这意味着每个 DataChannel 都是由传入和传出SCTP流的捆绑组成的。
当在实例化的 PeerConnection 对象上首次调用 CreateDataChannel() 函数时，将执行 DataChannel 设置（即创建 SCTP 关联）。随后每次对 CreateDataChannel() 函数的调用都只会在现有SCTP关联内创建一个新的 DataChannel。
