Skip to main content

SRS Server - 支持WebRTC over TCP

· 9 分钟

Written by Winlin, 李鹏

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

Why Important?

大约两年前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。
  • 多引入了一个协议，看起来简单的协议（几个交互），如何监控和排查问题，如何运维都是非常麻烦的。
  • 延迟和成本问题，多一跳就多一次延迟，多一份网元就多一个集群，这都是真金白银的CPU消耗。

因此，WebRTC支持TCP传输，最好的方案是直接TCP传输而不是TURN协议，参考以下两个RFC：

下面介绍下SRS目前的进展。

What's Now?

SRS 5.0正式解决了这个问题：

  • HTTP API、HTTP Stream、WebRTC over TCP，可以全部复用一个TCP端口，比如HTTPS(443)。
  • 支持直接UDP或TCP传输，不依赖TURN协议，没有额外的网元，没有额外部署和资源消耗。
  • 可部署在LoadBalancer后面(已实现)，可配合Proxy(未实现)或者Cluster(未实现)实现负载均衡和扩容。

Note: 注意需要升级到v5.0.60+，若使用Docker也请先确认SRS的版本。

我们先看最简单情况，用一个TCP(8080)端口，支持RTC推拉流：

docker run --rm -it -p 8080:8080/tcp \
  -e CANDIDATE="192.168.3.82" \
  -e SRS_HTTP_API_LISTEN=8080 \
  -e SRS_RTC_SERVER_TCP_ENABLED=on \
  -e SRS_RTC_SERVER_TCP_LISTEN=8080 \
  -e SRS_RTC_SERVER_PROTOCOL=tcp \
  registry.cn-hangzhou.aliyuncs.com/ossrs/srs:v5.0.60

一般需要支持直播，所以下面，只用一个TCP(8080)端口，支持RTC和直播：

docker run --rm -it -p 8080:8080/tcp \
  -e CANDIDATE="192.168.3.82" \
  -e SRS_VHOST_RTC_RTC_TO_RTMP=on \
  -e SRS_HTTP_API_LISTEN=8080 \
  -e SRS_RTC_SERVER_TCP_ENABLED=on \
  -e SRS_RTC_SERVER_TCP_LISTEN=8080 \
  -e SRS_RTC_SERVER_PROTOCOL=tcp \
  registry.cn-hangzhou.aliyuncs.com/ossrs/srs:v5.0.60

如果是非localhost推流，得使用HTTPS，所以可以默认使用TCP(8088)，启动命令如下：

docker run --rm -it -p 8088:8088/tcp \
  -e CANDIDATE="192.168.3.82" \
  -e SRS_VHOST_RTC_RTC_TO_RTMP=on \
  -e SRS_HTTP_API_LISTEN=8080 \
  -e SRS_HTTP_API_HTTPS_ENABLED=on \
  -e SRS_HTTP_API_HTTPS_LISTEN=8088 \
  -e SRS_HTTP_SERVER_HTTTPS_ENABLED=on \
  -e SRS_RTC_SERVER_TCP_ENABLED=on \
  -e SRS_RTC_SERVER_TCP_LISTEN=8088 \
  -e SRS_RTC_SERVER_PROTOCOL=tcp \
  registry.cn-hangzhou.aliyuncs.com/ossrs/srs:v5.0.60

Note: 可以换成IP访问。注意由于是自签名证书，所以需要点击下空白处，然后敲入字符串thisisunsafe

上面是通过环境变量配置的SRS，如果你习惯配置文件，也是可以的，和WebRTC over TCP相关的详细配置如下：

rtc_server {
    # For WebRTC over TCP directly, not TURN, see https://github.com/ossrs/srs/issues/2852
    # Some network does not support UDP, or not very well, so we use TCP like HTTP/80 port for firewall traversing.
    tcp {
        # Whether enable WebRTC over TCP.
        # Overwrite by env SRS_RTC_SERVER_TCP_ENABLED
        # Default: off
        enabled off;
        # The TCP listen port for WebRTC. Highly recommend is some normally used ports, such as TCP/80, TCP/443,
        # TCP/8000, TCP/8080 etc. However SRS default to TCP/8000 corresponding to UDP/8000.
        # Overwrite by env SRS_RTC_SERVER_TCP_LISTEN
        # Default: 8000
        listen 8000;
    }
    # The protocol for candidate to use, it can be:
    #       udp         Generate UDP candidates. Note that UDP server is always enabled for WebRTC.
    #       tcp         Generate TCP candidates. Fail if rtc_server.tcp(WebRTC over TCP) is disabled.
    #       all         Generate UDP+TCP candidates. Ignore if rtc_server.tcp(WebRTC over TCP) is disabled.
    # Note that if both are connected, we will use the first connected(DTLS done) one.
    # Overwrite by env SRS_RTC_SERVER_PROTOCOL
    # Default: udp
    protocol udp;
}

我们上面演示的是和HTTP复用端口，使用独立的TCP端口也是完全没问题的，具体可以自己尝试了。

Future Plan

饭一口口吃，路一步步走，代码一行行码；SRS欢迎大家贡献和参与，我们的深度开发者社区人越来越多了，已经达到了近50个深度定制SRS的开发者。

如果你在2013年错过了给SRS贡献RTMP，在2014年错过了贡献Edge集群，在2015年错过了贡献FLV，在2016年错过了贡献DVR，在2017年错过了MP4和DASH，在2018年错过了贡献Origin集群，在2019年错过了贡献Docker化和云原生，在2020年错过了SRT和WebRTC，在2021年错过了HLS集群，在2022年错过了新官网和SRT协程化。。。

今天，你又错过了贡献WebRTC over TCP，我和李鹏(TOC)花了两个下午搞定了；另外，也特别感谢夏立新(TOC)的预研，节省了我们不少时间。其实贡献并不难，难的是克服自己的惯性啊。

纵然有一万个不贡献的理由，对于程序员来说，有一个贡献的理由就够了：作为程序员，只白嫖开源却不曾贡献，和咸鱼又有何分别？！

你打算在2022年尾巴上错过贡献什么？还有4个月时间，我们就要冻结5.0的功能开发了，赶紧加入我们吧，还有非常多有意思又有价值的功能，等着你来一起完成。

©2013~2024 OSSRS 京ICP备19056366号-1