什么、为什么和如何
什么是WebRTC？
WebRTC是Web实时通信的缩写，既是API又是协议。WebRTC协议是两个WebRTC代理协商双向安全实时通信的一组规则。然后，WebRTC API允许开发人员使用WebRTC协议。WebRTC API 仅适用于 JavaScript。
类似的关系是HTTP和Fetch API之间的关系。WebRTC协议将是HTTP，WebRTC的API将是Fetch API。
WebRTC协议除了JavaScript之外，还有其他API和语言。您还可以找到WebRTC的服务器和特定于域的工具。所有这些实现都使用WebRTC协议，以便它们可以相互交互。
WebRTC协议在IETF的rtcweb工作组中维护。WebRTC API在W3C中被记录为webrtc。
我为什么要学习WebRTC？
这些是WebRTC会给你的一些东西：
- 开放标准
- 多种实现
- 在浏览器中可用
- 强制加密
- NAT 遍历
- 重新调整现有技术的用途
- 拥塞控制
- 亚秒级延迟
此列表并非详尽无遗，只是您在旅途中可能会欣赏的一些事物的示例。如果您还不知道所有这些术语，请不要担心，本书将在此过程中教给您。
WebRTC协议是其他技术的集合
WebRTC协议是一个巨大的话题，需要一整本书来解释。但是，首先，我们将其分为四个步骤。
- 信令
- 连接
- 安全
- 实时连接
这些步骤是连续的，这意味着上一步必须 100% 成功才能开始后续步骤。
关于WebRTC的一个特殊事实是，每一步实际上都由许多其他协议组成！为了制作WebRTC，我们将许多现有技术拼接在一起。从这个意义上说，你可以认为WebRTC更像是可追溯到2000年代初的众所周知的技术的组合和配置，而不是一个全新的过程。
这些步骤中的每一个都有专门的章节，但首先在高层次上理解它们是有帮助的。由于它们相互依赖，因此在进一步解释每个步骤的目的时会有所帮助。
信令：对等方如何在WebRTC中找到彼此
当WebRTC代理启动时，它不知道它将与谁通信或他们将要通信的内容。信令步骤解决了这个问题！信令用于引导呼叫，允许两个独立的WebRTC代理开始通信。
信令使用称为SDP（会话描述协议）的现有纯文本协议。每个SDP消息由键/值对组成，并包含“媒体部分”列表。两个WebRTC代理交换的SDP包含以下详细信息：
- 代理可访问的 IP 和端口（候选）。
- 代理希望发送的音频和视频轨道的数量。
- 每个代理支持的音频和视频编解码器。
- 连接时使用的值 （
uFrag/uPwd）。 - 保护时使用的值（证书指纹）。
重要的是要注意，信令通常发生在“带外”，这意味着应用程序通常不使用WebRTC本身来交换信令消息。任何适合发送消息的架构都可以在连接对等方之间中继 SDP，许多应用程序将简单地使用其现有的基础设施（例如 REST 端点、WebSocket 连接或身份验证代理）来促进适当客户端之间的 SDP 交易。
连接和 NAT 遍历使用STUN/TURN
一旦两个WebRTC代理交换了SDP，它们就有足够的信息来尝试相互连接。为了实现这种连接，WebRTC使用了另一种称为ICE（交互式连接建立）的成熟技术。
ICE是一种早于WebRTC的协议，允许在没有中央服务器的情况下在两个代理之间建立直接连接。这两个代理可能位于同一网络或世界的另一端。
ICE支持直接连接，但连接过程的真正魔力涉及称为“NAT遍历”的概念和STUN / TURN服务器的使用。稍后我们将更深入地探讨这两个概念，它们是与另一个子网中的 ICE 代理通信所需的全部内容。
当两个代理成功建立ICE连接时，WebRTC进入下一步;建立加密传输，以便在它们之间共享音频、视频和数据。
使用 DTLS 和 SRTP 保护传输层
现在我们有了双向通信（通过 ICE），我们需要确保我们的通信安全！这是通过另外两个协议完成的，这两个协议也早于WebRTC;DTLS（数据报传输层安全性）和 SRTP（安全实时传输协议）。第一个协议，DTLS，只是UDP上的TLS（TLS是用于保护HTTPS通信的加密协议）。第二种协议SRTP用于确保RTP（实时传输协议）数据包的加密。
首先，WebRTC通过ICE建立的连接进行DTLS握手来连接。与HTTPS不同，WebRTC不使用证书的中央颁发机构。它只是确保通过DTLS交换的证书与通过信令共享的指纹匹配。然后，此 DTLS 连接用于数据通道消息。
接下来，WebRTC使用RTP协议，使用SRTP进行音频/视频传输。我们通过从协商的 DTLS 会话中提取密钥来初始化 SRTP 会话。
我们将在后面的章节中讨论为什么媒体和数据传输有自己的协议，但现在知道它们是分开处理的就足够了。
现在我们完成了！我们已经成功地建立了双向和安全的通信。如果你的WebRTC代理之间有一个稳定的连接，这就是你需要的所有复杂性。在下一节中，我们将讨论WebRTC如何处理数据包丢失和带宽限制的不幸现实问题。
通过 RTP 和 SCTP 与对等方通信
现在我们已经连接了两个WebRTC代理并建立了安全的双向通信，让我们开始通信吧！同样，WebRTC将使用两种预先存在的协议：RTP（实时传输协议）和SCTP（流控制传输协议）。我们使用 RTP 交换使用 SRTP 加密的媒体，并使用 SCTP 发送和接收使用 DTLS 加密的数据通道消息。
RTP 是一个相当小的协议，但它提供了实现实时流的必要工具。RTP 最重要的一点是它为开发人员提供了灵活性，允许他们随心所欲地处理延迟、包丢失和拥塞。我们将在媒体章节中进一步讨论这个问题。
堆栈中的最后一个协议是 SCTP。关于 SCTP 的重要一点是，您可以关闭可靠且按顺序发送的消息传递（在许多不同的选项中）。这允许开发人员确保实时系统的必要延迟。
WebRTC，协议的集合
WebRTC解决了很多问题。乍一看，这项技术似乎被过度设计，但WebRTC的天才之处在于它的谦逊。它不是在假设它可以更好地解决所有问题的情况下创建的。相反，它采用了许多现有的单一用途技术，并将它们组合成一个简化的、广泛适用的捆绑包。
这使我们能够单独检查和学习每个部分，而不会不知所措。可视化它的一个好方法是“WebRTC代理”实际上只是许多不同协议的编排器。
WebRTC API是如何工作的？
本节概述了WebRTC JavaScript API如何映射到上述WebRTC协议。它并不是WebRTC API的广泛演示，而是创建所有内容如何联系在一起的心理模型。 如果您不熟悉协议或 API，请不要担心。这可能是一个有趣的部分，随着您了解更多信息，可以返回！
new RTCPeerConnection
RTCPeerConnection这是顶级的“WebRTC会话”。它包含上述所有协议。子系统已全部分配，但尚未发生任何反应。
addTrack
addTrack创建新的 RTP 流。将为此流生成随机同步源 （SSRC）。然后，此流将位于媒体部分中生成的会话描述中。每次调用createOfferaddTrack 将创建一个新的 SSRC 和媒体部分。
建立 SRTP 会话后，这些媒体数据包将立即开始使用 SRTP 加密并通过 ICE 发送。
createDataChannel
createDataChannel如果不存在 SCTP 关联，则创建新的 SCTP 流。默认情况下不启用 SCTP。仅当一端请求数据通道时，它才会启动。
建立 DTLS 会话后，SCTP 关联将立即开始通过 ICE 发送使用 DTLS 加密的数据包。
createOffer
createOffer生成要与远程对等方共享的本地状态的会话描述。
调用createOffer行为不会改变本地对等方的任何内容。
setLocalDescription
setLocalDescription提交任何请求的更改。在此调用addTrack，调用createDataChannel。 使用 createOffer生成的值进行调用setLocalDescription。
通常，在调用setRemoteDescription之后，您将把报价发送给远程对等方，后者将使用它来呼叫 。
setRemoteDescription
setRemoteDescription是我们通知本地代理远程候选人状态的方式。这就是使用 JavaScript API 完成“信号”行为的方式。
当双方都被调用setRemoteDescription时，WebRTC代理现在有足够的信息开始点对点（P2P）通信！
addIceCandidate
addIceCandidate允许WebRTC代理随时添加更多远程ICE候选者。此 API 将 ICE 候选者直接发送到 ICE 子系统，对更大的 WebRTC 连接没有其他影响。
ontrack
ontrack是从远程对等体接收 RTP 数据包时触发的回调。传入数据包将在传递给setRemoteDescription 的会话描述中声明。
WebRTC使用SSRC并查找关联的MediaStream和MediaStreamTrack，并触发此回调，并填充这些详细信息。
oniceconnectionstatechange
oniceconnectionstatechange是触发的回调，它反映了 ICE 代理状态的变化。当您的网络连接发生变化时，这就是通知您的方式。
onconnectionstatechange
onconnectionstatechange是 ICE 代理和 DTLS 代理状态的组合。您可以观看此内容，以便在 ICE 和 DTLS 都成功完成时收到通知。
