文章

Docker搭建支持 HTTPS 的 Webrtc Apprtc Server实践

最近想测试下最新的webrtc代码拥塞表现,所以想跑下最新的webrtc中自带的 AppRTCMobile程序, 网上关于Apprtc服务器的搭建文章比较多,现在浏览器和苹果端对要求使用https, 网上的介绍文章大部分不能直接使用,配置也非常繁琐。摸索之后,搞了一天,终于跑了起来,记录一下

自己一步步安装肯定非常复杂,所以直接基于 piasy/apprtc-server 这个docker镜像进行了修改。这个镜像是不支持 ssl 通信的,原始使用参考文章

如果不想自己配置,或者没有服务器资源,可以直接使用 https://rtc.fifo.site 这个地址测试, 只支持同个网段通信。

配置环境

  • 阿里云ECS
  • Centos Stream 9
  • docker
  • 1panel面板(强烈推荐安装,简化命令操作,也可以用宝塔面板,功能类似)

因为用docker,所以系统版本无所谓,只要能跑起来docker,x86_64架构(因为下面使用的docker镜像只有x86_64架构的)就可以。1panel面板,用于设置域名反向代理,ssl证书申请相关配置,建议安装一个,参考这里

容器创建

docker 创建 apprtc 容器

1
docker run --name apprtc -e PUBLIC_IP=rtc.fifo.site -t -i piasy/apprtc-server

解释:使用 piasy/apprtc-server 镜像,创建一个名为 apprtc 的容器,如果不熟悉docker,可以把上面的命令问给ChatGPT,解释的很明白.

默认 docker 网卡使用桥接模式,分配独立的 ip 地址,一般是 172.17.0.2, 端口使用情况如下:

  • 8080 (TCP)用于 Room Server,房间服务;
  • 8089 (TCP) 用于 Signal Server,信令服务,websocket 通信;
  • 3033 (TCP) 用于 ICE Server,打洞服务;
  • 3478(TCP和UDP) 和 59000-65000 (UDP)

之所以没有用 -p 参数做端口映射,是因为后面会使用反向代理,不用直接对外暴露这些端口,防火墙或者安全组不需要额外的端口放行,只要80和443端口可以通信即可。

修改容器

终端执行命令: apprtc为容器名称,这条命令可以进入容器的终端,有点类似于ssh远程终端,只不过进入的是docker容器

1
docker exec -i -t apprtc /bin/bash

如果安装了 1panel,可以直接在面板的容器菜单找到 apprtc 容器,选择终端,进入docker容器终端

image-20240712001320002panel docker容器终端

1. 修改 constants.py文件:

1
vim /apprtc/out/app_engine/constants.py

修改内容,做域名替换:

1
2
3
4
## 修改 ice地址
ICE_SERVER_BASE_URL = 'https://rtc.fifo.site'
## 修改wss地址
WSS_INSTANCE_HOST_KEY: 'rtc.fifo.site',

image-20240712001647788

2. 修改 apprtc.py文件:

1
vim /apprtc/out/app_engine/apprtc.py

将这个判断else分支中的 ws:// 改为 wss://, http:// 改为 https

image-20240712002347319

3. 修改 apprtc.debug.js文件:

1
vim /apprtc/out/app_engine/js/apprtc.debug.js	

修改内容:

1
2
#全局搜索pushState, 在pushState行前一行增加:
roomLink=roomLink.substring("http","https");

image-20240712001031289修改apprtc.debug.js

4 修改 run.sh

注释掉蓝色这三行,这个脚本是容器开始运行时候执行,防止容器重启后把上面的更改给变更回去

image-20240712002005731

重启容器

终端执行命令:

1
docker restart apprtc

反向代理和SSL

浏览器和iOS系统都对外网域名有SSL的要求,证书的话直接使用 1panel面板申请,可以自行百度下,很简单

image-20240712002922163证书申请

申请完证书,创建网站

image-20240712003039459创建网站

域名配置 https:

image-20240712003214018https配置

反向代理配置:

image-20240712003312406反向代理配置

1
2
3
https://rtc.fifo.site                 => 172.17.0.2:8080
https://rtc.fifo.site/ws              => 172.17.0.2:8089
https://rtc.fifo.site/iceconfig       => 172.17.0.2:3033

切忌前端请求路径和后端代理地址不要配错!

这样就可以通过 https://rtc.fifo.site 访问房间服务器,请求会被代理到本地的 http://172.17.0.2:8080端口,也就是docker容器中房间服务器监听的端口。同理信令通过外部请求wss://rtc.fifo.site/ws被转发到docker容器监听的 8089 信令端口,可以用这个工具测试websocket是否能连通

image-20240712004439517websocket连通测试

ice通过外部请求https://rtc.fifo.site/iceconfig被转发到docker容器监听的 3033端口。

为什么可以这么配置呢?因为在apprtc程序中,默认已经做了路径映射。这样外部的请求都是通过https,转发到非ssl的内部服务上,这就是反向代理,很巧妙!

通过不同请求路径做反向代理还有一个好处就是没有跨域的问题,问了下GPT,同一个域名的子域名,以及同一个域名不同端口间访问都属于跨域,上面反向代理不存在这种问题✌🏻

到这里所有的配置就弄完了,之后可以浏览器访问测试

浏览器访问

浏览器输入配置的域名 https://rtc.fifo.site, 可以看到链接是安全的

20240712101436Chrome Https访问

运行AppRTC Mac端Demo, 互通效果如下。

不知道为啥,必须得Mac端App先进房,浏览器后进房才能看到对方。两个浏览器互通没有先后进房的问题。

image-20240711205349329Mac Apprtc Demo

结语

整个过程配置起来并不复杂,但是确是花了一天时间试错总结出来的结果,修改4个文件,配置下反向代理就OK了。

但是到现在我还对反向代理,以及和docker内部服务的一些运作机制不是太明白,倒确实不影响使用,但弄清楚总是好的,以后有时间再了解下吧

下一步就是测试webrtc的拥塞控制在带宽限制,丢包,以及带宽抢占方面的表现了,后面也会把结果发出来,目前最新 webrtc差不多到 M120+了吧,版本迭代的很快!

参考资料

本文由作者按照 CC BY 4.0 进行授权