WebRTC相关

学习资料

官方网站, https://webrtc.org/ 

WebRTC Samples, https://webrtc.github.io/samples/

WebRTC 1.0: Real-Time Communication Between Browsers, https://www.w3.org/TR/webrtc/

Getting Started with WebRTC, https://www.html5rocks.com/en/tutorials/webrtc/basics/

名词解释

ACK:Acknowledgement,它是一种正向反馈,接收方收到数据后回复消息告知发送方。

NACK:Negative Acknowledgement,则是一种负向反馈,接收方只有在没有收到数据的时候才通知发送方。

REX:Retransmission,重传,当发送方得知数据丢失后,重新发送一份数据。

HTTP和WebSocket的区别

https://www.cnblogs.com/aspirant/p/11334957.html

https://www.cnblogs.com/goeasycloud/p/9355164.html

http协议是用在应用层的协议,他是基于tcp协议的,http协议建立链接也必须要有三次握手才能发送信息。

  http链接分为短链接,长链接,短链接是每次请求都要三次握手才能发送自己的信息。即每一个request对应一个response。长链接是在一定的期限内保持链接。保持TCP连接不断开。客户端与服务器通信,必须要有客户端发起然后服务器返回结果。客户端是主动的,服务器是被动的。 

  WebSocket他是为了解决客户端发起多个http请求到服务器资源浏览器必须要经过长时间的轮训问题而生的,他实现了多路复用,他是全双工通信。在webSocket协议下客服端和浏览器可以同时发送信息。

  建立了WebSocket之后服务器不必在浏览器发送request请求之后才能发送信息到浏览器。这时的服务器已有主动权想什么时候发就可以发送信息到服务器。而且信息当中不必在带有head的部分信息了与http的长链接通信来说,这种方式,不仅能降低服务器的压力。而且信息当中也减少了部分多余的信息。

  HTTP的长连接与websocket的持久连接

HTTP1.1的连接默认使用长连接(persistent connection),即在一定的期限内保持链接,客户端会需要在短时间内向服务端请求大量的资源,保持TCP连接不断开。客户端与服务器通信,必须要有客户端发起然后服务器返回结果。客户端是主动的,服务器是被动的。

 在一个TCP连接上可以传输多个Request/Response消息对,所以本质上还是Request/Response消息对,仍然会造成资源的浪费、实时性不强等问题。

如果不是持续连接,即短连接,那么每个资源都要建立一个新的连接,HTTP底层使用的是TCP,那么每次都要使用三次握手建立TCP连接,即每一个request对应一个response,将造成极大的资源浪费。

长轮询,即客户端发送一个超时时间很长的Request,服务器hold住这个连接,在有新数据到达时返回Response

websocket的持久连接只需建立一次Request/Response消息对,之后都是TCP连接,避免了需要多次建立Request/Response消息对而产生的冗余头部信息。

C10K问题(即单机1万个并发连接问题)

https://blog.csdn.net/chenrui310/article/details/101685827

https://zhuanlan.zhihu.com/p/61785349

SDP:会话描述协议Session Description Protocol

https://www.cnblogs.com/idignew/p/7249056.html

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

NAT与内网穿透

网络地址转换,就是替换IP报文头部的地址信息.由于IPv4地址有限,不可能为每一个上网设备分配一个ip,而NAT就是来解决这个问题的.我们在上网时很有可能处在一个NAT设备之后, NAT设备会在ip包通过时会修改其 源/目标IP地址,有时还会修改TCP/UDP协议的端口号,从而实现多台设备使用同一外网IP进行互联网通讯。
NAT中,动态端口映射时候,当内网机子和与外面通讯结束时候,NAT 表不保留,下次内网通讯时候,又重新建立一个表记录,除非简历静态NAT,否则外部无法主动与内部发起正确的链接。

NAT类型

1, Full Cone NAT(完全锥形NAT)

设备比较少,一旦内部主机端口在NAT网关完成端口映射,则后续外网任一主机都可以通过这映射好的端口进行访问

2, Restricted Cone NAT (限制锥形NAT)

相较与全雏形NAT,在完成端口映射后,对IP地址有限制,只有内网对外访问过的ip地址才可以对该端口进行连接

3, Port Restricted Cone NAT(端口限制锥形NAT)

相较于限制雏形NAT,在端口上也加以限制,只有内网向该ip与端口发送过信息才能对其访问

4, Symmetric NAT (对称NAT)

也就是说,虽然是同一个内网主机,对不同的外网ip+端口访问时,在NAT表上会映射成不同的端口号

音频与视频丢包的区别

音频可以延长已缓存的数据的播放时间,或者采用插值,甚至直接加入白噪声隔断。视频帧之间的相关性没有音频那么强,不过视频可以采取降低分辨率传说然后再用序列的超分辨率重建的算法(序列中能够补充分辨率不足带来的额外信息),而音频受制于奈奎斯特采样率,倍频很难。
 

STUN

STUN的全称是Simple Traversal of UDP Through NAT,即UDP对NAT的简单穿越方式。应用程序(即STUN CLIENT)向NAT外的STUN SERVER通过UDP发送请求STUN 消息询问自身的转换后地址

根据了解到的地址,发送给对端,然后对端请求这个地址,进行通讯。

在实际场景中有两种形式:

1.内网机器A访问stun服务器C,通过C获知自己的对外通信的ip和port,然后通过信令服务器告知机器B。B通过ip和port与A进行通信。

2.内网机器A访问stun服务器C,直接和C进行通信。(这个就是ice中的lite模式,也是webrtc中的prflx模式)

STUN协议最大的优点是无需现有NAT/FW设备做任何改动,同时STUN方式可在多个NAT串联的网络环境中使用. STUN的局限性在于STUN并不适合支持TCP连接的穿越,同时STUN方式不支持对对称NAT(Symmetric NAT).

对于连接多个网络的设备(比如同时开了WLAN和流量、LAN)可以询问到自身的多个ip,并反馈每个ip的情况。

TURN

TURN的全称为Traversal Using RelayNAT,即通过Relay方式穿越NAT,TURN应用模型通过分配TURNServer的地址和端口作为客户端对外的接受地址和端口,即私网用户发出的报文都要经过TURNServer进行Relay转发,这种方式除了具有STUN方式的优点外,还解决了STUN应用无法穿透对称NAT(Symmetric NAT)以及类似的Firewall设备的缺陷

ICE

ICE跟STUN和TURN不一样,ICE不是一种协议,而是一个framework,它整合了STUN和TURN。

参考自:https://www.cnblogs.com/whyandinside/archive/2010/12/08/1900492.html

WebRTC之iceServer

关于webrtc的知识还有很多,最好的学习资源都在 https://webrtc.org/start/ 

webrtc建立点对点的对等连接需要用到iceServers参数,可以使用公开免费的一些ice服务器资源,也可以使用开源程序自己搭建ice server,找了一些资源供参考:

1、IceBox  https://doc.zeroc.com/ice/latest/icebox

https://blog.csdn.net/u011784767/article/category/7006667  这里有三篇介绍IceBox的文章

2、coturn  https://github.com/coturn/coturn

https://www.cnblogs.com/wunaozai/p/5520084.html 这篇文章里有介绍coturn及安装使用

3、免费直接可用的iceserver列表  https://gist.github.com/yetithefoot/7592580

以上来源https://blog.csdn.net/bowei026/article/details/89816359

 WebRTC的演示

官方的演示中没有server,都是在本地的,不过可以通过查看main.js和console输出的内容进行学习。

可以把发起方和答复方的SDP内容复制一下然后比对查看区别。其中audio是音频支持能力,video是视频支持能力,主要关注opus和h264。

在演示的时候可以在同一个chrome浏览器中打开新标签页,输入 chrome://webrtc-internals/ 打开调试页面。

字节跳动的一个demo https://rtc.bytedance.com/

demo2 https://rtcmeet.me/ 使用的是Pion开发的WebRTC(Pure Go implementation of the WebRTC API)和ION(Distributed RTC System by pure Go and Flutter)

更多的官方演示https://webrtc.github.io/samples

 
 
 
 
posted @ 2020-11-08 11:27  evtricks  阅读(154)  评论(0编辑  收藏  举报