程序地带

[RTMP] 国内各大视频直播CDN厂商推流抢流行为分析


背景

当存在一个推流客户端正在向rtmp://xxx.com/live/yyy推流时,又有另外一个推流客户端同时对这个地址进行推流,会发生什么呢?


查阅了 Adobe RTMP Spec 发现规范本身并未说明和定义这个场景下RTMP服务器应该怎么处理。


最近在实际工作中遇到部分客户对推流地址资源管理不恰当而导致重复推流报错的问题,且在查问题的过程中发现各个CDN厂商对“抢流”的处理各不相同,查阅相关文档说明发现资料甚少,故专门对它们的抢流行为做如下分析。


抢流:指对同个地址资源进行重复推流


步骤
打开Wireshark捕获网卡,过滤规则:tcp && tcp.port == 1935 (之所以不直接写rtmpt是因为还想观察传输层的行为)
获取对应厂商的推拉流URL,假设推流地址是:rtmp://xxx.com/live/yyy
使用ffmpeg推送一个本地电影文件:ffmpeg -re -i Movie-1.flv -vcodec h264 -f flv "rtmp://xxx.com/live/yyy"
使用另一个ffmpeg推送另一个本地电影文件到同个URL:ffmpeg -re -i Movie-2.flv -vcodec h264 -f flv "rtmp://xxx.com/live/yyy"
使用ffplay播放拉流地址内容
观察现象并分析Wireshark抓包结果
厂商
网宿
阿里云
腾讯云
七牛云
金山云
数据

注:下列结果仅代表发表本文的时候的各CDN厂家行为,随着厂商对服务器的更新迭代,可能会有所改变。


厂商
现象
结论
官方文档说明
与文档描述一致
网宿
二次推流报错,ffplay拉流播放的是Movie-1内容
抓包分析发现第二次推流的RTMP连接能握手成功,但是publish()请求发出之后服务器应答onStatus("NetStream.Publish.BadName")(见参考文档)
直播推流与拉流
✔️
阿里云
二次推流报错,ffplay拉流播放的是Movie-1内容
抓包分析发现第二次推流的RTMP连接能握手成功,但是推流几秒之后CDN服务器会发来TCP RST包强制断开RTMP的TCP连接
未找到

腾讯云
二次推流成功,ffplay拉流播放的是Movie-1内容 关闭第一个推流的程序,播放内容变成Movie-2的内容
官方文档表明会拒绝第二个推流请求,但是实际实验下来竟然是可以重复推且不报错,不知道腾讯云这么实现有没有其他用意
推流失败问题排查

七牛云
二次推流报错,ffplay拉流播放的是Movie-1内容
RTMP能握手成功,但是推流几秒之后服务器会发来TCP RST包强制断开RTMP的TCP连接 与官方文档中提到的后者挤掉前者的说法不一致
推流不成功的原因和解决方法

金山云
二次推流报错,ffplay拉流播放的是Movie-1内容
抓包分析发现第二次推流的RTMP连接能握手成功,但是publish()请求发出之后服务器应答onStatus("NetStream.Publish.AlreadyExistStreamName")(见参考文档)
推拉流接入
✔️
结论

总的来说,按当前实验结果来看,在这种细枝末节的功能点上,金山云的文档说明最清晰最规范,点个赞!


网宿的行为符合Flash AS3的定义,至少有据可依。


而腾讯云与七牛云的文档说明均存在错误的地方(至少本次实验中是这样的),尤其是腾讯云的现象让我很意外。


而阿里云竟然连这块的文档都没有。。(也许是我没搜到,若有的话望指正)


参考

Adobe ActionScript3.0 NetStatusEvent


版权声明:本文为博主原创文章,遵循 CC 4.0 BY-SA 版权协议,转载请附上原文出处链接和本声明。
本文链接:https://www.cnblogs.com/suiyek/p/14268088.html

随机推荐

sunday算法特征码_sunday 算法

sunday算法编辑锁定Sunday算法是DanielM.Sunday于1990年提出的字符串模式匹配。其核心思想是:在匹配过程中,模式串发现不匹配时,算法能...

櫻花朽木 阅读(120)

sunday算法特征码_Sunday算法介绍及Java实现

前言最初想写这篇文章的原因是在LeetCode上看到了一道实现strStr函数的题:实现strStr()函数。给定一个haystack字符串和一个needle字符串,在ha...

北溟先生 阅读(487)