WebRTC 的网络基础知识：信令和媒体交换

在本系列的第一篇文章中，《WebRTC 的网络基础知识：传输和地址》我们介绍了网络协议和端口，了解了 LAN、WAN 和 NAT，并解释了 TCP 和 UDP 之间的区别。今天，我们将讨论 WebRTC 流量中的两个关键点：信令和媒体交换。

青春恋爱的回忆：信号

当我年轻的时候，在所有社交媒体和即时通讯革命之前（我知道我正在变老），与我喜欢的那个棕色眼睛的女孩交谈的可靠方法是交换笔记。这通常是通过我们共同的朋友西格蒙德发生的。

“告诉她我可以给她冰淇淋，”我会告诉西格蒙德，同时还递了一张纸条，我建议食堂作为我们相遇的候选地点。过了一会儿，他带着她的回答回来了：“你很幸运，我真的很喜欢冰淇淋。”

经过短暂的谈判，我们终于见面了。一段短暂却充满激情的少年爱情开始了。但是，您不是来这里阅读我的约会历史的。您是来这里学习 WebRTC 网络的，对吗？实际上，我告诉你这个故事是为了帮助解释信号。

提供和回答机制

正如我关于棕眼女孩的故事，当两个同伴想要通过 WebRTC 连接时，他们首先需要通过“共同的朋友”建立协商。换句话说，第三个节点能够以我们都知道的 Sigmund 相同的方式到达他们两个。

两个对等点将通过第三个节点（也称为信令服务器）交换信息。

想要发起连接的对等方使用会话描述协议 (SDP) 创建报价。Offer 通过信令通道发送。 

WebRTC 连接中的报价将包括有关受支持的音频和视频编解码器、ICE 候选者（我们将在一秒钟内详细讨论）和基于文本格式的加密详细信息，而不是冰淇淋邀请，如定义社民党。

一旦另一个节点收到 Offer，它就会创建一个包含自己信息的Answer 。Answer 再次通过信令通道发送回第一个对等点。

WebRTC 不定义也不强制执行信号机制。可以使用任何允许交换信息的技术，前提是双方都可以访问这样的渠道。

在双方都获得所有必需的信息后，他们可以建立连接并且媒体流量开始流动。在深入了解媒体流量的细节之前，让我们再解释一下网络地址转换 (NAT) 遍历的一个重要主题：交互式连接建立 (ICE) 框架。

使用 ICE 遍历 NAT

在当前的现实世界场景中，通过 WebRTC 连接的对等点生活在不同的局域网 (LAN) 上。连接发生在称为 WAN（广域网）的 LAN 集合中。这需要媒体流量经过多个 NAT 设备，这就是我们所说的 NAT 穿越。

正如我们在上一篇文章中讨论的那样，NAT 可以连接到互联网。同时，在直接连接两个对等点时，NAT 代表了一个重大挑战。ICE 为该问题提供了一种解决方案，使对等方能够收集和交换候选对。

就像我建议我与棕色眼睛的女孩相遇的食堂一样，一对候选人让另一对同伴知道“他们可以在哪里见面”。更准确地说，它提供了一对 IP 地址和可以找到对等点的端口。

此类信息将添加到要约和答案中。然后，每个对等方的 ICE 代理将对所有候选对执行动态检查，以确定最佳路由并建立连接。

最初，ICE 首先收集宿主ice 候选者。它们使用分配给用户设备网络接口的 IP 地址，这是一个仅在同一 LAN 中才有意义的本地地址。Host ICE candidates 仅对 LAN 连接有用。

接下来，ICE 框架将搜索NAT 设备提供的允许对等方连接到互联网的IP 地址和端口。这是通过向称为 STUN 服务器的外部服务器发出请求来完成的。

STUN 代表 NAT 的会话遍历实用程序。它是一种协议，为对等方提供了解其公共信息的方式。对等点将向 STUN 服务器发出 STUN 请求。服务器将回复请求来自的公共 IP 地址。

STUN 服务器通常会回复 UDP 和 TCP 类型的候选对，尽管 UDP 应该是首选。这些 ICE 候选者可以是服务器自反 (srflx)类型或对等自反 (prflx) 类型，后者是前者的变体。

当无法直接连接时，会使用第三种 ICE 候选类型。例如，当 NAT 类型不允许或存在防火墙限制时。这些是中继ICE 候选人有用 的场景。

中继 ICE 候选者是使用中继遍历 NAT (TURN) 服务器的 IP 地址。TURN 服务器会将媒体流量从一个点中继到另一个点。

ICE 收集和连接检查需要一些时间。这使两个对等点等待建立连接。幸运的是，有一种更优化的方法，称为 Trickle ICE。  

即时通讯时代的爱情：Trickle ICE

西格蒙德仍然很受人们欢迎，直到现在我还要依靠他才能找到我的费尔明娜。然而，时代变了，现在有了更好的沟通方式。虽然我仍然可以请他帮我安排一个地方与他介绍我认识的人见面，但我现在可以通过即时消息独立提出候选地点，而无需等待他。

类似地，我们可以在将它们添加到 SDP Offer and Answer 之前等待收集所有 ICE 候选者，而是在它们可用时将它们滴入信令通道。这减少了对等方等待连接的时间。

谈判结束，媒体时间到了：媒体和数据交换

一旦信令结束并且双方都有足够的信息直接连接（或通过 TURN 中继流量），那么他们就可以开始发送媒体和数据包。WebRTC 要求媒体流量应该受到保护。为此，它使用 DTLS。

DTLS（数据报传输层安全性）是一种通过 UDP 实现安全性的协议。这与 TLS（传输层安全性）对 TCP 连接所做的方式相同。

混合使用 DTLS 可确保数据不会被未授权方窃听或篡改。

音频和视频数据使用实时传输协议 (RTP) 的安全版本、安全 RTP (SRTP) 进行传输。RTP 是用于实时传输数据的协议。它广泛用于 VoIP 等通信系统。安全 RTP 与 DTLS 一起用于密钥管理。

有时被忽视但很棒的 WebRTC 功能是数据通道。数据通道允许通过 UDP 发送任意数据。为此使用的协议是流控制传输协议 SCTP，它建立在 DTLS 之上以确保安全。

小结

在这篇文章中，我们介绍了在建立 WebRTC 连接的整个过程中使用的最重要的协议，从格式化 Offer & Answer 和收集和检查 ICE 候选者到优化 ICE 和发送语音、视频和数据包。

编译自webrtc.ventures，作者：Hector Zelaya。