目标：
本章节开始分析SRS4.0 WebRTC服务相关的代码逻辑，分析代码之前，根据个人的体验，最好的学习方式，应该是先把SRS4.0 WebRTC环境搭建起来，通过反复的实际操作，才能真正理解相关的知识点。
另外，由于WebRTC环境涉及的内容比较多：服务端、客户端浏览器设置、信令服务器、https协议，导致网上很多关于搭建SRS4.0 WebRTC服务环境的一些文档对新手总是不够友好，所以这篇文档把自己的搭建过程记录下来，方便后面查询学习。
内容：
1、WebRTC测试环境组网图
如上图所示，搭建SRS4.0 WebRTC测试环境大概需要三台主机，两个客户端和一个服务器，IP地址分别是192.168.9.100，192.168.9.101，192.168.9.200 (其实，一台实体机通过vmware起几台虚拟机也能搞定这个配置环境)，客户端系统为win10，服务器系统为ubuntu16.04。
2、下载SRS4.0源代码并编译
在192.168.9.200服务器上，下载并编译SRS4.0源代码
// 从github下载SRS
git clone https://github.com/ossrs/srs.git
// 或者从gitee下载SRS
git clone https://gitee.com/winlinvip/srs.oschina.git
// 切换到4.0分支
git checkout -b srs40 origin/4.0release
// 从远程分支拉取代码
git pull
执行如下命令完成代码编译
cd trunk/ // 进入源代码目录
./configure // 执行配置文件
make // 使用make命令编译
3、测试场景1：RTC to RTC推拉流测试
如上图，对于RTC to RTC的推拉流测试，服务端需要部署3个服务：
1、端口为8088的HTTPS服务，为客户的提供静态网页和js代码拉取。
2、端口为443的HTTPS服务，处理客户端发送的API请求。（这个443端口在客户端js代码中已经写死了）
3、端口为8000的UDP端口，提供WebRTC服务。
这三个服务在SRS4.0中已经支持了，我们需要做的就是修改SRS的启动配置文件，并启动SRS。
1）在源代码的conf目录下，创建一个名为test.conf的启动配置文件，内容如下：
listen 1935; ## RTMP服务端口号
max_connections 1000;
daemon off;
srs_log_tank console; ## 表示服务在控制台运行，方便看日志
http_server {
enabled on;
listen 8080;
dir ./objs/nginx/html; ## 这个路径下有客户端浏览器需要的静态网页和js代码
https {
enabled on;
listen 8088; ## 8088端口支持https server，为客户端提供静态网页
key ./conf/server.key;
cert ./conf/server.crt;
}
}
http_api {
enabled on;
listen 1985;
https {
enabled on;
listen 443; ## 443端口支持https api(注意这里的端口号一定要是443)
key ./conf/server.key;
cert ./conf/server.crt;
}
}
stats {
network 0;
}
rtc_server {
enabled on; ## 打开WebRTC功能
listen 8000; ## WebRTC服务监听8000端口
candidate $CANDIDATE; ## 正式环境，这里最好改成服务器的物理IP地址
}
vhost __defaultVhost__ {
rtc {
enabled on; ## RTC配置
bframe discard;
}
}
2）启动SRS服务器
./objs/srs -c ./conf/test.conf
3）打开客户端浏览器
1、在192.168.9.100上，打开一个chrome浏览器，输入https://192.168.9.200:8088/players/rtc_publisher.html 如下图：
其中URL webrtc://192.168.9.200/live/livestream是客户端JS代码自动生成的，推拉流客户端必须保持一致
2、点击”开始推流“按钮，页面如下：记得要允许网页获取摄像头和麦克风权限
3、在192.168.9.101上，打开一个chrome浏览器，输入https://192.168.9.200:8088/players/rtc_player.html 如下图：
4、点击”播放视频“按钮，页面如下：
OK，这个简单的WebRTC推拉流测试就成功了。总结一下：先弄清楚基本原理和需要启动的服务后，重点是conf配置文件要写正确。如果还有问题的同学，可以给我留言。
4、测试场景2：SFU One to One推拉流测试
如果只是为了研究WebRTC协议，上面那个测试场景基本够用了。这里使用SRS4.0的WebRTC服务作为一个SFU，为客户端提供1对1的音视频通话，更像一个实际的产品，它的主要目的是启发大家基于SRS做二次开发，实现面向实际客户的RTC产品。
所以这个测试场景不可避免要引入信令服务器和https代理服务器的部署，对于这些组件，SRS的作者其实都已经提供了，只有搞清楚原理，搭建起来也很简单。
关于信令服务器和代理服务器的工作原理，可参考SRS作者写的技术文档 https://mp.weixin.qq.com/s/xWe6f9WRhtwnpJQ8SO0Eeg
因为这两个服务器是go语言写的，所以主机192.168.9.200的Ubuntu16.04系统中必须安装go语言环境，且版本最好是1.13以上。可参考以下链接：ubuntu安装go 1.13.8 https://blog.51cto.com/shijianfeng/2914276
1）SFU One to One模式服务部署图
2）修改SRS启动配置文件并启动SRS
修改SRS启动配置文件test.conf，内容如下：（重点就是要去掉和HTTPS相关的配置）
listen 1935; ## RTMP服务端口号
max_connections 1000;
daemon off;
srs_log_tank console; ## 表示服务在控制台运行，方便看日志
http_server {
enabled on;
listen 8080;
dir ./objs/nginx/html;
}
http_api {
enabled on;
listen 1985;
}
stats {
network 0;
}
rtc_server {
enabled on;
listen 8000; ## WebRTC服务监听8000端口
candidate $CANDIDATE;
}
vhost __defaultVhost__ {
rtc {
enabled on;
bframe discard;
}
}
启动SRS4.0服务器
./objs/srs -c ./conf/test.conf
3）编译并启动httpx-static代理服务器和signaling信令服务器
1、编译并启动signaling信令服务器
cd ~/git/srs/trunk/3rdparty/signaling && make && ./objs/signaling
信令服务运行后打印日志如下，此服务默认监听1989端口
[trace] 2021/10/13 01:55:54.131251 Signaling ok, root=./www, home page is http://localhost:1989
2、编译并启动httpx-static代理服务器
cd ~/git/srs/trunk/3rdparty/httpx-static && make &&
./objs/httpx-static -http 80 -https 443 -ssk server.key -ssc server.crt \
-proxy http://127.0.0.1:1989/sig -proxy http://127.0.0.1:1985/rtc \
-proxy http://127.0.0.1:8080/
httpx-static代理服务运行后打印日志如下，此服务http监听80端口，https监听443端口，信令代理到本地1989端口，rtc-api代理到本地1985端口，普通http代理到本地8080端口
[trace] 2021/10/13 02:01:51.974685 [5702][1000] Proxy /sig to http://127.0.0.1:1989/sig
[trace] 2021/10/13 02:01:51.977562 [5702][1000] Proxy /rtc to http://127.0.0.1:1985/rtc
[trace] 2021/10/13 02:01:51.977883 [5702][1000] Proxy / to http://127.0.0.1:8080/
[trace] 2021/10/13 02:01:51.979071 [5702][1000] http(:80), https(:443), self-sign(server.key, server.crt) html root at ./html
[trace] 2021/10/13 02:01:51.981048 [5702][1001] https serve at 443
[trace] 2021/10/13 02:01:51.981552 [5702][1002] http serve at 80
4）打开客户端浏览器
1、在192.168.9.100和192.168.9.101上，分别打开一个chrome浏览器，输入 https://192.168.9.200/demos/one2one.html?autostart=true 如下图：
注意：如图所示，界面中的SRS 、Room 、Display中的内容，一起组成了一个本地WebRTC的推流URL。在两个准备互相通话的浏览器中，两个浏览器Web页面的SRS和Room内容必须保持一致，而Display的内容必须保证不一样。
例如：192.168.9.100机器上Display的内容是100，而192.168.9.101机器上Display的内容是101，则192.168.9.100机器的WebRTC推流地址就是webrtc://192.168.9.200/live/100，而192.168.9.101机器的WebRTC推流地址就是webrtc://192.168.9.200/live/101。
最终，两个客户端在“开始通话”的时候，会分别和SRS服务器之间创建推流连接和拉流连接，其中每个客户端都使用自己的推流地址创建自己的推流连接，并用对方的推流地址创建自己的拉流连接。
这里还有个问题就是，一个客户端是如何知道另一个客户端的WebRTC推流地址的？呵呵，这当然是通过信令服务器实现的。
5、测试场景3：SFU多人通话视频会议
如果理解了前面SFU One 2 One的运行原理，应该不难理解使用SRS进行多人通话的环境搭建。具体可参考下面的技术文档：
SRS做多人会议，以及视频号连麦直播
总结
本文通过搭建SRS4.0 WebRTC服务的各种典型测试场景，希望达到两个目的：
1）初步了解WebRTC工作原理
2）为深入分析SRS4.0 WebRTC代码处理逻辑做准备
最后是一篇网上的文章，
http://www.ctiforum.com/news/guandian/549857.html，大概是翻译老外的，难度不深，但非常长，谈了WebRTC技术的来龙去脉，几乎把WebRTC所有技术概念都做了非常好的名词解释，提前理解一些技术概念方便后面理解软件代码。
1763
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
