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万个并发连接问题)
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类型
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)