当前位置：网站首页>云信小课堂 | IM及音视频中常见的认知误区

云信小课堂 | IM及音视频中常见的认知误区

2022-07-01 22:51:00 【网易云信】

Vol. 13

大家好，欢迎来到本期云信小课堂。和往期不同的是，本期云信小课堂没有在云信的某个功能实现或方案落地上做详细具体的指引及演示。而是在通过对 IM 及音视频中某些广为人知但却模糊不清的概念或指标进行剖析，从而帮助大家进一步了解云信产品的底层逻辑，本期将从 3 个常见问题展开。

能否实现100%的消息到达率？

在与客户沟通的过程中，时常会遇到客户咨询：云信的消息到达率是多少？事实上，这个问题很难回答，几乎每家提供 IM 服务的厂商都会对自己的消息到达率提供一定宣传性的承诺。例如：消息必达、稳定可靠、不丢消息等。

我们首先要对消息到达率这个指标做一定的拆解，IM 本身是一个具备一定复杂度的场景。

根据接收者的在线状态区分：

在线消息的到达率
离线消息的到达率

根据消息场景区分：

点对点/群聊消息到达率
聊天室消息到达率

另外，消息本身还存在漫游、多端同步、用户关系、用户状态等拓展场景，均会影响消息到达率的指标。我们在这里不做进一步扩展。

在线消息到达率

在线消息（点对点或群聊场景）到达率是一般人对到达率的基本认知。即当接收方在线时，发送方发送的消息到达接收方的概率/比例。一般消息的传输机制是这样的：

发送方与接收方与后端的连接服务建立长连接，并基于此长连接进行消息数据的传输。业务服务器对从连接服务器接收到的消息进行业务处理并异步进行消息存储及转发。

基于这个流程，我们明确可能影响到达率的客观因素：

发送方的连接状态或消息传输情况
接收方的连接状态及消息传输情况
后台服务的稳定性及其他程序异常的干扰因素

而云信是如何解决上述的影响因素的？

消息回执：消息回执是消息投递的重要保障机制，发送端明确接收到后台服务的回执即代表发送成功，后台服务明确收到接收端的消息回执即代表消息接收成功。未知状态下进行一定规则逻辑的重试行为。
服务高可用：大型的公有云服务对高可用的实现是复杂且多方面的，从入口切换、域名分配、多机房切换等各个层面对后台业务的稳定性进行保障。远超 SLA 中对业务可用性的定义。
回过头来说，100%到达率的说法，并不十分严谨，”消息必达“是我们向客户承诺：实现业务逻辑全面性和服务保障稳定性的信心。

离线消息到达率

接收方离线时，实际上是没有消息到达率的说法的，这个时候，消息到达率往往会转化为推送到达率。IM 业务在判断接收方离线时通常会以推送的方式（移动端设备）实现下次下发，从而保障使用者的体验。通常推送的传输机制如下

业务服务在识别接收方离线时，会向第三方推送服务发起推送请求，第三方推送服务通过与设备本身的长连接进行推送数据下发。这里影响推送到达率的因素有：

请求推送服务的成功率
推送服务下发的到达率

以上两个因素均受诸多客观因素影响，其中请求推送服务本身是个 HTTP 服务，一般会以重试的手段保障达到。而目前，推送服务本身设立了一定的推送条件，以小米推送服务为例，其官方接口的错误码中，定义了诸如：系统繁忙、远程服务错误、等服务可达性错误。以及不合法的主题、广播消息发送太频繁等业务性错误（详见小米推送服务错误码 https://dev.mi.com/console/doc/detail?pId=1557）。

因此推送本身不具备必达属性。

聊天室消息到达率

聊天室业务从设计之初便为了迎合超大容量的消息通信房间场景，其用户汇聚及定向广播的服务模式很好的解决了用户并发及投递效率问题。实际的业务场景出发，聊天室消息本身需要进行相对合理的下发管控。10 万人的聊天室，如果 100 人同时发消息，那么对消息接收者的体验是非常差的。所以服务本身会对聊天室的消息下发进行控制，详见云信聊天室消息流控策略（http://163.lu/GJTZU0）。在此基础上，开放消息优先级定义来确保重要聊天室消息可达。

总结

无论是何种场景，100% 消息到达率都是一种并非十分严谨的说法，我们怀着开放的心态，希望客户能够真正理解 IM 下发的核心逻辑而做出合理的判断。

我们更加关注服务商的机制是否完善、经验是否充足、案例是否具备代表性以及最重要的服务是否能够令人满意。网易云信，以超 1000 亿消息发送的技术积累及严谨客观的技术心态，希望我们的开发者们满意！

视频通话是不是分辨率越高越好？

这个问题的答案一定为“是”，通常来说，分辨率越高，代表画质越清晰、细腻，观感更好。无论是什么场景，没有人会嫌分辨率太高。不过在实际应用过程中，我们要考虑的因素会更多。视频通话的效果，并非由分辨率的单一因素决定，其中还包括帧率、延时、编码质量等。

通话网络

我们常说的网络，实际上代表多个指标：带宽、延迟、丢包率、抖动等。我们平常使用的网络，并没有我们想象中的优质，例如：采购了电信 1000M 的宽带，受限于路由器可能最大只能有 500M 的下行速度，而上行往往只有 50M。我相信，大部分人的家庭宽带并不会采购 1000M。并且我们在做视频通话时，可能家人正在用视频软件看剧，孩子在上网课，父母在刷短视频，路由器和我之前隔了几堵墙。那么实际可以分配使用的带宽会更少。

带宽就像一根水管，每条水管可以流多少水是固定的，当水流速度固定而水流量过大时就会产生拥堵。视频通话中，同样复杂度的视频场景下，不同的分辨率、帧率需要不同的传输码率，当网络带宽不足以承载所需码率时，就无法达到既定的通话效果。或是分辨率下降（出水细一点）、或是帧率下降（出水慢一点）、或是延迟升高。这种情况下，我们必须有所抉择，便是我们常说的视频质量控制。

设备性能

同时我们实际使用中，会存在各种不同设备，有些设备存在设备性能问题或者稳定性问题。例如：一些设备硬件编码不稳定，存在出帧延时大或者码率不稳定的情况；还有一些设备编码性能跟不上，达不到设置的帧率。针对这些问题，如果不进行调节，会发生卡顿、延时拉大等问题。这就需要我们对设备软硬件编码器的输出做监控，发现性能问题或者稳定性问题，进行相应的调节。如降低帧率或者分辨率来解决性能跟不上延时逐步拉大的问题；通过编码器设置参数的切换尝试解决硬件编码不稳定的问题等。这就是视频质量控制的设备适配。

不同场景对于视频的关注点是不同的，直播更关注清晰度、会议更关注流畅度、聊天更关注时延。那么这里就需要有不同的设置来支持对应场景的偏好。例如，云信为开发者提供的了各场景的参数配置建议，就是为了解决这类问题。音视频参数配置推荐（http://163.lu/nHcau2）

节点越多，能力越强？

关于节点是很多人都关注的话题，特别是如今越来越多的公司选择出海，国内的厂商在海外的基础设施建设是衡量企业实力的重要指标。但我们要知道，节点的数量并不能代表其通话的质量。抛开音视频引擎对弱网场景的优化来说，用户到接入节点的链路情况，才直接决定了传输质量的好坏。全球知名的视频会议服务提供商，在全球只部署了 17 个节点，却带来了广受好评的效果。举个例子，从东京经过香港再转线回杭州的网络延迟，可能比东京直接到新加坡要低。这就非常考验厂商在路由选择上的能力。