Web_RTC

最新推荐文章于 2024-07-30 16:49:30 发布

想像风一样流浪

最新推荐文章于 2024-07-30 16:49:30 发布

阅读量1.7k

点赞数

文章标签：前端实时音视频网络物联网

本文链接：https://blog.csdn.net/weixin_43724177/article/details/127759775

版权

Web_RTC

webrtc是一项实时通讯技术，它允许网络应用或者站点，在不借助中间媒介的情况下，建立浏览器之间点对点的连接，实现音视频流或者其他任意数据的传输。

请添加图片描述

你可以这样理解：

请添加图片描述

一 WebRTC协议介绍

1.ICE

交互式连接设施Interactive Connectivity Establishment (ICE) 是一个允许你的浏览器和对端浏览器建立连接的协议框架。在实际的网络当中，有很多原因能导致简单的从 A 端到 B 端直连不能如愿完成。这需要绕过阻止建立连接的防火墙，给你的设备分配一个唯一可见的地址（通常情况下我们的大部分设备没有一个固定的公网地址），如果路由器不允许主机直连，还得通过一台服务器转发数据。ICE 通过使用以下几种技术完成上述工作。

ICE协议的目的就是综合以下两种方法，通过通信双方互相发探测包，找出一种最合理，最廉价的可行路径。

2.STUN

NAT 的会话穿越功能Session Traversal Utilities for NAT (STUN) (缩略语的最后一个字母是 NAT 的首字母) 是一个允许位于 NAT 后的客户端找出自己的公网地址，判断出路由器阻止直连的限制方法的协议。

客户端通过给公网的 STUN 服务器发送请求获得自己的公网地址信息，以及是否能够被（穿过路由器）访问。

An interaction between two users of a WebRTC application involving a STUN server.

3.NAT

网络地址转换协议Network Address Translation (NAT) 用来给你的（私网）设备映射一个公网的 IP 地址的协议。一般情况下，路由器的 WAN 口有一个公网 IP，所有连接这个路由器 LAN 口的设备会分配一个私有网段的 IP 地址（例如 192.168.1.3）。私网设备的 IP 被映射成路由器的公网 IP 和唯一的端口，通过这种方式不需要为每一个私网设备分配不同的公网 IP，但是依然能被外网设备发现。

一些路由器严格地限定了部分私网设备的对外连接。这种情况下，即使 STUN 服务器识别了该私网设备的公网 IP 和端口的映射，依然无法和这个私网设备建立连接。这种情况下就需要转向 TURN 协议。

4.TURN

一些路由器使用一种“对称型 NAT”的 NAT 模型。这意味着路由器只接受和对端先前建立的连接（就是下一次请求建立新的连接映射）。

NAT 的中继穿越方式Traversal Using Relays around NAT (TURN) 通过 TURN 服务器中继所有数据的方式来绕过“对称型 NAT”。你需要在 TURN 服务器上创建一个连接，然后告诉所有对端设备发包到服务器上，TURN 服务器再把包转发给你。很显然这种方式是开销很大的，所以只有在没得选择的情况下采用。

An interaction between two users of a WebRTC application involving STUN and TURN servers.

5.SDP

会话描述协议Session Description Protocol (SDP) 是一个描述多媒体连接内容的协议，例如分辨率，格式，编码，加密算法等。所以在数据传输时两端都能够理解彼此的数据。本质上，这些描述内容的元数据并不是媒体流本身。

从技术上讲，SDP 并不是一个真正的协议，而是一种数据格式，用于描述在设备之间共享媒体的连接。

6.数据传输协议

WebRTC 采用的是标准的 RTP/RTCP 协议进行数据的封包和网络状态反馈，关于 RTP/RTCP 传输协议，已经发展多年，是比较成熟的多媒体传输协议了，也有很多不错的开源库，这里就不再赘述了。

二 WebRTC connectivity

WebRTC 各种相关协议如何相互交互，以便在对等体之间创建连接和传输数据和/或媒体。

1.sessiondescription

WebRTC 连接上的端点配置称为会话描述。该描述包括关于要发送的媒体类型，其格式，正在使用的传输协议，端点的 IP 地址和端口以及描述媒体传输端点所需的其他信息的信息。使用会话描述协议(SDP) 来交换和存储该信息; 如果您想要有关 SDP 数据格式的详细信息，可以在RFC 2327中找到。

当用户对另一个用户启动 WebRTC 调用时，将创建一个称为提议(offer) 的特定描述。该描述包括有关呼叫者建议的呼叫配置的所有信息。接收者然后用应答(answer) 进行响应，这是他们对呼叫结束的描述。以这种方式，两个设备彼此共享以便交换媒体数据所需的信息。该交换是使用交互式连接建立 (ICE)(ICE处理的，这是一种协议，即使两个设备通过网络地址转换 (NAT)。

然后，每个对等端保持两个描述：描述本身的本地描述和描述呼叫的远端的远程描述。

在首次建立呼叫时，还可以在呼叫格式或其他配置需要更改的任何时候执行提议/应答过程。无论是新呼叫还是重新配置现有的呼叫，这些都是交换提议和回答所必需的基本步骤，暂时忽略了 ICE 层：

呼叫者通过 navigator.mediaDevices.getUserMedia() (en-US) 捕捉本地媒体。
呼叫者创建一个RTCPeerConnection 并调用 RTCPeerConnection.addTrack() (注： addStream 已经过时。)
呼叫者调用 RTCPeerConnection.createOffer() 来创建一个提议 (offer).
呼叫者调用 RTCPeerConnection.setLocalDescription() (en-US) 将提议 (Offer) 设置为本地描述 (即，连接的本地描述).
setLocalDescription() 之后，呼叫者请求 STUN 服务创建 ice 候选 (ice candidates)
呼叫者通过信令服务器将提议 (offer) 传递至本次呼叫的预期的接受者。
接受者收到了提议 (offer) 并调用 RTCPeerConnection.setRemoteDescription() 将其记录为远程描述 (也就是连接的另一端的描述).
接受者做一些可能需要的步骤结束本次呼叫：捕获本地媒体，然后通过RTCPeerConnection.addTrack()添加到连接中。
接受者通过 RTCPeerConnection.createAnswer() (en-US) 创建一个应答。
接受者调用 RTCPeerConnection.setLocalDescription() (en-US) 将应答 (answer) 设置为本地描述。此时，接受者已经获知连接双方的配置了。
接受者通过信令服务器将应答传递到呼叫者。
呼叫者接受到应答。
呼叫者调用 RTCPeerConnection.setRemoteDescription() 将应答设定为远程描述。如此，呼叫者已经获知连接双方的配置了。

2.ICE候选地址

除了交换关于媒体的信息 (上面提到的 Offer / Answer 和 SDP ) 中，对等体必须交换关于网络连接的信息。这被称为 ICE 候选者，并详细说明了对等体能够直接或通过 TURN 服务器进行通信的可用方法。通常，每个对点将优先提出最佳的 ICE 候选，逐次尝试到不佳的候选中。理想情况下，候选地址是 UDP(因为速度更快，媒体流能够相对容易地从中断恢复 )，但 ICE 标准也允许 TCP 候选。

备注：一般来说，使用 TCP 的 ICE 候选者只有当 UDP 不可用或被限制使其不适用于媒体流时才会被使用。不是所有的浏览器都支持 ICE over TCP。

3.webrtc的建立

信令期间交换的信息

控制消息：用于设置、打开、关闭通信通道并处理错误。
为了建立连接所需的信息：设备间能够彼此交谈所需的 IP 寻址和端口信息。
媒体能力协商：交互双方可以理解哪些编解码器和媒体数据格式？这些都需要在 WebRTC 会议开始之前达成一致。
下图与文转载于：http://www.cnblogs.com/fangkm/p/4364553.html

我们假设两个对等方A和B都使用WebRTC对等双向媒体流（例如，视频聊天应用程序）的情况。

要连接到B的应用程序，A的应用程序必须生成SDP offer。SDP offer包含有关A的应用程序想要建立的会话的信息，包括要使用的编解码器，这是音频还是视频会话等。它还包含 ICE candidates，它们B应用程序用于尝试连接A应用程序需要用到的A的IP和port。

为了建立ICE候选者列表，A的应用程序向STUN服务器发出了一系列请求。服务器返回发起请求的公共IP地址和端口对。A的应用程序将每对添加到ICE候选列表中，换句话说，它收集ICE候选。一旦A的应用程序完成了ICE候选者的收集，它就可以返回SDP。

接下来，A的应用程序必须通过这些应用程序进行通信的信令通道将SDP传递给B的应用程序。WebRTC标准未指定用于此交换的传输协议。它可以通过HTTPS，安全WebSocket或任何其他通信协议执行。

现在，B的应用程序必须生成一个SDP Answer。B的应用程序遵循上一步中使用的A步骤：收集ICE candidates等。然后B的应用程序需要将此SDP Answer通过信令服务器返回给A的应用程序。

在A和B交换了SDP之后，它们将执行一系列连接检查。每个应用程序中的ICE算法都从对方SDP中收到的列表中获取ICE candidates IP /端口对，并向其发送STUN请求。如果另一个应用程序返回了响应，则原始应用程序认为检查成功，并将该IP /端口对标记为有效的ICE候选者。

在对所有IP /端口对完成连接检查之后，应用程序进行协商并决定使用剩余的有效对之一。选择一对后，媒体开始在应用程序之间流动。(有效通道选择策略一般是host>p2p>releay)

如果任何一个应用程序都找不到通过连通性检查的IP /端口对，它们将向TURN服务器发出STUN请求以获取媒体中继地址。中继地址是一个公共IP地址和端口，用于转发与应用程序之间接收到的数据包并设置中继地址。然后将该中继地址添加到候选列表，并通过信令通道进行交换。

PS:实际上实现时，使用的是生成SDP和交换ICE candidates 可以是并行执行。即生成SDP并不需要与STUN服务器通信。ICE candidate 信息不用包含在SDP 中发送。这样可以提高建立链接的速度。不用等ICE candidate搜集完成后才进行信令通信。
CE candidates 可以是并行执行。即生成SDP并不需要与STUN服务器通信。ICE candidate 信息不用包含在SDP 中发送。这样可以提高建立链接的速度。不用等ICE candidate搜集完成后才进行信令通信。