直播作为最新一代社交手段，引起了一大波潮流，笔者最近也简单研究了下，以下多为一些实践、信息收集得出，可能会有些错误。
直播基本架构：
采集、处理、编码、封包、推流、传输、转码、分发、推/拉流、解码、播放。
直播技术关键技术点分析：
- 低延迟通信：
- 传输层协议选择：TCP具有完善的连接管理、流量控制(rwnd)、拥塞控制(慢启动、cwnd)及预防(丢包识别算法、cwnd)等，使用tcp管理成本比较低；UDP本身可以认为是无协议的，在IP层之上增加了源端口、目标端口、分组长度和校验和，所以它不能保证消息交付、交付顺序、无长连接、无拥塞控制等，因此假设两点间的通信链路情况是最好的，udp完胜tcp。那么在真实链路中一定是有丢包等问题存在的，我们需要定一个前提：真实网络中平均的丢包率一定是不那么高的，或者比如低于80%、90%等等(过高的丢包率会使得流量控制、拥塞控制和预防等策略等机制过于复杂，实现成本太高就不便细讨论)，有了这个前提，我们认为根据自己的业务去选择使用udp，同时构建应用需求上的流量控制、拥塞控制、分组顺序、丢包重传、keep-alive等是可以的，不必达到tcp那么完美，只要满足应用需求且实现的准确，那么一般来说都会优于tcp协议的实现；
- 基础网络服务优化(物理层、数据链路层、网络层)：主要包括：多数据中心搭建(在国内要覆盖主要网络运营商的节点，因为各运营商间的互联效果不好)、边缘节点覆盖、自建节点路由调度优化策略、最后一公里问题，要做到的目标是临近终端就近处理与分发。举例Agora.io的基础网络服务部署使得全球平均端到端延迟为76ms，笔者了解到Twitch.tv就是因为基础网络服务做了很大的优化，最终被Amazon收入囊中；
- 带宽估计；带宽估计类似传输层中tcp协议通过ack、丢包等判断方法，但此处是在具体应用层中的实现：在自己协议中根据send和rcv方的具体数据和耗时作对比，计算出实时的链路稳定带宽，同样可参考tcp的滑动窗口实现；
- 丢包对抗：此概念非常重要，对于直播的最终效果我们必须要做，具体指在自身服务能满足的丢包率或2倍丢包率上做最终效果测试，来验证自己服务协议和质量的效果，必须能够抵抗住该丢包率才能够算是比较成功的服务协议(无雪花、无绿屏、无卡顿等)，因此丢包对抗也是对自有协议最基础、最严苛和最终的挑战之一。网损工具Linux Traffic Control；
- 大小流切换；该概念很明确，就是能够根据访问端情况，比如带宽估计结果、机型性能等作出切流的动作，但需要做平滑切换的优化，即切换时不能断流。据笔者了解的情况不同协议处理会有不同，但一般方式为在做切换动作时，后台请求要打开的目标流，等待流在显示端缓冲区ready，播放目标流然后关闭老流；
- 码率/帧率自适应：
- 使用自适应串流(ABS-adaptive bitrate streaming)技术，比如HAS-Dynamic Adaptive Streaming over HTTP国际标准组方案中的MPEG-DASH(和HLS思想基本一致)，通过把内容分割成小的基于HTTP的文件段序列，来进行流媒体播放。各个文件段可以设置成不同的比特率进行编码，以满足不同的客户端的网络需求。比如，DASH客户端可以根据当前的网络状况，自动选择对应的最匹配的比特率文件段下载，进行回放，而不会引起停顿或重新缓冲。这样，DASH客户端可以无缝地适应不断变化的网络条件，并提供高品质的播放，而能够尽量减少播放的停顿或缓冲。这种技术有个缺点直播时的延迟至少为一个分片文件时间，如果降低分片文件时间会导致编码时间大增，因为每个文件都是单独编码，否则就还是会有延迟，做到毫秒级使用很难；
- 不过笔者喜欢的方案是编码端会不断收到解码端的可用带宽反馈，当带宽在初始阈值外时重新初始化编码配置继续推流，关键是实现这个reload video configuration的过程要快；
- 机型适配：主要就是适配该机型能够处理的流的品质，此处务必要做精细的机型统计分类，对于业务的稳定也是至关重要，主流机型大概数量150款左右；
- 硬件编解码：编码考虑上行带宽及效率因素，同时如果发生频繁丢包需要增加编码时I帧的数量减少GOP长度，来保证画面及时恢复。解码笔者实际经验看一定要使用硬解码，软解码在pc上还行，在移动端电量、性能受影响很大；
以上关键点能得出一个结论：牛x的直播技术自建应用层流媒体协议是必须的，至于想要完美支持浏览器端应用，需要针对以上各关键点的实现和技术方案再做决定。
本文章为转载内容，我们尊重原作者对文章享有的著作权。如有内容错误或侵权问题，欢迎原作者联系我们进行内容更正或删除文章。
