协议

RTP/UDP:可以做到秒内延时，目前国内的CDN都不支持，但有些公司开发了私有协议实现了基于它们的直播，而且它们的延时都小于1秒，甚至小于500ms,像YY，映客直播采用的第三方技术等。

webRTC: 可以做到秒内延时，实际上它也是使用的RTP，单列出来是因为它是Google开源出来的，目前社区也开始活跃，做的人也多了；依据它出服务的公司国内有声网，中国电信研究院等。

HTTP-FLV: 内容延迟可以做到2~5秒，打开快。

RTMP: 内容延迟可以做2~5秒，当网络不好造成重传时，延时会大量增加。

HTML5 WebSocket: 方案还不成熟，延时可能也会在2~5秒。

HLS: 有5~7秒的内容延迟。

基础知识：I帧、B帧、P帧

I帧表示关键帧。可以理解为这一帧画面的完整保留；解码时只需要本帧数据就可以完成，因为包含完整画面。

P帧表示这一帧跟之前的一个关键帧（或P帧）的差别。解码时需要用之前缓存的画面叠加上本帧定义的差别，生成最终画面。也就是差别帧，P帧没有完整画面数据，只有与前一帧的画面差别的数据。

B帧是双向差别帧。B帧记录的是本帧与前后帧的差别（具体比较复杂，有4种情况）。换言之，要解码B帧，不仅要取得之前的缓存画面，还要解码之后的画面，通过前后画面的与本帧数据的叠加取得最终的画面。B帧压缩率高，但是编解码时会比较耗费CPU，而且在直播中可能会增加直播延时，因此在移动端上一般不使用B帧。

需要更低的延时，则表明服务器端和播放端的缓冲区都必须更短，来自网络的异常抖动容易引起卡顿。

业务可以接受较高的延时时，服务端和播放端都可以有较长的缓冲区，以应对来自网络的抖动，提供更流畅的直播体验。

这里通常有两种技术来平衡和优化这两个指标。

一是服务端提供灵活的配置策略，对于延时要求更敏感的，则在服务端在保证关键帧的情况下，对每个连接维持一个较小的缓冲队列；对于卡顿要求更高的直播，则适当增加缓冲队列的长度，保证播放的流畅。

二是服务端对所有连接的网络情况进行智能检测，当网络状况良好时，服务端会缩小该连接的缓冲队列的大小，降低延迟；而当网络状况较差时，特别是检测到抖动较为明显时，服务端对该连接增加缓冲队列长度，优先保证播放的流畅性。

网络部分的优化是两点