webRTC介绍

参考文档: https://tonybai.com/2023/09/23/p2p-rtc-implementation-with-go-and-webrtc-data-channel/

关于实时通信(RTC，Real-Time Communication)，我和大多数人一样，是用的多(比如网络电话、音视频会议等)，但对RTC概念和其底层技术原理了解的却不多。近期，一项目恰用到了RTC技术，我就顺便翻阅了一些资料，并用Go建立了一个端到端数据通信的小demo，这里给大家分享一下。

RTC

实时通信(Real-Time Communication)

实时通信（RTC）是实时发生的任何在线通信。生活中，最常见的采用实时通信方式的例子就是电话：一旦双方接通后，数据便直接从发送方即时发送到接收方，不会存储在前往目的地的途中。

而传统的邮件以及互联网电子邮件则并非实时通信，因为在邮件/电邮的场景下，我们发送数据后，对方通常要等待一段时间才能收到数据，同时我们也需要等待一段时间才能收到回复。相信这个反例可以更好地帮助大家理解实时通信的特点。

总结一下，实时通信具有以下特点(想象一下打电话的过程)：

  • 存在接通的过程
  • 点对点(通常没有中间存储或处理节点)
  • 传输低延迟

WebRTC

WebRTC技术的诞生

显然RTC技术是一种能给人们生活带来极大便捷的技术，尤其是在音视频实时传输方面，但很长时间以来，实时通信技术都十分复杂，还有专利门槛，将实时通信技术与业务结合既非常困难，又十分耗时，并且即便大力投入也未必能取得很好的效果，通常只有大厂才有这个能力实现稍完善的RTC方案和产品。

此外，随着Web技术的兴起、移动互联网时代的到来、4G/5G和宽带技术的蓬勃发展，人们都迫切希望将实时通信技术与Web等技术融合在一起，通过浏览器或智能终端即可快速建立音视频的实时数据通信。

于是2009年谷歌出手了！

  • 2009年，谷歌提出了创建WebRTC的概念，作为Adobe Flash以及无法在浏览器中运行的桌面应用程序的替代方案。
  • 2010年，谷歌收购了大量提供RTC技术授权的公司。
  • 2011年，谷歌开源了WebRTC项目。
  • 2011年末，W3C发布第一个WebRTC规范草案。
  • 2013年，谷歌和Mozilla展示了基于WebRTC的异构浏览器之间的视频通话。
  • 2017年，WebRTC进入候选推荐标准（Candidate Recommendation，CR）阶段。
  • 2021年初，WebRTC成为W3C正式推荐标准及IETF标准。

如今，WebRTC已经广泛用在了在线教育、电商直播、泛娱乐社交等应用领域。

WebRTC简明介绍

WebRTC(Web Real-Time Communication)是一套开源的点对点实时通信技术，最初为Web打造，旨在让Web应用可以直接在浏览器中进行实时的音视频通信和数据交换，而无需安装第三方插件。WebRTC具体体现为一组开源协议、引擎和API。

下面是W3C出品的WebRTC的技术栈的架构图(来自https://webrtc.github.io/webrtc-org/architecture/)：

webRTC_intraduction_1.webp

我们看到WebRTC还是蛮复杂的，涉及到多类API、会话/信令管理、音频编解码算法引擎、视频编解码算法引擎、包含多种协议的传输层以及底层音视频捕捉和渲染等。全面掌握WebRTC全技术栈是很困难的，好在上面的架构图将不同领域的开发者的关注点做了标记，大多数开发者关注WebRTC API和Web API即可。并且，随着WebRTC自身的演进，目前WebRTC已经不局限于浏览器，可以应用于其他各种应用程序。在Go社区，最知名的WebRTC类项目莫过于pion了，它提供了纯Go的WebRTC API实现，任何Go应用都可以使用pion的WebRTC API开发点对点实时通信应用。

WebRTC相关的协议

WebRTC并没有全部另立炉灶从头建立很多新协议，而是复用了很多成熟的网络协议和应用协议，尤其是涉及数据传输的协议。下图是WebRTC中使用的一些重要协议分布图：

webRTC_intraduction_2.webp

图改自《WebRTC技术详解》一书

很多协议大家都非常熟悉，比如HTTP、WebSocket、TLS、TCP、UDP等，但也有些协议是大家比较陌生的，如RTP/SRTP、SCTP等，针对这些陌生协议，我们下面简要介绍一下：

RTP和SRTP

RTP(Real-time Transport Protocol，实时传输协议)和SRTP(Secure RTP)

RTP协议支持通过IP网络实时传输音频和视频。RTP常用于流媒体服务的通信系统，例如网络电话、视频电话会议等系统。RTP也是WebRTC使用的最重要的协议之一，在WebRTC中，RTP用于在WebRTC客户端(比如浏览器)之间传输音频和视频媒体(media)数据包。

RTP是专为流媒体的端到端实时传输设计的，更关注信息的实时性，可以避免出现因网络传输丢失数据造成通话质量下降的情况。并且，如上图所示，RTP都是基于UDP构建的，并额外提供抖动补偿、包丢失检测和无序传递检测的功能。

此外，RTP在传递媒体流时会为每个媒体流建立一个会话，即音频和视频流各自使用单独的RTP会话，这样接收端就能有选择性地接收媒体流(音频、视频或音视频)。

基础的RTP没有内置任何安全机制，因此不能保证传输数据的安全性，这样端与端之间通信传输未加密的数据时，都有可能被第三方拦截并窃取。为此，WebRTC规范明确禁止使用未加密的RTP，而是使用安全增强后的SRTP(Secure RTP)。SRTP可以为单播和多播应用程序中的RTP数据提供加密、消息身份验证和完整性以及重放攻击保护等安全功能。

注：对于非音频或视频数据，WebRTC不使用RTP，而是在通信的两端建立一个data channel用于交换任意格式的数据。

SCTP

SCTP(Stream Control Transmission Protocol，SCTP）

WebRTC的端与端建立连接后，音视频数据的交互由RTP/SRTP协议完成，但非音视频数据，则由两端之间建立的数据通道(data channel)完成。数据通道支持传输字符串、文件、图片等数据。

数据通道API的使用方式与WebSocket非常相似，但是WebSocket运行于TCP之上，而WebRTC数据通道的底层传输使用了DTLS/UDP，具有较高的安全性，上层则是使用SCTP，默认使用可靠且有序的方式进行数据传输。

SCTP是在2000年由IETF的SIGTRAN工作组定义的一个传输层协议。它是面向连接、端到端、全双工、带有流量和拥塞控制的可靠传输协议，本来与TCP和UDP处于同一级别，可以直接运行在IP之上。只是在WebRTC中，它被用在了应用层。

ebRTC充分利用了SCTP的面向消息(非tcp那样的面向流)的、带有拥塞控制算法的可靠传输机制，同时SCTP支持在一个传输通道中关联多个流的特性，这样每个流可以单独处理，甚至可以具有不同的可靠性属性。流与流之间不存在线头阻塞问题。流由流编号标识，可以在一定程度上提供多路复用功能，而无需开多个SCTP连接。

SDP

SDP(Session Description Protocol, 会话描述协议)

SDP是一种文本形式的会话描述协议，用于描述多媒体会话的参数。

SDP是WebRTC端与端建立连接过程中必须要使用的协议。WebRTC使用SDP来描述对等连接的两端的媒体特征，包括会话属性、会话活动的时间、会话包含的媒体信息、媒体编/解码器、媒体地址和端口信息以及网络带宽的信息等。

下面是SDP协议内容的一个典型例子(来自https://developer.mozilla.org/en-US/docs/Glossary/SDP)：

v=0
o=alice 2890844526 2890844526 IN IP4 host.anywhere.com
s=
c=IN IP4 host.anywhere.com
t=0 0
m=audio 49170 RTP/AVP 0
a=rtpmap:0 PCMU/8000
m=video 51372 RTP/AVP 31
a=rtpmap:31 H261/90000
m=video 53000 RTP/AVP 32
a=rtpmap:32 MPV/90000

WebRTC的两个端在使用RTP/SRTP传输音视频数据或使用SCTP传输data channel数据之前，需要先建立连接。建立连接的过程类似于传统电话从拨号、呼叫等待、到接通的过程。这个过程通常会有一个叫信令服务器(signaling server)的中间角色(好比文首配图的人工电话交换机)参与。而SDP在建连过程中起着重要作用，信令服务器会将两端的SDP转发给另一方，直到两端都拥有了自己和对方的会话描述信息(SDP承载)，并在媒体交换格式方面达成了一致，这是两端连接成功的前提。

注：SDP不是WebRTC专属的，SDP在很多领域有广泛应用，最常见的就是即时通信(IM)领域。

STUN、TURN和ICE

使用WebRTC进行实时通信的两端通常都位于防火墙或NAT之后的“内网”，只有很少部分主机能够拥有独立的公网IP而直接接入Internet。也就是说，尝试建立连接的双方由于位于NAT网络之中，不能直接使用内网IP地址建立网络连接。WebRTC于是使用“NAT穿透技术(俗称打洞)”来帮助两端建立连接。

STUN就是一种最常见的NAT穿透协议，其全称是“Simple Traversal of UDP Through NATs”，即简单的用UDP穿透NAT。STUN本质上是一种公网地址及端口的发现协议，客户端向STUN服务器发送请求，STUN服务器返回客户端的公网地址及NAT网络信息。这些信息用于构建在ICE打洞时的候选地址，并由信令服务器转发给另一端。

不过STUN无法应对所有NAT网路情形，在对称NAT(映射的外网地址端口号不固定，会随着目的地址的变化而变化)情况下，WebRTC用户无法使用STUN协议建立P2P连接，这种情况就需要借助TURN协议提供的服务进行流量中转。

TURN（Traversal Using Relays around NAT）是一种通过数据转发的方式穿透NAT的，解决了防火墙和对称NAT的问题。TURN支持UDP和TCP协议。

注：使用STUN建立的是P2P的网络模型，网络连接直接建立在通信两端，没有中间服务器介入；而使用TURN建立的是流量中继的网络模型，用户两端都与TURN服务建立连接，用户的网络数据包通过TURN服务进行转发 — 《WebRTC技术详解》

我们看到，TURN与STUN的共同点都是通过修改应用层中的私网地址达到NAT穿透的效果，不同点是TURN是通过两方通讯的“中间人”方式实现穿透。但TURN与其他中继控制协议也有不同，它能够允许一个客户端使用一个中继地址与多个对端连接。

ICE(Interactive Connectivity Establishment, 交互式连接建立)跟STUN和TURN不一样，ICE不是一种协议，而是一个框架（Framework），它整合了STUN和TURN，并利用STUN和TURN服务器来帮助两端建立起连接。

WebRTC的一端通过ICE获得的每个网络信息都会被包装成一个ICE候选者(candidate)。ICE候选者描述了用于建立网络连接的网络信息，包含网络协议、IP地址、端口等。如果设备上有多个IP地址，那么每个IP地址都会对应一个候选。例如设备A上有内网IP地址IP-1，还有公网IP地址IP-2，A通过IP-1可以直接与B进行通信，但是WebRTC不会判断优先使用哪个IP地址，而是同样从两个IP地址收集候选，并将候选信息通过信令服务器转发给另一端。

ICE候选者有多种类型(以基于UDP传输为例)，包括host（本机候选）、srflx（映射候选）、relay（中继候选）和prflx（来自对称NAT的映射候选）。类型有优先级次序，其中host优先级最高，relay优先级最低。比如WebRTC收集到了两个候选者，一个是host类型，另一个是srflx类型，那么WebRTC一定会先尝试与host类型的Candidate建立连接，如果不成功，才会使用srflx类型的Candidate。

当两端都得到自己和对方的ICE候选信息后，就会进行ICE候选配对，并最终选出一个用于建立端与端连接的ICE候选者对(pair)，最终两端将基于这个候选者对中的网络信息建立了P2P的连接。

有了上面协议这层铺垫后，接下来我们再来看WebRTC建立连接的流程就容易多了。

WebRTC的建连流程

下面是WebRTC的典型建连流程图：

webRTC_intraduction_3.webp

如图所示，WebRTC端到端建立连接的第一步是与信令服务器建立连接并交换SDP信息。

信令服务器通常位于两端都能访问到的公网。当WebRTC一端启动后，它可能不知道要与谁通信，或者仅知道对方的极少的信息（比如一个ID），信令服务器可以帮助参与通信的两端解决这个问题。就像前面说的，你可以将信令服务器看作是电话人工交换机及其操作员，它可以帮助参与通信的两端找到彼此。WebRTC并未将信令服务器以及信令协议标准化，因为信令服务器是“业务相关”的，究竟是建立一对一连接，还是建立群聊，这些由信令服务器的业务来决定。承载信令的协议可以是普通的HTTP，也可以是WebSocket，亦可是像XMPP那样的专用信令协议。

在WebRTC中，主动发起连接的一方会创建offer，并通过信令服务器将offer转发给另一方；另一方收到offer后会创建answer，并同样通过信令服务器转发给发起方。无论是offer，还是answer，都包含了各自的SDP信息。

第二步，当交换SDP后，两端各自发起ICE过程，向STUN/TURN服务器发起请求，获取各自NAT后的公网信息，并形成ICE候选者。

第三步，双方通过信令服务器交换ICE候选者信息

当ICE候选者配对成功后，就来到了第四步，WebRTC两端直接建立连接。连接建立成功后，便可以进行数据传输交换了。

WebRTC data channel

上面提到过，WebRTC除了提供了音视频媒体实时通信能力外，还支持可以传输非媒体流数据的数据通道(data channel)。

和音视频数据一样，经由WebRTC数据通道进行的数据交换不经过服务器，不受服务器性能及带宽瓶颈的限制，同时减少了数据被拦截的概率。数据通道底层传输使用了DTLS，具有较高的安全性。上层使用SCTP，默认使用可靠且有序的方式进行数据传输。此外，data channel的建连过程与音视频的建连过程也是一致的。