《Web性能权威指南》-WebRTC-读书笔记

本文是《Web性能权威指南》第四部分——WebRTC的读书笔记。
第一部分——网络技术概览，请参考网络技术概览；
第二部分——无线网络性能，请参考无线网络性能；
第三部分——HTTP，请参考HTTP；
第四部分——欣赏器API与协议的前四章，请参考欣赏器API与协议。
WebRTC

Web Real-Time Communication，Web实时通信，WebRTC，由一组标准、协媾和JS API组成，用于实现欣赏器之间（端到端）的音频、视频及数据共享。WebRTC使得实时通信变成一种标准功能，任何Web应用都无需借助第三方插件和专有软件，而是通过简朴的JavaScript API即可使用。
要实现涵盖音频和视频的电话会议等美满、高品质的RTC应用、端到端的数据互换，必要欣赏器具备很多新功能：音频和视频处置惩罚本领、支持新应用API、支持好几种新网络协议。欣赏器把前述这些复杂性抽象成三个重要API：

• MediaStream：获取音频和视频流；
  
• RTCPeerConnection：音频和视频数据通信；
  
• RTCDataChannel：恣意应用数据通信。
  

WebRTC通过UDP传输数据。
标准和WebRTC的发展

WebRTC架构由十余个标准组成，涵盖应用和欣赏器API，以及很多必要的协媾和数据格式：

• W3C的Web Real-Time Communications（WEBRTC）Working Group负责订定欣赏器API；
  
• IETF的Real-Time Communication in Web-browsers（RTCWEB）工作组负责界说协议、数据格式、安全及其他在欣赏器中实现端到端通信必需的内容。
  

设计WebRTC时也会思量已有通信系统：VOIP（VoiceOver IP）、各种SIP客户端、PSTN（Public Switched Telephone Network，公共互换电话网）等。
音频和视频引擎

要实现电话会议功能，欣赏器必须访问系统硬件采集音频和视频；还需对它们分别加以处置惩罚以增强品质，保证同步，而且要适应不断变革的带宽和客户端之间的网络延迟调整输出的比特率。
吸取端的处置惩罚过程相反，必须实时解码音频和视频流，并适应网络抖动和时延。

如上图，欣赏器会负责：

• 音频流降噪和回声消除处置惩罚、优化的窄带或宽带音频编解码器编码、错误赔偿算法消除网络抖动和丢包造成的丧失；
  
• 视频的影像品质，选择最优的压缩和编解码方案，应用抖动和丢包赔偿。
  

欣赏器要动态调整其处置惩罚流程，以适应不断变革的音频和视频流及网络条件。
W3C的Media Capture and Streams规范规定一套JS API：

解读：

• MediaStream对象包罗一或多个Track（MediaStreamTrack）；
  
• MediaStream中的多个Track相互之间是同步的；
  
• 输入源可以是物理设备，如麦克风、摄像头、用户硬盘或另一端远程服务器中的文件；
  
• MediaStream的输出可被发送到一或多个目的地：本地的视频或音频元素、后期处置惩罚的JS代理，或远程另一端。
  

MediaStream对象表示一个实时的媒体流，以便应用代码从中取得数据，利用个别的Track和控制输出。所有的音频和视频处置惩罚，比如降噪、均衡、影像增强等都由音频和视频引擎主动完成。
getUserMedia()，从底层平台取得音频和视频流的简朴API；负责获准访问用户的麦克风和摄像机，并获取符合指定要求的流。取得流之后，还可以将它们提供给其他欣赏器API：

• 通过Web Audio API在欣赏器中处置惩罚音频；
  
• 通过Canvas API采集个别视频帧并加以处置惩罚；
  
• 通过CSS3和WebGL API为输出的流应用各种2D/3D特效。
  

当前的WebRTC实现使用Opus和VP8编解码器：

• Opus编解码器用于音频，支持固定和可变的比特率编码，适合的带宽范围为6~510Kbit/s。这个编解码器可以无缝切换，以适应不同的带宽。
  
• VP8编解码器用于视频编码，要求带宽为100~2000+Kbit/s，比特率取决于流的品质，如180p，360p，720p。
  

实时网络传输

实时通信讲求的就是实时、当下。因此，处置惩罚音频和视频流的应用一定要赔偿间歇性的丢包：音频和视频编解码器可以添补小的数据空白，通常对输出品质的影响也很小。类似地，应用必须实现自己的逻辑，以便因传输其他应用数据而丢包或延迟时快速恢复。实时和低延迟比可靠更重要。
UDP协议才更适合用于传输实时数据。UDP提供下列不服务：

• 不保证消息交付：不确认，不重传，无超时；
  
• 不保证交付次序：不设置包序号，不重排，不会发生队首阻塞；
  
• 不跟踪连接状态：不必建立连接或重启状态机；
  
• 不必要拥塞控制：不内置客户端或网络反馈机制。
  

UDP是欣赏器实时通信的基础，但要完全到达WebRTC的要求，欣赏器还必要位于其上的大量协媾和服务的支持，如下图所示：

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
  

ICE、STUN和TURN是通过UDP建立并维护端到端连接所必需的。DTLS用于保障传输数据的安全，加密是WebRTC强制的功能。SCTP和SRTP属于应用层协议，用于在UDP之上提供不同流的多路复用、拥塞和流量控制，以及部分可靠的交付和其他服务。
RTCPeerConnection API

RTCPeerConnection接口负责维护每一个端到端连接的完整生命周期：

• 管理穿越NAT的完整ICE工作流；
  
• 发送主动（STUN）持久化信号；
  
• 跟踪本地流；
  
• 跟踪远程流；
  
• 按需触发主动流协商；
  
• 提供必要的API，以天生连接发起，吸取应答，允许查询连接的当前状态等。
  

RTCPeerConnection把所有连接设置、管理和状态都封装在一个接口中。
DataChannel API用于实现端到端之间的恣意应用数据互换，类似于WebSocket，但却是端到端互换。而且，底层传输机制的属性也是可定制的。每个DataChannel可以颠末配置提供以下特性：

• 发送消息可靠或部分可靠的交付；
  
• 发送消息有序或乱序交付。
  

不可靠的乱序交付等同于原始UDP，即消息大概到达，也大概不到达，而且到达序次也没有保证。然而可让信道部分可靠，也就是设定重传的最大次数或时间限制：WebRTC的各个层负责处置惩罚确认和超时。
建立端到端的连接

打开XHR、EventSource或新WebSocket会话很简朴：依靠于界说美满的HTTP握手机制协商连接参数，都假定客户端可访问到目标服务器（比如，服务器具有公开的可路由到的IP地点，或客户端和服务器都在一个内部网中）。
WebRTC两头则很大概分别位于自己的私有网络中，中间还隔着一或多层NAT。为了发起会话，首先必须找到两头的候选IP和端口​，穿越NAT，查抄连接，以期找到可用路径。
要想乐成地建立端到端的连接，必须首先解决别的几个问题：

• 必须关照另一端想打开一个端到端的连接，以便它知道开始监听到来的分组；
  
• 必须找出两头之间建立连接所需的路由线路，并在两头传播这个信息；
  
• 必须互换有关媒介和数据流的必要信息，如协议、编码等。
  

WebRTC解决此中一个问题：内置ICE协议会执行必要的路由和连接查抄。然而，发送关照（信号）和协商会话仍然要由应用负责。
发信号和协商会话

在查抄连接或协商会话前，必须知道能否将信息发送到另一个端，另一端是否乐意建立连接。为此，必须发出一个信号，而另一端必须返回应答​。问题来了：假如另一端没有监听数据包，怎么办？最低限度，必要一个共享的发信通道。

WebRTC把发送信号和协议的选择交给应用，而标准故意未给发送信号的过程提供发起或实现。如许可让现有通信基础设施中的其他发信协议能够互利用，包括如下几个协议：

• SIP：Session Initiation Protocol，会话初始协议，应用级发信协议，广泛用于通过IP实现的语音通话（VoIP）和视频会议；
  
• Jingle：XMPP协议的发信扩展，用于VoIP和视频会议的会话控制；
  
• ISUP：ISDN User Part，ISDN用户部分，全球各大公共电话互换网中用于启动电话呼叫的发信协议。
  

WebRTC应用可以选择已有的任何发信协媾和网关，使用既有通信系统协商一次通话或视频会议。

发信服务器可以作为已有通信网络的网关，此时由网络负责将连接发起发送给目标端，然后再将应答返回给WebRTC客户端，以初始化信息互换。而应用也可使用自界说发信信道，大概由一或多台服务器和一个自界说通信协议构成：假如两头都连到同一个发信服务，那这个服务就可以为它们通报消息。
可与WebRTC互利用的通信网关，如开源的Asterisk。Asterisk有一个WebSocket模块，该模块支持将SIP作为发信协议，欣赏器建立到Asterisk网关的WebSocket连接，然后两者通过互换SIP消息来协商会话。
SDP

Session Description Protocol，会话描述协议。
应用实现共享的发信通道后，接下来就可以发起WebRTC连接：

1. // 初始化共享的发信通道
2. var signalingChannel = new SignalingChannel();
3. var pc = new RTCPeerConnection({});
4. // 向浏览器请求音频流
5. navigator.getUserMedia({ "audio": true }, gotStream, logError);
6. function gotStream(stream) {
7.         // 通过RTCPeerConnection注册本地音频流
8.         pc.addstream(stream);
9.         // 创建端到端连接的SDP（提议）描述
10.         pc.createOffer(function(offer) {
11.                 // 以生成的SDP作为端到端连接的本地描述
12.                 pc.setLocalDescription(offer);
13.                 // 通过发信通道向远端发送SDP提议
14.                 signalingChannel.send(offer.sdp);
15.         });
16. }
17. function logError() { ... }

复制代码

WebRTC使用SDP描述端到端连接的参数。SDP不包罗媒体本身的任何信息，仅用于描述会话状况，表现为一系列的连接属性：要互换的媒体范例（音频、视频及应用数据）​、网络传输协议、使用的编解码器及其设置、带宽及其他元数据。
SDP是一个基于文本的简朴协议（RFC 4568）​，用于描述会话属性。WebRTC应用不必直接处置惩罚SDP。JSEP（ JavaScript Session Establishment Protocol ， JS会话建立协议）界说对RTCPeerConnection对象几个方法的简朴调用，就把SDP所有的内部工作全都隐藏起来。天生发起之后，就可通过发信通道将它发送给远端。怎样编码SDP取决于应用：SDP字符串可以像前面那样（作为简朴的文本blob）直接传输，也可以将它编码成恣意格式后再传输。Jingle协议提供从SDP到XMPP（XML）格式的映射。
要建立端到端的连接，两头都必须遵循一个对称的工作流​，以互换各自音频、视频及其他数据流的SDP描述。

ICE

端与端之间通常有很多层防火墙和NAT设备阻隔。
查询利用系统获知IP地点（假如有多块网卡，就必要多个IP地点）​，将IP地点加端标语追加到天生的SDP字符串中。
WebRTC框架可处置惩罚大部分复杂工作：

• 每个RTCPeerConnection连接对象都包罗一个ICE代理；
  
• ICE代理负责网络IP地点和端口；
  
• ICE代理负责执行两头的连接查抄；
  
• ICE代理负责发送连接持久化信息。
  

设置好会话描述后（无论本地还是远程）​，本地ICE代剖析主动开始发现本地端所有大概的候选IP和端口的进程：

• ICE代理向利用系统查询本地IP地点；
  
• 假如有配置，ICE代剖析查询外部STUN服务器，以取得本地端的公共IP和端标语；
  
• 假如有配置，ICE代剖析将TURN服务器追加为末了一个候选项；假如端到端的连接失败，数据将通过指定的中间设备转发。
  

每发现一个新候选项（一个IP加一个端标语）​，代理就会主动通过RTCPeerConnection对象注册它，并通过一个回调函数（onicecandidate）关照应用。ICE在完成网络工作后，也会再触发同一个回调函数，以关照应用。

1. var ice = {"iceServers": [
2.                         // STUN服务器，配置为使用谷歌的公共测试服务器
3.                         {"url": "stun:stun.l.google.com:19302"},
4.                         // TURN服务器，用于端到端连接失败时转发数据
5.                         {"url": "turn:user@turnserver.com", "credential": "pass"}
6.                   ]};
7. var signalingChannel = new SignalingChannel();
8. var pc = new RTCPeerConnection(ice);
9. navigator.getUserMedia({ "audio": true }, gotStream, logError);
10. function gotStream(stream) {
11.         pc.addstream(stream);
12.         pc.createOffer(function(offer) {
13.                 // 应用本地会话描述：初始化ICE收集过程
14.                 pc.setLocalDescription(offer);
15.         });
16. }
18. pc.onicecandidate = function(evt) {
19.         // 预订ICE事件，监听ICE收集完成
20.         if (evt.target.iceGatheringState == "complete") {
21.                 local.createOffer(function(offer) {
22.                         console.log("Offer with ICE candidates: " + offer.sdp);
23.                         // 生成SDP提议（此时包含发现的ICE候选项）
24.                         signalingChannel.send(offer.sdp);
25.                 });
26.         }
27. }
28. // 包含ICE候选项的提议：
29. // a=candidate:1862263974 1 udp 2113937151 192.168.1.73 60834 typ host // 本地端的私有ICE候选项
30. // a=candidate:2565840242 1 udp 1845501695 50.76.44.100 60834 typ srflx // STUN服务器返回的公有ICE候选项

复制代码

ICE代理处置惩罚大部分复杂工作：ICE网络过程是主动触发的，STUN查找是在后台执行的，而发现的候选项也会主动通过RTCPeerConnection对象注册。上述过程完成后，可天生SDP发起，并通过发信通道发送给另一端。另一端吸取到ICE候选项后，就可建立端到端的连接：只要RTCPeerConnection对象设置远程会话描述（包罗另一端的一组候选IP和端标语）​，ICE代理就会执行连接查抄​，以确定能否抵达另一端。
ICE代理发送消息（STUN绑定哀求）​，另一端吸取之后必须以一个乐成的STUN相应确认。假如这个过程完成，则代表有一条端到端连接的路由线路！相反，假如所有候选项都绑定失败，要么将RTCPeerConnection标记为失败，要么回退到靠TURN转发服务器建立连接。
ICE代理主动确定连接查抄时间选项的序次和优先级：首先查抄本地IP地点，然后是公共IP，末了才查抄TURN。建立连接后，ICE代理周期性地向另一端发送STUN哀求，以此保证连接的持久化。
Trickle ICE

ICE网络过程决不是瞬间就能完成的：取得本地IP地点很快，但查询STUN服务器必要颠末到外部服务器的往返，还有另一次端到端的STUN连接查抄。Trickle ICE是对ICE协议的扩展，用于在于实现端与端之间的增量网络和连接查抄：

• 两头互换没有ICE候选项的SPD发起；
  
• 发现ICE候选项之后，通过发信通道发送到另一端；
  
• 新候选描述一就绪，立刻执行ICE连接查抄。
  

不比及ICE网络过程完成，而是依靠发信通道向另一端递增地交付更新，从而加快协商。
Trickle ICE导致发信通道的流量增加，但可明显减少初始化端到端连接的时间。所有WebRTC应用都应该思量这一点：尽快发送发起，然后依次发现依次发送ICE候选项。
跟踪ICE网络和连接状态

内置的ICE框架负责候选项发现、连接查抄、持久化等。开辟者要做的只是在初始化RTCPeerConnection对象时指定STUN和TURN服务器。
iceGatheringState属性生存本地端候选项的网络状态：

• new：对象刚刚创建，还没有连网；
  
• gathering：ICE代理正在网络本地候选项；
  
• complete：ICE代理网络过程完成。
  

如上图，iceConnectionState属性中生存着端到端的连接状态：

• new：ICE代理正在网络候选项且/或正在等候远程候选项的到来；
  
• checking：ICE代理至少已经收到来自一个组件的远程候选项，而且正在查抄候选项，但尚未发现连接；除查抄外，大概仍然在网络；
  
• connected：ICE代理已经找到一条通过所有组件的可用连接，但仍在查抄其他候选项，以确定是否存在更好的连接；此时仍有大概还在网络；
  
• completed：ICE代理已经完成网络和查抄，且发现通过所有组件的连接；
  
• failed：ICE代理查抄完所有候选项，但至少有一个组件的连接失败；其他一些组件的连接大概乐成；
  
• disconnected：一或多个组件的运动查抄失败，相对failed更严峻，在不稳固的网络上大概会间歇性触发（不必要采取什么举措）；
  
• closed：ICE代理已经关闭，不再相应STUN哀求。
  

ICE代理最重要的目标，就是辨认端到端之间的可行路径。可ICE代理不会就此止步。即便是连接已经建立，ICE代理也大概周期性地尝试其他候选项，以确定其他路径的性能是否更好。
Chrome提供一个工具，可查抄任何WebRTC连接的工作流和状态。打开标签页chrome://webrtc-internals，可查抄所有打开的端到端连接，检察互换的SDP描述：

完整示例

初始化WebRTC连接
相应WebRTC连接
simpleWebRTC库：使用一个用于穿透NAT的公共STUN服务器初始化了RTCPeerConnection，使用getUserMedia哀求音频和视频流，并初始化了连接到它自己发信服务器的WebSocket连接。
交付媒体和应用数据

要实现实时通信，还必要流量控制、拥塞控制、错误校验、带宽预测、延迟机制、通信加密等本领。
WebRTC又在UDP之上增加几层协议：

• DTLS：Datagram Transport Layer Security，数据报传输层安全，用于加密传输应用数据时针对要传输的媒体数据协商密钥；
  
• SRTP：Secure Real-Time Transport，安全实时传输，用于传输音频和视频流；
  
• SCTP：Stream Control Transport Protocol，流控制传输协议，用于传输应用数据。
  

通过DTLS实现安全通信

DTLS本质上就是TLS，为兼容UDP的数据报传输而做一些微小修改。
DTLS解决下列问题：

• TLS要求可靠的有序的适合分段的握手纪录以协商信道；
  
• 假如在混合多个分组的基础上对纪录分段，就不能保证TLS的完整性校验；
  
• 假如纪录的次序不对，也不能保证TLS的完整性校验。
  

DTLS对TLS纪录协议的扩展，就是为每条握手纪录明确添加分段偏移字段和序号。如许就满足有序交付的条件，也能让大纪录可以被分段成多个分组并在另一端再举行组装。DTLS握手纪录严酷按照TLS协议规定的次序传输，次序不对就报错。DTLS还要处置惩罚丢包问题：两头都使用计时器，假如预定时间内没有收到应答，就重传握手纪录。
纪录序号、偏移值和重传计时器让DTLS在UDP之上实现握手。为保证过程完整，两头都要天生自已签名的证书，然后按照常规的TLS握手协议走。

完整的DTLS握手必要两次往返。即，建立端到端的连接会产生额外延迟。
WebRTC客户端主动为每一端天生自已签名的证书。因此，也就没有证书链必要验证。DTLS保证加密和完整性，但把身份验证工作留给应用​。末了在满足握手要求的基础上，DTLS为处置惩罚常规纪录大概出现的分段和乱序问题，又增加两条重要的规则：

• DTLS纪录必须刚好放到一个网络分组中；
  
• 必须有一个分组密码用于加密纪录数据。
  

常规TLS纪录最大可以到达16KB。TCP可以处置惩罚分段和组装，但UDP不提供这些服务。结果，为适应UDP协议的乱序发送，也为了最大程度保持其语义，每个携带应用数据的DTLS纪录都必须放到一个UDP分组中。类似地，由于它们潜在依靠纪录数据的有序发送，因此也不允许使用流密码。
通过SRTP和SRTCP交付媒体

WebRTC以完全托管的形式提供媒体获取和交付服务：从摄像头到网络，再从网络到屏幕。WebRTC应用指定获取流的媒体约束，然后通过RTCPeerConnection对象注册它们。从此以后，就都是欣赏器提供的WebRTC媒体和网络引擎的事：编码优化、处置惩罚丢包、网络抖动、错误恢复、流量、控制等。

RTP：Real-Time Transport Protocol，实时传输协议，由RFC 3550界说。
WebRTC实际上并不是通过IP网络实时交付音频和视频的第一个应用。WebRTC只是重用了VoIP电话使用的传输协议、通信网关和各种贸易或开源的通信服务：

• 安全实时传输协议（SRTP，Secure RTP）通过IP网络交付音频和视频等实时数据的标准安全格式。
  
• 安全实时控制传输协议（SRTCP，Secure Real-time Control Transport Protocol）通过SRTP流交付发送和吸取方统计及控制信息的安全控制协议。
  

SRTP为通过IP网络交付音频和视频界说标准的分组格式​。SRTP本身并不对传输数据的实时性、可靠性或数据恢复提供任何保证机制，它只负责把数字化的音频采样和视频帧用一些元数据封装起来，以辅助吸取方处置惩罚这些流。

解读：

• 每个SRTP分组都包罗一个主动递增的序号，以便吸取端检测和发现媒体数据是否乱序；
  
• 每个SRTP分组都包罗一个时间戳，表示媒体净荷第一字节的采样时间，用于多个媒体流（如音频和视频）的同步；
  
• 每个SRTP分组都包罗一个SSRC标识符，这是个别媒体流中每个分组的唯一流ID；
  
• 每个SRTP分组可以包罗其他可选的元数据；
  
• 每个SRTP分组都包罗加密的媒体净荷，以及（可选的）认证标签，后者用于验证分组的完整性。
  

SRTP分组中包罗媒体引擎实时回放流必需的所有信息。而控制每个SRTP分组交付则是SRTCP协议的责任，SRTCP针对每个媒体流实现独立的外部反馈渠道。
SRTCP会跟踪发送及丢失字节和分组的数量，跟踪每个SRTP分组的序号、交织到达抖动，以及其他SRTP统计信息。然后，两头定时互换这些数据，以便调整每个流的发送速率、编码品质和其他参数。
SRTP和SRTCP直接在UDP之上运行，共同完成对应用提供的音频和视频流的实时适配和优化。WebRTC应用不会接触内部的SRTP或SRTCP协议：假如你要构建自界说的WebRTC客户端，那得直接利用这两个协议，否则欣赏器会替你搭建好所有必要的基础设施。
关于SRTP和SRTCP，还必要思量别的一些细节：

• SRTP和SRTCP都会加密应用净荷数据（WebRTC要求），但它们都没有提供协商密钥的机制！这就是为什么必须先举行DTLS握手的缘故原由：DTLS握手会为两头确定一个共享密钥，随后的SRTP和SRTCP可以使用这个密钥。
  
• SRTP和SRTCP都要求对不同的流分配不同的端口，而这对于NAT或防火墙后面的客户端固然就是一个问题。为解决这个问题，WebRTC使用另一个多路复用扩展，以便向同一个目标端口交付多个流（以及相应的控制信道）。
  
• IETF还订定一个新的拥塞控制算法，该算法使用SRTCP的反馈对WebRTC应用天生的音频和视频流举行优化。
  

通过SCTP交付应用数据

WebRTC对RTCDataChannel接口及其传输协议有哪些要求：

• 传输层必须支持多个独立信道的复用：
  
• 每个信道必须支持有序或乱序交付；
  
• 每个信道必须支持可靠或不可靠交付；
  
• 每个信道可以支持应用界说的优先级。
  
• 传输层必须提供一个面向消息的API：
  
• 每条应用消息都大概在传输层被分段和组装。
  
• 传输层必须实现流量和拥塞控制机制。
  
• 传输层必须保证数据的机密性和完整性。
  

TCP、UDP与SCTP比较
对比项目TCPUDPSCTP可靠性可靠不可靠可配置交付序次有序乱序可配置传输方式面向字节面向消息面向消息流量控制支持不支持支持拥塞控制支持不支持支持 DataChannel

设置与协商

配置消息序次和可靠性

部分可靠交付与消息大小

使用场景及性能

音频、视频和数据流

多方通信架构

基础设施及容量规划

数据效率及压缩

性能查抄表

注意事项：

• 发信服务
  
  
  
  • 使用低延迟传输机制；
    
  • 提供足够的容量；
    
  • 建立连接后，思量使用DataChannel发信。
    
  
  
• 防火墙和NAT穿越
  
  
  
  • 初始化RTCPeerConnection时提供STUN服务器；
    
  • 尽大概使用增量ICE，虽然发信次数多，但建立连接速率快；
    
  • 提供STUN服务器，以备端到端连接失败后转发数据；
    
  • 预计并保证TURN转发时容量足够用。
    
  
  
• 数据分发
  
  
  
  • 对于大型多方通信，思量使用超级节点或专用的中间设备；
    
  • 中间设备在转发数据前，思量先对其举行优化或压缩。
    
  
  
• 数据效率
  
  
  
  • 对音频和视频流指定得当的媒体约束；
    
  • 优化通过DataChannel发送的二进制净荷；
    
  • 思量压缩通过DataChannel发送的UTF-8数据；
    
  • 监控DataChannel缓冲数据的量，同时注意适应网络条件变革。
    
  
  
• 交付及可靠性
  
  
  
  • 使用乱序交付避免队首阻塞；
    
  • 假如使用有序交付，把消息大小控制到最小，以降低队首阻塞的影响；
    
  • 发送小消息（<1150字节），以便将分段应用消息造成的丢包丧失降至最低；
    
  • 对部分可靠交付，设置得当的重传次数和超时隔断；
    
  • 正确地设置取决于消息大小、应用数据范例和端与端之间的延迟。
    
  
  

免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！更多信息从访问主页：qidao123.com:ToB企服之家，中国第一个企服评测及商务社交产业平台。