WebRTC入门教学和一对一通话实现

WebRTC入门学习

简介

大体架构

互联网实时通信平台,html5标准之一,使用简单的API就可以实现音频通信。
WebRTC入门教学和一对一通话实现_第1张图片

  • 紫色部分的是Web应用开发者需要关注的部门,也就是WebRTC提供给开发者的接口
  • 蓝色部分是提供给浏览器厂商的接口,浏览器厂商使用这些接口实现应用层接口
  • 蓝色虚线部分是浏览器厂商可以选择自己实现的接口

iSAC/ iLBC Codec 音视频编解码器

NetEQ for voice 声音增强

Ecoh Candeler / Noise Reduction 消除回声,减少噪音

VP8 Codec 编解码器

Video jitter buffer 数据包缓冲区

image enhancements 图像增强

发展前景

WebRTC入门教学和一对一通话实现_第2张图片

相关厂商

  • 声网 声网 - 全球实时互动API平台开创者 (agora.io)
  • 即构科技

直播和WebRTC的区别

WebRTC入门教学和一对一通话实现_第3张图片

  • 直播是使用RTMP技术,并不需要非常高的实时性,时延有个几秒钟可能都没啥问题。所以主播将视频上传到服务器,然后通过CDN网络分发下去,给各个用户,各个用户就可以看到视频,和主播的交互往往都是通过弹幕的形式,而这种只需要传输文本,也不需要很高的实时性,所以只要带宽足够,无论有多少用户都可以。
  • WebRTC讲究的是实时音频通信,也就是实现多个人在同一个房间对话的效果,直播技术是单向的,用户能看到主播,而主播看不到用户。而WebRTC需要实现双向的通信,也就是所有用户直接都可以相互看到对方的画面,听到对方的声音,并且还要求有很低的延迟(你也不想说一句话,对方几秒后才回复吧),所以这就限制了通信的用户不能太多(否则服务器太多,链路拉长,时延就会很高,达不到实时音频通信的效果)。一般视频的人数最多只能有十几个人,而只传输声音,可以达到上百人(视频的数据量比声音高不少)

WebRTC通话原理

首先思考的问题:两个不同网络环境的浏览器,要实现点对点的实时音视频对话,难点在哪里?

媒体协商

也就是要了解对方支持的媒体格式(编码格式),用什么格式编的码,就需要用相同的格式解码回来。

WebRTC入门教学和一对一通话实现_第4张图片

所以在传输之前,要找双方支持的媒体格式,然后使用都支持的格式来进行视频传输
在这里插入图片描述

通信双方交换彼此的SDP(Session Description Protocol)信息,以此来了解双方支持的媒体类型,这个过程叫做媒体协商

网络协商

通信之前要了解双方的网络情况,确定大致的带宽,来决定通信的网络质量

NAT 网络地址转换

如果通信的双方都直接有一个公网IP,那么就可以直接进行通信

但是大多数电脑都不会独占一个公网IP(公网IP太少了),所以会将整个局域网内,为每个计算机分配一个私网IP(在这个局域网内唯一即可),这样局域网内部的计算机可以相互通信,然后给这个局域网(路由器)分配一个公网IP,这个局域网内的计算机和外网通信的时候就使用这个公网IP,而为了区分局域网内的各个计算机,路由器会请求STUN服务器给每个计算机(私网IP)分配一个编号(也可以叫端口号),使用公网IP和这个编号来和外网通信,发送数据包的时候,将IP和编号一起放在数据包的头部,这样路由器得到的应答数据包就可以根据端口号分发给私网内的计算机,这就是NAT网络地址转换。这样就可以在使用原来的IP协议的基础上,解决公网IP不足的问题。

WebRTC入门教学和一对一通话实现_第5张图片

STUN NAT会话穿越应用程序

NAT协议中,NAT端口的分配。以及[公网IP:NAT端口]到私网IP的映射,也是由STUN服务器完成,我们也可以

请求STUN服务器来查询自己计算机分配到的公网IP和端口
WebRTC入门教学和一对一通话实现_第6张图片

计算机发起请求前,先请求局域网内的STUN服务器,获取自己的公网IP和NAT端口。但是这还不够,还需要知道对方的公网IP和NAT端口才能进行通信,所以还需要一个公共发服务器保存各个计算机的公网IP和NAT端口,网络协商的时候不仅要从STUN服务器获取自己的公网IP和NAT端口,同时也要获得对方的公网IP和端口,这样才可以进行P2P通信。

[P2P学习(一)NAT的四种类型以及类型探测 - 山上有风景 - 博客园 (cnblogs.com)](https://www.cnblogs.com/ssyfj/p/14791064.html#:~:text=一般来讲, NAT可以分为四种类型,分别是%3A 1%2C 全锥型 (Full Cone) 2%2C 受限锥型,Cone)

四种NAT类型:

  • 全锥形,只要知道了公网IP和端口,任何外网主机都能和对应的内网主机进行通信进行通信
  • ip受限型,只有内网主机先给外网主机(ip)发过数据包,外网主机才能主动和内网主机通信
  • 端口受限型,只有内网主机先给外网主机(ip和端口)发过数据包,外网主机才能主动和内网主机通信
  • 对称型,内网主机每次发送新的数据包都会分配新的端口,所以只有内网主机主动发送的数据包的应答数据包才有效,外网主机不能主动联系内容主机

而如何获取内网的IP和端口,不属于STUNTURN协议的范畴

TURN协议

TURN协议其实是STUN协议的扩展

P2P学习(三)网络传输基本知识—TURN协议 - 山上有风景 - 博客园 (cnblogs.com)
WebRTC入门教学和一对一通话实现_第7张图片

进行NAT转换后可能不能直接使用P2P协议(NAT无法穿透)
WebRTC入门教学和一对一通话实现_第8张图片

  • 对称型和对称型不能通信是因为双方都是只能自己先发,而不能接受对方先发,没有能被先发的主机,所以就无法相互通信
  • 对称型和端口受限型和对称型不能相互通信也是同样的道理,他们都不能接受对方先发送数据包
  • 但是对称型和IP受限型(受限锥型)却可以通信,这是因为IP受限型可以先向对称型的相同IP但是不同端口的主机通信,然后因为IP受限型不区分端口,所以对称型此时就可以向IP受限型发送数据包

此时可以使用一个中继服务器来进行转发,是对STUN协议的补充

使用TURN协议的客户端必须能够通过中继地址和对等端进行通讯,并且能够得知每个peer的的IP地址和端口(确切地说,应该是peer的服务器反射地址)。

而这些行为如何完成,是不在TURN协议范围之内的,比如可以使用一个信令服务器来传输这些信息

使用TURN的优先级是最低的,因为它多了一段网络链路,时延增加,并且非常耗费网络带宽,是P2P的2倍,而服务器的带宽都是非常贵的。P2P需要的带宽是单向带宽的2倍,中继服务器则需要四倍(如下图所示,两个Peer都需要上传和下载)

WebRTC入门教学和一对一通话实现_第9张图片
WebRTC入门教学和一对一通话实现_第10张图片

在WebRTC中,描述网络信息的术语叫做candidate,前面描述媒体协商的媒体数据叫作SDP

ICE是集成STUN和TURN协议的框架

媒体协商和网络协商数据交换的通道——信令服务器

WebRTC入门教学和一对一通话实现_第11张图片

和信令服务器进行通信,可以使用各种不同的变成语言,并且可以自己设计指令,只要能完成交换彼此信息的功能即可

信令服务器需要搭建在通信的主机都能访问到的局域网里面(因为主机Peer需要通过信令服务器来交换SDP,candidate,所以必须保证主机能访问到),一般部署在公网里面,部署在公网里面,这样公网里面的主机都能访问到

信令服务器不仅要交换SDP,Candidate,还需要有房间机制(或者叫会话机制),一个房间里面的人可以相互通话,不同房间的人不能相互通话,所以我们需要知道本次会话包含哪些人(或者说,这个房间包含哪些人),所以就需要房间机制,需要对进出房间进行管理

WebRTC入门教学和一对一通话实现_第12张图片

各个部分如何进行交互

WebRTC入门教学和一对一通话实现_第13张图片
WebRTC入门教学和一对一通话实现_第14张图片

  1. 双方通信前的准备工作
    1. 发起者和接收者和信令服务器建立链接
    2. 发起者和接受者在本地创建PeerConnection,并添加媒体流(视频流和音频流,输入流和输出流)
  2. 进行媒体协商
    1. 通话发起者创建一个offer(可以理解为数据包),在里面设置浏览器自己支持的媒体类型,然后把这个SDP数据包发送给信令服务器,信令服务器再转发给接受者(双方能通信肯定在一个房间,在一个房间就可以知道对方的IP以及NAT端口)
    2. 接收者收到SDP数据包后,在本地保存对方的SDP信息,同时查询自己的SDP信息,保存在本地,并创建应答数据包将自己的SDP信息返回给信令服务器,中继服务器再转发给发起者,发起者也保存对方的SDP信息,这样媒体协商就完成了。
  3. 进行网络协商
    1. 服务发起者向STUN/TURN服务器发送ICE请求,然后默认的回调函数OnICECandidate会将Candidate信息保存对象内部,保存这一操作由对象自动完成。
    2. 然后将拿到的Candidate信息发送给信令服务器,信令服务器再转发给接收者,接收者将收到的Candidate信息保存再本地
    3. 查询自己的Candidate信息,然后保存并发送给信令服务器,信令服务器再转发给发起者,发起者将接受者的Candidate保存下来,这样媒体协商就完成了
  4. 主机之间进行通信
    1. 接受端和发送端之间会尝试进行通信,看看NAT打洞是否能成功,如果能成功就直接使用P2P进行通信,如果不行就使用中继服务器(STUN和TURN
    2. 确定完通信方式后,回调函数onAddStream会接受以及发送对方的媒体流,这样就能完成双方的数据通信

环境搭建

windows本地需要安装vscode,webstorm等js编译器,然后需要安装node和npm,下面介绍服务器安装流程

安装必要的依赖

ubuntu

apt-get install libssl-dev
apt-get install libevent-dev

centos

yum install libssl-dev
yum install libevent-dev

编译安装coturn

官方网站https://github.com/coturn/coturn

使用docker

Coturn/Docker/Coturn at Master ·转弯/转弯 ·GitHub

 docker run -d --privileged=true --network=host -p 3478:3478 -p 3478:3478/udp -p 5349:5349 -p 5349:5349/udp -p 49152-65535:49152-65535/udp coturn/coturn

测试是否成功

lsof -i:3478

查看当前端口是否被监听

同时可以打开这个网站来测试STUN的功能 https://webrtc.github.io/samples/src/content/peerconnection/trickle-ice/

测试STUN服务器的功能:

WebRTC入门教学和一对一通话实现_第15张图片

STUN不需要用户名密码,Priority显示Done,表示打洞功能是正常的

测试TURN功能:

用户名密码默认都是服务器的用户和密码

WebRTC入门教学和一对一通话实现_第16张图片

显示done表示成功

音频的采集和播放

打开摄像头

播放视频的代码流程

WebRTC入门教学和一对一通话实现_第17张图片

onOpenCamera是需要我们自己的编写的事件,在点击按钮后实现视频的播放

按钮自不必说使用

你可能感兴趣的:(webrtc,服务器,运维)