直播过程：采集 → 处理 → 编码 → 推流 → CDN分发 → 拉流 → 解码 → 播放
"stream_push": "rtmp://push-stream3-live-ssl.a.88cdn.com/live/1570_253746839?auth_key=1576833218-253746839-0-35787c8a0c044a6d35e20853ac25a4eb",
"stream_pull": "http://pull-stream3-live-ssl.a.88cdn.com/live/1570_253746839.flv?auth_key=1576836305-253746839-0-5e890d2e433c74c5da37b793c33f7907"
"stream_flv_pull_https": "https://pull-stream3-live-ssl.a.88cdn.com/live/1570_253746839.flv?auth_key=1576836305-253746839-0-5e890d2e433c74c5da37b793c33f7907"
"stream_hls_pull_https": "https://pullhls-stream3-live-ssl.a.88cdn.com/live/1570_253746839.m3u8?auth_key=1576836305-253746839-0-78b1ee171eaa9c2ba25ea15bdf36917b",
CDN（CDN即Content Delivery Network （内容分发网络））
通过用户使用的DNS服务器来判断客户端所在的网络位置，从而返回对应的服务IP。
BGP中转架构-最短传输路径（BGP即Border Gateway Protocol （边界网关协议））
BGP的技术原理往简单的说就是允许同一IP在不同网络中广播不同的路由信息，效果就是同一个IP，当电信用户来访问时走电信网内的路由，联通用户来访问时走的联通的路由（即IP唯一性）。
BGP相当于给跨网的用户就近搭建了一坐桥梁，不必绕远路，延时和稳定性都大大提高了
经过BGP的优化之后，我们还需要对网络的机房选路有一个优化。在国内一般而言相同的接入运营商（电信、联通、移动）并且地理位置最近的情况网络延迟最优，小于15ms。跨省同运营商的网络延迟25~50ms，跨运营商情况更复杂一些，在50~100ms。总结起来，直播当中每个包的延时可以缩短100ms，由于网络的叠加效果，反射到上层是秒级的延迟缩减。
直播协议
直播技术涉及很多的协议，如RTMP、HLS、HDL（HTTP-FLV）、RTP，我们使用的推流协议是rtmp协议，拉流协议是HDL（HTTP-FLV）。
RTMP协议
1、开源软件和开源库的支持稳定完整。开源的librtmp库，服务端有nginx-rtmp插件。
2、播放端安装率高。只要浏览器支持FlashPlayer就能非常简易的播放RTMP的直播，RTMP协议初次建立连接的时候握手过程过于复杂（底层基于TCP，这里说的是RTMP协议本身的交互），视不同的网络状况会带来给首开带来100ms以上的延迟。基于RTMP的直播一般内容延迟在2~5秒。
HTTP-FLV协议
即使用HTTP协议流式的传输媒体内容。内容延迟同样可以做到2~5秒，打开速度更快，因为HTTP本身没有复杂的状态交互。所以从延迟角度来看，HTTP-FLV要优于RTMP。
HLS 协议
HLS即Http Live Streaming，是由苹果提出基于HTTP的流媒体传输协议。HLS有一个非常大的优点：HTML5可以直接打开播放；这个意味着可以把一个直播链接通过微信等转发分享，不需要安装任何独立的APP，有浏览器即可，所以流行度很高。社交直播APP，HLS可以说是刚需，下来我们分析下其原理 。 基于HLS的直播流URL是一个m3u8的文件，里面包含了最近若干个小视频TS（一种视频封装格式，这里就不扩展介绍）文件，如 http://www.ucloud.cn/helloworld.m3u8 是一个直播留链接，其内容如下：
假设列表里面的包含5个TS文件，每个TS文件包含5秒的视频内容，那么整体的延迟就是25秒。当然可以缩短列表的长度和单个TS文件的大小来降低延迟，极致来说可以缩减列表长度为1，1秒内容的m3u8文件，但是极易受网络波动影响造成卡顿。那么我们怎么解决这个问题呢？后面将专门为大家讲解优化方案。
RTP协议
RTP即Real-time Transport Protocol，用于Internet上针对多媒体数据流的一种传输层协议。实际应用场景下经常需要RTCP（RTP Control Protocol）配合来使用，可以简单理解为RTCP传输交互控制的信令，RTP传输实际的媒体数据。 RTP在视频监控、视频会议、IP电话上有广泛的应用，因为视频会议、IP电话的一个重要的使用体验：内容实时性强。
对比与上述3种或实际是2种协议，RTP和它们有一个重要的区别就是默认是使用UDP协议来传输数据，而RTMP和HTTP是基于TCP协议传输。为什么UDP 能做到如此实时的效果呢？关于TCP和UDP差别的分析文章一搜一大把，这里不在赘述，简单概括： UDP：单个数据报，不用建立连接，简单，不可靠，会丢包，会乱序； TCP：流式，需要建立连接，复杂，可靠 ，有序。 实时音视频流的场景不需要可靠保障，因此也不需要有重传的机制，实时的看到图像声音，网络抖动时丢了一些内容，画面模糊和花屏，完全不重要。TCP为了重传会造成延迟与不同步，如某一截内容因为重传，导致1秒以后才到，那么整个对话就延迟了1秒，随着网络抖动，延迟还会增加成2秒、3秒，如果客户端播放是不加以处理将严重影响直播的体验。
总结一下：在直播协议的选择中，如果选择是RTMP或HTTP-FLV则意味着有2~5秒的内容延迟，但是就打开延迟开，HTTP-FLV 要优于RTMP。HLS则有5~7秒的内容延迟。选择RTP进行直播则可以做到1秒内的直播延迟。但就目前所了解，各大CDN厂商没有支持基于RTP直播的，所以目前国内主流还是RTMP或HTTP-FLV。
流媒体内容缓存与传输策略优化
基础知识：I帧、B帧、P帧
I帧表示关键帧。你可以理解为这一帧画面的完整保留；解码时只需要本帧数据就可以完成。
P帧表示这一帧跟之前的一个关键帧（或P帧）的差别。解码时需要用之前缓存的画面叠加上本帧定义的差别，生成最终画面。
B帧是双向差别帧。B帧记录的是本帧与前后帧的差别（具体比较复杂，有4种情况）。换言之，要解码B帧，不仅要取得之前的缓存画面，还要解码之后的画面，通过前后画面的与本帧数据的叠加取得最终的画面。
注：B帧压缩率高，但是编解码时会比较耗费CPU，而且在直播中可能会增加直播延时，因此在移动端上一般不使用B帧。
关键帧缓存策略
如：一个典型的视频帧序列为IBBPBBPBBP…… 对于直播而言，为了减少直播的延时，通常在编码时不使用B帧。P帧B帧对于I帧都有直接或者间接的依赖关系，所以播放器要解码一个视频帧序列，并进行播放，必须首先解码出I帧，其后续的B帧和P帧才能进行解码，这样服务端如何进行关键帧的缓存，则对直播的延时以及其他方面有非常大的影响。 比较好的策略是服务端自动判断关键帧的间隔，按业务需求缓存帧序列，保证在缓存中存储至少两个或者以上的关键帧，以应对低延时、防卡顿、智能丢包等需求。
客户端解析优化
移动端代码一般不会hardcode 推流、播放的服务器IP地址，集成星域CDN的SDK，获取远端域名，走SDK替换成新的HTTP地址，省带宽和拉流速度更快。
软硬编解选择
推流编码： 使用硬编；
播放解码：使用软解码方案。
软编码硬编码优缺点对比：
了解更多：
https://cloud.tencent.com/developer/article/1037761?from=10680