网络直播对实时通信的技术要求有多高？
时间：
来源： 维泰亚直播
题主指的实时通信是视频本身还是针对直播中的即时通讯，就是聊天室，可以互动送礼物点赞这种通信？
直播中一方面是视频的直播，另外一方面用户可以和主播互动，发文字消息、点赞、送礼物。这个其实用到的是im即时通讯中的聊天室的功能。也是题主所说的对实时通信的要求。
一、聊天室架构应满足哪些条件
高可用：任何一个节点故障都不应该引起服务不可用；
易扩展：具有水平扩展的特性，对不同量级的在线用户数都有应变的能力；
高并发低延迟：能支持大量的用户同时收发消息，消息从发出到送达所有在线端的延时在毫秒级；
客户端兼容性：新型的应用都是能同时跨多种设备实现消息互通的，比如网页端，手机端和桌面端，甚至智能电视等。
二、设计架构
客户端层
处理各种设备的兼容问题，包括对ios，Android，Windows， Web等各种开发平台的语言适配；消息通道的管理维护，包括移动设备上的弱网络管理，断线重连等；保证数据安全，所有上行下行的数据包都需要加解密处理，规避数据泄露或中间人攻击等各种安全风险。
网关接入层
管理大量客户端连接，单个节点可以维护的客户端数量在数十万量级；处理不同类型客户端的协议兼容，由于客户端实现技术的多样性，导致客户端与网关之间底层的数据通信协议存在差异，需要由不同的接入网关做协议转换；处理数据安全逻辑；跨网络的高可用逻辑，网络级别的主备(谁知道哪天网线会被蓝翔的毕业生挖断呢?)；广播消息的高效下行分发，将收到的广播消息分发到所有连接在本节点上的客户端。
路由层
作为业务层接入的中转，同时承担负载均衡和高可用的作用，单个业务节点处理能力达到瓶颈时更方便的扩容，路由层使业务层扩容对前置网关层完全透明；当一个网络的业务集群出现网络故障时，可以切换到备用网络，保证服务可用性。
业务层
处理聊天室内的业务消息，一个集群内有众多节点，节点角色相互对等，任何一个节点的故障会使整个集群的处理能力下降，但不会引起服务的中断，因为其他节点可以继续接管业务数据包的处理；业务集群同样有多个网络环境的热备，以应对可能出现的区域性网络故障。
三、难点在哪里
客户端多样性
目前的应用都存在跨平台的需求，iOS、安卓和PC端，网页端，甚至IOT物联网设备，能连多少是多少，多多益善；但是不同开发平台之间的技术差异性极大，不是所有公司都有这么全的全栈程序猿的；如果团队开发的话单就客户端开发人员就不是几个人可以完成的。
数据安全的保证
当前的网络安全形势异常复杂，开发应用时如果不在通信安全上花心思，那你的用户就是在互联网上裸奔；开发者需要针对不同的平台，不同的通信技术实现可靠的安全方案，避免用户数据在传输过程中泄露，避免中间人攻击等安全风险。
跨机房网络级的高可用方案
当机房网络出现故障时把责任推给市政施工队或者“网络抽风”已经不流行了，用户需要的是故障无感知。
所有环节的单点故障排除
任何硬件和软件都存在故障的可能，我们无法避免应用罢工，那就需要随时准备替补上场。
能应对任何用户量级的需求
架构级做到水平扩展的能力，当用户量增长时随时可以通过堆服务器来解决，而不是将架构推倒重来。
四、这么难？怎么做
技术发展到现在已经不流行重复造轮子了，因为轮子的结构越来越复杂，功能性和非功能性的指标要求越来越高；而我们的用户却不会再等我们了。当我们还在画轮子的图纸的时候，竞争对手可能已经把车子都造好，在路上跑了。虽然我们不是非得自己造轮子，但是了解如何完成一个完美的轮子的制作过程和质量标准却是非常有必要的，这也是我前面和你介绍了这么多的原因。
就像近几年大数据技术非常流行，如果你对这个领域有所了解你就会发现几乎所有公司都在使用现有的平台，比如Hadoop；或者直接使用，或者在上面做二次改造，原因无非就是上面说的几点。现在你遇到的也是同样的问题，聊天室这种功能在最近两年又火了起来，主要还是视频直播业务的大规模扩张；所以能借用目前已有的平台或工具是最快捷的路径，应用需要关注的是怎么以最快的速度抓住用户。
五、利益相关
我们团队是做IM、直播技术的，底层架构都是做好的，开放给开发者sdk和api接口，开发者接入后就可以实现直播的功能。感兴趣可以加我的qq3103607948 细聊。
知乎专栏 这篇文章汇集了我对这个行业的理解，欢迎大家指点。
已经有答案把直播架构各个环节应该说的都已经介绍全了，本文就从一个技术瓶颈最大的问题来说——延时。
网络直播按需求场景，可以分为两种：高延迟直播，低延迟实时互动直播。高延迟直播：是单向传输，只有主播端数据下行到观众端。低延迟实时互动直播：是双向的，既有主播端到观众端的下行视频流，也有观众端到主播段的上行视频流。
高延迟直播：通过CDN进行内容分发，大多数直播平台的做法是，同时选择多家CDN服务商。这种方案的延迟一般是2秒到数十秒。这种方案，是目前的主流方案。从架构实现上来说，采用了CDN进行内容的缓存分发。不大可能像某友商说的达到毫秒级延迟。从需求上来说，由于主播和观众没有互动。因此，CDN方案没有动力将延迟从秒级降低到毫秒级
真正对实时通信技术提出挑战的是“低延迟全互动直播”。
什么是“低延迟全互动直播”？
在这种场景下，容许多个主播并存在同一场直播中，也容许主播和观众对话。因此，这种场景下，高延迟是不可忍受的。
电信级的标准是400ms。延时大于400ms，对话会有明显的不适感，是不适宜对话的。我司新推出的直播产品可以支持7人同时视频连线，100人语音连线。这与其它的P2P连麦方案是不同的。（有兴趣的看官可以自己去求证）
2s延迟到400ms延迟有多难？
光在真空中的速度约为300,000km/s，而在其他介质中光 速会大大降低，在普通光纤中，工程上一般认为传输速度是200,000km/s。从现实上来说：北京-上海，距离1200km，往返延时12ms北京-纽约，距离11000km，往返延时110ms赤道周长，距离40000km，往返延时400ms
这个速度，可以理解为一条专线拉到头的速度。因此，某些宣传说自己零延迟的，基本是违背物理规律了。
实际应用中，拿北京到上海举例，主播端的视频、音频数据，要经过主播的硬件设备前处理-编码：传输：中间要经过数个机房、小区宽带、用户的路由器，到达用户终端设备，经过用户设备硬件设备解码，后处理，最终呈现到播放出来。
每一个环节都会产生延时。
回答题主的问题，网络直播对实时通信的技术要求有多高？
1、编解码技术。在保证音质、画质的前提下，尽量做到低码率。码率越低，数据包越小，传输越快。
2、网络传输架构改造。我司没有采用基于TCP协议的CDN方案，从底层协议和布网上开始，创建了基于UDP协议的SD-RTN方案。全球端到端，延时平均76ms。
端到端是指，从编码器发出开始，进入解码器之前的延时。包含两地传输、server之间的传输、Lastmile的策略。不含捕捉、播放、编码、解码的延时。
由于一些童鞋对平均延时76ms这个数字提出了一些质疑，补充几个图。（下图的数据，取自我们某客户，量级足够进行数学统计，8月20日-9月1日的数据。
SD-RTN与CDN的区别是：
（1）基本原理不同。CDN是存储转发结构，设计目的是在各个边缘节点缓存待分发内容，结构上从源站到观众是伞状多级缓存放大方式。SD-RTN本质上一个实时传输网络，用户的数据在网络单元内部和传输线路上都以实时交换方式传送，从而能够保证最低延迟。（2）底层协议不同。SD-RTN采用了专为实时传输设计的UDP协议，避免了采用TCP的延时不可控缺点。能够大大缩短交互延时，延时可从CDN方案的数秒，降低到数百毫秒。（3）内容分发机制不同。SD-RTN是基于自定义路由，选择最优传输路径，直接将内容端到端传输，数据在网络单元中从不缓存，从而最大可能的降低延迟，同时内容安全性也更好。CDN是将内容缓存于缓存服务器中，再将内容就近下发。
（4）使用场景不同。SD-RTN适用于要求极低时延的实时互动场景，例如网络电话、视频会议、有主播与观众交互需求的互动直播等。CDN适用于对时延要求不高的场景，例如对延时要求不高、类似电视的单点直播、网站加速等。若硬要将CDN改造用于互动直播，那么其结构上对降低延迟的不适应性，始终会成为质量改进需求的瓶颈。
如果有更多疑问，可以到我们RTC大会现场，欢迎来辩。亚洲唯一一个实时互联网大会，RTC 2016 ，报名开启！ - 声网Agora的文章 - 知乎专栏
现在的通信技术都能满足一般的网络直播。直播最大的问题就是延时，交互要求高的延时要低，交互要求低的，延时就不大重要。见的最多的主播与观众互动，延迟在一般在4s—10s。
延迟主要是涉及到两个技术。编解码技术。在保证音质、画质的前提下，尽量做到低码率。码率越低，数据包越小，传输越快。又拍直播云支持在线实时转码，支持一转多（一次性将直播画面转码成适合各种设备播放的格式、分辨率的多条直播流），适配不同网络、分辨率的终端设备，并能够根据终端设备接入的网络质量实现多码率无缝切换。网络传输技术：现阶段流行的视频直播，其主要手段是通过 TCP/IP 协议来进行通信。从架构实现上来说，采用了CDN进行内容的缓存分发。
随着各种直播的火热，用户规模的增长给平台带来巨大挑战。网络直播本身依赖于实时通信技术，只不过直播与音视频通话的区别在于，直播需要单路视频流触达观众，音视频通话需要双路视频流互动。但对于通信技术的要求还是非常高的，尤其是如何保证观看体验，是网络直播需要解决的核心问题。主要有以下几个方面：
一、解决延时、高并发技术难题
在解决问题之前，我们首先需要了解下这些问题究竟是怎么产生的，以便对症下药。首先是音视频的延时问题，我们可以从一场电商直播中音视频流从主播端到用户端的传输过程来进行分析：
1、主播端延时
主播端的延迟很大程度来自视频流的前处理，例如开播时主播都会用到的美颜软件，美颜其实就是视频前处理的一种，在摄像头采集到人脸视频信息后，会先由美颜进行一个前处理工作，然后再将视频编码传送到服务器上，在这一过程中，无论是前处理还是编码都是需要耗费一定时间的。
2、传输过程延时
传输过程本身就因为网络状况等问题存在一定的延时，如果服务器与服务器之间的网络有丢包，或某台服务器负载过高，都会导致音视频的延时。
除此之外，编码压缩工作也还会耗费一定的时间，当然这部分时间根据不同厂商提供的平台能力、可用性都有些差别，这和系统架构设计、运维能力都息息相关。
3、用户端延时
用户端的延时一方面要考虑到用户的网络状况，另一方面也要考虑到用户的硬件系统能否支持，一些老旧的机型在进行解码处理时，由于 CPU 被大量占用，很容易发热发烫，导致手机卡顿。
直播的延时就是在这些过程中慢慢积攒的，美颜需要合成处理的时间、传输需要一定的时间，音视频压缩合成需要一定的时间，视频分发还需要一定的时间……在遇到网速和服务器出现问题时，延迟可能会进一步增加。
而网络直播系统开发中比较常见的“高并发”问题就比较好解释了。正常情况下，直播平台可以很稳定流畅地为用户提供服务。
但一旦遭遇 618、明星直播等特殊情况，流量以平时的百倍、千倍甚至万倍的规模进入，所谓的高并发问题就出现了，如果在平台的开发过程中，没有考虑到并发量的问题，那么就会造成服务器的崩溃，导致观看失败，影响直播用户的使用体验。
二、WebRTC 协议成为解决网络直播延时的新武器
问题并非仅此而已，事实上当前中国仍旧有 80% 的移动环境处于弱网状态，基本上所有的移动直播，内容传输上都会很困难。相关数据显示，有超过 7 成的视频从业者认为，延迟和卡顿阻碍了直播行业的整体发展。
所以最理想的直播状态当然是在保证高清晰度的同时做到音视频的低延时和高流畅，这就意味着，延时最大不超过 500ms，数值越小越好。而延时反应到包括网络直播在内的直播场景中时，主要看 2 个核心指标：首开时间和再缓冲时间。
首开时间即从打开到看到视频画面的时间，会受域名解析、连接、首包时间的影响，首播时间控制在 1 秒内算是不错的效果。其次是再缓冲时间，是用户观看视频时的卡顿时间。
既然延时对于直播如此重要，那么延时问题该如何解决呢？
其实，经过这些年的发展，我国的直播技术已经趋于成熟，通过多种专为流媒体开发的协议和技术手段来优化延时问题。经过多年的沉淀，目前国内主流的有 RTMP 和 WebRTC 两大阵营。
RTMP 对底层的优化非常优秀，适合长时间播放，同时它对 Adobe Flash 支持好，基本上所有的编码器（摄像头之类）都支持 RTMP 输出。
另外 RTMP 最大的特点是与 CDN 的强绑定，借助 CDN 的负载均衡系统将内容推送到接近用户的边缘节点，使用户就近取得所需内容，提高用户访问的响应速度和成功率，解决因分布、带宽、服务器性能带来的访问延迟问题，目前 RTMP 一般延时在 3s 左右，对于标准的直播场景来说是够用的。
当然，虽然 RTMP 具备集成方便、兼容性较好等优势，但在延时问题上依然不能满足日益攀升的需求，于是 WebRTC 因其低延时和无卡顿的特性而备受关注。
WebRTC 是一种基于浏览器的实时通信的开源解决方案，使用 UDP 私有协议来进行媒体推流，而不需要创建离散的媒体段；并且它是面向无连接的，没有 TCP 连接断开时的挥手确认连接关闭的机制。
基于这两点，WebRTC 能够做到毫秒级的低延迟，远远低于基于 RTMP 协议的 CDN 分发的延迟。而且，它直接通过浏览器就可以完成推流和播放。
因此，WebRTC 协议针对有高互动性要求的电商直播场景尤为适宜。以我们熟知的淘宝直播为例，其在 19 年推出的超低延时直播服务 RTS 方案就是基于 WebRTC 实现的，可以为用户带来端到端延时 1 秒内的低延时直播体验。
当然 WebRTC 要实时超低延时也是需要多种技术来辅助的，RTS 服务就针对全链路直播指标进行监控和针对性优化，以及通过智能调度系统以及网络拥塞、抗弱网优化、缓冲策略等进行一系列底层核心技术优化。
另外，国内知名的第三方通信云服务商融云提供的 RTC 解决方案也是基于 WebRTC 来实现的。在通信协议层面保障音视频传输的稳定性和流畅性。
同时在底层架构设计上，融云 RTC 智能路由可以在复杂的互联网环境下，实现客户端实时网络探测，选择最近的 Media Server（媒体服务）节点接入，大幅度提升连接速度。
对于弱网下如何解决延迟问题，其中最核心的策略就是迅速预估带宽变化，根据带宽自动适配码率，来确保音视频流畅优先。
准确来说就是在网络链路发生丢包以前就监测到网络拥塞情况，再通过 NACK（丢包重传）、FEC（前向纠错）和动态调整码实现自适应带宽控制，以及通过接收端 Jitter Buffer（媒体流平稳）实现自适应抖动缓冲控制，在提升速度的同时保障通话质量。
比如融云自研的丢包补偿策略可使接收端定期通知发送端自己未接收到的包，发送端在发送缓冲区找到对应的数据包，重新发送到接收端，确保音视频的传输质量。通过这些先进的技术架构和自研的多项技术策略，融云音视频全球范围内的端到端延时小于 400ms，最低延时 66ms，从而保障端到端之间延迟无感知的实时互动。
高并发引出的架构话题
高并发问题主要是考验音视频服务的设计架构，是否能够在激增的流量冲击下实现平稳运行。从直播角度上来讲，若在某个时间点，直播平台能够承载大量的线上观看人数而不影响播放品质，说明该平台在出现高并发情况时，优化的比较到位。
举个例子，某平台邀请流量鲜肉进行直播带货，由于用户涌入过猛（如观看人数上升，弹幕消息爆发等），很容易导致画面卡顿甚至导致服务器宕机。所以在融云首席架构师李淼眼中，一个优秀的架构应该具备以下特征：
第一、伸缩性
伸缩性就是保证在业务不中断的情况下，可以平滑地进行各种服务。优秀的架构应该具备良好的伸缩性，所谓的“伸”，是系统在运行中业务量上来了，这个时候需要添加服务器，在业务不中断的情况下，可以平滑地把整个集群扩大，承载相应的业务量。
所谓的“缩”，是指在服务器处于空闲状态，保证业务不中断的前提下，可以把资源再降下来，避免浪费。
第二、高可用
当服务出现问题时，可提供容灾、自动切换、自动恢复等机制，减少停工时间，保证服务不间断地持续对外提供支持。
第三、扩展性
很多人容易混淆扩展性和伸缩性这两个概念。所谓扩展性，就是灵活地对业务进行变更。比如，在保证业务不中断的情况下，可以平滑的上线新功能，对用户来讲如果感知最小，那它的扩展一定很灵活。
第四、高性能
是指在固定的资源下可以承载更多的业务，这个也是开发人员一直追求的。
此外，服务器耦合的问题也在音视频架构中长期存在。业界现有的实时音视频普遍基于分布式有级联的 RTC 架构——信令服务器与媒体服务器紧密耦合，这种设计模式下如果媒体服务与信令服务之间存在异常状态，就会导致整个音视频通话中断，用户间信息传输的稳定性、可靠性难以保障。
但在实际音视频服务中，分布式的去中心化 RTC 通信架构可使信令服务与媒体服务解耦，彼此无依赖，确保当用户数激增或者流量激增的时候，能够快速的去扩展这些节点，很好地解决了延时和稳定性问题，保证直播业务能够稳定的运行。
对于电商直播的高并发，还有很重要的一点是直播间聊天室的属性实时同步的问题，在线人数、累计人数、商品链接与列表等信息，需要不断访问和请求服务器，并将数值进行返还，而数值频繁变化，无论是轮询还是通知，都有高并发压力。
所有在聊天室里面的需要展现的内容，都可以通过聊天室属性管理服务来实现，无需频繁地访问服务器即可自动获取相关信息，可大大缓解直播平台的服务器压力。
网络直播不仅仅是音视频技术的应用
实际上，除了音视频技术来保障直播质量之外，网络直播对于即时通讯和推送同样有着极高的需求。
比如说，电商直播中的聊天室，让用户可以在弹幕上与主播和粉丝互动，这就是很纯粹的即时通讯技术应用，用户在直播间的提问、点赞、下单等行为背后都需要即时通讯技术，而用户收到直播通知、购买成功通知等 App 的推送消息，同样是需要即时通讯技术来实现。
因此在应用内构建一套完整的直播体系，需要实时音视频、即时通讯等多种能力。对于直播系统的开发人员，还有一个痛苦是：如果通信的能力是分散的，集成了不同的厂商，如果出现问题，就要找好几个服务商去协调，这是很常见的。
比如说直播平台有时候碰到一个通信层面的问题，因为IM和音视频在很多场景下它是有耦合的，例如呼叫的信令，一般会通过IM消息去下发，然后把音视频呼叫起来，媒体流再进行一些中转。
如果是IM和音视频分别由两个厂商来提供能力，出现了这些问题之后，平台就要找不同的厂商去判断。所以在服务体系上面，对于开发人员来说成本也很高，从业务集成和服务这两个角度，其实使用同一个厂商的一套SDK，这些东西对于平台来说成本都是最低的，集成的效率也最高。
网络直播的未来在何方？
一方面，新技术将继续变革直播的形态。随着 5G、超高清、VR、边缘计算等技术发展，低时延、大流量、高并发将成为常态，主播与观众的互动将更加实时、丰富和有趣。特别是 5G 时代的到来，无疑将会给电商直播带来全新的变革。
1.更清晰
此前，淘宝主播“大大大雪梨”在浙江完成了全国首场 5G 电商直播。据报道，通过超清 4K 画面，消费者不仅能看到直播间的整体情况，还可以对局部细节进行放大，让商品实时展示更为清晰、直观。
2.更快速
使用 5G 技术直播，相对 4G 而言，5G 用户上行平均速率可达 4G 的十倍至百倍以上，现场每一帧直播画面都能实时传递。
3.低延时
即使是目前最先进的技术，在最优的网络环境下，直播延时也会达到几十毫秒，而 5G 的毫秒级低延时让人们几乎感受不到网络延迟的存在。
4.更稳定
4G 时代的网络需要同时一起传输各种数据，这些数据会互相争夺挤占带宽资源，体验感会变差。而 5G 切片技术的出现可以直接将一个物理通道分成多个虚拟通道，直播信号可专用其中一个资源独享的虚拟通道，实现固定带宽和高可靠性，能够保障视频直播的正常进行。
另一方面，市场产生了新趋势：小程序正在成为直播带货的新战场。
当前，淘宝、抖音、快手等各大平台的直播带货如火如荼，头部和腰部主播的热度居高不下，坑位费普遍上涨，卖货的佣金比例也有所增加，按照二八法则，后入者的门槛相对变高。于是，不少商户和品牌主把小程序作为直播带货的第二战场。
艾媒咨询数据显示，2019 年微信小程序电商用户达 2.40 亿人。微信平台红利及小程序的诞生，为移动电商发展提供强大助力。背靠微信成熟的生态和巨大的流量池，兼具强社交和易传播的优势，借力小程序高效连接线上和线下，把零售电商的核心要素充分联结起来，实现私域流量池的建立和变现。
无需安装、触手可及、用完即走、裂变分享，小程序直播，无疑将成为电商的必争之地。
以实时音视频技术为例，网络直播需要这一类的技术可以解决画质和时延的难题。因为如果时延过高，或者画质太差，整个网络直播的用户体验会非常差。
声音和视频画面在网络中的传输不可避免产生丢包、抖动、延时。
比如多人连麦的网络直播，随着高并发大流量，双向互动要求提高，必须对接CDN和RTC两个网络，通过合流、旁路直播的方式来满足场景需要，多个环节，层层分发，时延会达到3s以上。
在实际环境中，考虑边缘节点的部署、主干网络拥塞、弱网环境、设备性能、系统性能等问题，所以实际的延时会更大。
结合华为沉淀近30年的音视频技术以及对通信网络的理解，华为云SparkRTC将提供全球超低时延交互能力，它通过覆盖全球170多个国家的3000+个节点资源，能实现更优更快的端侧请求调度，端到端时延能做到小于200ms。而且基于AI的预测和智能路由，相比传统公共互联网时延降低20%。
华为云SparkRTC的协同移动加速能力，通过端管边云协同，支持中国移动、联通、电信全国各地用户加速，卡顿能减少22%。而且基于SparkRTC私有的抗网损算法，以及端边网云协同技术的配合，即便视频丢包50%，音频丢包80%情况下，也能流畅观看。
如果需要搭建类似于秀场直播的环境，借助华为云SparkRTC的感知编码，可以准确识别主播轮廓，对主播和背景做差异化编码处理，自适应调整码率分配权重，节省码率的同时提升视觉体验。
如果想拥有更流畅、稳定、低时延的网络直播，可以加入华为云DevRun实时音视频行业加速器（点击了解），体验华为云SparkRTC的上述能力，开发人员只需要2行代码，一分钟即可跑通demo，极简接入产品。
华为云面向实时音视频行业，开放技术底座能力，从技术、资源、商机等多维度为伙伴提供全生命周期的扶持，与伙伴共建行业繁荣生态。
如果你想拥有高质量的网络直播，欢迎点击链接与华为云合作，用更好的实时通信技术，创造更佳的直播环境。
点击关注，第一时间了解华为云新鲜技术~
SD-RTN与CDN的区别是：
（1）基本原理不同。CDN是存储转发结构，设计目的是在各个边缘节点缓存待分发内容，结构上从源站到观众是伞状多级缓存放大方式。SD-RTN本质上一个实时传输网络，用户的数据在网络单元内部和传输线路上都以实时交换方式传送，从而能够保证最低延迟。（2）底层协议不同。SD-RTN采用了专为实时传输设计的UDP协议，避免了采用TCP的延时不可控缺点。能够大大缩短交互延时，延时可从CDN方案的数秒，降低到数百毫秒。（3）内容分发机制不同。SD-RTN是基于自定义路由，选择最优传输路径，直接将内容端到端传输，数据在网络单元中从不缓存，从而最大可能的降低延迟，同时内容安全性也更好。CDN是将内容缓存于缓存服务器中，再将内容就近下发。
（4）使用场景不同。SD-RTN适用于要求极低时延的实时互动场景，例如网络电话、视频会议、有主播与观众交互需求的互动直播等。CDN适用于对时延要求不高的场景，例如对延时要求不高、类似电视的单点直播、网站加速等。若硬要将CDN改造用于互动直播，那么其结构上对降低延迟的不适应性，始终会成为质量改进需求的瓶颈。
如果有更多疑问，可以到我们RTC大会现场，欢迎来辩。亚洲唯一一个实时互联网大会，RTC 2016 ，报名开启！ - 声网Agora的文章 - 知乎专栏
现在的通信技术都能满足一般的网络直播。直播最大的问题就是延时，交互要求高的延时要低，交互要求低的，延时就不大重要。见的最多的主播与观众互动，延迟在一般在4s—10s。
延迟主要是涉及到两个技术。编解码技术。在保证音质、画质的前提下，尽量做到低码率。码率越低，数据包越小，传输越快。又拍直播云支持在线实时转码，支持一转多（一次性将直播画面转码成适合各种设备播放的格式、分辨率的多条直播流），适配不同网络、分辨率的终端设备，并能够根据终端设备接入的网络质量实现多码率无缝切换。网络传输技术：现阶段流行的视频直播，其主要手段是通过 TCP/IP 协议来进行通信。从架构实现上来说，采用了CDN进行内容的缓存分发。
随着各种直播的火热，用户规模的增长给平台带来巨大挑战。网络直播本身依赖于实时通信技术，只不过直播与音视频通话的区别在于，直播需要单路视频流触达观众，音视频通话需要双路视频流互动。但对于通信技术的要求还是非常高的，尤其是如何保证观看体验，是网络直播需要解决的核心问题。主要有以下几个方面：
一、解决延时、高并发技术难题
在解决问题之前，我们首先需要了解下这些问题究竟是怎么产生的，以便对症下药。首先是音视频的延时问题，我们可以从一场电商直播中音视频流从主播端到用户端的传输过程来进行分析：
1、主播端延时
主播端的延迟很大程度来自视频流的前处理，例如开播时主播都会用到的美颜软件，美颜其实就是视频前处理的一种，在摄像头采集到人脸视频信息后，会先由美颜进行一个前处理工作，然后再将视频编码传送到服务器上，在这一过程中，无论是前处理还是编码都是需要耗费一定时间的。
2、传输过程延时
传输过程本身就因为网络状况等问题存在一定的延时，如果服务器与服务器之间的网络有丢包，或某台服务器负载过高，都会导致音视频的延时。
除此之外，编码压缩工作也还会耗费一定的时间，当然这部分时间根据不同厂商提供的平台能力、可用性都有些差别，这和系统架构设计、运维能力都息息相关。
3、用户端延时
用户端的延时一方面要考虑到用户的网络状况，另一方面也要考虑到用户的硬件系统能否支持，一些老旧的机型在进行解码处理时，由于 CPU 被大量占用，很容易发热发烫，导致手机卡顿。
直播的延时就是在这些过程中慢慢积攒的，美颜需要合成处理的时间、传输需要一定的时间，音视频压缩合成需要一定的时间，视频分发还需要一定的时间……在遇到网速和服务器出现问题时，延迟可能会进一步增加。
而网络直播系统开发中比较常见的“高并发”问题就比较好解释了。正常情况下，直播平台可以很稳定流畅地为用户提供服务。
但一旦遭遇 618、明星直播等特殊情况，流量以平时的百倍、千倍甚至万倍的规模进入，所谓的高并发问题就出现了，如果在平台的开发过程中，没有考虑到并发量的问题，那么就会造成服务器的崩溃，导致观看失败，影响直播用户的使用体验。
二、WebRTC 协议成为解决网络直播延时的新武器
问题并非仅此而已，事实上当前中国仍旧有 80% 的移动环境处于弱网状态，基本上所有的移动直播，内容传输上都会很困难。相关数据显示，有超过 7 成的视频从业者认为，延迟和卡顿阻碍了直播行业的整体发展。
所以最理想的直播状态当然是在保证高清晰度的同时做到音视频的低延时和高流畅，这就意味着，延时最大不超过 500ms，数值越小越好。而延时反应到包括网络直播在内的直播场景中时，主要看 2 个核心指标：首开时间和再缓冲时间。
首开时间即从打开到看到视频画面的时间，会受域名解析、连接、首包时间的影响，首播时间控制在 1 秒内算是不错的效果。其次是再缓冲时间，是用户观看视频时的卡顿时间。
既然延时对于直播如此重要，那么延时问题该如何解决呢？
其实，经过这些年的发展，我国的直播技术已经趋于成熟，通过多种专为流媒体开发的协议和技术手段来优化延时问题。经过多年的沉淀，目前国内主流的有 RTMP 和 WebRTC 两大阵营。
RTMP 对底层的优化非常优秀，适合长时间播放，同时它对 Adobe Flash 支持好，基本上所有的编码器（摄像头之类）都支持 RTMP 输出。
另外 RTMP 最大的特点是与 CDN 的强绑定，借助 CDN 的负载均衡系统将内容推送到接近用户的边缘节点，使用户就近取得所需内容，提高用户访问的响应速度和成功率，解决因分布、带宽、服务器性能带来的访问延迟问题，目前 RTMP 一般延时在 3s 左右，对于标准的直播场景来说是够用的。
当然，虽然 RTMP 具备集成方便、兼容性较好等优势，但在延时问题上依然不能满足日益攀升的需求，于是 WebRTC 因其低延时和无卡顿的特性而备受关注。
WebRTC 是一种基于浏览器的实时通信的开源解决方案，使用 UDP 私有协议来进行媒体推流，而不需要创建离散的媒体段；并且它是面向无连接的，没有 TCP 连接断开时的挥手确认连接关闭的机制。
基于这两点，WebRTC 能够做到毫秒级的低延迟，远远低于基于 RTMP 协议的 CDN 分发的延迟。而且，它直接通过浏览器就可以完成推流和播放。
因此，WebRTC 协议针对有高互动性要求的电商直播场景尤为适宜。以我们熟知的淘宝直播为例，其在 19 年推出的超低延时直播服务 RTS 方案就是基于 WebRTC 实现的，可以为用户带来端到端延时 1 秒内的低延时直播体验。
当然 WebRTC 要实时超低延时也是需要多种技术来辅助的，RTS 服务就针对全链路直播指标进行监控和针对性优化，以及通过智能调度系统以及网络拥塞、抗弱网优化、缓冲策略等进行一系列底层核心技术优化。
另外，国内知名的第三方通信云服务商融云提供的 RTC 解决方案也是基于 WebRTC 来实现的。在通信协议层面保障音视频传输的稳定性和流畅性。
同时在底层架构设计上，融云 RTC 智能路由可以在复杂的互联网环境下，实现客户端实时网络探测，选择最近的 Media Server（媒体服务）节点接入，大幅度提升连接速度。
对于弱网下如何解决延迟问题，其中最核心的策略就是迅速预估带宽变化，根据带宽自动适配码率，来确保音视频流畅优先。
准确来说就是在网络链路发生丢包以前就监测到网络拥塞情况，再通过 NACK（丢包重传）、FEC（前向纠错）和动态调整码实现自适应带宽控制，以及通过接收端 Jitter Buffer（媒体流平稳）实现自适应抖动缓冲控制，在提升速度的同时保障通话质量。
比如融云自研的丢包补偿策略可使接收端定期通知发送端自己未接收到的包，发送端在发送缓冲区找到对应的数据包，重新发送到接收端，确保音视频的传输质量。通过这些先进的技术架构和自研的多项技术策略，融云音视频全球范围内的端到端延时小于 400ms，最低延时 66ms，从而保障端到端之间延迟无感知的实时互动。
高并发引出的架构话题
高并发问题主要是考验音视频服务的设计架构，是否能够在激增的流量冲击下实现平稳运行。从直播角度上来讲，若在某个时间点，直播平台能够承载大量的线上观看人数而不影响播放品质，说明该平台在出现高并发情况时，优化的比较到位。
举个例子，某平台邀请流量鲜肉进行直播带货，由于用户涌入过猛（如观看人数上升，弹幕消息爆发等），很容易导致画面卡顿甚至导致服务器宕机。所以在融云首席架构师李淼眼中，一个优秀的架构应该具备以下特征：
第一、伸缩性
伸缩性就是保证在业务不中断的情况下，可以平滑地进行各种服务。优秀的架构应该具备良好的伸缩性，所谓的“伸”，是系统在运行中业务量上来了，这个时候需要添加服务器，在业务不中断的情况下，可以平滑地把整个集群扩大，承载相应的业务量。
所谓的“缩”，是指在服务器处于空闲状态，保证业务不中断的前提下，可以把资源再降下来，避免浪费。
第二、高可用
当服务出现问题时，可提供容灾、自动切换、自动恢复等机制，减少停工时间，保证服务不间断地持续对外提供支持。
第三、扩展性
很多人容易混淆扩展性和伸缩性这两个概念。所谓扩展性，就是灵活地对业务进行变更。比如，在保证业务不中断的情况下，可以平滑的上线新功能，对用户来讲如果感知最小，那它的扩展一定很灵活。
第四、高性能
是指在固定的资源下可以承载更多的业务，这个也是开发人员一直追求的。
此外，服务器耦合的问题也在音视频架构中长期存在。业界现有的实时音视频普遍基于分布式有级联的 RTC 架构——信令服务器与媒体服务器紧密耦合，这种设计模式下如果媒体服务与信令服务之间存在异常状态，就会导致整个音视频通话中断，用户间信息传输的稳定性、可靠性难以保障。
但在实际音视频服务中，分布式的去中心化 RTC 通信架构可使信令服务与媒体服务解耦，彼此无依赖，确保当用户数激增或者流量激增的时候，能够快速的去扩展这些节点，很好地解决了延时和稳定性问题，保证直播业务能够稳定的运行。
对于电商直播的高并发，还有很重要的一点是直播间聊天室的属性实时同步的问题，在线人数、累计人数、商品链接与列表等信息，需要不断访问和请求服务器，并将数值进行返还，而数值频繁变化，无论是轮询还是通知，都有高并发压力。
所有在聊天室里面的需要展现的内容，都可以通过聊天室属性管理服务来实现，无需频繁地访问服务器即可自动获取相关信息，可大大缓解直播平台的服务器压力。
网络直播不仅仅是音视频技术的应用
实际上，除了音视频技术来保障直播质量之外，网络直播对于即时通讯和推送同样有着极高的需求。
比如说，电商直播中的聊天室，让用户可以在弹幕上与主播和粉丝互动，这就是很纯粹的即时通讯技术应用，用户在直播间的提问、点赞、下单等行为背后都需要即时通讯技术，而用户收到直播通知、购买成功通知等 App 的推送消息，同样是需要即时通讯技术来实现。
因此在应用内构建一套完整的直播体系，需要实时音视频、即时通讯等多种能力。对于直播系统的开发人员，还有一个痛苦是：如果通信的能力是分散的，集成了不同的厂商，如果出现问题，就要找好几个服务商去协调，这是很常见的。
比如说直播平台有时候碰到一个通信层面的问题，因为IM和音视频在很多场景下它是有耦合的，例如呼叫的信令，一般会通过IM消息去下发，然后把音视频呼叫起来，媒体流再进行一些中转。
如果是IM和音视频分别由两个厂商来提供能力，出现了这些问题之后，平台就要找不同的厂商去判断。所以在服务体系上面，对于开发人员来说成本也很高，从业务集成和服务这两个角度，其实使用同一个厂商的一套SDK，这些东西对于平台来说成本都是最低的，集成的效率也最高。
网络直播的未来在何方？
一方面，新技术将继续变革直播的形态。随着 5G、超高清、VR、边缘计算等技术发展，低时延、大流量、高并发将成为常态，主播与观众的互动将更加实时、丰富和有趣。特别是 5G 时代的到来，无疑将会给电商直播带来全新的变革。
1.更清晰
此前，淘宝主播“大大大雪梨”在浙江完成了全国首场 5G 电商直播。据报道，通过超清 4K 画面，消费者不仅能看到直播间的整体情况，还可以对局部细节进行放大，让商品实时展示更为清晰、直观。
2.更快速
使用 5G 技术直播，相对 4G 而言，5G 用户上行平均速率可达 4G 的十倍至百倍以上，现场每一帧直播画面都能实时传递。
3.低延时
即使是目前最先进的技术，在最优的网络环境下，直播延时也会达到几十毫秒，而 5G 的毫秒级低延时让人们几乎感受不到网络延迟的存在。
4.更稳定
4G 时代的网络需要同时一起传输各种数据，这些数据会互相争夺挤占带宽资源，体验感会变差。而 5G 切片技术的出现可以直接将一个物理通道分成多个虚拟通道，直播信号可专用其中一个资源独享的虚拟通道，实现固定带宽和高可靠性，能够保障视频直播的正常进行。
另一方面，市场产生了新趋势：小程序正在成为直播带货的新战场。
当前，淘宝、抖音、快手等各大平台的直播带货如火如荼，头部和腰部主播的热度居高不下，坑位费普遍上涨，卖货的佣金比例也有所增加，按照二八法则，后入者的门槛相对变高。于是，不少商户和品牌主把小程序作为直播带货的第二战场。
艾媒咨询数据显示，2019 年微信小程序电商用户达 2.40 亿人。微信平台红利及小程序的诞生，为移动电商发展提供强大助力。背靠微信成熟的生态和巨大的流量池，兼具强社交和易传播的优势，借力小程序高效连接线上和线下，把零售电商的核心要素充分联结起来，实现私域流量池的建立和变现。
无需安装、触手可及、用完即走、裂变分享，小程序直播，无疑将成为电商的必争之地。
以实时音视频技术为例，网络直播需要这一类的技术可以解决画质和时延的难题。因为如果时延过高，或者画质太差，整个网络直播的用户体验会非常差。
声音和视频画面在网络中的传输不可避免产生丢包、抖动、延时。
比如多人连麦的网络直播，随着高并发大流量，双向互动要求提高，必须对接CDN和RTC两个网络，通过合流、旁路直播的方式来满足场景需要，多个环节，层层分发，时延会达到3s以上。
在实际环境中，考虑边缘节点的部署、主干网络拥塞、弱网环境、设备性能、系统性能等问题，所以实际的延时会更大。
结合华为沉淀近30年的音视频技术以及对通信网络的理解，华为云SparkRTC将提供全球超低时延交互能力，它通过覆盖全球170多个国家的3000+个节点资源，能实现更优更快的端侧请求调度，端到端时延能做到小于200ms。而且基于AI的预测和智能路由，相比传统公共互联网时延降低20%。
华为云SparkRTC的协同移动加速能力，通过端管边云协同，支持中国移动、联通、电信全国各地用户加速，卡顿能减少22%。而且基于SparkRTC私有的抗网损算法，以及端边网云协同技术的配合，即便视频丢包50%，音频丢包80%情况下，也能流畅观看。
如果需要搭建类似于秀场直播的环境，借助华为云SparkRTC的感知编码，可以准确识别主播轮廓，对主播和背景做差异化编码处理，自适应调整码率分配权重，节省码率的同时提升视觉体验。
如果想拥有更流畅、稳定、低时延的网络直播，可以加入华为云DevRun实时音视频行业加速器（点击了解），体验华为云SparkRTC的上述能力，开发人员只需要2行代码，一分钟即可跑通demo，极简接入产品。
华为云面向实时音视频行业，开放技术底座能力，从技术、资源、商机等多维度为伙伴提供全生命周期的扶持，与伙伴共建行业繁荣生态。
如果你想拥有高质量的网络直播，欢迎点击链接与华为云合作，用更好的实时通信技术，创造更佳的直播环境。
点击关注，第一时间了解华为云新鲜技术~
【文章来源】:维泰亚直播综合资讯，本文唯一链接：http://xiangnaweitea.com/news/zonghe/1014.html
【文章关键词】: