SRS 5.0支持WebRTC over TCP

在很多网络条件下，WebRTC不适合使用UDP传输，因此支持TCP传输是极其重要的能力；而且SRS支持的是直接TCP传输的方式，避免使用TURN中转带来的额外网络层问题；这对于LoadBalancer也是非常友好的，一般支持TCP会更友好。

为什么这么重要？

---

大约两年前SRS支持了WebRTC，虽然支持了不少功能但还不够完善，这两年收到了很多反馈，其中常见的而且非常重要的有：

• 用不了UDP，可能是公司网络封掉了UDP协议，或者封掉了小于10000的UDP端口，总之各种不可用的场景，SRS有个小工具检测UDP端口可用性，请参考#2843。

• 媒体协议和端口太多了，TCP有RTMP(1935)和HTTP(80/443)，UDP有WebRTC(8000)和SRT(10080)，还有HTTP API端口(1985)，如何让协议端口更收敛？多开一个端口就多一份麻烦。HTTP API和Stream使用同样端口的问题，请参考#2881。

• UDP可用但丢包比较严重，有可能是系统设置问题，也有可能是网络设备或环境导致丢包，往往TCP是没问题的，请参考#2852

如果SRS能像HTTP-FLV那样，在HTTP(80)端口传输媒体数据，那该多么简单？多么可靠啊！只要能上网，HTTP(80)端口就一定是可用的。流传输图如下：

Publisher --------RTC------> SRS --------RTC--------> Player

(over TCP/80) (over TCP/80)

Note: 实际上WebRTC是有个API请求的，所以这里还省略了HTTP API请求，可以在同样端口上传输HTTP API，HTTP Stream和WebRTC数据。

专业人士一般会说：这个问题可以用TURN解决，流传输图如下：

Publisher -----> TURN ----> SRS -----> TURN -----> Player

(over TURN/3478). (over TURN/3478)

TURN的方案明显是不好的，有几个问题：

• 多引入了一个网元，需要额外考虑部署和依赖问题，而且有些TURN可能还没提供Docker。

• 多引入了一个协议，看起来简单的协议（几个交互），如何监控和排查问题，如何运维都是非常麻