即时通讯安全篇(三):一文读懂常用加解密算法与网络通讯安全

1、引言

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

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

技术交流:

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

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

本文已同步发布于: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)

相关推荐

鸿蒙原生即时通讯/IM系统RainbowTalk v2.8版发布,基于MobileIMSDK框架、ArkTS编写

💧 此版本解决了若干bug,以及ui和功能细节优化,同时支持最新鸿蒙7.0系统。

hellojackjiang2011的博客 165

深度剖析IM消息乱序的根本原因及优化方法

本文深度剖析即时通讯IM消息乱序的问题,梳理IM客户端时间戳不可信、多端并发、群消息扇出重试三大核心陷阱,拆解微信、钉钉、企业微信的时序设计方案,并从锚点设计、多端去交错、幂等兜底、可观测性等维度,给出IM项目消息时序性保证的落地优化策略。

hellojackjiang2011的博客 293

IM聊天不掉线?生产级WebSocket断线重连、心跳保活实战

本文将给出一套生产级Web端即时通信方案,包括心跳检测保活 + 指数退避重连,代码直接能跑。

hellojackjiang2011的博客 317

IM全文检索技术(五):vivo敏感词匹配系统的技术实践

本文将从算法选型入手,结合两个实际场景来介绍谛听系统的敏感词匹配算法。包括底层算法选型思路和两种实际场景下提升敏感词精准度、降低漏杀率的方案。

hellojackjiang2011的博客 189

Nginx生产级WebSocket实时长连接负载均衡,一文搞定

本文从基础配置、生产配置、Docker / K8s、安全、排障、性能调优,系统性讲清 WebSocket 在 Nginx 中的正确打开方式。

hellojackjiang2011的博客 308

即时通讯IM离线消息该怎么存?全面盘点主流存储方案

离线消息是IM系统的核心能力,当用户不在线时,消息必须可靠存储,待用户上线后完整推送。本文将对比主流的离线消息存储方案,帮你找到最适合业务场景的架构。

hellojackjiang2011的博客 310

移动端实时音视频聊天框架 RainbowAV v2.2.7发布

1)

hellojackjiang2011的博客 247

都HTML5了,Web端即时通讯技术到底该用什么?一文即懂!

本文分享的是 Web 端最常用即时通讯技术(包括 WebSocket、SSE、WebRTC、轮询等)的原理、优缺点与适用场景等,以及生产环境下的高并发场景下的进阶实践。

hellojackjiang2011的博客 341

基于开源MobileIMSDK框架,即时通讯IM产品RainbowChat v12.1发布

此版本新增了短信验证码的注册和登录功能,解决了Android 16手机上发送文件失败等问题。

hellojackjiang2011的博客 209

IM千人群聊该不该用消息写扩散?详细算算成本账!

本文将为你详解 IM 群聊消息的写扩散技术原理以及写扩散过程中的服务端详细性能成本,同时对比了市面上IM大厂的技术方案,给出分规模架构选型与以及性能优化策略等。

hellojackjiang2011的博客 402

直播系统聊天技术(十):基于实时消息总线的活动系统架构设计

本文分享的是网易云音乐技术团队基于实时消息总线技术,解决了直播活动系统的模块灵活组合、消息治理与异步履约等问题,希望能给你带来启发。

hellojackjiang2011的博客 369

轻量级Web端IM即时通讯框架MobileIMSDK-Web,基于Socket.io库

MobileIMSDK-Web是一套Web端即时通讯框架,超轻量级、极少依赖,高度提炼、简单易用。

hellojackjiang2011的博客 286

socket长连接在手游场景下的技术实践

本文介绍了37手游基于B站goim框架自研长连接系统的实践。系统采用分层设计,支持多协议和发布/订阅机制,用于直播弹幕、实时推送等场景,实现了高性能与业务适配。

hellojackjiang2011的博客 403

基于开源MobileIMSDK框架,即时通讯IM产品RainbowChat v12.0发布

RainbowChat 是一套基于 MobileIMSDK 开源通信框架的产品级移动端IM系统。可能是市面上开放源码的,唯一一款同时支持TCP、UDP、WebSocket三种网络通信协议的IM产品。

hellojackjiang2011的博客 518

社交场景下的统一即时通讯im消息流交互层模块化技术实践

这些IM场景,在消息流的展示形式上是极为相似的,同时每个业务又有着自己特殊的交互需求。基于此,我们对IM消息流能力做了标准化的构建,来减少IM功能的业务接入成本;同时也是为了统一各个业务的技术方案,减少跨业务开发的理解和维护成本。

hellojackjiang2011的博客 571

现代IM系统中聊天消息的同步和存储方案探讨

本文内容主要涉及IM系统中的消息系统架构,探讨一种适用于大用户量的消息同步以及存储系统的架构实现,能够支持消息系统中的高级特性“多端同步”以及“消息漫游”。在性能和规模上,能够做到全量消息云端存储,百万TPS以及毫秒级延迟的消息同步能力。

hellojackjiang2011的博客 75

即时通讯安全篇(十六):对称加密 vs 非对称加密?一文搞懂

本文将以通俗案例讲解加密本质,介绍对称加密(含 AES、迪菲–赫尔曼密钥交换)与非对称加密(RSA)原理、特点及应用,并阐释其数学基础。

hellojackjiang2011的博客 397

网络编程入门如此简单(五):UDP跟TCP相比,到底差了什么?

本文将通俗易懂地为你类比解释UDP与TCP的核心差异,包括如何基于UDP实现TCP的可靠传输:通过模拟三次握手、添加序列号与确认机制解决顺序和丢包问题,利用滑动窗口控制流量,并引入拥塞控制算法来动态调整发送速率等。

hellojackjiang2011的博客 448

基于WebSocket的IM即时通信方案在H5游戏场景下的技术实践

本文将从H5游戏场景下的实时信息更新需求切入,探讨下在类似这种高并发、低延迟的业务需求中,如何使用 IM 方案来解决频繁的数据更新问题,也顺便介绍下 WebSocket 的基本运作流程等。

hellojackjiang2011的博客 1069

鸿蒙Next原生IM即时通讯RainbowTalk,纯ArkTS编写,基于开源MobileIMSDK框架

RainbowTalk 是一套基于 MobileIMSDK 开源通信框架的产品级纯血鸿蒙NEXT端IM系统。RainbowTalk 由纯ArkTS编写、全新开发,没有套壳、也没走捷径,原生“纯血”。

hellojackjiang2011的博客 1227

如何保障分布式IM聊天系统的消息可靠性(即消息不丢)

本文主要聚焦分布式IM聊天系统消息可靠性问题,即如何保证消息不丢失。

hellojackjiang2011的博客 732

如何保障分布式IM聊天系统的消息有序性(即消息不乱)

本篇主要总结和分享分布式IM聊天系统架构中关于消息有序性的设计和实践。

hellojackjiang2011的博客 835

B站即时通讯IM消息系统的新架构升级实践

本文要分享的是B站IM消息系统的新架构升级实践总结,内容包括原架构的问题分析,新架构的整体设计以及具体的升级实现等。

hellojackjiang2011的博客 714

AI大模型爆火的SSE技术到底是什么?万字长文,一篇读懂SSE!

本文从SSE(Server-Sent Events)技术的原理到示例代码,为你通俗易懂的讲解SSE技术的方方面面。

hellojackjiang2011的博客 786

腾讯新闻APP的消息推送Push架构技术重构实践

本文主要分享的是腾讯技术团队近年来对腾讯新闻消息推送PUSH系统做的架构优化和技术实践。

hellojackjiang2011的博客 843

移动端弱网优化专题(十五):字节跳动移动端网络HttpDNS优化实践

本文要分享的是字节跳动团队针对火山HTTPDNS Cache2.0通过自研网段库与动态划分算法,将缓存粒度从“城市-运营商”细化为“网段”,解决了传统方案的城市级调度污染问题。配合缓存分级、预取等优化,在提升调度精准度的同时保证了高命中率,最终实现了服务端调度准确性提升和客户端性能优化。

hellojackjiang2011的博客 720

转转客服IM聊天系统背后的技术挑战和实践分享

在当今互联网时代,高效的用户服务是提升用户体验的关键。转转自研的客服IM聊天系统作为用户与客服沟通的桥梁,承担着传递信息、解决问题的关键角色。然而,消息数据的流转并非一帆风顺,本文将深入探讨IM系统在消息传递过程中遇到的问题和挑战,以及相应的技术解决方案。

hellojackjiang2011的博客 1096

ChatGPT如何实现聊天一样的实时交互?快速读懂SSE实时“推”技术

本文将带你快速认识SSE实时通信协议,包括它的技术原理、常见使用场景、与同类技术的对比以及简单的示例代码等。

hellojackjiang2011的博客 124

全面适配iOS 26液态玻璃,基于开源IM即时通讯框架MobileIMSDK:RainbowChat-iOS端v10.2发布

RainbowChat是一套基于开源IM即时通讯聊天框架 MobileIMSDK 的产品级移动端IM系统。

hellojackjiang2011的博客 1157

可靠传输的TCP协议send成功就意味着数据一定发出去了?

本篇文章我们以TCP协议的网络编程逻辑,从Socket缓冲区的角度去拆解,为什么号称可靠传输的TCP协议,在代码中调用send并成功发出数据,并不意味着这个数据就一定通过物理网络发出去了。

hellojackjiang2011的博客 125
上一篇: 企业级实时消息推送系统的架构设计,一文即懂!
下一篇: 可靠传输的TCP协议send成功就意味着数据一定发出去了?
jackjiang2025
jackjiang2025 网际时代技术分享账号 网际时代技术分享账号
博客等级 码龄8年 700粉丝 318原创
评论
成就一亿技术人!
拼手气红包6.0元
还能输入1000个字符
 
 条评论被折叠 查看
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付:10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值