相关协议
RTMP协议
实时消息传输协议。
基于TCP协议簇,属于TCP/IP四层模型的应用层,是用于实现实时数据通讯的网络协议。
连接时一整条数据流封装成FLV通过HTTP提供出去,没有落地文件,基于TCP长连接,不需要多次重连。
RTMP数据包结构
基本头:
- 1B:CSID(唯一索引)
- 2B:1B置0,剩下一个字节表示CSID-64
- 3B:1B置1,CSID = 第一个字节的值*256+第二个字节的值*64
消息头:
timetamp: 3B
message-length:1B,Message总长,不是切片长
type-id:1B,实际发送数据类型,8 -> 音频,9 -> 视频
stream-id:4B,当前chunl所在的ID
扩展时间戳
块数据
最大的块至少128B,块至少携带一个字节的内容
握手
-
过程简述
握手包含三个固定大小的块,客服端发送的三个是C0,C1,C2,服务端的三个是S0,S1,S2.
client--> server : 发送一个创建流的请求 (C0、C1)。
server--> client : 返回一个流的索引号 (S0、S1、S2)。
client--> server : 开始发送 (C2)
client--> server : 发送音视频数据(这些包用流的索引号来唯一标识)
-
完整握手的包格式
C0、S0: 1B,RTMP的版本,一般为3。
C1、S1: time(4B)+version(4B)+digest(764B)+key(764B)
C2、S2:random-data(1504B)+ digest-data(32B)
-
简单握手的包格式
C0、S0:
1B,RTMP的版本,一般为3,如果服务器无法识别版本号,应该回复版本3,客户端可以选择把版本降低到3,或者终止握手。
C1、S1:
time(4B):用时间戳,标识所有流段的时刻,尽可能多个流块使用相同的时间戳进行同步。
zero(4B):必须为全0。
random(1528B):可以包括任何数据,必须随机,作为后续识别的索引。
C2、S2: C1和S1的回应
time(4B):对端发送的时间戳
time2(4B):接受对端发送过来的包的时刻
random(1628B):对端发送过来的随机数
中断消息
他通讯一方将接收到的chunk-id作为当前协议有效数据,标识哪个chunk-id可以被丢弃
HLS协议
苹果公司发布的基于HTTP流媒体传输协议,原理是把直播流切片传输,每次用户可以只下载一部分,这部分可以在不同的备用源中下载(最近节点)。
基于HTTP80端口传输,很少会被防火墙拦下来。
同时,基于HTTP协议客户端按顺序下载春处在服务器的普通TS文件。
Video inputs
进行视频推流,视频源文件格式任意,协议一般RMTP。
Server
负责转码和切片。
传到服务器上的文件,转码模块将视频源中的数据转码成H264然后再stream segmenter中切片成ts文件
Distruibution
切片器创建一个索引文件,先下载一级Index file,里面记录了二级索引(alternate-A、Alternate-B、Alternate-C)的地址,然后客户端再去下载二级索引,二级索引中记录ts文件的下载地址。
client
通过HTTP协议播放视频。
会话模式
-
点播
可以获取到一个静态的索引文件,包含完整的资源文件地址,VOD点播拥有加密认证技术和动态切换文件传输速率的功能。
-
Live
实时事件的录制展示,索引文件动态变化,需要不停地更换索引文件,移除旧的索引文件。
协议规定
- 视频的封装格式是TS、m3u8。
- 视频的编码格式为H264,音频编码格式为MP3、AAC或者AC-3。
- 除了TS视频文件本身,还定义了用来控制播放的m3u8文件(文本文件)。
m3u8文件
-
#EXTM3U
每个M3U文件第一行都是这个tag,起标示作用
-
#EXT-X-VERSION
标示协议版本
-
#EXT-X-STREAM-INF
[,attribute = value]*
标签属性:
BANDWIDTH 指定码率
PROGRAM-ID 唯一ID
CODECS 指定编码类型
-
#EXT-X-MEDIA-SEQUENCE
每个media URI在playlist中只有唯一序号,相邻之间序号相连。
几个协议的对比
协议 | 实现原理 | 延时 | 穿透性 | 跨平台 | 应用场景 |
---|---|---|---|---|---|
RMTP | TCP传输流数据 | 1-3s | 1935端口可能禁用 | 差 | 低延时的互动直播,APP端 |
HLS | 视频切片,传输ts切片文件 | 取决于切片大小,一般>10s | 高 | 好 | 非互动直播,微信端 |
HDL | 通过HTTP协议传输FLV文件 | 1-3s 好于RTMP | 高 | 差 | 低延时互动直播 |
CDN原理
流程
-
本地DNS解析URL,DNS系统将域名解析权交给CNAME指向的CDN专用DNS服务器。
-
CDN的DNS服务器将全局负载均衡设备IP返回给用户,浏览器向服务器发起访问请求
-
CDN全局负载均衡设备根据设备IP地址和URL,选择一台用户所属区域的负载均衡设备,让浏览器发起请求
-
区域负载均衡设备选择一台合适的缓存服务器提供服务:
- IP地址,离哪个服务器最近;
- 根据URL携带内容名称,看哪个服务器上有用户所需内容
- 服务器负载,哪台服务器还有能力
-
全局负载均衡设备把服务器的IP地址返回给用户
-
用户向缓存服务器发起请求,缓存服务响应请求,如果缓存服务器上没有内容,就要向上一级缓存服务器请求内容,直至追溯到网站的源服务器将内容拉到本地。
缓存算法
负载均衡(Nginx)
作用
主要负责对所有发起服务请求的用户进行访问调度,确定提供给用户的地址是最终地址。
两级调度体系分为全局负载均衡(GSLB)和本地负载均衡(SLB),GSLB通过对每个服务节点进行最优判断
web集群
是由多个同时运行同一个web应用的服务器组成,一般分成三大类:
-
高性能集群(HPC):
以提高科学计算能力为目标的集群技术
-
高可用集群(HA)
如果高可用集群中的某个节点发生故障,那么这段时间内将由其他节点代替它的工作。
这种集群,一般有两种工作方式
-
主-主(Active-Active)方式:
支撑用户业务的应用程序正常状态下分别在两台节点上运行,但给某一方资源系统故障时,就会将应用和相关资源切换到对方节点上。
这样不会有服务器闲置,如果故障发生,导致应用字同一台服务器上娙,可能会导致处理能力不够的情况。
-
主 - 从(Active - Standby)工作方式:
为了提高可用性,主节点处理客户机请求,备用节点处于空闲状态,当主节点出现故障时,备用节点结题工作。
这种方式,节点二能完全接管应用保证运行时的处理能力要求,但是正常工作时会造成资源浪费。
-
-
高可用扩展集群
带有负载均衡算法的服务器集群技术,每个节点都处理一部分负载,并且可以动态的分配负载。
策略
-
轮询
按请求时间顺序逐一分配到不同的后端你服务器,如果后端服务器down掉,自动剔除
upstream backserver{ server 192.168.0.14; server 192.168.0.15; }
-
指定权重
在轮询几率,在后端服务器性能不均的情况,weight和访问比率成正比。
upstream backserver{ server 192.168.0.14; server 192.168.0.15; }
-
ip绑定hash
每个请求按访问ip的hash结果分配,这样每个访客固定一个后端服务器
-
fair
按后端服务器响应时间来分配请求,响应时间短的优先
upstream backserver{ server server1; server server2; fair; }
-
url_hash
按访问url的hash结果匹配,每个url定向到同一个后端服务器,当后端服务器为缓存的时候有效。
upstream backserver { server squid1:3128; server squid2:3128; hash $request_uri; hash_method crc32; }
淘宝开源Nginx负载均衡框架:Tengine
服务分发
负责响应最终用户的请求,把缓存在本地的内容快速地提供给用户
推流
推流,即主播将自己本地客户端采集编码后的视频数据“推”出去,上行到流媒体服务器。
边缘推流
功能:有限将视频推流至最优CDN节点,保证用户访问的都是最佳上行网络。
中心推流
功能:通过BGP线路将视频流直接传输至直播中心进行内容分发。
拉流
服务器已有直播内容,根据协议与服务器建立连接并接收数据,进行拉取的过程。