优秀的编程知识分享平台

网站首页 > 技术文章 正文

Iot 场景 WebRTC 通信机制的尝试（webrtc基于什么协议）

nanyue 2024-07-26 16:02:16 技术文章 12 ℃

具体实现步骤

  • 将 https://github.com/Jhuster/RTCStartupDemo 跑起来看看实际的效果
  • 将仓库的 RTCSignalClient 替换成网关的通信机制，查看是否可以使用 项目源码：Github，对项目进行了重构，最后可运行时间：2023/05/28

WebRTC 相关知识

WebRTC 使用的传输协议：

  1. ICE（Interactive Connectivity Establishment）：这是一个框架，用于使两个设备（对等方）通过 NAT（网络地址转换）和防火墙进行通信。ICE 使用 STUN（Session Traversal Utilities for NAT）和 TURN（Traversal Using Relays around NAT）协议来发现最佳的通信路径(通信路径有：公网 IP:Port 直接通信、局域网 IP: Port 直接通信、使用 TURN 服务器做为中继点进行传输)。
  2. DTLS（Datagram Transport Layer Security）：这是一种安全协议，用于在两个对等方之间建立安全连接，以防止数据被拦截或篡改。
  3. SRTP（Secure Real-time Transport Protocol）：一旦通过 DTLS 建立了安全连接，音频和视频流就会通过 SRTP 在两个对等方之间安全地发送。
  4. SCTP（Stream Control Transmission Protocol）：这是一种传输协议，用于在 RTCDataChannel 中发送数据。

WebRTC 中所涉及到的服务器

WebRTC 数据传输过程中，使用的是 P2P(Peer to Peer)，一般是不需要服务器的，只需要 ISP(互联网服务供应商) 根据自己的 ipTable 对数据进行转发。

但实际上 P2P 传输的建立需要服务器的参与，WebRTC 使用到的服务器具体为：信令服务器(Signaling Server)、STUN(Session Traversal Utilities for NAT)服务器、TURN(Traversal Using Relays around NAT) 服务器。这几个服务器的作用如下：

  1. 信令服务器(Signaling Server)：WebRTC 使用信令服务器来交换两个对等方（peers）之间的信息，包括会话控制消息（如打开和关闭连接）、错误消息、媒体元数据（如编码和格式）、网络数据（如网络地址和端口）、以及安全参数（如用于建立安全连接的密钥）。信令过程不直接包含在 WebRTC 规范中，因此可以使用任何可靠的传输机制（例如 WebSocket、XMPP、SIP 等）。具体到 Iot 场景，我们可以使用网关做为 Signaling Server。
  2. STUN服务器(Session Traversal Utilities for NAT)：STUN 服务器的主要功能是帮助位于 NAT（网络地址转换）之后的设备发现其公网 IP 地址和端口。这些信息被包含在信令信息中，以便其他对等体知道如何直接与其通信。
  3. TURN服务器(Traversal Using Relays around NAT)：当直接的点对点通信由于 NAT 或防火墙的限制而无法建立时，TURN 服务器充当中继，将数据转发给对应的对等体。TURN 服务器的使用会增加一些延迟，但在某些情况下，这是唯一能够使得通信成立的方法。

STUN 服务器和 TURN 服务器的工作流程

信令服务器，应该会比较好理解。简单来说，我们通过自己搭建的信令服务器，在 peer 之间交换各自的 ip，支持的音视频格式相关信息等，用于建立 P2P 连接。接下来详细说明一下 STUN 和 TURN 服务器的工作流程。

使用 STUN 服务器的情况：

Alice 和 Bob 的电脑都位于 NAT （网络地址转换）设备之后，例如他们的路由器。他们的电脑使用私有 IP 地址，只有路由器有公网 IP 地址。在这种情况下，Alice 和 Bob 的电脑无法知道他们的公网 IP 地址和端口，这是建立点对点连接所必需的。

这时，他们的电脑可以向 STUN 服务器发送请求，STUN 服务器会响应他们的公网 IP 地址和端口。Alice 和 Bob 的电脑再通过信令服务器将这些信息交换给对方。然后，他们就可以尝试直接建立点对点的连接，进行音视频通信。

使用 TURN 服务器的情况：

在某些情况下，即使有了 STUN 服务器提供的公网 IP 地址和端口，Alice 和 Bob 也可能无法直接建立点对点的连接。例如，他们所在的网络可能由于 NAT 类型或防火墙设置的原因，阻止了点对点的连接。

这时，他们可以使用 TURN 服务器。Alice 的电脑将音视频数据发送给 TURN 服务器，TURN 服务器再将数据转发给 Bob，反之亦然。虽然这会增加一些延迟，但它能够让 Alice 和 Bob 进行音视频通信。

相关学习资料推荐，点击下方链接免费报名，先码住不迷路~】

音视频免费学习地址：https://xxetb.xet.tech/s/2cGd0

【免费分享】音视频学习资料包、大厂面试题、技术视频和学习路线图，资料包括（C/C++，Linux，FFmpeg webRTC rtmp hls rtsp ffplay srs 等等）有需要的可以点击788280672加群免费领取~

WebRTC 传输连接的建立

连接的建立过程需要使用到以上提到的三个服务器。具体包括三个阶段：Offer、Answer、IceCandidate。三个阶段都处理完成之后，就可以开始相关数据的传输。具体的流程图如下：

其中 Offer、Answer 和 ICE Candidate 的区别：

  • 数据上的区别：
    • SDP（Session Description Protocol）：在创建 Offer 和 Answer 时收集的 SDP 信息主要描述了一方的媒体能力和网络状态。一个 SDP 描述看起来可能像这样：
o=- 4185532051989611207 2 IN IP4 127.0.0.1
s=-
t=0 0
a=group:BUNDLE audio video
a=msid-semantic: WMS 0a4051f6-a736-4607-b645-b240ba7b95cf
m=audio 9 UDP/TLS/RTP/SAVPF 111 103 9 102 0 8 105 13 110 113 126
c=IN IP4 0.0.0.0
a=rtcp:9 IN IP4 0.0.0.0
a=ice-ufrag:lAHT
a=ice-pwd:zi34AQt9daqojFjk0ayBcVsO
a=ice-options:trickle renomination
a=fingerprint:sha-256 6D:E4:4B:15:DC:26:F2:AB:88:51:B9:24:21:78:19:9B:03:FD:69:C6:3D:58:24:59:14:24:8A:A1:60:C0:BD:00
a=setup:actpass
a=mid:audio
a=extmap:1 urn:ietf:params:rtp-hdrext:ssrc-audio-level
a=extmap:2 http://www.webrtc.org/experiments/rtp-hdrext/abs-send-time
a=extmap:3 http://www.ietf.org/id/draft-holmer-rmcat-transport-wide-cc-extensions-01
a=sendrecv
a=rtcp-mux
a=rtpmap:111 opus/48000/2
a=rtcp-fb:111 transport-cc
a=fmtp:111 minptime=10;useinbandfec=1
a=rtpmap:103 ISAC/16000
a=rtpmap:9 G722/8000
a=rtpmap:102 ILBC/8000
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:105 CN/16000
a=rtpmap:13 CN/8000
a=rtpmap:110 telephone-event/48000
a=rtpmap:113 telephone-event/16000
a=rtpmap:126 telephone-event/8000
a=ssrc:161843853 cname:5qtwHvMz9P2Je6uK
a=ssrc:161843853 msid:0a4051f6-a736-4607-b645-b240ba7b95cf ARDAMSa0
a=ssrc:161843853 mslabel:0a4051f6-a736-4607-b645-b240ba7b95cf
a=ssrc:161843853 label:ARDAMSa0
m=video 9 UDP/TLS/RTP/SAVPF 96 97 98 99 125 100 101 127
c=IN IP4 0.0.0.0
a=rtcp:9 IN IP4 0.0.0.0
a=ice-ufrag:lAHT
a=ice-pwd:zi34AQt9daqojFjk0ayBcVsO
a=ice-options:trickle renomination
a=fingerprint:sha-256 6D:E4:4B:15:DC:26:F2:AB:88:51:B9:24:21:78:19:9B:03:FD:69:C6:3D:58:24:59:14:24:8A:A1:60:C0:BD:00
a=setup:actpass
a=mid:video
a=extmap:14 urn:ietf:params:rtp-hdrext:toffset
  • ICE 候选项：在 onIceCandidate() 方法中收集的 ICE 候选项主要包含了可能的 IP 地址和端口信息。一个 ICE 候选项看起来可能像这样：
{
 candidate: "candidate:842163049 1 udp 1686052607 1.2.3.4 46154 typ srflx raddr 10.0.0.17 rport 46154 generation 0",
 sdpMid: "audio",
 sdpMLineIndex: 0
}
  • 具体区别的总结：
    • SDP（Session Description Protocol）：SDP 主要描述了一方的媒体能力和网络状态。这包括：
      • 媒体能力：例如音频和视频的编码格式（如 Opus、ISAC、G722、PCMU、PCMA 等）以及相关的参数（如采样率、通道数等）。
      • 网络状态：例如 IP 地址、端口、传输协议（如 UDP/TLS/RTP/SAVPF）等。
      • 其他设置：例如 ICE 的用户名（ufrag）、密码（pwd）、选项（options）、DTLS 的指纹（fingerprint）、设置（setup）等。
    • ICE 候选项：ICE 候选项主要包含了可能的 IP 地址和端口信息。这包括：
      • 网络地址：例如 IP 地址和端口。
      • 网络状态：例如传输协议（如 UDP）、优先级等。
      • 类型：例如候选项的类型（如 host、srflx、prflx、relay），表示候选项是直接的本地地址、服务器反射的地址、对等反射的地址，还是中继的地址。
      • 关联信息：例如 sdpMid 和 sdpMLineIndex，用于将 ICE 候选项关联到 SDP 描述中的特定媒体流。

WebRTC 传输的具体示例

公网（Internet）：

当 Alice 和 Bob 想要在互联网上通过 WebRTC 进行音视频通信时，他们首先需要通过信令服务器交换所谓的 SDP（Session Description Protocol）信息，这包含了各自的 IP 地址和端口信息，以及一些支持的音视频编码格式等信息。

在交换 SDP 信息的同时，他们也需要通过 DTLS（Datagram Transport Layer Security）交换密钥。这个密钥将被用来加密和解密 SRTP 数据包。Alice 使用这个密钥加密音频和视频数据包，然后通过互联网发送给 Bob。由于这些数据包是加密的，所以在传输过程中，即使被拦截，也无法被篡改或解读。Bob 收到数据包后，再使用同样的密钥解密，就能得到原始的音频和视频数据。

局域网（Local Area Network）：

在一个公司的局域网内，两台电脑（例如 A 和 B）可以直接通过 WebRTC 进行音视频通信。这种情况下，由于他们在同一个局域网内，所以可以直接通过局域网 IP 进行通信，不需要通过 STUN 或 TURN 服务器进行 IP 和端口的发现。

同样，他们也需要通过 DTLS 交换密钥，然后使用这个密钥来加密和解密 SRTP 数据包。A 电脑使用这个密钥加密音频和视频数据包，然后通过局域网发送给 B 电脑。由于这些数据包是加密的，所以在传输过程中，即使被拦截，也无法被篡改或解读。B 电脑收到数据包后，再使用同样的密钥解密，就能得到原始的音频和视频数据。

使用 WebRTC 的优缺点分析

  • 优点
    • 功能强大，API 较为简单。支持局域网通信和广域网通信，支持音频、视频的实时传输。支持回声消除、噪声抑制、抗丢包处理、抖动缓冲区、自动增益控制和声音活动检测等等。支持多种编解码器（如 VP8、VP9、H.264、Opus、G.711、G.722 等)。
    • 框架成熟，各个传输模块都有相对应的协议定义。在连接建立阶段，ICE 用于进行 NAT 穿透以建立 P2P 连接，而 DTLS 用于在两个通信节点之间保证数据的安全性和完整性。一旦连接建立，数据传输会使用 SRTP 或者 SCTP 进行加密和解密，以保证在传输过程中的安全性。
    • 可以适应各种网络环境，通过 STUN/TURN 服务器可以实现 NAT 穿透，实现多种复杂网络环境下的通信。使用 P2P 进行传输，保证传输的速率。
    • 框架开源，可以查看并理解其底层实现。
  • 缺点
    • 数据传输协议使用的是 UDP，在消息的到达率上无法做到非常稳定。UDP 不保证数据包的到达和顺序，在网络状况较差的情况下可能导致音视频质量降低。
    • 架构较为成熟和复杂，修改源码进行定制有一定的难度。需要深入理解其底层实现，需要开发者有足够网络编程经验和音视频开发经验。
    • 在对广域网的支持时，需要花费一定的时间和资源进行开发和调试，尤其是在处理与 NAT、防火墙等相关的问题时。如果需要通过 TURN 服务器进行流量中继，可能会需要一定的运营成本。

总结

WebRTC 是一个功能强大，成熟且开箱即用的 P2P 音视频通信框架。它在多个平台上都有良好的支持，非常适合集成到应用中或进行二次开发。同时，作为开源框架，WebRTC 提供了底层的源码，允许开发者进行深度定制，从而满足特殊需求。然而，这种深度定制通常需要开发者有足够的网络编程和音视频开发经验，这对于开发者来说有一定的挑战性。此外，在广域网络环境下使用 WebRTC，尤其是需要使用 TURN 服务器进行流量中继时，可能会带来额外的运营成本。总的来说，WebRTC 是一个强大且灵活的工具，但使用它可能需要一定的技术和资源投入。

Reference

https://github.com/Jhuster/RTCStartupDemo

https://github.com/ddssingsong/webrtc_server_java

WebRTC-Android 探索 - 创建音视频通话程序的基本姿势 - 掘金

Android | WebRTC

How does WebRTC work?

原文 https://zhuanlan.zhihu.com/p/632838259

Tags：

猜你喜欢

最近发表
标签列表