本文由夏冰软件cc分享，下文进行了排版和内容优化。

1、引言

本文接上篇《什么是IM系统的消息时序一致性？》，本篇将通俗易懂地讲解IM系统中的端到端加密原理，为了降低阅读门槛，相关的技术概念会提及但不深入展开。

IM即时通讯系统的技术本质是“即时消息技术”，是互联网实时互动场景的底层架构，包括聊天、直播、在线客服等业务领域在内，所有需要实时互动、高实时性的场景，都需要用到IM技术。而为了让即时通讯更安全，高安全场景下的IM系统通常会使用端到端加密技术进行通讯加密。下面我们就来了解一下端到端加密技术在IM系统中的应用。

技术交流：

- 移动端IM开发入门文章：《新手入门一篇就够：从零开发移动端IM》

- 开源IM框架源码：https://github.com/JackJiang2011/MobileIMSDK（备用地址点此）

（本文已同步发布于：http://www.52im.net/thread-4792-1-1.html）

2、系列文章

1. 《零基础IM开发入门(一)：什么是IM系统？》
2. 《零基础IM开发入门(二)：什么是IM系统的实时性？》
3. 《零基础IM开发入门(三)：什么是IM系统的可靠性？》
4. 《零基础IM开发入门(四)：什么是IM系统的消息时序一致性？》
5. 《零基础IM开发入门(五)：什么是IM系统的端到端加密？（* 本文）》
6. 《零基础IM开发入门(六)：什么是IM系统的的心跳机制？ (稍后发布)》
7. 《零基础IM开发入门(七)：如何理解并实现IM系统消息未读数？ (稍后发布)》
8. 《零基础IM开发入门(八)：如何理解并实现IM系统的多端消息漫游？ (稍后发布)》

3、网络通讯数据加密的3个层次

3.1 概述

一般的数据加密可以在通信的3个层次来实现：链路加密、节点加密和端到端加密。

3.2 链路加密

对于在两个网络节点间的某一次通信链路，链路加密能为网上传输的数据提供安全保证。对于链路加密(又称在线加密)，所有消息在被传输之前进行加密，在每一个节点对接收到的消息进行解密，然后先使用下一个链路的密钥对消息进行加密，再进行传输。

在到达目的地之前，一条消息可能要经过许多通信链路的传输。由于在每一个中间传输节点消息均被解密后重新进行加密，因此，包括路由信息在内的链路上的所有数据均以密文形式出现，这样，链路加密就掩盖了被传输消息的源点与终点。由于填充技术的使用以及填充字符在不需要传输数据的情况下就可以进行加密，这使得消息的频率和长度特性得以掩盖，从而可以防止对通信业务进行分析。

相关文章推荐阅读：《IM聊天系统安全手段之通信连接层加密技术》。

3.3 节点加密

尽管节点加密能给网络数据提供较高的安全性，但它在操作方式上与链路加密是类似的：两者均在通信链路上为传输的消息提供安全性，都在中间节点先对消息进行解密，然后进行加密。因为要对所有传输的数据进行加密，所以加密过程对用户是透明的。然而，与链路加密不同，节点加密不允许消息在网络节点以明文形式存在，它先把收到的消息进行解密，然后采用另一个不同的密钥进行加密，这一过程是在节点上的一个安全模块中进行。

节点加密要求报头和路由信息以明文形式传输，以便中间节点能得到如何处理消息的信息，因此这种方法对于防止攻击者分析通信业务是脆弱的。

3.4 端到端加密

端到端加密允许数据在从源点到终点的传输过程中始终以密文形式存在。采用端到端加密(又称脱线加密或包加密)，消息在被传输时到达终点之前不进行解密，因为消息在整个传輸过程中均受到保护，所以即使有节点被损坏也不会使消息泄露。

端到端加密系统的价格便宜些，并且与链路加密和节点加密相比更可靠，更容易设计、实现和维护。端到端加密还避免了其它加密系统所固有的同步问题，因为每个报文包均是独立被加密的，所以一个报文包所发生的传输错误不会影响后续的报文包。端到端加密系统通常不允许对消息的目的地址进行加密，这是囚为每一个消息所经过的节点都要用此地址来确定如何传输消息。由于这种加密方法不能掩盖被传输消息的源点与终点，因此它对于防止攻击者分析通信业务是脆弱的。

没有使用端到端加密时的通信原理图（各个环节都存在泄密的可能）：

使用端到端加密后的通信原理图（除了发送者和接收者，其它环境都是密文状态）：

4、IM系统中的端到端加密原理

在IM系统中，当用户A发送消息给用户B时，IM系统会生成一对公钥和私钥，并将公钥发送给用户B。用户A使用用户B的公钥对消息进行加密，然后将加密后的消息发送给用户B。

在用户B接收到消息后，使用自己的私钥对消息进行解密，从而获取明文内容。由于私钥只有用户B拥有，因此除了用户B之外，任何人都无法解密消息。

没有使用端到端加密时的聊天消息存在诸多风险：

使用了端到端加密后的聊天就安全多了：

5、IM系统使用端到端加密的好处

数据安全性：在IM系统中，端到端加密可以确保消息在传输过程中始终保持加密状态，防止黑客和第三方窃取用户的通信内容。

隐私保护：由于消息内容只有通信双方能够解密和阅读，即使是IM系统应用自身也无法获取明文内容。这意味着用户的隐私得到了最大程度的保护。

抗窃听：IM系统使用端到端加密技术，使得窃听者无法获取通信内容，从而有效防止了窃听行为的发生。

6、IM系统使用端到端加密的意义

由于在数据传输到服务器之后，任何有权访问此服务器的人，包括员工、供应商及其他有关人员（甚至是黑客），都有可能读取到用户的数据。

所以，使用端到端加密技术主要有以下意义：

1）保护个人隐私：在信息时代，个人隐私面临着越来越大的威胁。在IM系统中使用端到端加密可以有效保护了用户的通信内容，确保个人隐私不被侵犯。

2）防止数据泄露：许多用户在社交软件中分享了大量的个人信息和敏感数据。而IM系统中的端到端加密就可以确保这些数据在传输过程中不会被窃取，从而避免了数据泄露的风险。

3）抵御网络攻击：黑客和网络犯罪分子经常利用网络漏洞和弱点来攻击用户的通信。IM系统中的端到端加密可以有效防止这些攻击，保护用户的通信安全。

4）维护社交关系：人们越来越依赖社交应用来保持联系和交流。IM系统使用端到端加密可以使得用户能够放心地分享私密信息，维护社交关系的同时保护了个人隐私。

7、IM系统使用端到端加密的不足

通讯效率低：由于端对端加密需要对通讯数据进行加密和解密，因此可能会导致通信效率较低。

需双向支持：端对端加密需要发送方和接收方都需要支持该技术，否则就将无法实现端对端加密通信。

安全性问题：虽然端对端加密可以防止中间人攻击，但如果黑客能够获得了私钥或公钥，那么他们也能够轻易地获取到通信数据。

8、延伸阅读

本文内容主要是面向即时通讯技术的初学者以及产品经理，所以相关的技术概念都没有深入探讨，感光趣的可以继续深入阅读我整理的以下几篇资料。

1. IM聊天系统安全手段之通信连接层加密技术
2. IM聊天系统安全手段之传输内容端到端加密技术
3. 移动端安全通信的利器——端到端加密（E2EE）技术详解
4. 简述实时音视频聊天中端到端加密（E2EE）的工作原理

9、参考资料

[1] 网络编程懒人入门(三)：快速理解TCP协议一篇就够

[2] 即时通讯初学者必知必会的20个网络编程和通信安全知识点

[3] 为什么要用HTTPS？深入浅出，探密短连接的安全性

[4] 理论联系实际：一套典型的IM通信协议设计详解（含安全层设计）

[5] 微信新一代通信安全解决方案：基于TLS1.3的MMTLS详解

[6] 移动端安全通信的利器——端到端加密（E2EE）技术详解

[7] 常用加解密算法与通讯安全讲解

[8] 通俗易懂：一篇掌握即时通讯的消息传输安全原理

[9] 基于Netty的IM聊天加密技术学习：一文理清常见的加密概念、术语等

[10] 手把手教你为基于Netty的IM生成自签名SSL/TLS证书

[11] 微信技术分享：揭秘微信后台安全特征数据仓库的架构设计

[12] 即时通讯初学者必知必会的20个网络编程和通信安全知识点

（本文已同步发布于：http://www.52im.net/thread-4792-1-1.html）

本文由B端技术中心资深开发工程师马家忆分享，原题“B站在实时音视频技术领域的探索与实践”，下文进行了排版和内容优化。

1、引言

直播行业从传统的娱乐直播发展到教育直播、电商直播等形式，产生了很多新的玩法。传统的直播是一位主播展示才艺，观众通过弹幕、送礼物等方式进行互动。随着网络质量不断地提高，用户也对直播平台产生的新的要求，实时互动直播的场景就出现了，观众可以同时观看多位主播之间互动的画面，让直播间的气氛更好。B站直播的连麦PK、视频连线业务就提供了这个能力。主播看到的是对方主播实时的流（延迟400ms以内），而观众看到的是“准实时”的流（延迟2~5s左右）。

本文讲述搭建这样一套最新流行的实时视频直播系统需要了解的背景知识以及系统的整体架构，希望对大家有帮助。

2、系列文章

本文是系列文章中的第 13 篇，本系列总目录如下：

《视频直播技术干货(一)：揭秘百万级粉丝互动的Facebook实时视频直播》

《视频直播技术干货(二)：P2P技术如何将实时视频直播带宽降低75%？》

《视频直播技术干货(三)：实时直播答题系统的实现思路与技术难点分享》

《视频直播技术干货(四)：首次披露快手是如何做到百万观众同场看直播仍能秒开且不卡顿的？》

《视频直播技术干货(五)：七牛云使用QUIC协议实现实时视频直播0卡顿》

《视频直播技术干货(六)：新浪微博实时直播答题的百万高并发架构实践》

《视频直播技术干货(七)：实时视频直播首屏耗时400ms内的优化实践》

《视频直播技术干货(八)：淘宝高清、低延时的实时视频直播技术解密》

《视频直播技术干货(九)：千万级直播系统后端架构设计的方方面面》

《视频直播技术干货(十)：一文读懂主流视频直播系统的推拉流架构、传输协议等》

《视频直播技术干货(十一)：超低延时视频直播技术的演进之路》

《视频直播技术干货(十二)：从入门到放弃，快速学习Android端直播技术》

《视频直播技术干货(十三)：B站实时视频直播技术实践和音视频知识入门》（* 本文）

3、关于作者

马家忆：B端技术中心资深开发工程师。

4、实时音视频关键技术概述

从0到1搭建一套实时音视频系统并支撑现有的业务，如果没有接触过这方面的东西会感觉无从下手。

我们可以看到，1996年IETF就推出了RTP协议用于实时音视频传输，2011年Google推出了WebRTC用于网页端实时音视频通话（见《了不起的WebRTC：生态日趋完善，或将实时音视频技术白菜化》）。

从这些现有的协议和项目中，我们可以发现实时音视频技术的关键点，评估自身现有的基础组件支持情况并结合业务场景寻找适合自己的解决方案。

5、关键技术1：传输协议

RTP协议（Real-time Transport Protocol）定义了在互联网上传输实时音视频数据的标准格式，属于应用层协议。RFC 3550描述RTP协议的传输层主要使用UDP，RFC 4571描述了RTP协议的TCP传输方式。

在我们的实时音视频场景中应当优先选择UDP，理由如下：

1）TCP保证数据流的可靠性和顺序性。TCP的超时重传策略为了保证通用和公平，相对比较保守，重传超时时间（RTO）可能会变的很大。假如中途丢失一个包，后续的包即使先到达也要缓存起来等待重传完成以后才能送到应用层。在网络状况不佳的情况下，使用TCP传输会产生较大的延迟；

2）UDP允许数据包丢失、乱序和重复。即使数据丢失也不会阻塞接收缓冲区等待重传，这就为实时性提供了保障。在上层的RTP协议中，协议头部包含了时间戳和序列号，可以对数据包进行重排和丢弃，解决了乱序和重复的问题。如果接收端监测到丢包，并且丢失的包是必要的且无法恢复，则发送NACK消息通知发送端重传（下一节会详细探讨这个话题）。

UDP虽然在低延迟领域上有压倒性的优势，但是用户侧有可能存在防火墙拦截所有的UDP包。考虑到在网络环境足够好的情况下使用TCP也能达到不错的效果，因此我们做了一个降级策略，优先使用UDP，当且仅当UDP不通的时候使用TCP。

6、关键技术2：丢包补偿

前面讲到我们的传输层协议优先选择UDP，那么就需要引入一些机制解决丢包问题。

前向纠错FEC（Forward Error Correction）指的是发送端发送原始数据的同时附加部分冗余的信息，如果接收端检测到原始数据丢失则尝试使用冗余的信息进行恢复。发送端发送n个数据包，同时根据原始数据生成k个冗余的数据包，将n+k个数据包发送出去，接收端只要收到至少n个数据包就可以得到全部的原始数据。

FEC算法的关键在于异或。异或(Exclusive OR)是一个数学运算符，数学符号为“⊕”，两边数值转换成二进制按位运算，相同时为0，不同时为1。

以一阶冗余算法为例，n个数据包生成1个冗余包，发送n+1个数据包。我们发送三个数值分别为a、b、c，生成冗余数据x=a ⊕b ⊕ c一起发送。假如数值b在传输中丢失了，计算a ⊕c ⊕ x即可得到b。

在实际应用中，FEC没有这么简单，WebRTC实现了UlpFEC和FlexFEC，UlpFEC可以针对数据包的重要程度实施不同程度的保护以充分利用带宽，FlexFEC还支持对列做冗余，同时WebRTC默认的音频编码器Opus本身就支持FEC。

前向纠错适合少量随机丢包的场景，可以无视网络延迟时间，但是增加了带宽消耗。

后向纠错包括ARQ（Automatic Repeat Request）和PLC（Packet Loss Concealment）。ARQ指的是接收端检测到数据丢失的时候发送NACK报文请求发送端重传，适合突发大量丢包的场景，没有额外的带宽消耗，但是时效性取决于RTT，如果存在很多接收端还要考虑避免NACK风暴造成雪崩。PLC用于音频，当数据缺失时使用模型根据前后数据预测丢失的数据。

总之，前向纠错和后向纠错各有优缺点，需要搭配使用。

7、关键技术3：流量控制

流量控制指的是根据网络状况的波动估算可用带宽，根据带宽的变化自动调节音视频码率和发送速率。当网络质量变差的时候迅速降低数据量以确保实时性，网络较好时则慢慢提升数据量带来更清晰的画面。在WebRTC中提供了优秀的Google Congestion Control算法，包括基于延迟的评估和基于丢包率的评估，取两种评估方式的最小值作为目标带宽通知编码器和数据发送模块。

基于延迟的评估算法包括Transport-CC和Goog-REMB，目前最新版的WebRTC默认使用的是Transport-CC。Transport-CC在发送端进行带宽评估，接收端通过TransportFeedback RTCP包向发送端反馈每个RTP包的到达时间，发送端在一个时间窗口内计算每个RTP包到达时间与发送时间之差，通过Trendline滤波器处理后预测网络状况。假设我们当前处于Hold状态，如果检测到网络状态为OverUse，此时应该减小数据量，变更为Decrease状态；如果检测到网络状态为Normal，此时可以尝试增加数据量，变更为Increase状态。

基于丢包的评估算法是当网络突发大量丢包时的兜底策略：

• 1）如果丢包率在2%以下的时候说明网络质量好，目标带宽增加8%；
• 2）如果丢包率在在2%~10%说明当前发送数据的带宽和网络质量相匹配可以保持不变；
• 3）如果丢包率大于10%说明网络质量差，目标带宽减小到(1-丢包率*0.5)* 当前带宽。

8、关键技术4：数据缓冲

如果我们只考虑实时性，那么收到数据就立刻解码并渲染必然是最好的选择，但是网络并不稳定，延迟、乱序、丢包、重复包都有可能发生。如果采用上面的策略，音频可能因为网络的抖动变的断断续续，视频可能因为丢包导致缺少参考帧从而出现黑屏或花屏，所以有必要引入一个缓冲区，增加一点可以接受的延迟来保证用户体验。

在WebRTC中，视频包会被放入JitterBuffer模块进行处理，JitterBuffer会进行视频包的排序、组装成完整的帧、确保参考帧有效，然后把数据送到解码器。同时，根据网络状况自适应地调节缓冲区的长度。音频包会被放入NetEQ中，它维护了音频的缓冲区，同时负责将音频同步到视频。我们做播放器一般都是以音频的时间为基准同步视频，但是WebRTC刚好相反，它是以视频为基准的。当音频数据堆积的时候加速音频播放，音频数据不足的时候降低速度把音频拉长。

9、关键技术5：回声消除

在语音通话的场景中，麦克风采集到的声音发送给远端，远端的扬声器播放出来以后又被远端的麦克风采集到这个声音并传送回来，这样讲话的人会感觉到有回声，影响体验。

WebRTC提供了回声消除算法AEC，时延估计（Delay Estimation）模块找到扬声器信号和麦克风信号的时延，线性自适应滤波器（Linear Adaptive Filter）参考扬声器信号估算回声信号并将其剪去，最后通过非线性处理（Nonlinear Processing）模块消除残留的回声。

10、关键技术6：最优路径

实时音视频对网络的要求非常高，如果通话双方距离很远，那么通话质量是很难保证的。城市A的设备给城市D的设备发送数据，直接发送未必是最优的选择，从城市B和城市C中转一下有可能更快。

理想的解决方案是在全球部署加速节点，用户就近接入。根据加速节点之间的实时网络质量探测数据，找到一条最优传输路径，避开网络的拥堵。

11、开源音视频框架WebRTC简述

刚才介绍了实时音视频系统实现过程中所需的关键技术，多次提到了WebRTC。显然，对于绝大多数团队来说，这些内容如果全部自主研发几乎是不可能的事情，而我们站在WebRTC的基础上去设计自己的系统是较为明智的选择。

WebRTC的代码非常复杂，想要把它搞清楚是一件非常困难的任务，我第一次看到WebRTC的代码根本就不知道从哪里下手。

幸运的是，WebRTC官方提供了架构图，可以先帮助我们对它进行一个宏观的了解。

WebRTC整体架构大概可以分为接口层、会话层、引擎层和设备I/O层：

1）接口层包括Web API和WebRTC C++ API，Web API给Web开发者提供了JavaScript接口，这样Web端就具备了接入WebRTC的能力；WebRTC C++ API面向的是浏览器开发者，让浏览器开发商具备集成WebRTC的能力。当然，WebRTC C++ API也可以用于Native客户端接入；

2）会话层主要包含信令相关的逻辑，比如媒体协商，P2P连接管理等；

3）引擎层是WebRTC最核心的功能，包括音频引擎、视频引擎和传输模块。音频引擎包含音频编解码器（Opus）、NetEQ和著名的3A（回声消除、自动增益、降噪）算法；视频引擎包括视频编解码器（VP8、VP9、H264）、JitterBufer和图像增强（降噪）算法；传输模块包含SRTP、多路复用和P2P模块；

4）设备I/O层主要和硬件交互，包括音视频采集和渲染，以及网络I/O。

上面一节描述的实时音视频关键技术中，WebRTC实现了除“最优路径”之外的全部内容。WebRTC几乎每个模块都是可以按需替换的，便于我们增加定制的内容。我们可以根据实际需求决定如何使用WebRTC，Native客户端可以通PeerConnection接口接入，服务端拿到RTP/RTCP包以后完全可以直接调用引擎层处理拿到最终的YUV和PCM数据，甚至只把WebRTC内部模块抠出来用在自己的系统上也是没问题的。

更多相关资料可阅读：

1. 零基础入门：基于开源WebRTC，从0到1实现实时音视频聊天功能
2. 实时音视频入门学习：开源工程WebRTC的技术原理和使用浅析
3. 零基础快速入门WebRTC：基本概念、关键技术、与WebSocket的区别等

12、B站视频直播系统架构

我们回到B站的连麦PK业务场景，两位主播进行互动PK，同时大量观众在直播间观看PK的过程。

显然，两位主播通话要求低延迟，必须使用实时音视频系统交互；而观众观看直播的延迟要求相对没那么严格，可以采取传统直播的模式，通过RTMP或者SRT推流到CDN，用户从CDN拉流。

然后我们要思考两个问题。

12.1 问题1：主播之间的音视频通话是采用P2P还是服务器中转？

首先对P2P和服务器中转两种方案做个对比：

对于P2P方案来说，只需要部署STUN和TURN服务器，如果成功建立P2P连接那么后续媒体数据传输就不需要经过服务器，所以具有成本优势。然而，P2P的缺点也很明显，如果打洞失败还是需要TURN服务器中转，且建立连接的过程耗时较高，用户之间距离较远的情况下网络质量不可控，而且现有的第三方网络加速服务基本上都不支持P2P。

我们这里选择服务器中转的方案，因为实时音视频本身对网络的要求比较高，不会设置过高的码率，所以网络传输的数据量是可控的，成本能够接受。而且我们的实时音视频数据要对接AI审核，还要实现服务器混流，这是P2P方案做不到的。

12.2 问题2：推送给观众的流到CDN，这个工作放在主播客户端还是服务器？

两位主播PK对应的是两路流，观众只从CDN拉一路流，所以必须有个地方做混流。这里的混流指的是把两位主播的视频进行拼接、音频进行混合，然后打包成一路流。主播客户端能收到对方的流，可以和自己的流做混流；在前面提到的服务器中转方案中，服务器有双方的流，同样也可以完成混流。

我们先对比一下两种方案的优劣：

服务器进行混流需要先解码再编码，这需要消耗大量计算资源，所以成本很高；主播客户端进行混流需要额外增加一路流的编码和上传，对设备性能和上行带宽来说也是很大的挑战。

主播客户端需要等待服务器把对方的流发送过来才能混流，所以从延迟的角度来看服务器混流稍微占据优势，不过这个延迟相比CDN的延迟可以忽略不计。如果后期对通话质量要求变高，主播的设备性能和上行带宽跟不上，我们可以很容易增加服务器来扩展计算资源和带宽，所以在可扩展性方面服务器混流胜出。

另外，当主播从正常直播切换到连麦PK状态的时候，采用服务器混流必须先把直播的流停掉再由服务器接管，中间的时间差可能会产生卡顿或黑屏影响观众体验，而主播客户端混流可以做到无缝切换。

所以，这两种方案各有优缺点，我们采取折衷的办法：如果主播的设备负载较低且上行带宽比较充足，优先采用主播客户端混流的方式，否则降级为服务器混流。

12.3 开始架构设计

上面两个问题分析清楚了，就可以开始设计了。

这是我们的系统整体架构：

rtc-service主要提供信令、频道管理、主播管理、公有云上媒体服务器集群的健康检查和节点分配、同步主播状态到业务服务器、记录通话流水。

rtc-job是对rtc-service的补充，定期检查当前在线主播的状态，发现主播异常下线时触发兜底逻辑。

rtc-router负责收发主播的音视频数据。主播可以收到同一个频道内其他人的音视频流。如果需要服务器混流，则访问注册中心并采用Google的有界负载一致性哈希算法（Consistent Hashing with Bounded Loads）选取rtc-mixer节点，并往对应节点推送主播的音视频流。

rtc-mixer负责混流，根据需求拼接画面和混音，然后推送到CDN，观众通过CDN拉流。

主播的客户端并没有直接向rtc-router发送数据，而是通过第三方的四层加速网络转发。我们前面提到了“最优路径”的概念，第三方的四层加速服务可以让用户接入最近的加速节点，然后寻找最优路径把数据转发到我们的公有云节点。客户端只能看到第三方的加速节点IP，看不到我们公有云媒体服务器的IP，这在一定程度上可以防止服务器遭到攻击；其次，我们可以在保证异地多活的前提下让公有云集群相对比较集中，节省成本。

服务的可用性和容错性也是一个很重要的问题，假如在主播PK即将胜利的时刻服务出现故障，弹出"PK异常终止请重新再来"，这很令人绝望。我们不仅要保证服务可用，还要尽最大可能保证服务出现故障时减小对用户的影响，让流程能够走下去。接下来讨论系统中每个风险模块为了实现这个目标所采取的措施：

四层加速网络故障。这个属于第三方厂商提供的服务，每个厂商提供的接入方式大同小异，基本上就是附加的header有差别，所以同时对接多家厂商对客户端来说是很容易做到的。客户端进行连通性检查，只要存在至少一家厂商的服务可用，就不会影响业务。

公有云上的rtc-router和rtc-mixer故障。在公有云上部署服务，尽量要多厂商、多区域部署，防止单机房整体宕机。我们同样准备了多个集群，每个集群都部署了多台rtc-router、rtc-mixer和ZooKeeper，单个集群可以独立工作，如果单个集群不可用或者负载达到上限则会被熔断。核心机房的rtc-service会对公有云上的集群进行健康检查，如果rtc-router宕机，rtc-service会通过信令通道通知客户端切换到同集群中其他服务器，当同集群没有可用机器时则切换集群。如果rtc-mixer宕机，rtc-router会通过ZooKeeper重新选择一台接管混流任务。

核心机房的rtc-service和rtc-job故障。这部分内容和B站大部分核心服务部署在同样的集群，复用了B站比较成熟的高可用架构。这部分内容可以参考其他文章，这里不再赘述。

13、本文小结

如果我们把实时音视频技术比作一座富丽堂皇的城池，这篇文章只能带领大家来到城门口。我们也不会停止探索的脚步。希望大家读到这里能够有所收获，如有疏漏，欢迎批评指正。

14、参考资料

[1] 实时语音通讯的回音及回音消除概述

[2] 实时语音通讯的回音消除技术详解

[3] 实时语音通讯丢包补偿技术详解

[4] 零基础，史上最通俗视频编码技术入门

[5] IM实时音视频聊天时的回声消除技术详解

[6] 学习RFC3550：RTP/RTCP实时传输协议基础知识

[7] 基于RTMP数据传输协议的实时流媒体技术研究（论文全文）

[8] 爱奇艺技术分享：轻松诙谐，讲解视频编解码技术的过去、现在和将来

[9] 零基础入门：实时音视频技术基础知识全面盘点

[10] 实时音视频面视必备：快速掌握11个视频技术相关的基础概念

[11] 零基础入门：基于开源WebRTC，从0到1实现实时音视频聊天功能

[12] 实时音视频入门学习：开源工程WebRTC的技术原理和使用浅析

[13] 零基础快速入门WebRTC：基本概念、关键技术、与WebSocket的区别等

[14] 移动端实时音视频直播技术详解（五）：推流和传输

[15] 移动端实时音视频直播技术详解（六）：延迟优化

[16] 实时视频直播客户端技术盘点：Native、html5、WebRTC、微信小程序

[17] 浅谈开发实时视频直播平台的技术要点

[18] 视频直播技术干货：一文读懂主流视频直播系统的推拉流架构、传输协议等

（本文已同步发布于：http://www.52im.net/thread-4785-1-1.html）

1、前言

本文深入分析了即时通信(IM)系统中所面临的各种安全问题，综合利用对称加密算法（DES算法）、公开密钥算法（RSA算法）和Hash算法(MD5)的优点，探讨组合加密算法在即时通信中的应用。

技术交流：

2、IM安全系列文章

本文是IM通讯安全知识系列文章中的第2篇，总目录如下：

《即时通讯安全篇（一）：正确地理解和使用Android端加密算法》

《即时通讯安全篇（二）：探讨组合加密算法在IM中的应用》（本文）

《即时通讯安全篇（三）：常用加解密算法与通讯安全讲解》

《即时通讯安全篇（四）：实例分析Android中密钥硬编码的风险》

《即时通讯安全篇（五）：对称加密技术在Android上的应用实践》

《即时通讯安全篇（六）：非对称加密技术的原理与应用实践》

《即时通讯安全篇（七）：用JWT技术解决IM系统Socket长连接的身份认证痛点》

《即时通讯安全篇（八）：如果这样来理解HTTPS原理，一篇就够了》

《即时通讯安全篇（九）：你知道，HTTPS用的是对称加密还是非对称加密？》

《即时通讯安全篇（十）：为什么要用HTTPS？深入浅出，探密短连接的安全性》

《即时通讯安全篇（十一）：IM聊天系统安全手段之通信连接层加密技术》

《即时通讯安全篇（十二）：IM聊天系统安全手段之传输内容端到端加密技术》

《即时通讯安全篇（十三）：信创必学，一文读懂什么是国密算法》

《即时通讯安全篇（十四）：网络端口的安全防护技术实践》

《即时通讯安全篇（十五）：详解硬编码密码的泄漏风险及其扫描原理和工具》

3、即时通信应用所面临的安全问题

即时通信系统大都采用C/S、B/S、P2P等技术来实现即时通信的功能，软件编制没有统一的标准，使得IM系统本身存有多种安全漏洞，加上用户缺乏安全意识，导致在使用即时通信系统时出现各种安全问题。

3.1 信息窃取问题

目前的IM系统在交换信息或传输文件时仅仅采用了弱加密甚至不加密的方式，攻击者利用此缺陷监听、窃取重要数据，这种泄密可能性给企业或个人造成不可估量的损失，尤其是对一些特殊行业，如金融和证券等行业，将会构成巨大的商业安全威胁，这种攻击的类型是对信息机密性的攻击。

3.2 信息篡改问题

信息篡改又称中间人攻击，是攻击者试图在IM系统信息交互过程中，通过监听、窃取正常的信息流，对信息进行修改后再发往信息接收方。只要信息存在，就可能出现这种攻击，它还可能攻击传输中的信息，这种攻击的类型是对信息完整性的攻击。

3.3 信息伪造问题

在现有的IM系统中，接收方一般只根据发送方的ID或发送过来的简单信息进行确认，这样就给攻击者提供了机会。攻击者通过令人误导的昵称或者迷惑性的语言，骗取对方的信任，从而套取信息、诈骗或达到其他不良目的。这种攻击的类型是对信息真实性的攻击。

3.4 其他问题

由于IM系统的文件传输采取了P2P模式，它可以将文件作为附件通过点对点方式传送，而绕过网络周边安全防御设备。由于点对点隧道直接传至桌面计算机，因此受感染的文件借即时通信系统就能绕过防病毒网关的扫描，各种病毒如蠕虫、特洛伊木马等可以借此轻松地进入网络，很多被病毒感染的文件则可能利用即时通信系统进行传播。

攻击者也可以用缓冲区溢出、拒绝服务等攻击方式，通过IM系统的安全漏洞对整个网络系统进行攻击或传播病毒。

4、主流的加密算法介绍

4.1 对称加密：DES算法

DES即数据加密标准，这种加密算法是由IBM研究提出来的， 是一种分组密码，它用于对64比特的数据进行加密和解密。DES算法所用的密钥也是64比特，但由于其中包含了8个比特的奇偶校验位，因而实际的密钥长度是56比特。DES算法多次组合替代算法和换位算法，利用分散和错乱的相互作用，把明文编制成密码强度很高的密文。DES算法的加密和解密的流程是完全相同的，区别仅仅是加密与解密使用子密钥序列的顺序正好相反n1。DES算法属于对称加密算法，即加密和解密共享同一个密钥，主要用于解决数据机密性问题。

4.2 公开密钥算法：RSA算法

RSA算法作为惟一被广泛接受并实现的通用公共密钥加密方法，是众多阐述非对称密码体制的算法中最具代表性的，几乎成了公开密钥密码学的同义词。它是麻省理工大学的Rivest，Shamir和Adleman（RSA算法即为三人名字的缩写）于1977年研制并于1978年首次发表的一种算法。该算法的数学基础是数论的欧拉定理，它的安全性依赖于大数的因子分解的困难性，该算法至今仍没有发现严重的安全漏洞。RSA使用两个密钥，一个是公钥(PubHc Key)，另一个是私钥(Private Key)加密时把明文分戍块，块的大小可变，但不超过密钥的长度。RSA把明文块转化为与密钥长度相同的密文。其算法如下：

首先选择两个相异大质数p、q，计算n=pq，取小于n的数e与（p-l）(q-l)互质。根据给定的e，再选择d满足ed除以z的模余数是1（即满足ed mod (p-l)(q-l)=1），根据欧几里得算法(a=bn+c，则a与b的最大公因子就等于b与c的最大公因子)，这样的d-定可以找到。这样数对(n，e)为公钥，数对(n，d)为私钥在编码时，假设资料为A，将其分戍等长数据N块，每块为nKn。计算C=llle mod n，则c就是编码后的资料。至于解码，取III=Cd mod n。黑客攻击时怨得到e，这样就必须对n进行因式分解，选择足够大的质数p、q便能阻止分解因式。

对于p、q的选择，一般来说是足够大的素数，对于大数，并没有一个确定的界限，因为随着计算机技术的发展，破解能力正在逐步增强（根据摩尔定理计算能力18个月就翻一番）。RSA实验室的建议是，安全性要求相对较低时，p和q的乘积达到768位；安全性要求相对较高时，乘积达到1024位以上。

RSA算法还可以用于“数字签名”，即用私钥进行加密，公钥来解密。

4.3 Hash算法：MD5算法

MD5算法并不是加密算法，但却能形成信息的数字“指纹”，主要用途是确保数据没有被篡改或变化过，以保证数据的完整性。MD5算法有三个特性：

• 1）能处理任意大小的信息，并生成固定长度128位的信息摘要；
• 2）具有不可预见性，信息摘要的大小与原始信息的大小没有任何联系，原信息的每一个微小变化都会对信息摘要产生很大的影响；
• 3）具有不可逆性，没有办法通过信息摘要直接恢复原信息。

5、应用探讨：组合加密算法实现即时通信系统的认证模型

本文综合利用以上算法的优点，在IM系统中建立以下消息发送模型，以解决IM系统所面临的信息窃取、篡改、伪造等安全问题。模型中用户A和B为IM系统的客户端，用户A和B之间彼此拥有对方的公钥或数字证书，A向B发送消息，其全过程如图1所示。

对于IM系统中蠕虫病毒感染安全问题的处理，通过以下模型进行处理，如图2所示。

6、应用探讨：组合加密算法实现即时通信系统的通信模型

按照以上加密认证模型，建立如图3所示的安全即时通信系统的实现模型，该模型包含两个层次的认证，一是服务器与客户机之间的双向认证，二是客户机与客户机之间的双向认证，即在两端连接发送数据之前，必须协商并交换密钥信息。服务器作为自签署证书的CA认证中心，认证的所采用的密码技术极为公开密密钥技术。

模型中的公开密钥技术充当了加密共享密钥和数字签名的作用，以解决服务器与客户机、客户机与客户机之间的身份鉴别和客户机之间进行数据通信的密钥传输问题。在Java密码术体系结构中，密钥生成和操作可以使用keytool程序来执行。

7、应用探讨：组合加密算法应用模型的安全性及效率分析

在以上模型中，利用对称加密算法处理消息、文件的加密，以解决信息、文件传送的机密性问题，具有加密速度快的特点；用公开密钥算法的加密技术解决了对称密钥在网络中明文传输问题；用Hash算法计算出摘要，再通过公开密钥算法的数字签名技术对摘要进行签名，既提高了效率，又保证了信息文件传输的鉴别和不可否认性；在文件处理过程中，通过病毒扫面和组合加密双重处理，减少了网络中文件传输病毒蠕虫感染的几率。

更多有关IM安全和架构资料

[1] 传输层安全协议SSL/TLS的Java平台实现简介和Demo演示》

[2] 理论联系实际：一套典型的IM通信协议设计详解（含安全层设计）》

[3] 微信新一代通信安全解决方案：基于TLS1.3的MMTLS详解》

[4] 来自阿里OpenIM：打造安全可靠即时通讯服务的技术实践分享》

[5] 简述实时音视频聊天中端到端加密（E2EE）的工作原理》

[6] 移动端安全通信的利器——端到端加密（E2EE）技术详解》

[7] Web端即时通讯安全：跨站点WebSocket劫持漏洞详解(含示例代码)》

[8] 通俗易懂：一篇掌握即时通讯的消息传输安全原理》

[9] IM开发基础知识补课(四)：正确理解HTTP短连接中的Cookie、Session和Token》

[10] 快速读懂量子通信、量子加密技术》

[11] 即时通讯安全篇（七）：如果这样来理解HTTPS原理，一篇就够了》

[12] 一分钟理解 HTTPS 到底解决了什么问题》

[13] 一篇读懂HTTPS：加密原理、安全逻辑、数字证书等》

[14] 基于Netty的IM聊天加密技术学习：一文理清常见的加密概念、术语等

[15] 手把手教你为基于Netty的IM生成自签名SSL/TLS证书

[16] 微信技术分享：揭秘微信后台安全特征数据仓库的架构设计

[17] 零基础IM开发入门(二)：什么是IM系统的实时性？

[18] 零基础IM开发入门(三)：什么是IM系统的可靠性？

[19] 零基础IM开发入门(四)：什么是IM系统的消息时序一致性？

[20] 新手入门一篇就够：从零开发移动端IM

[21] 转转平台IM系统架构设计与实践(一)：整体架构设计

[22] 基于实践：一套百万消息量小规模IM系统技术要点总结

[23] 一套亿级用户的IM架构技术干货(上篇)：整体架构、服务拆分等

[24] 一套亿级用户的IM架构技术干货(下篇)：可靠性、有序性、弱网优化等

[25] 一套海量在线用户的移动端IM架构设计实践分享(含详细图文)

[26] 一套原创分布式即时通讯(IM)系统理论架构方案

（本文已同步发布于：http://www.52im.net/thread-217-1-1.html）