标签归档:WebP2P

部署AppRTC服务

AppRTC是WebRTC视频通话的服务程序,一般可以将其作为参考实现,搭建AppRTC服务受限于很多条件,并不是太容易。在参考了官方操作和大量的博客之后,根据自己操作实践排除了很多网络博客上的错误方法,终于部署成功了一套环境。测试环境为阿里云的CentOS 7服务器,带公网IP和域名。

部署前的必要条件

部署前,首先要明确的是必要的依赖环境,必须满足以下需求:

  • 公网服务器,如果非公网就只能在局域网玩玩了,此处暂不讨论局域网
  • SSL证书,因为WebRTC必须在HTTPS环境下使用,因此通信WebSocket也必须支持

如果没有证书,但是有域名的话,可以去申请免费的证书,具体百度 Let’s Encrypt。本博客使用了Caddy服务器,此服务器可自行自动申请其证书,其证书存放在

/var/lib/caddy/acme/acme-v02.api.letsencrypt.org/sites/

下,按站点域名存放,假设本次部署使用的 example.com 域名,对应 8.8.8.8,其证书存放在

/var/lib/caddy/acme/acme-v02.api.letsencrypt.org/sites/example.com/

下,包含公钥文件 example.com.cert 和私钥文件 example.com.key 文件。

上面的 example.com 和 8.8.8.8 是域名和对应的IP,此处为举例,抹去了我的真实的地址。

安装编译环境

除了必要条件外,编译安装相关源码也需要一些编译环境,已知目前最终部署的程序为

  • apprtc GAE的Python和NodeJS开发的房间服务器
  • collider golang开发的信令服务器
  • coturn c语言开发的stun/turn服务器

系统基础环境安装

因为上面的依赖以及后续使用发现,系统需要安装的依赖环境如下(已经安装了跳过)

yum install python #要求2.7版本
curl -sL https://rpm.nodesource.com/setup_10.x | bash – #安装比较高的10版本
npm -g install grunt-cli #grunt工具
yum install gcc-c++ make #C/C++编译器等
yum install golang #golang编译器
yum install java-1.8.0-openjdk #安装JDK,我选择了1.8版本
yum install libevent-devel #编译coturn需要
yum install git #可以下载Github源码
yum install sqlite-devel #编译coturn需要

GAE环境安装

准确的讲需要安装的是 Google app engine SDK for Python,但是因为众所周知的原因,我们并不能直接访问,但是我从其他地方获知了一个比较老的下载地址,可以离线安装,而且是可以下载的

wget https://dl.google.com/dl/cloudsdk/channels/rapid/downloads/google-cloud-sdk-188.0.1-linux-x86_64.tar.gz

虽然这个是Google Cloud SDK,但是我发现确实是可以用,并且可以更新,估计是现在进行了整合吧

tar xzvf google-cloud-sdk-188.0.1-linux-x86_64.tar.gz
./google-cloud-sdk/bin/gcloud components update

这其中因为 AppRTC 是用GAE的Python开发的,依赖Python 2.7环境。据说现在支持了3.7版本了,因为不能上官网,不确定。

编译构建版本

编译coturn

因为coturn是必须依赖的组件,我们优先处理这个,这个软件并不在仓库中,其依赖的libevent的版本与仓库中的一致,并不需要单独编译,因此只需要下载编译这个软件即可

因为这个软件中带了RPM的构建脚本,因此我这里打算进行RPM包的构建,首先安装RPM构建工具

yum install rpm-build

开始下载源码进行编译构建安装包

wget https://github.com/coturn/coturn/archive/4.5.1.1.tar.gz
mkdir -p ~/rpmbuild/SOURCES
mv 4.5.1.1.tar.gz -p ~/rpmbuild/SOURCES/turnserver-4.5.1.1.tar.gz
rpmbuild -ta ~/rpmbuild/SOURCES/turnserver-4.5.1.1.tar.gz

等构建成功后,会在 ~/rpmbuild/RPMS/x86_64 目录下发现好几个安装包,只需要安装 turnserver 即可

rpm -ivh ~/rpmbuild/RPMS/x86_64/turnserver-4.5.1.1-0.el7.x86_64.rpm

如果怕编译麻烦的,可在本站下载编译好的包进行安装

rpm -ivh https://cdn.xilixili.net/linux/turnserver-4.5.1.1-0.el7.x86_64.rpm

至于配置,我们后面再讲。

编译collider

Collider是Go开发的服务,依赖websocket,依然不能访问其地址。因此只能下载镜像安装,此处以将Go的环境设置的当前用户目录下的go目录为例说明。另外Collider的代码在AppRTC之中,因此此处就直接下载AppRTC的源码了,后续不需要下载了。

export GOPATH=$HOME/go
mkdir -p ~/go/src
git clone https://github.com/apprtc/apprtc
ln -s `pwd`/apprtc/src/collider/collider $GOPATH/src
ln -s `pwd`/apprtc/src/collider/collidermain $GOPATH/src
ln -s `pwd`/apprtc/src/collider/collidertest $GOPATH/src
mkdir -p $GOPATH/src/golang.org/x
cd $GOPATH/src/golang.org/x
git clone https://github.com/golang/net.git
go get collidermain
go install collidermain

至此,程序编译好并且安装到了 $GOPATH/bin 下面。

配置启动服务

注意,下面所有提供网络的服务,要注意防火墙配置,特别是UDP端口,测试平台关闭了防火墙。

配置启动coturn

首先需要生成签名证书

mkdir /cert
openssl req -x509 -newkey rsa:2048 -keyout /cert/turn_server_pkey.pem -out /cert/turn_server_cert.pem -days 99999 -nodes

然后再生成用户,以 apprtc 为例

turnadmin -k -u apprtc -p apprtc

执行之后会生成一个key,记住这个key,马上要用到。编辑 /etc/turnserver/turnserver.conf 文件,这个文件大部分的功能都默认是注释的,因此基本找到出处进行修改,大概如下

listening-ip=8.8.8.8
listening-port=3478
relay-ip=8.8.8.8
tls-listening-port=5349
external-ip=8.8.8.8
Verbose
fingerprint
lt-cred-mech
use-auth-secret
static-auth-secret=apprtc
user=apprtc:0x949534a397bcf2e88470c86ad3749d9c(替换成上面的key)
user=apprtc:apprtc
cert=/cert/turn_server_cert.pem
pkey=/cert/turn_server_pkey.pem

保存之后,启动服务

systemctl enable turnserver
systemctl start turnserver

注意,很多教程说要配置 TRUN REST API,即自己需要实现个REST API服务,让AppRTC进行查询获取,通过分析和测试,发现第一这个服务必须是POST请求的,具体格式参考标准,第二是并不需要这个API也能正常使用,因此请不要折腾REST API了。

启动Collider服务

暂时以测试为主,后续可为此程序编写添加个systemd服务。

此服务需要对外提供WSS服务,因此需要证书,将之前的域名证书拷贝过去即可

cd /var/lib/caddy/acme/acme-v02.api.letsencrypt.org/sites/example.com/
cp example.com.cert cert.pem
cp example.com.key key.pem
chmod 755 /cert/*

然后通过下面的命令启动服务

./collidermain -port=8089 -tls=true -room-server=”http://example.com:8080″

注意,我们设置的这个服务的端口是8089端口,AppRTC默认的HTTP端口是8080,HTTPS端口是8081,但是实际测试中发现AppRTC在使用HTTPS的时,会经常SSL异常,未查明原因。

配置启动AppRTC

配置AppRTC的配置文件 ~/apprtc/src/app_engine/constants.py 文件如下(仅列出修改项)

ICE_SERVER_OVERRIDE = [
{
“urls”: [
“turn:8.8.8.8:3478?transport=udp”,
“turn:8.8.8.8:3478?transport=tcp”
],
“username”: “apprtc”,
“credential”: “0x949534a397bcf2e88470c86ad3749d9c” #替换成上面的key
},
{
“urls”: [
“stun:8.8.8.8:3478”
]
}
]

ICE_SERVER_BASE_URL = ”
ICE_SERVER_URL_TEMPLATE = ”
ICE_SERVER_API_KEY = os.environ.get(‘ICE_SERVER_API_KEY’)

# Dictionary keys in the collider instance info constant.
WSS_INSTANCE_HOST_KEY = ‘example.com:8089’
WSS_INSTANCE_NAME_KEY = ‘vm_name’
WSS_INSTANCE_ZONE_KEY = ‘zone’
WSS_INSTANCES = [{
WSS_INSTANCE_HOST_KEY: ‘example.com:8089’,
WSS_INSTANCE_NAME_KEY: ‘wsserver-std’,
WSS_INSTANCE_ZONE_KEY: ‘us-central1-a’
}]

上面的配置已经可以保证使用了,且在命令行指定SSL证书后,就能提供服务了,但是由于之前提到了SSL异常问题,即使在切换到HTTP之后并使用nginx代理后,出现了URL不匹配的错误,因此还不能直接使用,为了解决上面的问题,我修改了代码,首先配置 ~/apprtc/src/app_engine/constants.py 修改

REDIRECT_URL = ‘https://example.com:9090’

这里假设nginx代理的地址是 example.com:9090 ,然后修改该目录下的 apprtc.py 文件,大概在300行左右,修改其中room_link的赋值为

room_link = constants.REDIRECT_URL + ‘/r/’ + room_id

然后编译代码并运行代码,命令如下

cd ~/apprtc
grunt build
cd ~
google-cloud-sdk/bin/dev_appserver.py –host example.com ~/apprtc/out/app_engine/ –dev_appserver_log_level debug

会看到输出显示

Starting module “default” running at: http://example.com:8080

也就是意味着服务提供的地址是 http://example.com:8080

安装配置nginx代理

如上,使用nginx代理https请求,端口为 9090,直接yum安装

yum install nginx

配置 /etc/nginx/nginx.conf 文件

#server {
# listen 80 default_server;
# listen [::]:80 default_server;
# server_name _;
# root /usr/share/nginx/html;

# # Load configuration files for the default server block.
# include /etc/nginx/default.d/*.conf;

# location / {
# }

# error_page 404 /404.html;
# location = /40x.html {
# }

# error_page 500 502 503 504 /50x.html;
# location = /50x.html {
# }
#}

server {
listen 9090 ssl default_server;
server_name example.com;
ssl_certificate “/cert/cert.pem”;
ssl_certificate_key “/cert/key.pem”;
location /{
proxy_pass http://example.com:8080;
proxy_set_header Host $host;
}
}

配置默认注释了原来默认配置的80端口的配置,添加了一个9090的代理服务,配置之后启动服务

systemctl enable nginx
systemctl start nginx

体验测试

通过 https://example.com:9090 访问AppRTC服务

再找另外一个用户同时打开浏览器,输入相同的号码并JOIN,即可实现视频通话。

另外在目录下的~/apprtc/src/web_app/html/params.html网页中自定义了一些配置参数,可以在URL中自定义WebRTC的参数,比如打开高清摄像头、关闭音频等等,具体参考这个页面即可。

采用默认配置测试后,个人使用感觉效果如下

  • 语音很清晰无噪音,两个用户使用手机外放离的很近的时候,可能是回声消除的原因会出噪音
  • 视频感觉效果一般般,带宽占用也不高,毕竟是P2P模式,但并不是特别清晰
  • 整体感觉和微信视频差不多,可能稍好一点
  • 并没有找到测试turn的环境,这个环境下的效果不清楚

手机微信也可以的哦。

可以节约CDN带宽流量的流媒体P2P(Flash/Android/IOS)

很多朋友关心SRS是否有计划支持RTMFP,是否计划支持P2P,这篇文章详细介绍了SRS和P2P的关系。

Summary

我们所指的P2P,并非传统客户端P2P的方式,譬如ed2k那种协议。我们特指三种P2P:

  1. FlashP2P:Adobe开发的P2P,Flash播放器之间可以互相P2P,分享视频。

  2. AndroidP2P:特指Android的App的P2P方式,Android上HTML5不可能做P2P。

  3. IOSP2P:特指IOS的App的P2P方式,IOS上HTML5不可能做P2P。

这三种P2P都有几个共同点:

  1. 只讨论流媒体范畴的P2P,普通文件和数据的P2P不考虑。

  2. 流媒体传输使用通用协议,譬如flv、mp4或hls,配合CDN完成P2P原始资源的传输,而并非所有的数据都是P2P网络用私有协议传输。

  3. 尽量避免安装额外插件。譬如FlashP2P就在flash播放器上跑(别纠结flash本身就是个插件),只需要集成AS的SDK,不需要额外安装ActiveX浏览器插件。而Android和IOS的P2P,需要集成P2P系统的SDK,只需要安装商家的App,而不需要再安装专门用来做P2P的App。

综上所述,我们可以将Flash/Android/IOS
P2P,简称为P2P。下面讲P2P一种可能的结构,以及SRS和P2P的关系。

Structure

一个P2P系统,可以包含下面几个结构:

  1. 客户端SDK:P2P系统必须提供客户端SDK,集成在播放器或者App中。譬如FlashP2P提供的是AS的库,Android提供的是java的库,IOS提供oc的库。

  2. API调度集群:P2P系统必须支持API调度,弥补DNS的不足,以及提供P2P系统需要的额外数据。API调度就是SDK交互的第一个后端,完成认证、其他服务器资源的分配、流信息、实时调度。

  3. RTMFP集群:或者称为基础协议集群,由API调度返回给SDK可用的服务器,客户端使用RTMFP服务器完成NAT打洞,以及必要的数据传输。

  4. Tracker集群:或者称为伙伴发现协议集群,由API调度返回给SDK可用的服务器,客户端向Tracker请求可用的伙伴节点。

  5. Pingback集群:或者称为实时数据集群,由API调度返回给SDK可用的服务器,并提供给API调度集群调度的实时数据依据,SDK向Pingback集群汇报实时数据。

  6. 流媒体源站集群:或者称为流媒体源,主要负责流媒体数据的生成,和CDN对接,由API调度返回给SDK可用的CDN边缘地址。

可以在SRS基础上完成的结构是:流媒体源站集群、RTMFP集群。其他大多是HTTP协议,主要是P2P系统内部的算法和逻辑处理,适合使用Python或者GO实现。

另外,Pingback集群需要提供10秒级别的系统数据,使用GO或者Spark都可以,数据量小时用GO实现也可以,数据量很大时可以用Spark。

下面详细分析SRS在WebP2P中的位置和状态。

SRS for P2P

回过头来说,SRS现在已经支持P2P中的流媒体源站集群和RTMFP集群了吗?SRS支持了流媒体源站集群,但是RTMFP集群不支持。

所谓SRS支持了流媒体源站集群,指的是SRS能输出一种HLS,能符合一种P2P系统的要求。这种P2P系统就是观止创想的P2P系统,具体参考BravoP2P。也就是说,若使用SRS作为您的流媒体服务器,是可以直接对接到观止的P2P系统的,可以给现有的HLS流加上P2P功能。

SRS为何不支持RTMFP集群呢,有几个原因:

  1. RTMFP目前不开源。

  2. RTMFP和SRS的差异太大,就算支持了RTMFP集群,还只是P2P系统的六分之一,没法用起来。

  3. SRS的目标是提供通用方案,SRS3的Dragon技术,SRS4对接Spark,目前还没有支持P2P系统的计划,P2P系统里面很多是私有方案。

因此,在现在的路线图,例如SRS3(预计2016年发布)和SRS4(预计2017年发布)的路线图中,都没有RTMFP的影子。

也就是说,在P2P系统中,SRS只计划支持流媒体源站功能。下面分开看看各种P2P系统。

FlashP2P

FlashP2P是由Adobe研发的P2P协议,包括握手、NAT打洞、数据传输,Adobe收购了一家做P2P的公司,将这个RTMFP协议集成到了Flash中。

FlashP2P在PC上的很成熟了,稳定性也可以达到商用的要求。从2013年开始,支持FlashP2P的公司也开始粗现,现在除了我们观止创想,还有云某动、快播解散后的一个团队等等。

AndroidP2P

Android手机、盒子和Pad上面支持P2P,这个目前还在发展中。

IOSP2P

IOS手机和Pad上面支持P2P,这个难度比AndroidP2P还大,目前没有消息。

Challenge

上面讲了各种P2P的情况,P2P的挑战有以下几点:

  1. 转换思维对接CDN:CDN最惧怕的就是P2P公司,不是要分他流量那么简单,而是对接起来灰常痛苦。据说有的FlashP2P系统,得在CDN每个边缘节点部署服务器,因为流媒体切片不通用,这不是要CDN的命么?因此首先最大的挑战就是转换为互联网思维,尽量使用通用方案,让CDN爽了P2P系统才能爽。

  2. 保证流畅度:传统P2P可以暂停缓冲个几个小时,而WebP2P直播正在进行时,缓冲个几次用户就刷新页面,这个P2P节点就相当于牺牲了。因此保证流畅度才能保证分享率,如何保证流畅度呢,这个就各显神通了。

  3. 实时调度:P2P的变化非常快,有的用户刷新页面啦,有的系统拖动啦,有的还暂停,有的就喜欢乱点。因此整个P2P的节点信息都是变化很快的,这对实时分析系统有非常大的挑战。

  4. 负载均衡和热备:P2P的集群也需要负载均衡,譬如RTMFP协议就支持Redirect方式,可以实现负载均衡和热备。传统P2P系统挂掉后节点就没法看视频,而一个P2P系统挂掉后依然能看,因为有CDN在那里呢,但是带宽就开始飙升了。而P2P系统的恢复需要较长时间,因此必须使用热备,在出现问题时切换到正常的系统。

这些挑战都是我们曾经遇到的,还包括没有遇到的。