从交互方式来看,流媒体分为点播(VOD)和直播(LIVE)
直播(LIVE):HLS,RTMP,http+MP4,http+flv,RTP+RTSP
点播(VOD):http+MP4,http+flv,HLS,DASH.
从业务场景来看,总结一下常见的应用方案
直播:RTMP,HLS,http+flv
音视频通话:webrtc(RTP),SIP+RTP
视频点播:http+MP4,http+flv,hls
IPTV:RTSP(信令)+RTP(媒体)
会议电视:RTP(媒体)+SIP(信令),H323(信令)+RTP(媒体)
视频监控:国标SIP(信令)+RTP(媒体),RTSP(媒体)+RTP(媒体)
VOIP:SIP(信令)+RTP(媒体)
延时低,安全,满足单播、组播不同的要求
流媒体协议需要根据目标场景,选择TCP/UDP,再进行应用层协议开发
TCP和UDP之间最大的区别是:
TCP面向有连接,能够对自己提供的连接实施控制。
UDP面向无连接,不会对自己提供的连接实施控制。
TCP适用于要求可靠传输的应用,例如文件传输。
UDP适用于实时应用,例如:IP电话、视频会议、直播等。
但在流媒体的实际使用场景中,如果直接用UDP来传输音视频,那公网传输中无法避免的丢包、乱序等极端情况会导致客户端无法解码。而如果直接TCP来传输音视频,那TCP自身的拥塞控制机制、传输数据延时大,队头阻塞等问题,会对音视频的实时传输造成一定的困扰。
因此对于流媒体传输,需要对运输层TCP/UDP协议进行高层次的开发,以适应流媒体传输时的应用需求。
RTP(Real-time Transport Protocol)实时传输协议是用于Internet上针对多媒体数据流的一种传输层协议。
RTP协议和RTP控制协议RTCP一起使用,而且它是建立在UDP协议上的。
UDP一样,并不提供任何传输可靠性的保证和流量的拥塞控制机制,无法保证实时业务的服务质量。这里就有个疑问,既然UDP和RTP都是传输层协议,RTP由在UDP之上,那二者有什么关系?
简单来说,RTP协议和UDP两者共同完成传输层协议传输。UDP只是负责传输数据包,RTP提供时间标志戳及其他技术来保证流媒体在实时传输时的时间正确性。
(1)延时低
(2)具有多播功能
多播在网络视频会议方面有着很广泛的应用,它主要应用于这样一种环境
假设红色的圆为存放有视频数据的流媒体服务器,其他的圆为连接到该服务器的各个客户端,当所有的绿色的客户端要求同时观看红色服务器上的某一个视频时,如果服务器为每一路客户端单独建立连接进行数据的传输,这样明显不太合理浪费带宽,因此,多播技术可以很好地解决这种问题,即同一份数据,由服务器发送到公共的多播地址,各个客户端均监听同一个多播地址来获取数据,这样,既节省了带宽,同时也保证了各个客户端所观看的视频的同步。
RTP协议在最初就是为了实现类似的视频会议的应用而诞生的
(3)安全,支持加密数据和身份验证功能
实时传输控制协议(Real-time ControlProtocol,RTCP)与RTP共同定义在1996年提出的RFC 1889中,是和 RTP一起工作的控制协议。RTCP单独运行在低层协议上,由低层协议提供数据与控制包的复用。在RTP会话期间,每个会话参与者周期性地向所有其他参与者发送RTCP控制信息包,如下图所示。
对于RTP会话或者广播,通常使用单个多目标广播地址,属于这个会话的所有RTP和RTCP信息包都使用这个多目标广播地址,通过使用不同的端口号可把RTP信息包和RTCP信息包区分开来。
RTCP负责管理传输质量。在RTP会话期间,各参与者周期性地传送RTCP包,包中含有已发送的数据包的数量、丢失的数据包的数量等统计信息。服务器利用这些信息动态地改变传输速率,甚至改变有效载荷类型。
RTP和RTCP配合使用,能通过有效的反馈和最小的开销,使传输效率最佳化,因此特别适合在互联网上传输实时数据。
比RTP多了一个S的RTSP是RealTime Streaming Potocol 实时流协议,是传输层(RTP是传输层)之上的应用层协议,可选择UDP、组播UDP、TCP、RTP为传输机制。RTSP定义了双向多应用程序如何有效地通过IP网络传送多媒体数据。
RTSP充当多媒体服务器的网络远程控制,使实时数据如音频与视频的快进快退、中止、播放成为可能。
和RTP相比,应用场景上RTSP是一种双向实时数据传输协议,它允许客户端向服务器端发送请求,如回放、快进、倒退等操作。协议上,RTSP是应用层协议,可基于RTP来传送数据,还可以选择TCP、UDP、组播UDP等通道来发送数据,具有很好的扩展性。这里就比较清晰了,运营商的IPTV直播业务,没有任何回放、倒退等操作,所以可以直接采用UDP+RTP+组播实现。
控制到视频帧,因此可以承载实时性很高的应用
RTMP(Real Time Messaging Protocol)实时消息传送协议是Adobe Systems公司为Flash播放器和服务器之间音频、视频和数据传输开发的开放协议。
RTMP协议从属于应用层,被设计用来在适合的传输协议(如TCP)上复用和打包多媒体传输流(如音频、视频和互动内容)。RTMP提供了一套全双工的可靠的多路复用消息服务,类似于TCP协议[RFC0793],用来在一对结点之间并行传输带时间戳的音频流,视频流,数据流。通常情况下,不同类型的消息会被分配不同的优先级,当网络传输能力受限时,优先级用来控制消息在网络底层的排队顺序。
低延迟,稳定性高,支持所有摄像头格式,浏览器加载 flash插件就可以直接播放
HTTP Live Streaming(HLS)是苹果公司(Apple Inc.)实现的基于HTTP的流媒体传输协议,可实现流媒体的直播和点播,主要应用在iOS系统,为iOS设备(如iPhone、iPad)提供音视频直播和点播方案。HLS点播,基本上就是常见的分段HTTP点播,不同在于,它的分段非常小。
相对于常见的流媒体直播协议,例如RTMP协议、RTSP协议、MMS协议等,HLS直播最大的不同在于,直播客户端获取到的,并不是一个完整的数据流。HLS协议在服务器端将直播数据流存储为连续的、很短时长的媒体文件(MPEG-TS格式),而客户端则不断的下载并播放这些小文件,因为服务器端总是会将最新的直播数据生成新的小文件,这样客户端只要不停的按顺序播放从服务器获取到的文件,就实现了直播。由此可见,基本上可以认为,HLS是以点播的技术方式来实现直播。由于数据通过HTTP协议传输,所以完全不用考虑防火墙或者代理的问题,而且分段文件的时长很短,客户端可以很快的选择和切换码率,以适应不同带宽条件下的播放。不过HLS的这种技术特点,决定了它的延迟一般总是会高于普通的流媒体直播协议。
(1)跨平台性:支持iOS/Android/浏览器,通用性强。
(2)穿墙能力强:由于HLS是基于HTTP协议的,因此HTTP数据能够穿透的防火墙或者代理服务器HLS都可以做到,基本不会遇到被防火墙屏蔽的情况。
(3)切换码率快(清晰度):自带多码率自适应,客户端可以选择从许多不同的备用源中以不同的速率下载同样的资源,允许流媒体会话适应不同的数据速率。客户端可以很快的选择和切换码率,以适应不同带宽条件下的播放。
(4)负载均衡:HLS基于无状态协议(HTTP),客户端只是按照顺序使用下载存储在服务器的普通TS文件,做负责均衡如同普通的HTTP文件服务器的负载均衡一样简单。
安全可靠传输协议(Secure Reliable Transport)简称SRT,是一种基于UDT协议的开源互联网传输协议,Haivision和Wowza合作成立SRT联盟,管理和支持SRT协议开源应用的组织,这个组织致力于促进视频流解决方案的互通性,以及推动视频产业先驱协作前进,实现低延时网络视频传输。
SRT是时下非常受欢迎的开源低延迟视频传输协议,SRT解决了复杂的传输时序问题,SRT可以减少延迟,消除中心瓶颈,并降低网络成本。
(1)可靠性:适应于任何网络环境,高效处理网络丢包、抖动和带宽波动等干扰
(2)延迟低:由于采用了UDP传输方式,并使用ARQ的丢包恢复机制,基于公网的传输延迟级别一般可控制在1s以内
(3)高质量:SRT的传输和纠错机制可以最大化利用可用带宽并排除网络错误和干扰,因此可以在同等网络环境下传输更高码率的视频流,配合H.264和HEVC等高效编码格式,能够在不良的网络状况下依然保证视频的高质量
(4)带宽利用率高:不同于ABR的多码率自适应分发技术需要为冗余码率占用额外的带宽,SRT实时监测网络链路状态,并可以进行实时的码率调整(NAE,网络自适应编码)。此外,ARQ的丢包恢复机制相比TCP的丢包恢复机制也大大节省带宽,减少网络拥塞
(5)安全性:SRT采用AES-128或256加密保护内容安全
(6)免费开源:SRT完全免费开源
TCP是一个面向连接的协议,TCP一定是点对点的,一定是两个主机来建立连接的,TCP肯定是单播。
只有UDP才会使用广播和组播。
有时一个主机要向网上的所有其它主机发送帧,这就是广播,广播分为二层广播(目的MAC全F)和三层广播(IP地址的主机位全1),二层广播是不能跨路由器的,三层广播是可以跨路由器路由的。
多播(组播)属于单播和广播之间,帧仅传送给属于多播组的多个主机。
在广播电视领域为了减少服务器压力,通常使用组播跟用户推流。如IPTV,通常机顶盒通过光猫加入某个组播地址,接收某个CDN的组播流。
http://www.52im.net/thread-267-1-1.html
https://zhuanlan.zhihu.com/p/496823042
https://blog.csdn.net/fengliang191/article/details/120813885
https://blog.csdn.net/weixin_38054045/article/details/104390238
https://zhuanlan.zhihu.com/p/551804049
https://cloud.tencent.com/developer/article/1038381
https://blog.csdn.net/xiaoliuliu2050/article/details/103954804
https://zhuanlan.zhihu.com/p/114436399
https://zhuanlan.zhihu.com/p/403771996