Jack Jiang

我的最新工程MobileIMSDK:http://git.oschina.net/jackjiang/MobileIMSDK
posts - 516, comments - 13, trackbacks - 0, articles - 1

2025年8月7日

1、引言

平时开发工作中,我们会经常接触加密、解密的技术。尤其在今天移动互联网时代,越来越多的用户会将数据存储在云端,或使用在线的服务处理信息。这些数据有些涉及用户的隐私,有些涉及用户的财产,要是没有一套的方案来解决用户的数据安全问题的话,这将是一个多么可怕的事儿。

作为开发者,也会经常遇到用户对数据安全的需求,当我们碰到了这些需求后如何解决,如何何种方式保证数据安全,哪种方式最有效,这些问题经常困惑着我们。52im社区本次着重整理了常见的通讯安全问题和加解密算法知识与即时通讯/IM开发同行们一起分享和学习。

技术交流:

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

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

2、通讯安全性威胁

一般的,我们在网络中传输的数据,都可以认为是存在这潜在的风险的。用一句话来概括就是:“任何在网络中传输的明文数据都存在安全性威胁。

下面就列举下我们通信中面临的四种威胁:

  • 1)中断:攻击者有意破坏和切断他人在网络上的通信,这是对可用性的攻击;
  • 2)截获:属于被动攻ji,攻击者从网络上qie听他人的通信内容,破坏信息的机密性;
  • 3)篡改:攻击者故意篡改网络上传送的报文,这是对完整性的攻击;
  • 4)伪造:攻击者伪造信息在网络传送,这是对真实性的攻击。
1

我们经常说加密解密算法是数据安全领域里的“剑”,是一种主动的防护,对数据进行必要的加密处理,以保证其在数据传输、存储中的安全。接下来讲着重讲解加解密算法知识。

3、Base64算法介绍

3.1 原理

严谨的说,base64并不是加密算法,这里提到他是因为他的实现比较简单,通过他的实现,我们可以更好的理解加密解密的过程。

下面看下他是如何“加密”的。假设我们要对“BC”字符串进行加密。现将其转换为二进制表达方式,并连起来:01000010 01000011,接下来对二进制按6位分组,不够6位补0,得到010000、100100、001100(最后两位补0)。下面查表,找到对应的值“QKM”。那么“QKM”就是“BC”用base64“加密”后的值了。

2

从上面的base64算法,我们可以窥视部分加密的本质:将一段有意义的信息,通过某种方式,映射为一段看不懂的信息。

使用函数表达即为:

public Ciphertext encrypted(Plaintext text);

值得注意的是:base64里有一张映射表,如果改变映射表的顺序,最终得到的结果就会跟着改变。有点类似烹调,在相同原料、相同烹调方式下,我们改变加入的调料,最终做出的东西将会也不一样。这里的映射表,我们叫之为“密钥”。

3.2 小结

通过base64算法可以看出,一个加密算法会有两部分组成:

  • 1)密钥;
  • 2)算法。

两者不能都公开,都公开的话,就可以被人逆向运算,进行解密。

一般的:我们将密钥进行保密,将算法进行公开。算法的公开,有利于算法的推广,普及,更有利于寻找算法中的漏洞。也就是因为base64同时公开了算法、密钥,所以我们说他并不是真正的加密算法。当然如果你调整了上面映射表,那么也能做到加密算法的目的,不过base64加密的强度比较差,所以不建议在实际应用中作为加密算法使用。

4、摘要算法介绍

4.1 基本

我们在平时的工作中经常听到MD5算法。比如在一些下载页面里会给出一个md5的作为文件验证串,在迅雷下载中作为文件的唯一标识。

这类算法严格上来说也不是加密算法,是一种叫做摘要算法的算法,不过在平时的使用中,我们经常将摘要算法混合使用,所以在广义上来说也可以将他叫为加密算法。

4.2 摘要长度

摘要算法的特点是可以将任意长度的字符串,给转换为定长的字符串。

可以意料的是,在这个转换过程中,一定是一共单向的过程。打个比方,我们将一个256长度的字符串转换为128长度的字符串,转换前有N^256种可能,转换后有N^128种可能,这一定不可能是1对1的对应关系。

所以我们只要保证摘要串(转换后的串)位数只够的长,使得“给定一个字符串A,经过摘要算法处理后的串B,很难找到一个字符串C,其摘要后的串和串B相同” 即可。所以目前主流的摘要算法MD/SHA的摘要串长度都在128位以上。而正是出于这个原因,美国还对长摘要串的加密算法进行了出口的限制。

4.3 通讯模型

摘要算法在平时的使用中,经常以如下的形式进行:

假设客户端需要传输一段信息data给服务器端,为了data在网络中数据的完整性,或者说防止信息data被恶意的用户篡改,可以始终这种安全通信模型:客户端与服务器端实现确定了加密密钥key,一段任意的字符串,客户端将key与数据data拼接在一起,进行摘要得到摘要串C,将data、C传给服务器端,服务器端得到data和C后,同样使用与客户端相同的方法,计算摘要串S,如果S等于C的话,就说明A在传输中,没有被人篡改。

流程如下图:

3

对于我们在通信的面临的四种威胁,摘要算法是否能防范呢:

  • 1)截获:由于网络中传输的数据依然的明文的,对于攻击者来说暴露无遗,所以摘要算法对于这种威胁,没什么办法。
  • 2)中断:摘要算法,是对数据的验证,对整个网络的可用性方面的攻击,无法防范。
  • 3)篡改:客户端发出的数据,中途被攻击者进行了修改,由于攻击者并不知道密钥key,将无法生成正确的摘要串。所以,摘要算法可以防范篡改威胁。
  • 4)伪造:攻击者伪造成客户端,给服务器端发数据,但由于拿不到密钥key,伪造不出摘要串。所以,在这种情况下,摘要算法是有一定的防范作用的。但是,在伪造威胁中,还有一种是重放攻击,攻击者事先将客户端发给服务器端的包截下来,然后重复发送。例如:客户端发给服务器端密码时,被攻击者记录了下来,当下次,服务器端再向客户端询问密码时,攻击者只需将记录下来的包发给服务器端即可。所以摘要算法对于伪造威胁的防范是不彻底的,其只可以辨别伪造的内容,不能辨别伪造的发送方。
4

常见的摘要算法有MD5/MD4/SHA-1/SHA-2等,其摘要串长度也不尽相同。现在MD4/MD5/SHA-1等一些摘要串长度128比特的摘要算法已不再安全,山东大学的王小云教授已经证明MD4/MD5/SHA-1已经可以快速生成“碰撞”。所以在真正的对安全性要求极高的场所还是使用长摘要串的摘要算法来的靠谱一些。

5

5、对称加密算法介绍

5.1 基本

理论上说对称加密算法,才是我们真正说的加密算法。

所谓对称加密算法,通俗的讲,就是使用密钥加密,再使用密钥解密的加密算法的总称。也就是平时我们说到加密算法,脑子里第一个跳出来的加密方式一般都是对称加密算法。上面将的base64其实也是一种“对称加密算法”,只是其密钥公开了而已。

5.2 通讯模型

同样的场景:客户端要将数据data发给服务器端。客户端对使用密钥key,对数据data加密,生成加密串C,通过网络将C传输为服务器端,服务器端,使用密钥key对C解密,获取数据data,做自己的业务逻辑。

6

简单直接的一种加密方式,与摘要算法不同的地方是,加密过程其是双向的,C由data加密而来,同样可以解密获得data,前提条件是加密解密时的key相同。而摘要算法无法从C解密得到data。

加密过程简单,那么其在对抗通信中面临的四种威胁的作用有怎么样呢:

  • 1)截获:这么在网络中传输的内容为密文,即使攻击者截获了报文,由于没有密钥,也无法解析。所以,这次对称加密算法在防范截获威胁方面有这很大的优势;
  • 2)中断:和摘要算法一样,无法防范;
  • 3)篡改:由于数据是密文传输的,攻击者,无法解析,更无法伪造了。所以,可以防范;
  • 4)伪造:对于数据的伪造,和摘要算法一样,可以防范,但对于伪造的发送方,对称加密算法和摘要算法一样,比较的无力。
7

5.3 算法优缺点

对称加密算法有着很多的好处,比较加密速度快,算法简单,安全模型的安全性较高等,但在正式中使用时,却不得不解决一个问题:密钥如何传递。如果将密钥在网络中传递,势必有被截获的风险。由于这个问题的存在,导致单纯的使用对称加密算法的通讯模型,并不是一个通用的模型,只在一些特殊的场合中使用,例如:客户端/服务器端为同一端点,或者线下合作的场景——双方将密钥写入合同中,线下传递。

不过对于密钥,还是建议经常的更换,密钥的po解是一个耗时的过程,长时间不变的密钥,无遗对攻击者创造了po解的机会,当有一天攻击者po解了密钥,灭顶之灾也就来到。

说了这么多的对称加密算法,还没有说对称加密算法有哪些,比较常用的对称加密算法有DES/3DES/AES/IDEA/RC4/RC2等。其加密强度,可以从其支持的密钥长度看出,密钥越长,加密强度越好;同时,加密过程越慢。

8

6、非对称加密算法介绍

6.1 基本

对称加密算法指加密解密用同一密钥,那么非对称加密就是加密解密用不同的密钥。

加密算法一次生成两个密钥,一个叫做公钥,一个较为密钥。公钥加密的数据,用密钥解密;密钥加密的数据,用公钥来解密(有些非对称加密算法,只能用密钥加密,公钥解密,或只能用密钥加密,公钥解密)。

非对称加密算法的确神奇,其理论的基础来自于数论。例如RSA算法建立在数论中的“大数分解和素数检测”的理论基础上。而ElGamal和ECC算法基于的则是数论中的“离散对数问题”。数学中的最后一个未找到应用场景的分支学科——数论,终于在加密学领域,找到了应用场景,这不得不说是个奇迹。

非对称加密算法的加入,使得加密算法得以真正的完整,他有这举足轻重的作用。他很好的解决了对称加密算法的缺陷。

6.2 通讯模型

客户端要将数据data发送给服务器端,客户端向服务器端发起对话请求,服务器端生成一对密钥——公钥Gkey和私钥Skey。将Gkey发送给客户端,客户端使用Gkey对数据data进行加密,获得密文C,将C发给服务器端,服务器端使用自己的Skey解密,获得数据data,完成后续业务逻辑。

9

从上面的通讯模型中可以看到,在网络中传输的只有密文C、和公钥Gkey。而私钥Skey不会在网络中传输,攻击者只能获取到公钥,无法对解密密文C,也就保证了数据的安全性。

详细的分析下通讯中面临的四种威胁:

  • 1)截获:同样网络中传输的是密文,即时被截获,攻击者没有私钥,也无法解析密文。所以可以很好的防范截获威胁;
  • 2)中断:对于针对可用性的攻击,由于一般都是基于底层协议的攻击,所以一般很难防范;
  • 3)篡改:由于数据是密文传输的,攻击者没有私钥,无法解析,更无法伪造了;
  • 4)伪造:对于数据的伪造,和摘要算法一样,可以防范,但对于伪造的发送方,对称加密算法和摘要算法一样,比较的无力。
10

和对称加密算法一样,只能对通信中的截获、篡改有防范作用,对其他两个中断、伪造威胁都无法防范。而由于非对称加密算法,很好的解决了对称加密算法中密钥交换的问题,所以其有着很不错的应用场景,可以说是一种通用的加密模型。

6.3 算法优缺点

那么非对称加密算法就没有缺点吗?

也不是。首先,我们看上面的通讯模型,他比对称加密算法的通讯模型来的复杂,存在着两次请求/响应。此外,非对称加密算法的计算可能会很慢,比对称加密算法来慢得多。所以,非对称加密算法在解决了对称加密算法的缺陷后,存在着一些性能问题,比较通用的解决办法是将两种加密算法进行结合——先使用非对称加密算法传递临时的对称加密算法的密钥,密钥传递完成后,再使用更快的对称加密算法来进行真正的数据通信。

典型的非对称加密算法有RSA/ElGamal/ECC算法,除了这两个算法外,还有一个DH算法,其比较的另类,其设计的初衷就是解决对称加密算法中密钥安全交换的问题。

其通讯模型如下:

所有客户端生成一堆公钥CGkey和私钥CSkey,将AGkey发给服务器端。服务器端通过AGkey生成服务器端的公钥SGkey和私钥SSkey,并将SGkey发还给客户端。客户端通过CSkey与SGkey生成对称加密算法的密钥key,服务器端通过CGkey和SSkey生成相同的密钥key。后续客户端和服务器端都是用各自的密钥key来通信。

11

不得不说,这又是一个多么神奇的算法。但是他的确存在。并且早于其他的非对称加密算法。

7、数字签名介绍

7.1 基本

以上三种算法都有防篡改的功能,但摘要算法、和对称加密算法若要防篡改,则需要交换密钥,这又是一件麻烦事儿。所以一般在单纯的防篡改的需求上,都是使用非对称加密算法。但若是对整个明文进行加密的话,加密过程势必消耗大量时间,所以就诞生了数字签名。

数字签名,本质上就是非对称加密算法,但出于解密运行效率的考虑,并是不对明文进行加密,而是对明文的摘要加密,生成“数字串”,并将“数字串”附在明文之后。

数字签名实际上是非对称加密算法的一个妥协方案,为了提高加解密的效率,舍弃了非对称加密算法对截获威胁的优势。

7.2 通讯模型

先来看非对称加密算法的第一种通讯模型,由客户端生成一堆密钥——公钥Gkey和私钥Skey,并使用Skey对明文data进行加密,获得密文C。将C与Gkey发送给服务器端,服务器端使用Gkey对C进行解密。

12

这种通讯模型,只需要一次请求/响应过程,但却无法防范截获威胁,由于最后的密文C的解密用的是公钥Gkey,而Gkey在通过网络传递,所以攻击者可以很方便的对数据进行截获、解密,获得明文data。但这种通讯模型,对于数字签名的场景正合适,数字签名的场景并不准备防范“截获”威胁。

那么下面来看下完整的数字签名的通讯模型:服务器端生成一堆密钥,公钥Gkey和私钥Skey,在将明文data进行摘要,获得摘要串Z1,使用私钥对Z1加密,获得密文C,将C,data,Gkey发给服务器端,服务器端使用Gkey解密后获得Z1,重新根据data计算出摘要Z2,通过比较Z1是否等于Z2来判断数据是否被篡改。

13

以上的模型主要由两个步骤组成,摘要与非对称加密算法的应用。

平常我们经常用到的签名算法,也是这两种算法的组合,比如:

  • 1)SHA1wthRSA,使用SHA1来做摘要,RSA做未对称加密;
  • 2)MD5withRSA,使用MD5做摘要算法,RSA做未对称加密;
  • 3)SHA1withDSA,DSA是ElGamal算法的一种改进。

8、数字证书介绍

8.1 基本

上面说了这么多算法,又是摘要算法,又是对称加密算法,又是非对称加密算法的。但是对于通讯中的四种威胁——截获、中断、篡改、伪造最多也就只能解决其中的两个,对于中断、和伪造威胁,只能干瞪眼。难道,就没有其他办法了吗。

对于中断,一般是网络拓扑或协议级别要解决的问题,已经超出了我们的范畴,暂时不表,我们只能做到的是当网络不可用时,传输的数据出现丢包或异常时可以进行及时的建设,这里就需要用到数据完整性的验证了。

至于,要对付攻击者“伪造”的威胁,这不仅仅是单一算法层面可以解决的问题了。

8.2 通讯模型

正如上面几节所说,伪造分为两种,一种是数据伪造,只要做好防篡改的工作,数据伪造都可以很好的防范。另外一种是伪装成某一网站,与用户进行交互,盗取用户的一些信。比较常见的如钓yu网站、黑代理服务器等。

哪非对称加密算法的通讯模型来举个例子。客户端A在获得给自己公钥时,并没有怀疑与公钥发出方的身份,客户端A以为发给他的依然B,实际上,B发出的公钥已经被攻击者C拦截并丢弃了,C重新生成公钥伪装为B发给了客户端,后续的流程实际上都是攻击者C在于客户端A通讯,而客户端A则以为与自己通讯的是服务器B。

14

这个伪造的过程在平时我们的生活中也经常会碰见,比如:在实名制以前,张三买到火车票后,半路被人da劫,车票被抢。这就有点类似于遭遇了攻击者的攻击,攻击者抢走了张三的火车票(公钥Gkey),并伪造了一张可以以将乱真的车票,(重新生成公钥Gkey)使用这张车票上火车。整个过程看似天衣无缝,攻击者获得了一张免费的车票,张三损失了一张火车票。

当然,现在这种火车票qiang劫的事件已经不太会发生了,因为已经实行了实名制。实名制的引入,给我们解决上面的“伪造”威胁提供了一个方案。火车票实名制,使用了身份证作为验证用户身份的一个证明。那么我们在网络通讯中是否也可以引入这么个“网站身份证”呢。回答是肯定的,目前也正是这么做的,我们叫他“数字证书”。

8.3 CA

正如我们身份证是由可信任的gong an 局办发。数字证书也是由权威机构签发,我们叫做CA,CA会保证证书的确是发给了应该得到该证书的的人。CA也属于一个机构,他也有被人伪造的风险。所以CA一般是分级的,顶层的叫做RootCA,由他保证下面的CA的身份。

所以我们的机器里,保存着有限的几个RootCA的机构的公钥。打个比方,张三有个数字证书,是由A这个CA机构颁发的,A的身份由RootCA来保证。当浏览器与张三的网站进行通讯时,获取到了张三的数字证书,实际上这个数字证书是个嵌套的证书,里面包含着两个子证书:RootCA颁发给A的证书,和A颁发给张三网站的证书。在浏览器中保存着有限个着RootCA的公钥。使用RootCa的公钥对A证书进行验证,验证通过,使用A证书里的公钥对张三网站的证书进行验证,只有再次验证通过后,才能说张三网站的证书得到了确认。

整个验证过程是一个信任链。

15

数字证书里主要包含着两样东西:数字证书所有者的身份信息,数字证书所有者的公钥。为了保证证书在网络中通信不被篡改,证书里会带上这些信息的数字签名。那么对数字证书的验证就是对数字签名的验证,这就是上图中每次证书的验证都要使用到公钥的原因了。

9、参考资料

[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] 基于Netty的IM聊天加密技术学习:一文理清常见的加密概念、术语等

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

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

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

[17] 零基础IM开发入门(五):什么是IM系统的端到端加密?

10、IM安全系列文章

本文是IM通讯安全知识系列文章中的第 3 篇,总目录如下:

即时通讯安全篇(一):正确地理解和使用Android端加密算法

即时通讯安全篇(二):探讨组合加密算法在IM中的应用

即时通讯安全篇(三):常用加解密算法与通讯安全讲解》(本文)

即时通讯安全篇(四):实例分析Android中密钥硬编码的风险

即时通讯安全篇(五):对称加密技术在Android上的应用实践

即时通讯安全篇(六):非对称加密技术的原理与应用实践

即时通讯安全篇(七):用JWT技术解决IM系统Socket长连接的身份认证痛点

即时通讯安全篇(八):如果这样来理解HTTPS原理,一篇就够了

即时通讯安全篇(九):你知道,HTTPS用的是对称加密还是非对称加密?

即时通讯安全篇(十):为什么要用HTTPS?深入浅出,探密短连接的安全性

即时通讯安全篇(十一):IM聊天系统安全手段之通信连接层加密技术

即时通讯安全篇(十二):IM聊天系统安全手段之传输内容端到端加密技术

即时通讯安全篇(十三):信创必学,一文读懂什么是国密算法

即时通讯安全篇(十四):网络端口的安全防护技术实践

即时通讯安全篇(十五):详解硬编码密码的泄漏风险及其扫描原理和工具


(本文已同步发布于:http://www.52im.net/thread-219-1-1.html)

posted @ 2025-09-25 11:58 Jack Jiang 阅读(4) | 评论 (0)编辑 收藏

本文由腾讯云架构师技术同盟策划,作者章为忠,原题“如何设计一个企业级消息推送系统架构?”,下文有修订和重新排版。

1、引言

想象一下这样的场景:随着企业规模扩大,业务系统日益增多,而几乎每个系统都包含消息通知的功能模块。此时,各业务系统不得不重复开发消息推送功能,不仅耗费大量人力与时间成本,功能质量也难以统一保障。更麻烦的是,邮件、短信、企业微信等推送渠道各自为战,推送效果参差不齐不说,还让管理工作陷入混乱。加之不同渠道的消息分散在各处,员工稍不留意就可能错过重要通知,影响工作效率与决策及时性。

如果你是技术负责人,该如何搭建一套能解决这些问题的企业级统一消息推送平台?今天我们就从核心挑战出发,拆解一套可落地的统一推送服务架构方案。

1

技术交流:

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

(本文已同步发布于:http://www.52im.net/thread-4863-1-1.html)

2、面临的技术挑战

在动手画图做方案之前,我们必须先明确设计一个消息推送系统面临哪些核心挑战。

这些是架构设计的关键所在:

1)多渠道集成难题:邮件、短信、企业微信等渠道的接口规范和推送逻辑存在较大差异,如何将它们完美集成?这背后需要解决接口适配、协议转换等底层问题。

2)高并发与高性能要求:随着业务的增长或是促销活动期间,消息量可能从日均 10 万飙升至 100 万,系统必须能够扛住高并发,保证 “推得快、不卡顿”,同时要具备足够大的吞吐量和足够低的延迟。

3)可靠性与可用性要求:核心消息(订单提醒、会议通知等)一旦丢失或重复发送都会造成严重问题,因此必须确保100% 送达;系统还需实现 7×24 小时不间断运行,杜绝单点故障。

4)灵活的模板与个性化推送:不同的业务需要配置不同的消息模版(营销活动需要活泼的模板,财务通知则需要严谨的格式);此外,还要能够根据用户偏好进行推送(例如用户只查看企业微信消息),以提高触达效果。

5)易于集成与扩展:各业务系统要能够 “即插即用” 地接入推送服务;而且,未来新增渠道、新业务时,需要确保无需对平台进行大规模修改就能快速支持。

在深入了解当前消息推送工作中存在的各类问题与潜在挑战之后,我们再来梳理一条消息从发送到接收都经历了哪些过程和处理?推送系统在企业整体架构中处于什么位置?请接着往下读。。。

3、系统架构核心流程解析(消息推送的全链路步骤)

2

消息推送从发起至接收的核心流程步骤如下:

第1步:在各应用系统发送通知内容到消息网关;既可以单条推送,也可以支持批量推送;例如常见的订单通知和支付通知。

第2步:接下来,由消息网关转发到消息分发服务,在这一层,将会对消息进行验证、确定好优先级、套用格式模板(这里对应在后台维护一个模板库)和确定发送的时间。

第3步:进入到消息路由,也就是技术上常说的异步消息队列。

第4步:通过各个消息渠道,进行具体的消息发送,如:APP站内通知/邮件通知/短信通知/社交账号通知/办公群通知等。

第5步:通知的发送记录和状态,以及统计分析(例如同一个账号同一天发送多少条)。

第6步:就是整体的推送统计,例如:每周总共发送多少次、触达多少用户、打开阅读量有多少、转化多少,从而不断提升你产品的用户体验。

4、推送系统在全局系统架构中的位置

从架构结构来看,一个复杂业务平台通常涵盖表现层、接入层、应用层、服务层(含中台)及基础层等核心模块。作为业务系统中不可或缺的组成部分,推送服务并不直接面向终端用户,而是支撑各类应用稳定运行的基础性服务。

它在整体架构中的具体位置如下所示:

3

(▲ 图中红色部分为统一消息推送平台)

5、 推送系统整体架构设计

5.1 概述

接下来将正式启动并着手设计一套更为完整、系统且具备可扩展性的统一消息推送架构体系。平台采用「接入层 - 业务层 - 服务层 - 数据存储」的四层架构,通过各层协同实现消息推送的标准化与高效化。

具体架构如下图所示:

4

上图展示了统一推送平台的整体架构。每一层的功能和作用将在下面的小节中分别介绍。

5.2 接入层

作为外部请求进入系统的第一道关口,接入层核心作用是「过滤无效请求,筑牢系统安全防线」。

这一层通过 API 网关集中管理所有推送请求,重点完成三项管控:

1)身份验证:仅授权业务系统凭有效凭证调用,阻断非法访问。

2)权限校验:按规则限定不同系统的推送渠道,比如 A 系统可用短信、B 系统仅开放企业微信,避免越权。

3)流量控制:设置阈值(如单系统每秒最多发 1000 条)实现削峰,防范攻击或突发流量压垮系统。

举例来说:营销系统调用推送接口时,API 网关会先验 token 有效性,确认其有短信和邮件权限后,再限制请求频率,确保消息推送节奏在系统承载范围内,从接入环节保障流程安全稳定。

5.3 业务层

负责解析请求、做核心决策,是业务规则的集中处理中心。

收到请求后,先解析内容:要推给谁?用什么模板?什么时候推?优先级高不高?

比如:收到订单系统「订单支付成功」的推送请求,会先匹配「支付通知」模板,确定接收人,设为消息推送的优先级「高」(必须立即推),再判断发送渠道,调用对应的消息推送服务。

5.4 服务层

集成所有推送渠道,把统一格式的消息「翻译」成各渠道能识别的格式。

核心是「适配器模式」:每个渠道对应一个适配器(如短信适配器、企业微信适配器),适配器负责格式转换和接口调用。

比如:企业微信适配器,会把业务逻辑层生成的消息,按企业微信 API 要求的格式组装(加签名、填应用 ID),再调用企业微信的接口发送。需要接入新渠道时,只需开发一个对应的适配器即可,不用改其他层,扩展性拉满。

5.5 数据存储层

数据存储层主要是对全流程数据、消息进行系统化管理。

即存储原始消息内容、推送参数等业务数据,也记录各环节的处理日志、渠道反馈结果与用户交互行为数据。

通过统一的数据模型与存储规范,为后续的推送效果分析、业务优化与数据追溯提供可靠的数据支撑,形成 “接入 - 处理 - 分发 - 存储” 的闭环管理体系。

6、推送系统技术架构设计

6.1 应用集成架构

业务系统(ERP、OA、CRM、IM聊天、客服系统等)通过接口方式接入统一消息平台,能够接入短信、邮件、站内信、企业微信等多种信息渠道,支持以操作界面形式实现统一消息发送。可通过平台界面,编辑消息内容或引用消息模板,实现信息的多渠道统一发送。

平台应用集成架构如下图所示:

5

6.2 平台技术架构

我们将整个平台系统拆解为多个关键服务模块,比如:

  • 1)消息融合接收服务;
  • 2)消息处理分发服务;
  • 3)消息模版服务;
  • 4)渠道发送服务;
  • 5)后台管理服务等。

这些服务模块全面覆盖从请求接入到消息推送、再到后续分析的全流程。

完整的技术架构图如下:

6

7、 本文小结

企业级统一基础推送服务,是一个通用特性,适用于所有现代分布式应用,无论采用何种编程语言和技术。通过统一推送服务解决分散推送的痛点,避免了开发重复造轮子,消息更精准、渠道更符合偏好、关键消息不丢失、系统不宕机。让消息真正成为业务运转的助力而非负担。

不过在实际落地时,需结合企业规模灵活调整:若企业仅部署少数几个业务系统,单独搭建完整的推送系统反而可能造成资源浪费,此时选择轻量化的集成方案会更具性价比。

8、 参考资料

[1] 极光推送系统大规模高并发架构的技术实践分享

[2] 魅族2500万长连接的实时消息推送架构的技术实践分享

[3] 专访魅族架构师:海量长连接的实时消息推送系统的心得体会

[4] 一个基于长连接的安全可扩展的订阅/推送服务实现思路

[5] 实践分享:如何构建一套高可用的移动端消息推送系统?

[6] Go语言构建千万级在线的高并发消息推送系统实践(来自360公司)

[7] 腾讯信鸽技术分享:百亿级实时消息推送的实战经验

[8] 百万在线的美拍直播弹幕系统的实时推送技术实践之路

[9] 京东京麦商家开放平台的消息推送架构演进之路

[10] 解密“达达-京东到家”的订单即时派发技术原理和实践

[11] 技术干货:从零开始,教你设计一个百万级的消息推送系统

[12] 长连接网关技术专题(四):爱奇艺WebSocket实时推送网关技术实践

[13] 喜马拉雅亿级用户量的离线消息推送系统架构设计实践

[14] 微信直播聊天室单房间1500万在线的消息架构演进之路

[15] 百度直播的海量用户实时消息系统架构演进实践

[16] 消息推送技术干货:美团实时消息推送服务的技术演进之路

[17] 揭秘vivo百亿级厂商消息推送平台的高可用技术实践

[18] 得物从零构建亿级消息推送系统的送达稳定性监控体系技术实践

[19] B站千万级长连接实时消息系统的架构设计与实践

[20] 转转千万级用户量消息推送系统的架构演进之路


(本文已同步发布于:http://www.52im.net/thread-4863-1-1.html)

posted @ 2025-09-18 14:05 Jack Jiang 阅读(24) | 评论 (0)编辑 收藏

1、基本介绍

RainbowChat是一套基于开源IM即时通讯聊天框架 MobileIMSDK 的产品级移动端IM系统RainbowChat源于真实运营的产品,解决了大量的屏幕适配、细节优化、机器兼容问题。RainbowChat可能是市面上提供im即时通讯聊天源码的,唯一一款同时支持TCP、UDP两种通信协议的IM产品。与姊妹产品RainbowTalkRainbowChat-Web 技术同源,历经考验。

 详细介绍:http://www.52im.net/thread-19-1-1.html
 版本日志:http://www.52im.net/thread-2735-1-1.html
 运行截图:iOS端全部运行截图 (另:Android端运行截图 点此查看
 下载体验:App Store安装地址 (另:Android端下载体验 点此查看

app_store

2、MobileIMSDK开源工程

2

MobileIMSDK 是一套专门为移动端开发的开源IM即时通讯框架,超轻量级、高度提炼,一套API优雅支持UDP 、TCP 、WebSocket 三种协议,支持iOS、Android、H5、小程序、Uniapp、标准Java平台,服务端基于Netty编写。

工程同步开源地址:

3、v10.0 版更新内容

此版更新内容更多历史更新日志):

  • 1)[新增] 新增了短信验证码的注册和登录功能;
  • 2)[新增] 新增了“发现”页面;
  • 3)[新增] 增加了聊天界面中未读消息数ui的显示;
  • 4)[bug] 解决了iOS18.5中查看图片会导致APP崩溃的问题;
  • 5)[bug] 解决了两个表情占位符重复的问题;
  • 6)[bug] 解决了某些情况下删除表情导致APP崩溃的问题;
  • 7)[bug] 解决了搜索聊天记录的关键字英文字母时因大小写导致高亮不显示的问题;
  • 8)[bug] 解决了转发消息完成后,总是自动滚动到最后一行的问题;
  • 9)[优化] 现在不能删除首页列表中的“确认提醒”这个item了;
  • 10)[优化] 优化了存在多条置顶消息消息的情况下,没有按置顶时间而是消息时间排序的问题;
  • 11)[优化] 登录和退出登录接口中废弃了osType字段;
  • 12)[优化] 只有好友才能查看对方的注册和登录时间;
  • 13)[优化] 优化了聊天记录分页加载逻辑,在大量消息情况下提升性能;
  • 14)[优化] 优化了极端情况下聊天记录加载时同一秒内收发的消息存在顺序问题;
  • 15)[优化] 群聊中优化了消息发送者昵称的显示;
  • 16)[优化] 优化了在iOS18模拟器上从相册选择图片时相册是空的问题;
  • 17)[优化] 查找好友时不再显示在线状态;
  • 18)[优化] 根据当前主流审美潮流优化了诸多界面的UI细节。

4、部分功能运行截图预览

(☞ 更多截图点此查看 ☜)

4.1 登陆和注册等:6_logins

4.2 首页等主要界面:

7_main_tabs

4.3 “我的”、“个人中心”等页面:

8_my_profiles

4.4 好友关系等:

9_sns

4.5 陌生人聊天:

10_chat_guest

4.6 好友聊天:

11_chat_friend

4.7 世界频道聊天(相当于在线聊天):

12_bbs

4.8 群聊:

13_chat_group

4.9 大文件消息:

14_big_file

4.10 短视频消息:

4.11 名片消息:

16_contact

4.12 位置消息:

17_location

4.13 “扫一扫”功能:

18_scan

4.14 “搜索”功能:

19_search

4.15 “群名片”功能:

20_group_card

4.16 “消息转发”功能:

21_forward

4.17 “消息引用”功能:

24_quote

4.18 “@”功能:

23_at

4.19 “消息撤回”功能:

25_revoke

posted @ 2025-09-16 12:51 Jack Jiang 阅读(26) | 评论 (0)编辑 收藏

本文由转转技术李帅分享,原题“转转客服IM的WebSocket集群部署方案”,下文有修订和重新排版。

1、引言

转转作为国内头部的二手闲置交易平台,拥有上亿的用户。用户在使用转转app遇到问题时,一般可以通过在线客服、热线电话等方式联系转转客服并解决问题。

客服IM系统是转转自研的在线客服系统,是用户和转转客服沟通的重要工具,主要包括机器人客服、人工客服、会话分配、技能组管理等功能。在这套系统中,我们使用了很多开源框架和中间件,今天讲一下客服IM系统中WebSocket集群的的实践和应用。

技术交流:

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

(本文已同步发布于:http://www.52im.net/thread-4860-1-1.html)

2、快速认识WebSocket

2.1 WebSocket 诞生背景

早期,很多网站为了实现推送技术,所用的技术都是轮询(也叫短轮询)。轮询是指由浏览器每隔一段时间向服务器发出 HTTP 请求,然后服务器返回最新的数据给客户端。

常见的轮询方式分为轮询与长轮询,它们的区别如下图所示:

1

 

为了更加直观感受轮询与长轮询之间的区别,我们来看一下具体的代码:

2

这种传统的模式带来很明显的缺点,即浏览器需要不断的向服务器发出请求,然而 HTTP 请求与响应可能会包含较长的头部,其中真正有效的数据可能只是很小的一部分,所以这样会消耗很多带宽资源。

PS:关于短轮询、长轮询技术的前世今身,可以详细读这两篇:《新手入门贴:史上最全Web端即时通讯技术原理详解》、《Web端即时通讯技术盘点:短轮询、Comet、Websocket、SSE》。

比较新的轮询技术是 Comet。这种技术虽然可以实现双向通信,但仍然需要反复发出请求。而且在 Comet 中普遍采用的 HTTP 长连接也会消耗服务器资源。

在这种情况下,HTML5 定义了 WebSocket 协议,能更好的节省服务器资源和带宽,并且能够更实时地进行通讯。

Websocket 使用 ws 或 wss 的统一资源标志符(URI),其中 wss 表示使用了 TLS 的 Websocket。

如:

ws://echo.websocket.org

wss://echo.websocket.org

WebSocket 与 HTTP 和 HTTPS 使用相同的 TCP 端口,可以绕过大多数防火墙的限制。

默认情况下:

  • 1)WebSocket 协议使用 80 端口;
  • 2)若运行在 TLS 之上时,默认使用 443 端口。

2.2 WebSocket 简介

WebSocket 是一种网络传输协议,可在单个 TCP 连接上进行全双工通信,位于 OSI 模型的应用层。WebSocket 协议在 2011 年由 IETF 标准化为 RFC 6455,后由 RFC 7936 补充规范。

WebSocket 使得客户端和服务器之间的数据交换变得更加简单,允许服务端主动向客户端推送数据。在 WebSocket API 中,浏览器和服务器只需要完成一次握手,两者之间就可以创建持久性的连接,并进行双向数据传输。

介绍完轮询和 WebSocket 的相关内容之后,接下来用一张图看一下 XHR Polling(短轮询) 与 WebSocket 之间的区别。

XHR Polling与 WebSocket 之间的区别如下图所示:

3

2.3 WebSocket 优点

普遍认为,WebSocket的优点有如下几点:

  • 1)较少的控制开销:在连接创建后,服务器和客户端之间交换数据时,用于协议控制的数据包头部相对较小;
  • 2)更强的实时性:由于协议是全双工的,所以服务器可以随时主动给客户端下发数据。相对于 HTTP 请求需要等待客户端发起请求服务端才能响应,延迟明显更少;
  • 3)保持连接状态:与 HTTP 不同的是,WebSocket 需要先创建连接,这就使得其成为一种有状态的协议,之后通信时可以省略部分状态信息;
  • 4)更好的二进制支持:WebSocket 定义了二进制帧,相对 HTTP,可以更轻松地处理二进制内容;
  • 5)可以支持扩展:WebSocket 定义了扩展,用户可以扩展协议、实现部分自定义的子协议。

由于 WebSocket 拥有上述的优点,所以它被广泛地应用在即时通讯/IM、实时音视频、在线教育和游戏等领域。

对于前端开发者来说,要想使用 WebSocket 提供的强大能力,就必须先掌握 WebSocket API,下面带大家一起来认识一下 WebSocket API。

PS:如果你想要更浅显的WebSocket入门教程,可以先读这篇《新手快速入门:WebSocket简明教程》后,再回来继续学习。

3、WebSocket的易错常识

3.1 WebSocket 与 HTTP 有什么关系?

WebSocket 是一种与 HTTP 不同的协议。两者都位于 OSI 模型的应用层,并且都依赖于传输层的 TCP 协议。

虽然它们不同,但是 RFC 6455 中规定:WebSocket 被设计为在 HTTP 80 和 443 端口上工作,并支持 HTTP 代理和中介,从而使其与 HTTP 协议兼容。 为了实现兼容性,WebSocket 握手使用 HTTP Upgrade 头,从 HTTP 协议更改为 WebSocket 协议。

既然已经提到了 OSI(Open System Interconnection Model)模型,这里分享一张很生动、很形象描述 OSI 模型的示意图(如下图所示)。

4

(图片引用自:https://www.networkingsphere.com/2019/07/what-is-osi-model.html

当然,WebSocket与HTTP的关系显然不是这三两句话可以说的清,有兴趣的读者可以详读下面这两篇:

  1. WebSocket详解(四):刨根问底HTTP与WebSocket的关系(上篇)
  2. WebSocket详解(五):刨根问底HTTP与WebSocket的关系(下篇)

3.2 WebSocket 与长轮询有什么区别?

长轮询就是:客户端发起一个请求,服务器收到客户端发来的请求后,服务器端不会直接进行响应,而是先将这个请求挂起,然后判断请求的数据是否有更新。如果有更新,则进行响应,如果一直没有数据,则等待一定的时间后才返回。

长轮询的本质还是基于 HTTP 协议,它仍然是一个一问一答(请求 — 响应)的模式。而 WebSocket 在握手成功后,就是全双工的 TCP 通道,数据可以主动从服务端发送到客户端。

5

要理解WebSocket 与长轮询的区别,需要深刻理解长轮询的技术原理,以下3篇中有关长轮询的技术介绍建议深入阅读:

  1. Comet技术详解:基于HTTP长连接的Web端实时通信技术
  2. 新手入门贴:史上最全Web端即时通讯技术原理详解
  3. Web端即时通讯技术盘点:短轮询、Comet、Websocket、SSE
  4. 网页端IM通信技术快速入门:短轮询、长轮询、SSE、WebSocket

3.3 什么是 WebSocket 心跳?

网络中的接收和发送数据都是使用 Socket 进行实现。但是如果此套接字已经断开,那发送数据和接收数据的时候就一定会有问题。

可是如何判断这个套接字是否还可以使用呢?这个就需要在系统中创建心跳机制。

所谓 “心跳” 就是定时发送一个自定义的结构体(心跳包或心跳帧),让对方知道自己 “在线”,以确保链接的有效性。

而所谓的心跳包就是客户端定时发送简单的信息给服务器端告诉它我还在而已。代码就是每隔几分钟发送一个固定信息给服务端,服务端收到后回复一个固定信息,如果服务端几分钟内没有收到客户端信息则视客户端断开。

在 WebSocket 协议中定义了 心跳 Ping 和 心跳 Pong 的控制帧:

  • 1)心跳 Ping 帧包含的操作码是 0x9:如果收到了一个心跳 Ping 帧,那么终端必须发送一个心跳 Pong 帧作为回应,除非已经收到了一个关闭帧。否则终端应该尽快回复 Pong 帧;
  • 2)心跳 Pong 帧包含的操作码是 0xA:作为回应发送的 Pong 帧必须完整携带 Ping 帧中传递过来的 “应用数据” 字段。

针对第2)点:如果终端收到一个 Ping 帧但是没有发送 Pong 帧来回应之前的 Ping 帧,那么终端可以选择仅为最近处理的 Ping 帧发送 Pong 帧。此外,可以自动发送一个 Pong 帧,这用作单向心跳。

PS:这里有篇WebSocket心跳方面的IM实战总结文章,有兴趣可以阅读《Web端即时通讯实践干货:如何让你的WebSocket断网重连更快速?》。

3.4 Socket 是什么?

网络上的两个程序通过一个双向的通信连接实现数据的交换,这个连接的一端称为一个 Socket(套接字),因此建立网络通信连接至少要一对端口号。

Socket 本质:是对 TCP/IP 协议栈的封装,它提供了一个针对 TCP 或者 UDP 编程的接口,并不是另一种协议。通过 Socket,你可以使用 TCP/IP 协议。

百度百科上关于Socket的描述是这样:

Socket 的英文原义是“孔”或“插座”:作为 BSD UNIX 的进程通信机制,取后一种意思。通常也称作”套接字“,用于描述IP地址和端口,是一个通信链的句柄,可以用来实现不同虚拟机或不同计算机之间的通信。

在Internet 上的主机一般运行了多个服务软件,同时提供几种服务。每种服务都打开一个Socket,并绑定到一个端口上,不同的端口对应于不同的服务。Socket 正如其英文原义那样,像一个多孔插座。一台主机犹如布满各种插座的房间,每个插座有一个编号,有的插座提供 220 伏交流电, 有的提供 110 伏交流电,有的则提供有线电视节目。 客户软件将插头插到不同编号的插座,就可以得到不同的服务。

关于 Socket,可以总结以下几点:

  • 1)它可以实现底层通信,几乎所有的应用层都是通过 socket 进行通信的;
  • 2)对 TCP/IP 协议进行封装,便于应用层协议调用,属于二者之间的中间抽象层;
  • 3)TCP/IP 协议族中,传输层存在两种通用协议: TCP、UDP,两种协议不同,因为不同参数的 socket 实现过程也不一样。

下图说明了面向连接的协议的套接字 API 的客户端/服务器关系:

6

PS:要说WebSocket和Socket的关系,这篇《WebSocket详解(六):刨根问底WebSocket与Socket的关系》有专门进行详细分享,建议阅读。

4、选择WebSocket协议

IM是实时通信(Instant Messaging)的简称,实时是IM系统的基本要求(详见《什么是IM系统的实时性?》)。在客服系统中,用户和客服实时收发消息,是最基础、最重要的功能。

WebSocket(以下简称ws)是一种在单个TCP连接上进行全双工通信的协议,允许服务端主动向客户端推送数据。能够以较小的开销,实现更强的实时性。因此客服IM系统采用了ws协议,实现了服务端同时接收与发送数据的能力。

5、WebSocket服务的集群式部署

在实际生产环境中,我们不可能使用单台服务器做ws服务,一旦出现问题就是毁灭性的,所以我们会使用集群式部署ws服务。

ws协议是全双工通信协议,可以双向通信的,部署多台机器后,如下图所示,不同用户会分别和不同的机器连接,A如何向C发送消息呢?

7

具体是:

  • 1)我们在nginx配置中,将ws服务的负载均衡策略设置为ip_hash,保证用户在IP不变的情况,一直分配在一个固定服务器上;
  • 2)用户与ws服务建立连接后,获取当前机器hostname,将用户uid与机器hostname关系存储在redis中;
  • 3)每个ws服务都维护了一个独立的consumer,采用广播消费模式,仅消费属于自己tag的消息,tag即为当前机器hostname。
8

6、IM消息在集群架构下发送流程

IM消息在当前集群架构下的发送流程是这样的。

1)用户A在向用户C发送消息时,用户A将消息发送给ws-1服务器,ws-1服务接收消息后,从redis中获取用户C的连接信息。

2)ws-1服务器拿到用户C和ws-2的关系后,设置mq消息tag="ws-2",直接将用户消息通过mq发送出去。

3)ws-2服务器的consumer接收到对应mq消息后,即可通过ws连接将消息推送用户C 至此,我们就完成了一条消息的发送与接收。

关于集群架构下IM实例间的消息可靠投递,也可以详细参考下面的资料:

  1. 闲鱼亿级IM消息系统的可靠投递优化实践
  2. 融云技术分享:全面揭秘亿级IM消息的可靠投递机制
  3. 一套亿级用户的IM架构技术干货(上篇):整体架构、服务拆分等
  4. 一套亿级用户的IM架构技术干货(下篇):可靠性、有序性、弱网优化等

7、集群架构下的断线重连逻辑

网络环境错综复杂,难免会有网络掉线、网络环境切换的情况,都会导致用户和ws服务的连接发生变化。

一个比较典型的场景就是C端用户网络在4G和wifi之间进行切换,会导致ip变化,从而可能到导致用户和另外的ws服务再次建立连接。这种情况可能会导致消息重复发送、以及额外的资源消耗,所以要尽量避免。

处理方式如下:

  • 1)即时清理:用户与ws服务建立连接时,当前ws服务查询redis中存储的用户连接信息。当连接信息与当前ws服务不一致时,当前ws服务更新redis存储信息、并发出广播mq消息,通知其他ws服务关闭与当前用户的连接通道。
  • 2)定时清理:除此之外,还需要前端同学配合,定时向连接的ws服务发送心跳消息,ws服务定时检测用户连接的心跳情况,关闭废弃的用户连接。

关于WebSocket的断线快速重连,这里还有篇文章可一并阅读:《Web端即时通讯实践干货:如何让你的WebSocket断网重连更快速?》。

8、本文小结

以上就是我们在客服IM系统中使用WebSocket协议实现的消息收发的主要流程。要实现一个完整的IM系统,不仅要保证消息的实时性,消息的一致性、顺序性也很重要,还有网络异常等情况下的重连、用户心跳检测等,这些功能需要客户端同学一起协作才能完成。

9、参考资料

[1] 网页端IM通信技术快速入门:短轮询、长轮询、SSE、WebSocket

[2] 搞懂现代Web端即时通讯技术一文就够:WebSocket、socket.io、SSE

[3] 万字长文,一篇吃透WebSocket:概念、原理、易错常识、动手实践

[4] WebSocket从入门到精通,半小时就够!

[5] Web端即时通讯实践干货:如何让你的WebSocket断网重连更快速?

[6] 为何基于TCP协议的移动端IM仍然需要心跳保活机制?

[7] 一文读懂即时通讯应用中的网络心跳包机制:作用、原理、实现思路等

[8] 阿里IM技术分享(五):闲鱼亿级IM消息系统的及时性优化实践

[9] 万字长文:手把手教你实现一套高效的IM长连接自适应心跳保活机制

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

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

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

[13] 转转平台IM系统架构设计与实践(二):详细设计与实现

[14] 支持百万人超大群聊的Web端IM架构设计与实践

[15] 一套分布式IM即时通讯系统的技术选型和架构设计

[16] 一套十万级TPS的IM综合消息系统的架构实践与思考

[17] 得物从0到1自研客服IM系统的技术实践之路

[18] 闲鱼亿级IM消息系统的可靠投递优化实践

[19] 融云技术分享:全面揭秘亿级IM消息的可靠投递机制

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

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

[22] 一套高可用、易伸缩、高并发的IM群聊、单聊架构方案设计实践

[23] 什么是IM系统的实时性?


(本文已同步发布于:http://www.52im.net/thread-4860-1-1.html)

posted @ 2025-09-08 13:37 Jack Jiang 阅读(37) | 评论 (0)编辑 收藏

为了更好地分类阅读 52im.net 总计1000多篇精编文章,我将在每周三推送新的一期技术文集,本次是第46 期。

[- 1 -] 微信团队原创分享:Android版微信的臃肿之困与模块化实践之路

[链接] http://www.52im.net/thread-893-1-1.html

[摘要] 本文讲述微信 Android 版架构从分层到多进程、模块化的演进,及因代码膨胀重构模块化的过程与效果。


[- 2 -] 微信后台团队:微信后台异步消息队列的优化升级实践分享

[链接] http://www.52im.net/thread-801-1-1.html

[摘要] 本文分享了该组件2.0版本的功能特点及优化实践,希望能为类似业务(比如移动端IM系统等)的消息队列设计提供一定的参考。


[- 3 -] 微信团队原创分享:微信客户端SQLite数据库损坏修复实践

[链接] http://www.52im.net/thread-789-1-1.html

[摘要] 本文介绍微信客户端 SQLite 数据库损坏的原因,及优化空间占用、文件 sync 和备份 master 表以提升修复率的实践。


[- 4 -] 腾讯原创分享(一):如何大幅提升移动网络下手机QQ的图片传输速度和成功率

[链接] http://www.52im.net/thread-675-1-1.html

[摘要] 本文内容是由腾讯TMQ专项测试团队针对手机QQ图片上传速度和成功率问题,在各种复杂移动网络环境下的优化实践总结和整理而成。文章虽是针对手机QQ图片上传这一特定业务功能,但内容中大量涉及复杂移动网络环境下无线网络的特性、特点以及相关第一手测试数据,都是非常珍贵的,尤其值得移动端IM开发、消息推送这种深度依赖移动网络的应用开发者借鉴和参考。


[- 5 -] 腾讯原创分享(二):如何大幅压缩移动网络下APP的流量消耗(上篇)

[链接] http://www.52im.net/thread-696-1-1.html

[摘要] 该文讲述腾讯某产品因用户投诉背景流量高,经测试分析,通过优化将 24 小时流量降至 100KB 以下的过程。


[- 6 -] 腾讯原创分享(三):如何大幅压缩移动网络下APP的流量消耗(下篇)

[链接] http://www.52im.net/thread-697-1-1.html

[摘要] 本篇中将详细介绍我们的具体分析方法和实践优化思路,以及在优化过程中总结出来的法则等。


[- 7 -] 如约而至:微信自用的移动端IM网络层跨平台组件库Mars已正式开源

[链接] http://www.52im.net/thread-684-1-1.html

[摘要] 微信Mars到底有什么用呢?毫无疑问,微信Mars存在的前提就是为了更好的服务微信这个超级IM而存在,最适合干的活就是开发移动端IM了,当然由于提炼的很好,相信移动端推送技术等都是可以使用微信Mars作为网络层lib来使用,从而以微信的成果为起点开发出拥有更加优秀网络体验的移动端富网络应用。


[- 8 -] 微信Mars:微信内部正在使用的网络层封装库,即将开源

[链接] http://www.52im.net/thread-620-1-1.html

[摘要] 该文介绍微信 Mars 网络层封装库即将开源,涵盖其模块构成、特点、源起及跨平台开发经验。


[- 9 -]  开源libco库:单机千万连接、支撑微信8亿用户的后台框架基石 [源码下载]

[链接] http://www.52im.net/thread-623-1-1.html

[摘要] 该文介绍微信于 2013 年开源的 libco 库,其特性、背景、技术架构及对微信后台并发能力的提升作用。


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

[链接] http://www.52im.net/thread-310-1-1.html

[摘要] 本文将详细介绍基于TLS 1.3的微信新一代通信安全协议mmtls。


[- 11 -] 微信团队原创分享:Android版微信后台保活实战分享(进程保活篇)

[链接] http://www.52im.net/thread-210-1-1.html

[摘要] 该文分享 Android 版微信进程保活实战,包括进程拆分、及时拉起及利用前台服务提升进程优先级等方案。


[- 12 -] 微信团队原创分享:Android版微信后台保活实战分享(网络保活篇) 

[链接] http://www.52im.net/thread-209-1-1.html

[摘要] 该文分享 Android 版微信网络保活实战,包括长连接心跳机制、动态心跳策略及保证消息实时的 notify 机制等。


[- 13 -] Android版微信从300KB到30MB的技术演进(PPT讲稿) [附件下载]

[链接] http://www.52im.net/thread-206-1-1.html

[摘要] ANDROID系统先天的弊端与产品需求研发过程的矛盾,推动着客户端架构演进史。这架车轮不断向前滚动,不断调整进化的架构,在为微信未来的高速成长保驾护航。我们一起来了解微信ANDROID客户端的架构演进过程。


[- 14 -] 微信团队原创分享:Android版微信从300KB到30MB的技术演进

[链接] http://www.52im.net/thread-205-1-1.html

[摘要] 该文讲述 Android 版微信从 300KB 到 30MB 的技术演进,分拓荒、成长、变革、进化、开放五阶段,介绍架构调整与问题解决。


[- 15 -] 如何解读《微信技术总监谈架构:微信之道——大道至简》

[链接] http://www.52im.net/thread-201-1-1.html

[摘要] 该文解读微信技术总监演讲,介绍微信以 “敏捷” 为核心,通过拆分系统、基础组件、监控等实现快速迭代与稳定服务。


👉52im社区本周新文:转转客服IM系统的WebSocket集群架构设计和部署方案,欢迎阅读!👈

我是Jack Jiang,我为自已带盐!https://github.com/JackJiang2011/MobileIMSDK/

posted @ 2025-09-04 12:59 Jack Jiang 阅读(30) | 评论 (0)编辑 收藏

1、引言

网络ping不通是网络中出现频率最高的故障之一,同时也是最让人抓狂的故障,谁没遇到过?今天就和你细说下ping不通的原因,看看能不能和你遇到的情况对上号。

技术交流:

cover-opti

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

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

2、系列文章

本文是系列文章中的第 20篇,本系列文章的大纲如下:

3、ping命令技术原理

了解ping命令原因,我们来通过一个实例来了解。

假定主机A的IP地址是 192.168.1.1 ,主机B的IP地址是 192.168.1.2 ,都在同一子网内,则当你在主机A上运行“Ping 192.168.1.2”后,都发生了些什么呢?

首先:Ping命令会构建一个固定格式的ICMP请求数据包,然后由ICMP协议将这个数据包连同地址“192.168.1.2”一起交给IP层协议(和ICMP一样,实际上是一组后台运行的进程)。

IP层协议将以地址“192.168.1.2”作为目的地址,本机IP地址作为源地址,加上一些其他的控制信息,构建一个IP数据包。并在一个映射表中查找出IP地址192.168.1.2所对应的物理地址(也叫MAC地址,这是数据链路层协议构建数据链路层的传输单元帧所必需的),一并交给数据链路层。

后者构建一个数据帧,目的地址是IP层传过来的物理地址,源地址则是本机的物理地址,还要附加上一些控制信息,依据以太网的介质访问规则,将它们传送出去。

1

主机B收到这个数据帧后,先检查它的目的地址,并和本机的物理地址对比,如符合则接收,否则丢弃。接收后检查该数据帧,将IP数据包从帧中提取出来,交给本机的IP层协议。

同样:IP层检查后,将有用的信息提取后交给ICMP协议,后者处理后,马上构建一个ICMP应答包,发送给主机A,其过程和主机A发送ICMP请求包到主机B一模一样。

直接说:就是利用网络上机器IP地址的唯一性,给目标IP地址发送一个数据包,再要求对方返回一个同样大小的数据包来确定两台网络机器是否连接相通,时延是多少。

上面的过程就是ping命令的原理:主机A收到了主机B的一个应答包,说明两台主机之间的去、回通路均正常,但也并不是所有网络都是正常的,下面我们来看ping不通的原因。

4、同网段ping不通的原因概述

ping命令不通,主要有两种情况:

  • 1)同网段内的ip地址ping不通;
  • 2)不同网段的ip地址ping不通。

各个情况不一样,我们首先来看同网段ping不通的两种情况。

5、同网段ping不通的情况1:“无法访问目标主机”

目的ip和源ip是同一网段的,ping的结果是“无法访问目标主机”,属于ping的请求没有发出。

我们来看下,ping同网段不存的ip地址:

2

ping的请求发出后,返回显示“无法访问目标主机"。

什么原因呢?说明此时ping的需求并没有成功发出。

这时要检查:

  • 1)对方是否开机?ip是否存在?
  • 2)有跨交换机vlan的话,检查对应的中间trunk链路是否导通?
  • 3)走直连路由是否正确?是否应该走默认路由,而走了直连路由;
  • 4)子网掩码是否错误;
  • 5)默认网关是否填写正确。

6、同网段ping不通的情况2:“超时(time out)”

目的ip和源ip是同一网段的,ping的结果是“超时或者time out” ,属于ping的请求已经成功发出了,但目标主机没有回复。

ping的请求发出后,返回显示“超时":

3

什么原因呢?这种情况是ping已经成功发出了,到达了主机,但是没有得到响应

要检查:

  • 1)检查下防火墙,防火墙禁止了对ping的回应;
  • 2)子网掩码的设置错误,导致不在同一个网段;
  • 3)设备硬件故障,导致设备没有对应的mac地址,无法生成路由表,而走默认路由;
  • 4)ip冲突,或ip地址与直联路由不在同一个网段;
  • 5)网关没有设置好。

7、 跨网段ping不通的原因概述

不同网段ping不通,通常的表现有“无法访问目标主机”、“time out”,但具体分析起来其实可能的原因是比较多的,我们还是一起来看下跨网段常见的原因吧。

8、 跨网段ping不通的情况1:“无法访问目标主机”

跨网段出现无法访问目标主机,说明请求没有成功发出,获取不了目的ip地址与mac地址。

4

可能出现的原因是:

  • 1)目的ip地址不存在;
  • 2)检查路由表是否有缺省的路由;
  • 3)检查arp表是否有网关的mac地址;
  • 4)有网关设置错误;
  • 5)走了默认路由。

9、 跨网段ping不通的情况2:“time out”

若显示 time out,表示 ping 的 request 消息已经发出,目的ip的网关已经获取到目的ip的mac地址,但是目的主机没有回复,或源主机无法收到。

这些应该检查回程路由和节点回程路由。

5

可能的原因有:

  • 1)检查下防火墙,是否拦截了ping的请求消息;
  • 2)检查经过节点的路由是否正确,或者是否有回程路由;
  • 3)回程路由的硬件网卡出口和ping的request的入口网卡不是同一个;
  • 4)交换机vlan对应的接口全部down了,导致vlan状态down,vlan的对应路由没有生成。

10、本文小结

当我们网络ping不通时,首先要看ping显示的结果是”无法访问目标主机“还是”超时“,再看是同网段,还是不同网段,采取相应的分析方法。

另外在分析与解决网络故障时,我们要熟练的了解ping、arp、tracert、route这几个命令的用法,可以快速的定位ping不通的原因。

尤其是这arp、tracert、route这三个命令的用法,解决故障非常方便。

11、参考资料

[1] 史上最通俗的集线器、交换机、路由器功能原理入门

[2] 通俗讲解,有了IP地址,为何还要用MAC地址?

[3] 外行也能读懂的网络硬件设备功能原理速成

[4] 每天都在用的Ping命令,它到底是什么?

[5] 能Ping通,TCP就一定能连接和通信吗?

[6] 什么是公网IP和内网IP?NAT转换又是什么鬼?

[7] 假如你来设计网络,会怎么做?

[8] 你真的了解127.0.0.1和0.0.0.0的区别?

[9] 一文搞懂localhost和127.0.0.1

[10] 深入操作系统,彻底搞懂127.0.0.1本机网络通信

[11] 冰山之下,一次网络请求背后的技术秘密

[12] 得物自研移动端弱网诊断工具的技术实践分享


(本文已同步发布于:http://www.52im.net/thread-4857-1-1.html)

posted @ 2025-08-28 11:51 Jack Jiang 阅读(34) | 评论 (0)编辑 收藏

1、基本介绍

1

RainbowTalk是一套基于开源即时通讯讯IM框架 MobileIMSDK 的产品级鸿蒙NEXT端IM系统。纯ArkTS编写、全新开发,没有套壳、也没走捷径,每一行代码都够“纯血”。与姊妹产品RainbowChatRainbowChat-Web 技术同源,历经考验。

☞ 详细介绍:http://www.52im.net/thread-4822-1-1.html
☞ 运行截图:http://www.52im.net/thread-4824-1-1.html (运行视频
☞ 下载体验:http://www.52im.net/thread-4825-1-1.html

2、MobileIMSDK开源工程

2

MobileIMSDK 是一套专门为移动端开发的开源IM即时通讯框架,超轻量级、高度提炼,一套API优雅支持UDP 、TCP 、WebSocket 三种协议,支持iOS、Android、H5、小程序、Uniapp、标准Java平台,服务端基于Netty编写。

工程同步开源地址:

开源仓库目录说明:

 proj_dir

MobileIMSDK框架由以下部分组成:

 3

MobileIMSDK框架的架构原理图:

4

v2.4 版更新内容

此版更新内容更多历史更新日志):

  • 1)[优化] 解决了聊天界面中语音消息下载、图片消息上传时消息气泡ui会闪烁的问题;
  • 2)[优化] 解决深色模式下聊天消息文字看不清的问题;
  • 3)[新增] 新增了大文件消息(支持断点续传、下载、查看文件内容等)。

部分新增功能运行截图(更多截图运行视频):

6

posted @ 2025-08-20 10:14 Jack Jiang 阅读(45) | 评论 (0)编辑 收藏

1、基本介绍

RainbowChat是一套基于MobileIMSDK通信框架的产品级移动端IM系统。RainbowChat源于真实运营的产品,不同于市面上某些开源或淘宝售卖的demo级代码,RainbowChat的产品前身已被成千上万真实的客户使用过,解决了大量的屏幕适配、细节优化、机器兼容问题。

RainbowChat可能是市面上唯一一款同时支持TCP、UDP两种通信协议的全源码IM产品(且核心通信层也是自主开发的)。RainbowChat是RainbowChat-Web 和鸿蒙NEXT产品RainbowTalk 的姊妹产品。

2、品质说明

❶ 源自真正运营的商业产品:RainbowChat的技术源于真实运营的商业产品。

❷ 它不是个Demo:不同于市面上某些开源或淘宝的demo级代码,RainbowChat已被成千上万真实的客户使用过,解决了大量的屏幕适配、细节优化、机器兼容问题。

❸ 简洁、精炼、优化、原生:
RainbowChat为了最小化开发者2次开发时的兼容性、可读性、可维护性难度,把框架的依赖、工具的依赖、各种库版本的依赖、运行环境的依赖都尽最大努力降到最低,极大降低开发者的开发环境和部署环境搭建的成本,达到最简洁、最精炼的目标。

* 截止目前:RainbowChat已全面深度适配最新Android系统,确保更佳的用户体验效果。

3、运行演示与安装体验

❶ 运行截图,详见:《Android端全部功能截图iOS端全部功能截图
❷ 下载体验,详见:《RainbowChat下载体验

4、功能简介

1、支持文本消息、语音留言消息、图片消息、大文件消息(支持断点续传)、短视频消息、个人名片、群名片、位置消息、Emoji表情、消息撤回、消息转发、消息引用、“@”功能、“扫一扫”功能等;
2、支持一对一陌生人聊天模式;
3、支持一对一正式好友聊天模式;
4、支持多对多群聊聊天模式,且自动防刷屏(仅限专业版)
5、完善的群组信息管理:建群、退群、解散、转让、邀请、踢人、群公告等 (仅限专业版)
6、完整的注册、登陆、密码找回等功能闭环;
7、个人中心功能:改基本信息、改个性签名、改头像、改密码等;
8、支持个人相册、个人语音介绍;
9、完整的礼物发送和积分管理子系统;
10、完整的离线消息/指令拉取机制;
11、完整的本地消息/指令缓存机制,节省网络流量;
12、完整的富媒体文件(语音、大文件、图片、短视频)缓存机制,节省网络流量;
13、完整的好友关系管理:查找好友、发出请求、处理请求、删除好友、好友备注等;
14、全功能实时语音聊天(完全自主开发,现在就可体验);
15、全功能实时视频聊天(完全自主开发,现在就可体验);
16、内置一完整“商城”模块,目前仅用于演示产品的完整性;
17、其它未提及的功能和特性请自行下载体验。

RainbowChat线上版本目前仅作演示和研究之用,运行环境配置最小化(仅1核1G和1MB带宽),请客观评估。

5、技术亮点 

1)持续打磨和升级至今(历经时间考验和大量客户面辐射的代码,可靠性、兼容性一定优于短时间内堆砌功能的产品);
2)底层算法库到上层功能,完全自主开发,技术资产可控;
3)同时支持TCP、UDP两种通信协议(可能是市面上能买到的唯一一款);
4)独有的UDP协议支持, 能更好地适应卫星网、移动弱网、嵌入式物联网等场景;
5)即时通讯核心层基于MobileIMSDK 工程,保证了业务代码与通信核心的高度分层(经验不足的IM产品是做不到这一点的);
6)支持完整的消息送达保证(QoS)机制,保证送达率,理论丢包率约为0.0001%;
7)独有的UDP协议无连接特性保证在高延迟、跨洲际、不同网络制式的恶恶劣环境中能稳定、可靠地运行;
8)基于 MobileIMSDK 工程的自有协议,未来的流量压缩对于APP端的节电控制和流量控制、服务端的网络吞吐等都有完全的控制能力;
9)完善的网络状况自动检测、断网重连等服务自动治愈能力;
10)核心算法和实现均为自主原创(历经8年,并非开源拼凑),保证了技术的持续改进、升级、扩展;
11)聊天协议兼容:实现了与RainbowChat-Web产品、鸿蒙NEXT产品RainbowTalk完全兼容的协议模型;
12)消息收发互通:实现了与RainbowChat-Web产品、鸿蒙NEXT产品RainbowTalk的无缝消息互通。

6、注册、登录和“个人中心”等

 

7、好友聊天功能

8、实时语音聊天功能

9、实时视频聊天功能

10、群聊功能

 

11、视频消息功能

12、位置消息功能

13、“大文件”消息(支持断点续传)

 

14、“扫一扫”功能

15、“搜索”功能

16、消息转发功能

17、消息引用功能

18、“@”功能

posted @ 2025-08-19 14:17 Jack Jiang 阅读(41) | 评论 (0)编辑 收藏

     摘要: 本文引用了后台技术汇一枚少年郎“大模型应用之:SSE流式响应”的内容,下文有修订和重新排版。1、引言文章介绍了SSE(Server-Sent Events)技术在大模型流式响应中的应用,包括其发展历程、ChatGPT流式输出原理、SSE技术特点及与WebSocket的对比,并提供了两种流式响应落地方案。* 相关阅读:《全民AI时代,大模型客户端和服务端的实时通信到...  阅读全文

posted @ 2025-08-14 14:31 Jack Jiang 阅读(53) | 评论 (0)编辑 收藏

     摘要: 本文由携程技术Butters分享,原题“干货 | 日均流量200亿,携程高性能全异步网关实践”,下文有修订和重新排版。1、引言本文分享的是携程API网关全异步改造的实践分享,包括从Zuul 1.0同步架构升级为基于Netty的全异步架构,通过RxJava实现业务流程异步化,结合流式转发、ZGC等技术显著提升性能,并构建控制面实现多协议统一治理与模块化编排。 &nb...  阅读全文

posted @ 2025-08-07 12:01 Jack Jiang 阅读(57) | 评论 (0)编辑 收藏

Jack Jiang的 Mail: jb2011@163.com, 联系QQ: 413980957, 微信: hellojackjiang