WebRTC 学习资料整理一

最新推荐文章于 2024-08-09 06:00:00 发布

natureXin

最新推荐文章于 2024-08-09 06:00:00 发布

阅读量4.1k

点赞数

分类专栏： WebRtc

WebRtc 专栏收录该内容

3 篇文章 1 订阅

订阅专栏

官网永远是最重要，但同时也是最容易忽略的学习途径。So you should look official websites firtsly.。

先看一看基础概念的解释
WebRTC 相關縮寫名詞簡介

推荐一种方式，打开官方给的例子，然后通过浏览器调试，定位到控制到就能够看到这个流程了。WebRTC samples
如下：

Offer/Answer 與 Signal Channel 是什麼？

WebRTC 必須透過某種中介伺服器才能建立連線，而我們稱這種媒介為「訊號通道 (Signal Channel)」。也就是說，在建立連線之前，會先透過訊號通道交換建立連線所需的資訊。

我們所要交換的資訊就是「Offer」與「Answer」，而其內容就是上述的 SDP。

當 Peer A 設立連線時，就會建立 Offer。接著會透過選定的訊號通道將此 Offer 傳送給 Peer B。在 Peer B 收到訊號通道傳來的 Offer 之後，就會建立 Answer，並透過同樣的訊號通道將 Answer 回傳給 Peer A。

ICE Candidate 是什麼？

如上所述，Offer/Answer 與 SDP 用以交換多媒體的格式內容；ICE candidate 則用以交換網路連線的建立方式，並可說明端點溝通的方法 (直接通訊，或透過 TURN 伺服器通訊)。

概述

二、A Closer Look Into WebRTCwebkit添加新内容

环境搭建

一、Webrtc服务器搭建

通话的房间服务器(Room Server)
通话的信令服务器(Signaling Server)
防火墙打洞服务器(STUN/TURN/ICE Server)

二、iOS下音视频通信-基于WebRTC非常全面的介绍，并且有Demo。大爱，跟着demo走一遍就熟了

严格来说它仅仅是不需要服务端来进行数据中转而已。

WebRTC至少有两件事必须要用到服务器：

浏览器之间交换建立通信的元数据（信令）必须通过服务器。
- 我们在A和B需要建立P2P连接的时候，至少要服务器来协调，来控制连接开始建立。而连接断开的时候，也需要服务器来告知另一端P2P连接已断开。这些我们用来控制连接的状态的数据称之为信令，而这个与服务端连接的通道，对于WebRTC而言就是信令通道。
- 在建立连接之前，客户端之间显然没有办法传递数据。所以我们需要通过服务器的中转，在客户端之间传递这些数据，然后建立客户端之间的点对点连接。但是WebRTC API中并没有实现这些，这些就需要我们来实现了。
为了穿越NAT和防火墙。
WebRTC主要实现了三个API

MediaStream：通过MediaStream的API能够通过设备的摄像头及话筒获得视频、音频的同步流
RTCPeerConnection：RTCPeerConnection是WebRTC用于构建点对点之间稳定、高效的流传输的组件
RTCDataChannel：RTCDataChannel使得浏览器之间（点对点）建立一个高吞吐量、低延时的信道，用于传输任意数据。
其中RTCPeerConnection是我们WebRTC的核心组件。

P2P连接的过程

A和B连接上服务端，建立一个TCP长连接（任意协议都可以，WebSocket/MQTT/Socket原生/XMPP），我们这里为了省事，直接采用WebSocket，这样一个信令通道就有了。
A从ice server（STUN Server）获取ice candidate并发送给Socket服务端，并生成包含session description（SDP）的offer，发送给Socket服务端。
Socket服务端把A的offer和ice candidate转发给B，B会保存下A这些信息。
然后B发送包含自己session description的answer(因为它收到的是offer，所以返回的是answer，但是内容都是SDP)和ice candidate给Socket服务端。
Socket服务端把B的answer和ice candidate给A，A保存下B的这些信息。

三、WebRTC(iOS)下载编译(下载指定版本)

点对点连接下，会导致这样一个问题：

如果客户端A想给客户端B发送数据，则数据来到客户端B所在的路由器下，会被NAT阻拦，这样B就无法收到A的数据了。
但是A的NAT此时已经知道了B这个地址，所以当B给A发送数据的时候，NAT不会阻拦，这样A就可以收到B的数据了。这就是我们进行NAT穿越的核心思路。

思路：
我们借助一个公网IP服务器。a、b都往公网IP/PORT发包,公网服务器就可以获知a,b的IP/PORT，又由于a,b主动给公网IP服务器发包，所以公网服务器可以穿透NAT A,NAT B送包给a,b。
所以只要公网IP将b的IP/PORT发给a,a的IP/PORT发给b。这样下次a和b互相消息，就不会被NAT阻拦了。

基础概念

一、WebRTC入门教程.md

STUN (Session Traversal Utilities for NAT) 只能UDP，告诉我暴露在广域网的地址IP port ，我通过映射的广域网地址进行P2P数据通信。
TURN( Traversal Using Relays around for NAT)UDP或TCP，打洞失败后，提供服务器中转数据，通话双方数据都通过服务器，占服务器带宽较大 - 为了确保通话在绝大多数环境下可以正常工作。跨网只能用服务器中转（测试发现的），使用TURN这种情况在视频通话中占10%
ICE 网络连接服务

二、WebRtc建立P2P链接的总体流程UML类图非常不错。

链接总体流程
时序图
类图

协议

一、NAT

NAT（Network Address Translation，网络地址转换）是1994年提出的。当在专用网内部的一些主机本来已经分配到了本地IP地址（即仅在本专用网内使用的专用地址），但现在又想和因特网上的主机通信（并不需要加密）时，可使用NAT方法。这种通过使用少量的公有IP 地址代表较多的私有IP 地址的方式，将有助于减缓可用的IP地址空间的枯竭。

NAT实现方式：即静态转换Static Nat、动态转换Dynamic Nat和端口多路复用OverLoad
NAT穿透方法：目前常用的针对UDP的NAT 穿透（NAT Traversal）方法主要有：STUN、TURN、ICE、uPnP等。其中ICE方式由于其结合了STUN和TURN的特点，所以使用最为广泛。针对TCP的NAT穿透技术目前仍为难点。实用的技术仍然不多。
NAT工作原理：NAT将自动修改IP报文的源IP地址和目的IP地址，Ip地址校验则在NAT处理过程中自动完成。有些应用程序将源IP地址嵌入到IP报文的数据部分中，所以还需要同时对报文的数据部分进行修改，以匹配IP头中已经修改过的源IP地址。否则，在报文数据部分嵌入IP地址的应用程序就不能正常工作。简单来讲就是通过一个转换头，将内网地址变为公网地址，接收的时候根据记录将公网地址变成内网，完成传输。

二、STUN

是一种网络协议，它一种网络协议，它允许位于NAT（或多重NAT）后的客户端找出自己的公网地址，查出自己位于哪种类型的NAT之后以及NAT为某一个本地端口所绑定的Internet端端口。这些信息被用来在两个同时处于NAT 路由器之后的主机之间建立UDP通信。。目的就是找到外界连接内部地址的所需信息。

STUN是一个客户机－服务器协议。一个VoIP电话或软件包可能会包括一个STUN客户端。这个客户端会向STUN服务器发送请求，之后，服务器就会向STUN客户端报告NAT路由器的公网IP地址以及NAT为允许传入流量传回内网而开通的端口。

以上的响应同时还使得STUN客户端能够确定正在使用的NAT类型——因为不同的NAT类型处理传入的UDP分组的方式是不同的。四种主要类型中有三种是可以使用的：完全圆锥型NAT、受限圆锥型NAT和端口受限圆锥型NAT——但大型公司网络中经常采用的对称型 NAT（又称为双向NAT）则不能使用。

三、STUN和TURN技术浅析比较全面的分析

STUN（Simple Traversal of User Datagram Protocol Through Network Address Translators），即简单的用UDP穿透NAT，是个轻量级的协议，是基于UDP的完整的穿透NAT的解决方案。它允许应用程序发现它们与公共互联网之间存在的NAT和防火墙及其他类型。它也可以让应用程序确定NAT分配给它们的公网IP地址和端口号。STUN是一种Client/Server的协议，也是一种Request/Response的协议，默认端口号是3478。

在现实Internet网络环境中，大多数计算机主机都位于防火墙或NAT之后，只有少部分主机能够直接接入Internet。很多时候，我们希望网络中的两台主机能够直接进行通信，即所谓的P2P通信，而不需要其他公共服务器的中转。由于主机可能位于防火墙或NAT之后，在进行P2P通信之前，我们需要进行检测以确认它们之间能否进行P2P通信以及如何通信。这种技术通常称为NAT穿透（NAT Traversal）。最常见的NAT穿透是基于UDP的技术，如RFC3489中定义的STUN协议。

NAT对待UDP的实现方式有4种方式、简单可以理解为：

随便搞，没搞过的也可以搞
只有搞过的才能搞
之前带过套的才能搞
只有搞得爽的才能搞

TURN，首先在RFC5766中定义，英文全称是Traversal Using Relays around NAT:Relay Extensions to Session Traversal Utilities for NAT，即使用中继穿透NAT:STUN的扩展。简单的说，TURN与STURN的共同点都是通过修改应用层中的私网地址达到NAT穿透的效果，异同点是TURN是通过两方通讯的“中间人”方式实现穿透。

如果一个主机位于NAT的后面，在某些情况下它不能够与其他主机点对点直接连接。在这些情况下，它需要使用中间网点提供的中继连接服务。TURN协议就是用来允许主机控制中继的操作并且使用中继与对端交换数据。TURN与其他中继控制协议不同的是它能够允许一个客户端使用一个中继地址与多个对端连接。

四、WebRTC protocols

五、SDP 协议分析

SDP 完全是一种会话描述格式 ― 它不属于传输协议 ― 它只使用不同的适当的传输协议，包括会话通知协议（SAP）、会话初始协议（SIP）、实时流协议（RTSP）、MIME 扩展协议的电子邮件以及超文本传输协议（HTTP）。SDP协议是也是基于文本的协议，这样就能保证协议的可扩展性比较强，这样就使其具有广泛的应用范围。SDP 不支持会话内容或媒体编码的协商，所以在流媒体中只用来描述媒体信息。