WebRTC的RTCPeerConnection()原理探析

本文主要是介绍WebRTC的RTCPeerConnection()原理探析，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！

WebRTC的RTCPeerConnection()原理探析

从getUserMedia()到RTCPeerConnection()，自认为难度陡增。我想一方面是之前在Linux平台上学习ROS调用摄像头时，对底层的外设接口调用、摄像头参数都有学习理解；另一方面是，我们在大三下学期才开始计算机网络的课程学习，对网络通信的理解尚处于未能达到闭环的自闭状态（自闭——"全程自学完成知识闭环"）
面对ICE、SDP、NAT gateways、STUN、TURN等词汇异常懵逼（解释可以参考这篇introduction）所以写文如下，增进自己的理解，也为同样对这部分困惑的人提供一份参考

写在前面
WebRTC P2P的现实物理实现
signaling的具体实现过程

写在前面

目前，在看过一些WebRTC的资料之后，认为RTCPeerConnection()是最难的但也是最关键的，同样在RTCPeerConnection()中，signaling部分是最难的，但也是最重要的，我想弄清楚这个部分，对WebRTC的各种跨平台搭建会非常有帮助（跨PC、Android、Raspberry Pi）
建立了解基本的计算机网络知识，比如协议架构模型、设备之间的通信所需的基本步骤
OK，先忽略各种具体的API，从一个基于现实物理器械的现实角度看看WebRTC的P2P到底怎么实现，参考Lifetime of a WebRTC session

WebRTC P2P的现实物理实现

想必大家都寄过快递，给人寄快递，就是一个很典型的P2P的过程，下面对应WebRTC来讲解一下这个过程

getUserMedia() 把要寄的东西找出来，在WebRTC里面对应的就是获取audio | video，以及对对获取设备的选择、分辨率的设置之类
RTCPeerConnection() 的signaling，类似于选什么快递公司（communication protocols），要寄的东西要不要处理一下形式、要装箱子寄还是塑料袋就好、收到快递打开使用有没有注意事项（media codecs and formats），填好寄到的地址（IP adress and port information），然后快递就可以寄出了

Signaling is the process of sending control information between two devices to determine the communication protocols, channels, media codecs and formats, and method of data transfer, as well as any required routing information.

There are three basic types of information that need to be exchanged during signaling:

Control messages used to set up, open, and close the communication channel, and to handle errors.
Information needed in order to set up the connection: the IP addressing and port information needed for the peers to be able to talk to one another.
Media capability negotiation: what codecs and media data formats can the peers understand? These need to be agreed upon before the WebRTC session can begin.

通过RTCPeerConnection() 里的一系列API实现上述signaling 过程，这个过程在下一节里面详细分解
当然寄快递有时候也会出现错误或者碰到异常情况（虽然现实中这种情况我没遇到过），假如是每天都要发一次货物的那种，ICE restart，就是指去找新的发货方式，在找到新的发货渠道之前保持原来的方式，直到找到新的发货方式

signaling的具体实现过程

先放一张示意图（来源）

WebRTC_signaling

理论过程:

Each peer creates an RTCPeerConnection object representing their end of the WebRTC session.
Each peer establishes a handler for icecandidate events, which handles sending those candidates to the other peer over the signaling channel.
Each peer establishes a handler for track event, which is received when the remote peer adds a track to the stream. This code should connect the tracks to its consumer, such as a <video> element.
The caller creates and shares with the receiving peer a unique identifier or token of some kind so that the call between them can be identified by the code on the signaling server. The exact contents and form of this identifier is up to you.
Each peer connects to an agreed-upon signaling server, such as a WebSocket server they both know how to exchange messages with.
Each peer tells the signaling server that they want to join the same WebRTC session (identified by the token established in step 4).