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

0. IM安全系列文章

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

• 《即时通讯安全篇（一）：正确地理解和使用Android端加密算法》
• 《即时通讯安全篇（二）：探讨组合加密算法在IM中的应用》
• 《即时通讯安全篇（三）：常用加解密算法与通讯安全讲解》（本文）
• 《即时通讯安全篇（四）：实例分析Android中密钥硬编码的风险》
• 《即时通讯安全篇（五）：对称加密技术在Android上的应用实践》
• 《即时通讯安全篇（六）：非对称加密技术的原理与应用实践》
• 《即时通讯安全篇（七）：用JWT技术解决IM系统Socket长连接的身份认证痛点》
  

1. 通讯安全概述

1引言

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

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

2安全性威胁

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

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

- 第一，中断。攻击者有意破坏和切断他人在网络上的通信，这是对可用性的攻击。
- 第二，截获。属于被动攻击，攻击者从网络上qie听他人的通信内容，破坏信息的机密性。
- 第三，篡改。攻击者故意篡改网络上传送的报文，这是对完整性的攻击。
- 第四，伪造。攻击者伪造信息在网络传送，这是对真实性的攻击。

3加密解密算法

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

2. Base64算法介绍

1原理

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

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



从上面的base64算法，我们可以窥视部分加密的本质：将一段有意义的信息，通过某种方式，映射为一段看不懂的信息。使用函数表达即为：

public Ciphertext encrypted(Plaintext text);

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

2小结

通过base64算法，可以看出，一个加密算法会有两部分组成：密钥、算法。两者不能都公开，都公开的话，就可以被人逆向运算，进行解密。一般的，我们将密钥进行保密，将算法进行公开。算法的公开，有利于算法的推广，普及，更有利于寻找算法中的漏洞。也就是因为base64同时公开了算法、密钥，所以我们说他并不是真正的加密算法。当然如果你调整了上面映射表，那么也能做到加密算法的目的，不过base64加密的强度比较差，所以不建议在实际应用中作为加密算法使用。

3. 摘要算法介绍

1基本

我们在平时的工作中经常听到MD5算法。比如在一些下载页面里会给出一个md5的作为文件验证串，在迅雷下载中作为文件的唯一标识。这类算法严格上来说也不是加密算法，是一种叫做摘要算法的算法，不过在平时的使用中，我们经常将摘要算法混合使用，所以在广义上来说也可以将他叫为加密算法。

2摘要长度

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

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

3通讯模型

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

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

流程如下图：



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

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

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

4. 对称加密算法介绍

1基本

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

2通讯模型

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



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

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

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

3算法优缺点

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

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

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

5. 非对称加密算法介绍

1基本

对称加密算法指加密解密用同一密钥，那么非对称加密就是加密解密用不同的密钥。加密算法一次生成两个密钥，一个叫做公钥，一个较为密钥。公钥加密的数据，用密钥解密；密钥加密的数据，用公钥来解密（有些非对称加密算法，只能用密钥加密，公钥解密，或只能用密钥加密，公钥解密）。

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

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

2通讯模型

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



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

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

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

3算法优缺点

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

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

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

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

6. 数字签名介绍

1基本

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

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

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

2通讯模型

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



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

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



以上的模型主要由两个步骤组成，摘要与非对称加密算法的应用。平常我们经常用到的签名算法，也是这两种算法的组合，比如：SHA1wthRSA，使用SHA1来做摘要，RSA做未对称加密；MD5withRSA，使用MD5做摘要算法，RSA做未对称加密；SHA1withDSA，DSA是ElGamal算法的一种改进。

7. 数字证书介绍

1基本

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

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

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

2通讯模型

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

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



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

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

3CA

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

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

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



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

全站即时通讯技术资料分类

[1] 网络编程基础资料：
《TCP/IP详解 - 第11章·UDP：用户数据报协议》
《TCP/IP详解 - 第17章·TCP：传输控制协议》
《TCP/IP详解 - 第18章·TCP连接的建立与终止》
《TCP/IP详解 - 第21章·TCP的超时与重传》
《理论经典：TCP协议的3次握手与4次挥手过程详解》
《理论联系实际：Wireshark抓包分析TCP 3次握手、4次挥手过程》
《计算机网络通讯协议关系图（中文珍藏版）》
《NAT详解：基本原理、穿越技术(P2P打洞)、端口老化等》
《UDP中一个包的大小最大能多大？》
《Java新一代网络编程模型AIO原理及Linux系统AIO介绍》
《NIO框架入门(三)：iOS与MINA2、Netty4的跨平台UDP双向通信实战》
《NIO框架入门(四)：Android与MINA2、Netty4的跨平台UDP双向通信实战》
>> 更多同类文章 ……

[2] 有关IM/推送的通信格式、协议的选择：
《为什么QQ用的是UDP协议而不是TCP协议？》
《移动端即时通讯协议选择：UDP还是TCP？》
《如何选择即时通讯应用的数据传输格式》
《强列建议将Protobuf作为你的即时通讯应用数据传输格式》
《移动端IM开发需要面对的技术问题（含通信协议选择）》
《简述移动端IM开发的那些坑：架构设计、通信协议和客户端》
《理论联系实际：一套典型的IM通信协议设计详解》
《58到家实时消息系统的协议设计等技术实践分享》
>> 更多同类文章 ……

[3] 有关IM/推送的心跳保活处理：
《Android进程保活详解：一篇文章解决你的所有疑问》
《Android端消息推送总结：实现原理、心跳保活、遇到的问题等》
《为何基于TCP协议的移动端IM仍然需要心跳保活机制？》
《微信团队原创分享：Android版微信后台保活实战分享(进程保活篇)》
《微信团队原创分享：Android版微信后台保活实战分享(网络保活篇)》
《移动端IM实践：实现Android版微信的智能心跳机制》
《移动端IM实践：WhatsApp、Line、微信的心跳策略分析》
>> 更多同类文章 ……

[4] 有关WEB端即时通讯开发：
《新手入门贴：史上最全Web端即时通讯技术原理详解》
《Web端即时通讯技术盘点：短轮询、Comet、Websocket、SSE》
《SSE技术详解：一种全新的HTML5服务器推送事件技术》
《Comet技术详解：基于HTTP长连接的Web端实时通信技术》
《WebSocket详解（一）：初步认识WebSocket技术》
《socket.io实现消息推送的一点实践及思路》
>> 更多同类文章 ……

[5] 有关IM架构设计：
《浅谈IM系统的架构设计》
《简述移动端IM开发的那些坑：架构设计、通信协议和客户端》
《一套原创分布式即时通讯(IM)系统理论架构方案》
《从零到卓越：京东客服即时通讯系统的技术架构演进历程》
《蘑菇街即时通讯/IM服务器开发之架构选择》
《腾讯QQ1.4亿在线用户的技术挑战和架构演进之路PPT》
《微信技术总监谈架构：微信之道——大道至简(演讲全文)》
《如何解读《微信技术总监谈架构：微信之道——大道至简》》
《快速裂变：见证微信强大后台架构从0到1的演进历程（一）》
《17年的实践：腾讯海量产品的技术方法论》
>> 更多同类文章 ……

[6] 有关IM安全的文章：
《即时通讯安全篇（一）：正确地理解和使用Android端加密算法》
《即时通讯安全篇（二）：探讨组合加密算法在IM中的应用》
《即时通讯安全篇（三）：常用加解密算法与通讯安全讲解》
《即时通讯安全篇（四）：实例分析Android中密钥硬编码的风险》
《传输层安全协议SSL/TLS的Java平台实现简介和Demo演示》
《理论联系实际：一套典型的IM通信协议设计详解（含安全层设计）》
《微信新一代通信安全解决方案：基于TLS1.3的MMTLS详解》
《来自阿里OpenIM：打造安全可靠即时通讯服务的技术实践分享》
《简述实时音视频聊天中端到端加密（E2EE）的工作原理》
《移动端安全通信的利器——端到端加密（E2EE）技术详解》
《Web端即时通讯安全：跨站点WebSocket劫持漏洞详解(含示例代码)》
《通俗易懂：一篇掌握即时通讯的消息传输安全原理》
《IM开发基础知识补课(四)：正确理解HTTP短连接中的Cookie、Session和Token》
《快速读懂量子通信、量子加密技术》
《即时通讯安全篇（七）：如果这样来理解HTTPS原理，一篇就够了》
《一分钟理解 HTTPS 到底解决了什么问题》
《一篇读懂HTTPS：加密原理、安全逻辑、数字证书等》
>> 更多同类文章 ……

[7] 有关实时音视频开发：
《即时通讯音视频开发（一）：视频编解码之理论概述》
《即时通讯音视频开发（二）：视频编解码之数字视频介绍》
《即时通讯音视频开发（三）：视频编解码之编码基础》
《即时通讯音视频开发（四）：视频编解码之预测技术介绍》
《即时通讯音视频开发（五）：认识主流视频编码技术H.264》
《即时通讯音视频开发（六）：如何开始音频编解码技术的学习》
《即时通讯音视频开发（七）：音频基础及编码原理入门》
《即时通讯音视频开发（八）：常见的实时语音通讯编码标准》
《即时通讯音视频开发（九）：实时语音通讯的回音及回音消除概述》
《即时通讯音视频开发（十）：实时语音通讯的回音消除技术详解》
《即时通讯音视频开发（十一）：实时语音通讯丢包补偿技术详解》
《即时通讯音视频开发（十二）：多人实时音视频聊天架构探讨》
《即时通讯音视频开发（十三）：实时视频编码H.264的特点与优势》
《即时通讯音视频开发（十四）：实时音视频数据传输协议介绍》
《即时通讯音视频开发（十五）：聊聊P2P与实时音视频的应用情况》
《即时通讯音视频开发（十六）：移动端实时音视频开发的几个建议》
《即时通讯音视频开发（十七）：视频编码H.264、V8的前世今生》
《简述开源实时音视频技术WebRTC的优缺点》
《良心分享：WebRTC 零基础开发者教程（中文）》
>> 更多同类文章 ……

[8] IM开发综合文章：
《移动端IM开发需要面对的技术问题》
《开发IM是自己设计协议用字节流好还是字符流好？》
《请问有人知道语音留言聊天的主流实现方式吗？》
《IM系统中如何保证消息的可靠投递（即QoS机制）》
《谈谈移动端 IM 开发中登录请求的优化》
《完全自已开发的IM该如何设计“失败重试”机制？》
《微信对网络影响的技术试验及分析（论文全文）》
《即时通讯系统的原理、技术和应用（技术论文）》
《开源IM工程“蘑菇街TeamTalk”的现状：一场有始无终的开源秀》
>> 更多同类文章 ……

[9] 开源移动端IM技术框架资料：
《开源移动端IM技术框架MobileIMSDK：快速入门》
《开源移动端IM技术框架MobileIMSDK：常见问题解答》
《开源移动端IM技术框架MobileIMSDK：压力测试报告》
《开源移动端IM技术框架MobileIMSDK：Android版Demo使用帮助》
《开源移动端IM技术框架MobileIMSDK：Java版Demo使用帮助》
《开源移动端IM技术框架MobileIMSDK：iOS版Demo使用帮助》
《开源移动端IM技术框架MobileIMSDK：Android客户端开发指南》
《开源移动端IM技术框架MobileIMSDK：Java客户端开发指南》
《开源移动端IM技术框架MobileIMSDK：iOS客户端开发指南》
《开源移动端IM技术框架MobileIMSDK：Server端开发指南》
>> 更多同类文章 ……

[10] 有关推送技术的文章：
《iOS的推送服务APNs详解：设计思路、技术原理及缺陷等》
《Android端消息推送总结：实现原理、心跳保活、遇到的问题等》
《扫盲贴：认识MQTT通信协议》
《一个基于MQTT通信协议的完整Android推送Demo》
《求教android消息推送：GCM、XMPP、MQTT三种方案的优劣》
《移动端实时消息推送技术浅析》
《扫盲贴：浅谈iOS和Android后台实时消息推送的原理和区别》
《绝对干货：基于Netty实现海量接入的推送服务技术要点》
《移动端IM实践：谷歌消息推送服务(GCM)研究（来自微信）》
《为何微信、QQ这样的IM工具不使用GCM服务推送消息？》
>> 更多同类文章 ……

[11] 更多即时通讯技术好文分类：
http://www.52im.net/forum.php?mod=collection&op=all

学习了，很好

您好   我是一名读者 ，上面有一条通讯模型那一块我感觉还是有点问题，还有一种可能，数据没有被篡改，只是把秘钥和数据的组合串给篡改了，最终传过去的data是对的，但是解码后对比还是错误的，这样另一方客户还是会觉得数据被改过。

引用：小菜鸟 发表于 2018-06-15 11:19
您好   我是一名读者 ，上面有一条通讯模型那一块我感觉还是有点问题，还有一种可能，数据没有被篡改，只是 ...

是的，你说的有这种可能性，但毫无疑问，无论哪部分被篡改，都可以无条件认为是不可信的数据了，不需要纠结

im这方面的开源软件推荐下哈

不少错别字

引用：登至必极 发表于 2019-10-18 09:38
不少错别字

不影响阅读就行了

作为程序员的我 看得我强迫症犯了