HTTP & RTMP 直播比较

HTTP协议的主要特点可概括如下：

1.支持客户/服务器模式。

2.简单快速：

客户向服务器请求服务时，只需传送请求方法和路径。请求方法常用的有GET、HEAD、POST。每种方法规定了客户与服务器联系的类型不同。由于HTTP协议简单，使得HTTP服务器的程序规模小，因而通信速度很快。

3.灵活：

HTTP允许传输任意类型的数据对象。正在传输的类型由Content-Type加以标记。

4.无连接：

无连接的含义是限制每次连接只处理一个请求。服务器处理完客户的请求，并收到客户的应答后，即断开连接。采用这种方式可以节省传输时间。

5.无状态：

HTTP协议是无状态协议。无状态是指协议对于事务处理没有记忆能力。缺少状态意味着如果后续处理需要前面的信息，则它必须重传，这样可能导致每次连接传送的数据量增大。另一方面，在服务器不需要先前信息时它的应答就较快。


HLS直播最大的不同在于，直播客户端获取到的，并不是一个完整的数据流。HLS协议在服务器端将直播数据流存储为连续的、很短时长的媒体文件（MPEG-TS格式），而客户端则不断的下载并播放这些小文件，因为服务器端总是会将最新的直播数据生成新的小文件，这样客户端只要不停的按顺序播放从服务器获取到的文件，就实现了直播。

由此可见，基本上可以认为，HLS是以点播的技术方式来实现直播。由于数据通过HTTP协议传输，所以完全不用考虑防火墙或者代理的问题，而且分段文件的时长很短，客户端可以很快的选择和切换码率，以适应不同带宽条件下的播放。不过HLS的这种技术特点，决定了它的延迟一般总是会高于普通的流媒体直播协议。

互联网上RTMP协议的延迟基本上能够满足要求。

1. RTMP的特点如下：

1 Adobe支持得很好：

RTMP实际上是现在编码器输出的工业标准协议，基本上所有的编码器（摄像头之类）都支持RTMP输出。
原因在于PC市场巨大，PC主要是Windows，Windows的浏览器基本上都支持flash，
Flash又支持RTMP支持得非常好。

2 适合长时间播放：

   因为RTMP支持的很完善，所以能做到flash播放RTMP流长时间不断流，
   当时测试是100万秒，即10天多可以连续播放。
   对于商用流媒体应用，客户端的稳定性当然也是必须的，否则最终用户看不了还怎么玩？
   我就知道有个教育客户，最初使用播放器播放http流，需要播放不同的文件，结果就总出问题，
   如果换成服务器端将不同的文件转换成RTMP流，客户端就可以一直播放；
   该客户走RTMP方案后，经过CDN分发，没听说客户端出问题了。

3延迟较低：

   比起YY的那种UDP私有协议，RTMP算延迟大的（延迟在1-3秒），
   比起HTTP流的延时（一般在10秒以上）RTMP算低延时。
   一般的直播应用，只要不是电话类对话的那种要求，RTMP延迟是可以接受的。
   在一般的视频会议应用中，RTMP延时也能接受，原因是别人在说话的时候我们一般在听，实际上1秒延时没有关系，我们也要思考（话说有些人的CPU处理速度还没有这么快）。

4 有累积延迟：

   技术一定要知道弱点，RTMP有个弱点就是累积误差，原因是RTMP基于TCP不会丢包。

所以当网络状态差时，服务器会将包缓存起来，导致累积的延迟；待网络状况好了，就一起发给客户端。 这个的对策就是，当客户端的缓冲区很大，就断开重连。

1. RTMP延迟的测量
   如何测量延时，是个很难的问题，
   不过有个行之有效的方法，就是用手机的秒表，可以比较精确的对比延时。

总结

经过测量发现，在网络状况良好时：
  . RTMP延时可以做到0.8秒左右。
  . 多级边缘节点不会影响延迟（和SRS同源的某CDN的边缘服务器可以做到）
  . Nginx-Rtmp延迟有点大，估计是缓存的处理，多进程通信导致？
  . GOP是个硬指标，不过SRS可以关闭GOP的cache来避免这个影响.
  . 服务器性能太低，也会导致延迟变大，服务器来不及发送数据。
  . 客户端的缓冲区长度也影响延迟。
    譬如flash客户端的NetStream.bufferTime设置为10秒，那么延迟至少10秒以上。