webrtc详细介绍

自作笔记，来自https://hpbn.co/webrtc/，出自一本好书《High Performance
Browser Networking》

w3c webrtc文档

web层主要接口：
MediaStream: 采集音视频
RTCPeerConnection: 传输音视频
RTCDataChannel: 传输自定义数据

前言一大段废话，强调了一下webrtc使用的udp，但不是普通的udp，在udp上做了很多优化云云。。

webrtc标准和开发

• Web Real-Time Communications (WEBRTC) W3C Working Group是负责定义浏览器接口部分标准的组织
• Real-Time Communication in Web-browsers (RTCWEB) 是 IETF 工作组，负责定义协议，数据格式，安全，以及一切技术底层。

webrtc具有很强的扩展性，容易跟其他现有的音视频通讯系统结合。符合现在网速的爆发性增长，很有前瞻性。

音视频引擎

1.在发送端，问题点在于应对不断波动的带宽和延迟，对音视频流进行处理。
2.在接收端，流程是相反的，客户端必须实时解码流，并能够适应网络抖动和延迟延迟。
总之，捕获和处理音频和视频是一个复杂的问题。

获得音频流后，进行噪声减少和回声消除，然后自动选择窄带或宽带进行编码。最后，一个特殊的错误隐藏算法被用来隐藏网络抖动和丢包的负面影响，这只是亮点！视频引擎通过优化图像质量、选择最佳的压缩和编解码器设置、应用抖动和包丢失隐藏等来执行类似的处理。
所有的处理都是由浏览器直接完成的，更重要的是，浏览器动态地调整其处理管道，以计算音频和视频流和网络状态的不断变化的参数。一旦完成所有这些工作，Web应用程序将接收优化的媒体流，然后它可以输出到本地屏幕和扬声器，转发到其他对等端，或使用HTML5媒体API的后期处理！

音视频获取及处理（getUserMedia）
媒体捕获和流W3C规范定义了一组新的JavaScript API，使应用程序能够从平台请求音频和视频流，以及一组API来处理和处理所获取的媒体流。（图18-2）mediastream对象是主要的接口。

• mediastream对象包含一个或多个单独的轨道（mediastreamtrack）。
• 同属于一个mediastream的track间彼此同步。
• 输入源可以是物理设备，如麦克风、网络摄像机或来自用户硬盘或远程网络对等点的本地或远程文件
• mediastream的输出可以被发送到一个或多个目的地：本地video或audio元素，用JavaScript进行后期处理，或发送到远程节点。

我们可以对任意一个track进行操作，可以提出限制来获取适应的音视频源。另外，可以克隆track，修改track等等。

获取到track后，还能与其他web接口进行互动：

• Web Audio API允许在浏览器中处理音频。
• Canvas API 可对单个frame进行处理

• CSS3和WebGL API可以对输出流添加各种2D和3D效果。

  Media Capture and Streams APIs

目前webrtc默认音频编码格式为opus，视频vp8.
opus码率：6-510kbit/s
vp8码率：100-2000kbit/s
720p at 30 FPS: 1.0~2.0 Mbps
360p at 30 FPS: 0.5~1.0 Mbps
180p at 30 FPS: 0.1~0.5 Mbps
一般一个peer端需要2.5mbps的带宽可进行高清视频聊天。

实时网络传输

实时通信是对时间非常敏感的。因此，音视频流应该可以容忍间歇性的分组丢失：音频和视频编解码器可以填充小的虚假数据，通常对输出质量影响极小。另外，应用程序可以传送额外的数据来恢复丢失或延迟的数据包，但是及时性和低延迟比可靠性更重要。
由于实时性的需要选择udp。

补充说明（有空再看看）：
Building Blocks of UDP

webrtc协议栈：

ICE: Interactive Connectivity Establishment (RFC 5245)
STUN: Session Traversal Utilities for NAT (RFC 5389)
TURN: Traversal Using Relays around NAT (RFC 5766)
SDP: Session Description Protocol (RFC 4566)
DTLS: Datagram Transport Layer Security (RFC 6347)
SCTP: Stream Control Transport Protocol (RFC 4960)
SRTP: Secure Real-Time Transport Protocol (RFC 3711)

RTCPeerConnection

RTCPeerConnection 功能：

• 负责整个ICE流程
• 负责发送automatic (STUN) keepalives， 保持peers的连接
• 管理本地媒体流
• 管理远程流
• 触发各种跟媒体流有关的事件
• 提供offer，answer，连接状态查询等API

DataChannel可配置成可靠的，不可靠的，有序的，无序的。

建立Peer-to-Peer连接

通知（信令）和初始会话协商的交付留给应用程序
不展开，可看我其他文章
浏览器网络连接

ICE的工作模式有3种：

1. 交互式ICE
   ICE agent：
   每个RTCPeerConnection都包含一个ICE agent，负责收集本地ip，port对；负责进行peer间的连接检查；负责发送keepalives。

   一旦sdp（本地或者远端）设置好，ICE agent开始自动发现本地可能的ip：port对：
   1.获取本地ip
   2.如果有配置，从STUN获取公网ip:port
   3.如果有配置，TURN作为最后的手段，对数据包进行转发。

当一个新的candidate被发现，agent自动添加到RTCPeerConnection，并通过onicecandidate回调。当ICE收集完成，也通过这个回调告诉你。

var ice = {
  "iceServers": [
  {
  "url": "stun:stun.l.google.com:19302"}, 
  {
  "url": "turn:turnserver.com", "username": "user", "credential": "pass"} 
]};

var signalingChannel = new SignalingChannel();
var pc = new RTCPeerConnection(ice);

navigator.getUserMedia({ "audio": true }, gotStream, logError);

function gotStream(stream) {
  pc.addStream(stream);

  pc.createOffer(function(offer) {
    pc.setLocalDescription(offer); 
  });
}

pc.onicecandidate = function(evt) {
  if (evt.target.iceGatheringState ==