WebRTC工作原理详细介绍、WebRTC信令交互过程和WebRTC流媒体传输协议介绍
简介
WebRTC（Web Real-Time Communication）是一项允许在网页浏览器之间进行音视频通信的技术，基本不需要安装额外的插件。它的核心特点是支持低延迟的点对点（P2P）通讯，常用于视频聊天、实时文件共享、多人视频会议等场景。
WebRTC的工作原理
WebRTC 的工作原理大致分为以下几个步骤：
-
建立连接：WebRTC 会通过信令通道进行通信，以交换必要的信息（如SDP和ICE候选）来建立 P2P 连接。信令协议本身不被 WebRTC 规定，你可以根据实际需求选择 WebSocket、HTTP 或其他方式来实现。
-
交换SDP（Session Description Protocol）：
SDP 是一种描述多媒体会话的信息格式。它通常包含关于媒体流（视频、音频等）的详细信息，例如视频编解码器、传输协议、网络信息等。SDP 并不直接传输音视频流，它只是描述了如何将音视频流发送和接收。
你可以通过 SDP 来告知对方你可以支持的编解码器，或者你的网络地址信息等。
在 WebRTC 中，SDP 有两种类型：offer 和 answer。Offer 是发起者发送的，包含了会话的设置；Answer 是接受者的回应，确认并调整参数。
ICE候选（Interactive Connectivity Establishment）：
ICE 是一种 NAT 穿越技术，帮助两个位于 NAT（路由器或防火墙后）的设备建立连接。它的核心是通过交换候选网络地址来确定最优路径。
每个设备都会收集并交换可能的连接地址（如本地 IP、STUN 服务器或 TURN 服务器等），这些地址称为 ICE 候选。然后，双方通过尝试这些候选地址来最终建立 P2P 连接。
这也能确保 WebRTC 能够在不同的网络环境中稳定工作，尤其是在防火墙、NAT 或代理服务器的情况下。
信令服务器：
WebRTC 本身并不定义信令机制。
信令是用于在 WebRTC 连接的双方之间交换信息（如 SDP 和 ICE 候选）的过程，通常需要一个外部的信令服务器来完成。
信令服务器负责转发消息，例如将一个端的 SDP offer 传递到另一个端，或者帮助两个客户端交换 ICE 候选。
信令的具体实现可以使用 WebSocket、HTTP、或者自定义的协议。
WebRTC 通信过程简述
初始化：
客户端 A 和客户端 B 都通过信令服务器发送信令请求，表示希望建立连接。
交换 SDP：
客户端 A 创建一个 SDP offer，并将其发送到客户端 B。
客户端 B 接收并解析这个 offer，然后返回一个 SDP answer，确认双方的媒体设置。
交换 ICE 候选：
每个客户端开始收集 ICE 候选信息（即可能的网络地址）。
客户端 A 和客户端 B 通过信令服务器交换这些 ICE 候选信息，直到双方能够找到一个合适的连接路径。
建立 P2P 连接：
一旦交换完所有信息并成功找到连接路径，WebRTC 就会建立起一个点对点的音视频通信通道。
在此之后，两端相互交换了音视频流的传输细节，信令服务器的作用基本结束，两端开始进行传输音视频流。WebRTC流媒体传输协议有很多种，
譬如srs、zlmeidakit等开源流媒体服务一般会使用RTP点到点协议传输视频流。
下面详细讲讲WebRTC流媒体传输的协议：
WebRTC流媒体传输协议
在 WebRTC 中，流媒体传输的协议非常关键，决定了数据如何从一个客户端流畅地传输到另一个客户端。
WebRTC 通信协议的流媒体传输过程主要包括以下几个关键技术和协议：
- RTP（Real-Time Transport Protocol）
作用：RTP 是 WebRTC 中的主要协议，用于音频和视频的传输。它为实时流媒体提供了端到端的服务，包括数据包的顺序和时间戳。
工作原理：RTP 数据包包含音频或视频数据本身，并附加有序列号、时间戳等信息。接收方使用这些信息来重建正确的播放顺序和同步。
特点：
支持多媒体流的传输（音频、视频、文本等）。
能够处理实时流的丢包和延迟问题。
RTP 本身并不提供可靠性，通常结合 RTCP（RTP 控制协议）来提供性能反馈。 - RTCP（RTP Control Protocol）
作用：RTCP 是与 RTP 配合使用的协议，负责监控和报告 RTP 流的性能。它提供关于流的质量反馈（如丢包、延迟、带宽使用情况等），这对于调整传输过程中的音视频质量至关重要。
工作原理：RTCP 定期向所有参与者发送报告，报告的内容包括接收端的延迟、丢包率、带宽使用情况等，帮助发送端优化流媒体的传输质量。 - SCTP（Stream Control Transmission Protocol）
作用：SCTP 是 WebRTC 中用于数据传输的另一种协议，主要用于数据通道的传输。它是一个面向消息的、可靠的传输协议，支持多流传输和错误恢复。
工作原理：SCTP 不像 TCP 一样将数据打包成字节流，而是将数据分成独立的消息。它在传输过程中支持多个流，避免了阻塞现象（即一个流的拥塞不会影响其他流）。
特点：SCTP 支持多重流，可以用来传输文本、文件等非音视频数据。 - UDP（User Datagram Protocol）
作用：WebRTC 主要依赖 UDP 作为底层的传输协议，因为它提供低延迟和高效的传输，适合实时通讯应用。虽然 UDP 不保证数据包的顺序或可靠性，但 WebRTC 通过其他手段（如使用 RTP 和 RTCP）来解决这些问题。
特点：UDP 能够避免 TCP 中因丢包而产生的重传延迟，非常适合实时流的传输。它的无连接特性减少了额外的协议开销。 - ICE（Interactive Connectivity Establishment）
作用：ICE 并不是直接的传输协议，而是一个 NAT 穿越技术，帮助 WebRTC 客户端找到最优的网络路径。ICE 是 WebRTC 中非常重要的一环，它通过 STUN 和 TURN 协议来确保 WebRTC 可以跨越防火墙和 NAT 路由器，建立稳定的连接。
STUN（Session Traversal Utilities for NAT）：帮助客户端检测自己在 NAT 后的公共 IP 地址，用于直接连接。
TURN（Traversal Using Relays around NAT）：如果直接连接失败，TURN 作为中继服务器，通过转发数据流来确保连接的建立。 - DTLS（Datagram Transport Layer Security）
作用：WebRTC 采用 DTLS 来对传输的数据进行加密，确保通信的安全性。它基于 TLS（传输层安全协议），用于保证端到端的加密和身份验证。
工作原理：DTLS 在 UDP 之上提供加密保护，确保音视频流和其他数据在传输过程中不被篡改或窃听。 - SRTP（Secure Real-time Transport Protocol）
作用：SRTP 是 WebRTC 中用于 RTP 流的加密协议，提供对实时音视频流的加密、认证和完整性保护。
工作原理：SRTP 在 RTP 数据包中嵌入加密和认证信息，确保传输的音频和视频内容不被窃听或篡改。
WebRTC 的流媒体传输协议主要包括 RTP/RTCP（用于音视频数据的传输和控制）、SCTP（用于数据通道的传输）、UDP（底层传输协议）、ICE（穿越 NAT 和防火墙）、DTLS（数据加密）和 SRTP（音视频数据加密）。这些协议共同作用，确保 WebRTC 能够在低延迟的情况下进行安全、可靠的实时通信。
关键概念解释：
STUN（Session Traversal Utilities for NAT）：一种帮助 WebRTC 穿越
NAT（路由器）的方法。它通过询问外部服务器来获得你设备的公共 IP 地址，适用于很多家庭和公司网络。TURN（Traversal Using Relays around NAT）：如果 STUN 不能穿越 NAT（如在对方网络的 NAT
非常严格的情况下），TURN 服务器可以作为中继，帮助你通过它传输数据。但 TURN
会带来额外的延迟和带宽消耗，因为流量需要通过中继服务器。P2P（Peer-to-Peer）：WebRTC 的核心思想是让两台设备通过 P2P
连接直接交换数据，这意味着它不需要经过第三方服务器转发音视频流，大大减少了延迟和服务器负担。
WebRTC 是一个强大的技术，能够支持浏览器之间的实时通信。信令服务器、SDP、ICE 候选信息等在 WebRTC 中是非常重要的组成部分，它们帮助客户端找到彼此，并建立可靠的连接。信令过程、交换的 SDP 和 ICE 信息可以通过很多不同的协议和方式实现，但无论如何，它们的目标都是为了确保 WebRTC 能够在各种网络环境下成功工作。