WebRTC概念简介

WebRTC（Web Real-Time Communication）。Real-Time Communication，实时通讯。

WebRTC能让web应用和站点之间选择性地分享音视频流。在不安装其它应用和插件的情况下，完成点对点通信。

WebRTC背后的技术被实现为一个开放的Web标准，并在所有主要浏览器中均以常规Javascript API的形式提供。对于客户端（例如Android和iOS），可以使用提供相同功能的库。 WebRTC是个 开源项目 ，得到Google，Apple，Microsoft和Mozilla等等公司的支持。2011年6月1日开源并在Google、Mozilla、Opera支持下被纳入万维网联盟的W3C推荐标准。

WebRTC包括一系列API和相互关联的协议来实现通信。

Voice over Internet Protocol，在网络上传输声音消息的技术。

例如网络音频通话。或者叫做IP电话，宽带电话。使用VoIP技术的一大原因是费用低。

Network address translation，网络地址转换。

NAT能给你的设备一个公共IP地址。一个路由器（router）有一个公共IP地址，每个连接到路由的设备有一个私有的IP地址。

设备发送请求时，会从一个特定端口，通过私有IP发送到路由的公共IP。这样每个设备在网上不需要都有一个公共IP地址，但也能被其它设备发现。

参考 IP Network Address Translator (NAT) Terminology and Considerations

Interactive Connectivity Establishment，互动式连接建立（交互式连通性建立）。

ICE是一套能让web浏览器之间互相连接的框架。通常来说，节点A到B是很难直接相连的。防火墙会阻止连接，设备没有公共IP地址，路由不允许直接连接其他节点。

ICE使用STUN或者TURN服务（或者同时使用两者）来建立连接。

参考 ICE | rfc8445

Session Traversal Utilities for NAT (STUN) ，NAT会话传输工具。

STUN协议能发现客户端（节点）的公共地址。客户端发送一个请求给网上的STUN服务器，服务器返回客户端的公共地址。不管客户端在路由器的NAT后能否可达。

STUN为请求者提供了可公开访问的IP地址，它就不再参与对话了。

有些路由器会限制设备与外面其它设备的连接。这意味着即使STUN服务器知道了路由的公共IP地址，也没法建立连接。

这种情况下我们需要使用 TURN 。

Traversal Using Rel***s around NAT，使用中继绕过NAT传输。

一些路由器使用一种叫“Symmetric NAT”（对称型NAT）的限制。这意味着路由器仅允许之前连接过的节点（peer）来建立连接。

STUN 提供了一个能让应用（终端，节点）穿过NAT的方法。STUN允许客户端获得一个传输地址（一个IP和端口）来获取其它节点的数据。

然而STUN获取到的地址不一定能被所有节点使用。这些地址是否可用取决于网络拓扑的情况。所以，单独STUN无法提供完整的穿越NAT的方案。

TURN协议允许两个处于NAT环境的主机利用中继进行通讯。客户端能够在TURN服务器上分配资源，与其它客户端（peer）进行通讯。

客户端关联一个TURN服务器的地址（rel***ed server address）来作为中继。

客户端发送报文给TURN服务，TURN服务使用rel***ed server address作为源地址向其他客户端中继转发报文。

穿越NAT，这个过程就像是“打洞”。也有人称TURN服务器为“打洞服务器”。

这么看，TURN服务器需要有大的带宽。因此，ICE会优先考虑直接通讯，无法直接通讯情况下会使用TURN。

参考 TURN rfc8656

Session Description Protocol，会话描述协议。

描述多媒体连接内容的协议。例如分辨率，格式，编码，加密算法等等。

实际上，SDP不是个真正的协议。它也是用来描述设备之间连接与传输多媒体的数据格式。

参考 SDP: Session Description Protocol | rfc8866

一些缩写

更多请参考 WebRTC概念简介

WebRTC介绍

1、 WebRTC是什么？

2、 WebRTC能做什么?

3、 常用API

4、 基本原理

WebRTC全称是Web Real-Time communication，是一种实时音视频通讯技术，通过WebRTC可以使浏览器之间建立点对点的连接，并实时传输数据。

通过上述图片可以看到【浏览器M】和【浏览器L】可以在不依赖于Web服务器的情况下点对点实时传输数据。上图中的Web服务器不是用于数据传输，而是用于协助【浏览器M】和【浏览器L】进行连接，进行协助连接的服务器也叫【信令服务器】。

WebRTC主要分为四部分，分别是信令、建立连接、安全加密、数据传输，下面分别介绍四个步骤。

信令是指通信两端基于交换的数据进行协商。通俗的解释就是在互联网中两个浏览器之间如果要进行点对点的数据传输，连接双方需要交换对方的一些基本信息，基本信息包括对方的地址，带宽，数据的编解码格式，是否支持音视频等等信息。

通信双方的基本信息完成交换后，浏览器双方开始建立连接。在网络中，浏览器双方可能在同一个内网，可能不在同一个内网，中间可能还隔着交换机、路由器，还会存在防火墙。在网络的环境复杂的情况下，通信的双方需要找到一条***路径传输数据建立连接。建立连接主要使用的协议就是ICE协议。【ICE协议】又需要依赖【STUN协议】和【TURN协议】。

在WebRTC中，为了保证媒体传输的安全性，引入了【DTLS】作为传输加密协议，DTLS原理和作用类似于SSL/TLS，【DTLS】主要适用于UDP通信过程的加密，SSL/TLS主要适用于TCP通信过程的加密。

在WebRTC中，音视频数据传输是使用RTP协议，然后通过 DTLS 协商出加密密钥之后，RTP 也需要升级为 SRTP，通过密钥加密后进行通信。协议栈如下图所示：

上面说了对数据加密是使用DTLS，传输数据则分为两种情况，一种是传输音视频数据，另一种是传输自定义应用数据。

1、音视频数据传输，主要使用RTP/SRTP、RTCP/SRTCP协议

前面主要对WebRTC做了一个简单介绍，跳过了很多细节，有些地方可能不够严谨，如果有兴趣的读者，可以对技术做进一步研究，比如：

1、信令如何进行协商？

2、传输层用了UDP，UDP本身是不可靠的，那么，音视频数据、自定义用户数据的时序、质量是如何保证的？

3、RTP用来传递音视频数据，为什么还需要有RTCP？

4、SCTP如何从协议层面兼顾传输的效率和质量？如何实现自定义数据的高效传递？

5、ICE协议的完整流程。

6、其他。

WebRTC 的传输协议

WebRTC 的实现中媒体数据和媒体控制数据通过 RTP/RTCP 来传，媒体数据的处理及媒体数据传输控制基于 RTP/RTCP 来实现。除了 RTP/RTCP 外，连接建立，参数协商，RTP/RTCP 包的传输等过程由信令协议、peer connection 和 p2p 完成，这部分也用到了非常多的协议，包括 ICE，STUN，TURN，SDP，DTLS 等，这些协议有许多的 RFC 定义。这些协议大多也都随着时间在更新优化。

这里梳理一下相关的协议及它们的变化发展。

RFC 5245, Interactive Connectivity Establishment (ICE): A Protocol for Network Address Translator (NAT) Traversal for Offer/Answer Protocols

RFC 6336, IANA Registry for Interactive Connectivity Establishment (ICE) Options

RFC 8445, Interactive Connectivity Establishment (ICE): A Protocol for Network Address Translator (NAT) Traversal

RFC 8839, Session Description Protocol (SDP) Offer/Answer Procedures for Interactive Connectivity Establishment (ICE)

RFC 8838, Trickle ICE: Incremental Provisioning of Candidates for the Interactive Connectivity Establishment (ICE) Protocol

RFC 8863, Interactive Connectivity Establishment Patiently Awaiting Connectivity (ICE PAC)

RFC 5389, Session Traversal Utilities for NAT (STUN)

RFC 7350, Datagram Transport L***er Security (DTLS) as Transport for Session Traversal Utilities for NAT (STUN)

RFC 8553, DNS AttrLeaf Changes: Fixing Specifications That Use Underscored Node Names

RFC 5928, Traversal Using Rel***s around NAT (TURN) Resolution Mechani***

RFC 8489, Session Traversal Utilities for NAT (STUN)

RFC 5766, Traversal Using Rel***s around NAT (TURN): Rel*** Extensions to Session Traversal Utilities for NAT (STUN)

RFC 6156, Traversal Using Rel***s around NAT (TURN) Extension for IPv6

RFC 8656, Traversal Using Rel***s around NAT (TURN): Rel*** Extensions to Session Traversal Utilities for NAT (STUN)

RFC 4347, Datagram Transport L***er Security

RFC 5746, Transport L***er Security (TLS) Renegotiation Indication Extension

RFC 7507, TLS Fallback Signaling Cipher Suite Value (SCSV) for Preventing Protocol Downgrade Attacks

RFC 6347, Datagram Transport L***er Security Version 1.2

RFC 5763, framework for Establishing a Secure Real-time Transport Protocol (SRTP) Security Context Using Datagram Transport L***er Security (DTLS)

RFC 8842, Session Description Protocol (SDP) Offer/Answer Considerations for Datagram Transport L***er Security (DTLS) and Transport L***er Security (TLS)

RFC 4566, SDP: Session Description Protocol

RFC 8866, SDP: Session Description Protocol

关于webrtc协议和webrtc协议前端怎么处理的介绍到此就结束了，不知道你从中找到你需要的信息了吗 ？如果你还想了解更多这方面的信息，记得收藏关注本站。