CN114338574A

CN114338574A - 一种即时通讯方法、管理节点及系统

Info

Publication number: CN114338574A
Application number: CN202111560376.4A
Authority: CN
Inventors: 陈源龙; 董希尧; 李全龙
Original assignee: Harbin Institute of Technology
Current assignee: Harbin Institute of Technology
Priority date: 2021-12-07
Filing date: 2021-12-07
Publication date: 2022-04-12
Anticipated expiration: 2041-12-07
Also published as: CN114338574B

Abstract

本申请提供一种即时通讯方法、管理节点及系统，即时通讯方法包括：接收所述发送客户端发送的消息数据并解析，获得所述消息数据的长度和目标地址；响应于确定所述消息数据的长度大于预设阈值，则采用第一通信协议向所述目标地址发送所述消息数据；响应于确定所述消息数据的长度小于或等于所述预设阈值，则采用第二通信协议向所述目标地址发送所述消息数据。本申请提供的即时通讯方法、管理节点及系统，将UDP协议和TCP协议传输结合起来，以消息等待算法为基础，具有低延时，低内存消耗，可分布式部署，可加密等特点。

Description

一种即时通讯方法、管理节点及系统

技术领域

本申请涉及信息交互技术领域，尤其涉及一种即时通讯方式及系统。

背景技术

即时通讯软件是一种基于互联网的即时交流软件，主要包括登录注册、消息发送、消息接收、消息传输、信息持久化、加入或退出群组、创建临时视频聊天、生成房间号、上报临时数据库、通过房间号获取视频聊天组、查询房间号等功能。在这些功能中，最重要当属消息传输和视频聊天功能。

发明内容

有鉴于此，本申请的目的在于提出一种即时通讯方法。

基于上述目的，本申请提供了即时通讯方法，包括：

接收发送客户端发送的消息数据并解析，获得所述消息数据的长度和目标地址；

响应于确定所述消息数据的长度大于预设阈值，则采用第一通信协议向所述目标地址发送所述消息数据；

响应于确定所述消息数据的长度小于或等于所述预设阈值，则采用第二通信协议向所述目标地址发送所述消息数据。

可选的，响应于确定所述消息数据的长度大于预设阈值，通过GRPC协议接口向接收端发送所述消息数据；

响应于确定所述消息数据的长度小于或等于预设阈值，通过UDP协议接口向所述接收端发送所述消息数据；

其中，所述GRPC协议接口与所述接收端之间的通信连接为长连接，所述UDP协议接口与所述接收端之间的通信连接为无连接。

可选的，接收所述发送客户端发送的消息数据并解析前，还包括：

响应于注册配置中心的分配算法，与所述发送客户端建立通信连接。

可选的，所述响应于注册配置中心的分配算法，与所述发送客户端建立通信连接，包括：

所述注册配置中心生成一致性哈希环；

根据哈希算法计算得到的第一哈希值映射于所述一致性哈希环上；

所述注册配置中心获取所述发送客户端的唯一标识符，通过所述哈希算法计算得到所述标识符对应的第二哈希值，并根据所述第二哈希值将所述发送客户端映射到所述一致性哈希环上；

按照预设方向与在所述一致性哈希环上距离最近的所述第二哈希值对应的所述发送客户端建立通信连接。

可选的，所述接收所述发送客户端发送的消息数据并解析前，还包括：

所述发送客户端对发起的请求进行protobuf序列化编码，得到信息数据；

接收所述信息数据后，进行protobuf反序列化编码，得到请求。

可选的，即时通讯方法还包括：

到达检查周期时，所述发送客户端对比传输失败次数和最大传输失败次数；

响应于确定所述传输失败次数小于或等于所述最大传输失败次数，则将初始阈值乘以第一参数，得到第一调整阈值，且将所述第一调整阈值替换所述初始阈值，作为所述预设阈值；

响应于确定所述传输失败次数大于所述最大传输失败次数，则将所述初始阈值除以第二参数，得到第二调整阈值，且将所述第二调整阈值替换所述初始阈值，作为所述预设阈值；

其中，所述初始阈值、最大传输失败次数和检查周期由所述发送客户端设置；所述传输失败次数为采用所述第二通信协议向所述目标地址发送所述消息数据的失败次数，由所述发送客户端记录。

可选的，即时通讯方法还包括：

设置发送时延；

响应于确定所述消息数据为音频数据或视频数据，则所述消息数据的发送间隔不小于所述发送时延。

可选的，即时通讯方法还包括：

所述发送客户端生成第一密钥；

所述发送客户端通过所述第一密钥加密所述消息数据，得到消息密文；

所述发送客户端通过用户信息服务器获取所述接收端对应的第二公钥；

所述发送客户端通过所述第二公钥对所述第一密钥进行加密处理，得到加密密钥；

所述发送客户端向所述接收端发送所述加密密钥和所述消息密文。

基于同一发明构思，本申请还提供了一种管理节点，用于实现前述方法。

基于同一发明构思，本申请还提供了一种即时通讯系统，包括：

发送客户端，被配置为发送登录请求；还被配置为发送消息数据；

注册配置中心，被配置为接收所述登录请求，并发送调用指令；还被配置为响应于确定所述身份验证通过，则发送通信连接指令；

用户认证中心，被配置为接收所述调用指令，对所述发送客户端进行身份验证；

前述管理节点，被配置为接收所述通信连接指令，与所述发送客户端建立通信连接；还被配置为接收所述消息数据并转发送；

接收客户端，被配置为接收所述管理节点转发送的消息数据并展示。

从上面所述可以看出，本申请提供的即时通讯方法、管理节点及系统，将UDP协议和TCP协议传输结合起来，以消息等待算法为基础，具有低延时，低内存消耗，可分布式部署，可加密等特点。除此之外，也相应设计了对应的分布式消息传输系统，使用了一致性哈希算法来保证消息在集群内部的定位接收和传输，并以此消息传输机制和微服务思想为基础，辅助以高可用的服务集群控制和小巧的客户端程序，整个消息服务后端的设计也遵循高内聚低耦合的形式。

附图说明

为了更清楚地说明本申请或相关技术中的技术方案，下面将对实施例或相关技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本申请的实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。

图1为本申请实施例的即时通讯方法的流程示意图；

图2为本申请实施例的即时通讯方法的发送管理节点分配的流程示意图；

图3为本申请实施例的即时通讯系统的架构示意图；

图4为本申请实施例的即时通讯系统的一致性哈希环的示意图；

图5为本申请实施例的即时通讯方法的发送管理节点查找流程示意图；

图6为本申请实施例的即时通讯方法的发送消息数据时的消息等待流程示意图；

图7为本申请实施例的即时通讯方法的消息等待时间调整流程示意图；

图8为本申请实施例的即时通讯方法的使用两种通信协议发送消息数据的流程示意图；

图9为本申请实施例的即时通讯方法的预设阈值调整流程示意图；

图10为本申请实施例的即时通讯方法的消息数据加密传输流程示意图；

图11为本申请实施例的即时通讯方法的三种协议小数据发送量对比测试数据示意图；

图12为本申请实施例的即时通讯方法的三种协议大数据发送量对比测试数据示意图；

图13为本申请实施例的即时通讯方法的两种协议的拥塞控制示意图；

图14为本申请实施例所提供的一种更为具体的电子设备硬件结构示意图。

附图标记说明：

1、客户端；101、发送客户端；102、接收客户端；2、管理节点；201、发送管理节点；202、接收管理节点；3、用户认证中心；4、注册配置中心；5、文件服务器；6、数据库服务器；7、一致性哈希环；8、发送端；9、接收端；10、UDP协议接口；11、GRPC协议接口。

具体实施方式

为使本申请的目的、技术方案和优点更加清楚明白，以下结合具体实施例，并参照附图，对本申请进一步详细说明。

需要说明的是，除非另外定义，本申请实施例使用的技术术语或者科学术语应当为本申请所属领域内具有一般技能的人士所理解的通常意义。本申请实施例中使用的“第一”、“第二”以及类似的词语并不表示任何顺序、数量或者重要性，而只是用来区分不同的组成部分。“包括”或者“包含”等类似的词语意指出现该词前面的元件或者物件涵盖出现在该词后面列举的元件或者物件及其等同，而不排除其他元件或者物件。“连接”或者“相连”等类似的词语并非限定于物理的或者机械的连接，而是可以包括电性的连接，不管是直接的还是间接的。“上”、“下”、“左”、“右”等仅用于表示相对位置关系，当被描述对象的绝对位置改变后，则该相对位置关系也可能相应地改变。

基于背景技术中所述内容，申请人研究发现目前比较流行的通讯软件基本都是用TCP协议(Transmission Control Protocol，传输控制协议)或者直接使用更上层的HTTP协议(HyperText Transfer Protocol，超文本传输协议)作为通信协议。这种方法优点是方便开发，而且消息传输稳定。缺点就是对于每一个用户都需要独立维护一个长连接，这对于服务器来说需要耗费大量的内存资源，导致相同资源消耗下能够承载的用户量变少。

当然，也有使用UDP协议(User Datagram Protocol，用户数据包协议)作为底层传输协议的即时通信软件，缺点是无法保证消息传输的时序，而且消息大小受到UDP数据包大小的限制。

此外，还有GRPC协议(Google Remote Procedure Call，谷歌开源的远程调用协议框架)，它是最为广泛运用的RPC通信协议(Remote Procedure Call，远程调用协议)，具有高效及带宽占用率小的特点。但是GRPC协议也具有一定的不足，由于GRPC本身也是基于TCP协议开发的，长连接数量过多的情况仍然会出现，而且在弱网络环境下TCP协议重传超时的RTO(Recovery Time Objective，恢复时间目标)也特别大。TCP协议建立连接的时候需要进行三次握手，需要耗费3次RTT(Round Trip Time，往返时间)，而UDP协议传输消息只需要1次RTT，加上回传的ACK(Acknowledge character，确认字符)，也只需要2次RTT，而且UDP协议的报文头长度只有8byte(字节)，而TCP协议的报文头长度有20byte，传输效率：

由上式可知，UDP协议传输小段消息的效率比TCP协议高。

为了提出新的即时通讯方法，首先对通信模型进行选型，申请人选取包括上述通信协议在内的多个广泛应用的通信协议进行测试。所有测试均使用单线程模型，使用下表中的各个通信协议发送随机echo字段，以测算每一种通信协议的延时。

表1.各种通信协议echo测试

由上表的测试结果可知，与其他通信协议相比采用HTTP协议的传输速度并没有落后太多，但是也毫无优势。

GRPC协议虽然在使用长连接进行数据传输时的传输速度相当优秀，但在频繁重连时传输速度会产生大幅下降。申请人在经过对源码的排查以及相关wiki指引之后发现，GRPC协议在稳定的网络环境下进行持久的http2(超文本传输协议2.0)模式的传输更能体现其优势，因此并不能适用于频繁重连的情况。

UDP协议作为传输速度第二的通信协议，兼具传输速度和传输包体信息率(正文占总报文包体的含量)的优势。但是由于UDP协议本身的无连接性，很难保证消息按照发送顺序送达或者消息能够送达。虽然消息顺序我们可以使用消息ID唯一确定，但是如果消息在传输的过程中丢失是不可容忍的，所以只使用UDP协议作为传输协议的方案是不可行的。

KCP协议(快速可靠协议)，其在开源社区广泛受到好评，它是一个底层使用UDP协议编写的传输层ARQ(Automatic Repeat-reQuest，自动重传请求)通信协议，但从测试数据来看，KCP协议在多种情况下的传输速度均并不理想。

经过上述测试和分析，如图1所示，申请人提出一种即时通讯方法，包括：

步骤S101，接收发送客户端101发送的消息数据并解析，获得消息数据的长度和目标地址。

步骤S102，响应于确定消息数据的长度大于预设阈值，则采用第一通信协议向目标地址发送消息数据；响应于确定消息数据的长度小于或等于预设阈值，则采用第二通信协议向目标地址发送消息数据。

可选的，第一通信协议为GRPC协议，第二通信协议为UDP协议。

可选的，实施例中的消息数据长度为消息数据包的字节数，预设阈值为UDP协议可接受的消息数据包的大小，如512byte。

发送消息数据的客户端1作为发送客户端101，与发送客户端101建立通信连接的管理节点2为发送管理节点201；接收消息数据的客户端1作为接收客户端102，与接收客户端102建立通信连接的管理节点2为接收管理节点202。接收管理节点202用于接收发送管理节点201所发送的消息数据。

如图8所示，当发送端8(包括发送客户端101和发送管理节点201)所要发送的消息数据长度小于或等于预设阈值时，通过UDP协议接口10向接收端9(包括接收客户端102或接收管理节点202)发送消息数据，UDP协议接口10与接收端9之间的通信连接为无连接形式。当发送端8所要发送的消息数据长度大于预设阈值时，通过GRPC协议接口11向接收端9发送消息数据，GRPC协议接口11与接收端9之间的通信连接为长连接形式。

当然，由于通信环境并不恒定，发送客户端101也可通过下述算法对预设阈值的大小进行调整。

如图9所示，发送客户端101先设置初始阈值、最大传输失败次数和检查周期。

步骤S501，发送客户端101记录采用第二通信协议向目标地址发送消息数据失败次数，得到传输失败次数。

步骤S502，到达检查周期时，发送客户端101对比传输失败次数和最大传输失败次数。

步骤S503，响应于确定传输失败次数小于或等于最大传输失败次数，则将设置的初始设阈值乘以1.5，得到第一调整阈值，且将第一调整阈值替换初始阈值，作为预设阈值。

步骤S504，响应于确定传输失败次数大于最大传输失败次数，则将初始阈值除以2，得到第二调整阈值，且将第二调整阈值替换初始阈值，作为预设阈值。

一些实施例中，步骤S101前还包括：响应于注册配置中心4的分配算法，与发送客户端101建立通信连接。

实施例中包括多个管理节点2，当发送客户端101发送通信连接的建立请求时，注册配置中心4对该请求进行响应，为发送客户端101分配一个管理节点2进行长连接。通过较为简单的哈希算法进行分配，例如有N个管理节点2，发送客户端101的标识符为k，则与该发送客户端101对应的管理节点2的序号为：hash(k)％N。

上述哈希算法虽然简单，但也存在问题。当管理节点2的总量发生变化时，也就是上述的N值发生变化，那么几乎所有的发送客户端101所对应的管理节点2都将改变，需要重新连接。

此外，相关技术中，为了保证服务器能够稳定提供服务，一般都会选择使用集群部署的方式来保证整个消息数据传输服务能够稳定对外进行提供服务。相关技术中常使用随机路由的方式，为用户选定一个固定IP地址(网络间互联协议提供的一种统一的地址格式)的主机。这种方法虽然方便，但是随机路由的方式容易造成热点问题(属于某个主机的用户数量过多，集群内其他主机的用户数量过少)。

一些实施例中，为了解决上述问题，采用一致性哈希算法进行发送客户端101与管理节点2之间的分配，过程如图2：

步骤S201，注册配置中心4生成一致性哈希环7。

可选的，本实施例采用的哈希算法为MurMur3Hash，这是一种高效且易于理解的散列方式。

如图3，本实施例中，所有管理节点2形成一个集群，集群中的任意一个管理节点2可以得知集群内其他管理节点2的IP地址。整个集群基于一致性哈希算法进行构建并进行管理，本地需要保存一个一致性哈希环7的副本，如图3和图4。集群中的每个管理节点2需要定时向注册配置中心4同步一致性哈希环7信息，用于维护与集群中其他管理节点2的消息畅通。

一致性哈希环7如图4所示，环上的数字是0～2^32-1。换句话说，本实施例所选用的哈希函数的值空间为0到2^32-1，即通过该哈希函数算得的哈希值是个32位无整型数字，这些数字组成一致性哈希环7。

步骤S202，根据哈希算法计算得到的第一哈希值映射于一致性哈希环7上。

换句话说，通过第一哈希值，在一致性哈希环7上找到各个管理节点2对应的位置。

步骤S203，注册配置中心4获取发送客户端101的唯一标识符，通过哈希算法计算得到标识符对应的第二哈希值，并根据第二哈希值将发送客户端101映射到一致性哈希环7上。

可选的，将用户的用户名作为发送客户端101的唯一标识符，通过MurMur3Hash算法计算该标识符所对应的第二哈希值。

步骤S204，按照预设方向与在一致性哈希环7上距离最近的第二哈希值对应的发送客户端101建立通信连接。

例如，用户的标识符哈希值为v，与之对应的管理节点2为k_i，k_i的值是v在一致性哈希环7上顺时针遍历遇到的下一个管理节点2(由于管理节点2的下标是从“0”开始)。

如图5所示，可采用二分法对目标第一哈希值对应的管理节点2进行快速查找定位。

步骤S301，判别L＜＝R是否成立，式中L的初始值为1，R为集群大小。

步骤S302，若步骤S301中的算式成立，则取M＝(L+R)/2。

步骤S303，若步骤S301中的算式不成立，则判断Pos是否等于集群大小，式中Pos为管理节点2的下标。

步骤S304，若步骤步骤S303的判断结果为是，则Pos＝0，查找成功。

步骤S305，判断ID为M-1的管理节点2的哈希值＜＝用户标识符的哈希值是否成立。

步骤S306，若步骤S305中的算式成立，则Pos暂取M，L暂取M+1，并重复步骤S301。

步骤S307，若步骤S305中的算式不成立，则R暂取M-1，并重复步骤S301。

可选的，发送管理节点201与发送客户端101之间的通信连接为长连接；同理，接收管理节点202与接收客户端201的通信连接也为长连接。

此外，若管理节点2的数量不多，则很可能出现几个管理节点2在一致性哈希环7上的距离较近，并不是均匀分布的，这也将会导致产生热点问题。此时，可将一个管理节点2的标识符进行编号，即一个管理节点2生成多个虚拟的标识符，再对多个虚拟的标识符进行哈希计算，得到多个虚拟的第一哈希值，并映射在一致性哈希环7上。此时，一致性哈希环7上分布着许多与真实的管理节点2对应的虚拟管理节点，由于虚拟管理节点的数量众多，其分布趋近于均匀分布。然后，再通过上述步骤查找与发送客户端101对应的虚拟管理节点，最后再将发送客户端101与该虚拟管理节点对应的真实管理节点2匹配即可。

一致性哈希算法用于解决客户端1(包括发送客户端101和接收客户端102)在一致性哈希环7上均匀分布的问题，它即使对有序的输入，依旧能够保持很好的散列效果，并且可以保持良好的处理效率，被广泛运用于降低分布式数据库扩张的时候的迁移成本。MurMur3Hash也是redis(Remote Dictionary Server，远程字典服务)用于hashtable(哈希表，也叫散列表)的一种哈希算法。

一些实施例中，管理节点2接收发送客户端101发送的消息数据并解析前，还包括：

将发送客户端101对发起的请求进行protobuf序列化编码，得到信息数据。

管理节点2接收信息数据后，进行protobuf反序列化编码，得到请求。

序列化是将用户通过发送客户端101发起的请求转换为可以存储或传输的形式的过程。

当然，发送客户端101与发送管理节点201之间，发送管理节点201与接收管理节点202之间以及接收管理节点202与接收客户端102之间进行信息传输时，都要经过序列化编码和反序列化编码的过程。

如图6可选的，即时通讯方法还包括：

步骤S701，设置发送时延。

步骤S702，响应于确定消息数据为音频数据或视频数据，则消息数据的发送间隔不小于发送时延。

可选的，实施例中，发送端8(包括发送客户端101及发送管理节点201)进行消息数据发送共有两种模式。一种是直接发送的模式，该方式适用于消息数据较少，如文本数据。另一种是延迟发送(或称消息等待机制，MessageWait)的模式，该方式适用于消息数据连续且较多，如视频或音频数据。延迟发送模式中，每个数据包均按照发送时延进行发送，发送时延为5至50ms。

可选的，为了降低服务器所承受的压力，实施例中的接收端9(包括接收客户端102及接收管理节点202)强制使用消息等待机制，消息数据的接收时延为50至1000ms。

如图7，在消息等待机制中，消息等待时间可以进行设置和调整。

S401，对消息等待时间进行初始设置，使消息等待时间为初始设置时间。

S402，判断步骤S401中的消息等待时间内是否发生预定事件(即消息数据的收发事件)。

S403，若发生，则消息等待时间保持步骤S401中的初始设置时间不变，并重复步骤S402。

S404，若未发生，则调整消息等待时间，将步骤S401中的初始设置时间乘以2得到新消息等待时间，但要保证新消息等待时间小于预先设置的最大等待时间，并重复步骤S402。

如图10所示，可选的，即时通讯方法还包括一种消息数据加密方法，包括

步骤S601，发送客户端101生成第一密钥。

可选的，第一秘钥为随机生成的16位AES秘钥，AES秘钥存储于发送客户端101的本地数据库中。

步骤S602，发送客户端101通过第一密钥加密消息数据，得到消息密文。

步骤S603，发送客户端101通过用户信息服务器获取接收端9对应的第二公钥。

可选的，第二公钥为RSA公钥。

可选的，用户信息服务器包括用于上传RSA公钥的SetAuthPubKey(上传用户公钥)接口和用于获取任意RSA公钥的GetAuthPubKey(获取用户公钥)接口。

步骤S604，发送客户端101通过第二公钥对第一密钥进行加密处理，得到加密密钥。

步骤S605，发送客户端101通过管理节点2向接收端9发送加密密钥和消息密文。

接收端9在接收加密秘钥后，会通过自己的RSA公钥解密加密秘钥，得到步骤S601中的AES秘钥，并将其存储在本地数据库。此后，当发送客户端101与接收端9之间传输消息数据时，若SecretLevel(机密等级)＝1，则使用本地存储的步骤S601中的AES秘钥解密，否则仍使用明文传输。

以下是上述实施例、UDP协议和GRPC协议之间的比对测试数据。

单客户端1发送大量消息数据测试。

表2. 1000个请求客户端1的超时时间设置为200ms

通信协议	客户端1响应超时	服务端接收超时	总耗时
				UDP	67.2％	0％	55.62ms
GRPC	0％	0％	43.22ms
				实施例	0％	0％	43.750ms

表3. 10000个请求，客户端1超时时间设为200ms

通信协议	客户端1响应超时	服务端接收超时	总耗时
				UDP	80.20％	7.72％	582.29ms
GRPC	92.56％	80.01％	389.28ms
				实施例	0％	0.01％	507.19ms

表4. 10000个请求，客户端1超时时间设为3000ms

通信协议	客户端1响应超时	服务端接收超时	总耗时
				UDP	79.70％	6.12％	591.33ms
GRPC	0％	0％	379.28ms
				实施例	0％	0％	501.19ms

由上述试验可以看出，实施例在低延时上和GRPC协议相同，而且客户端1的消息数据送达感知也比UDP协议更加友好。UDP协议虽然耗时也不高，但是它的客户端1消息数据送达感知过差，无法感知消息数据送达这一过程，如果包装成接口，使用接口的用户无法感知到消息数据已经送达，可能会对后续的消息数据传输造成影响。

单客户端1发送消息数据设置间隔测试。

由于此传输方式只应用于客户端1传输，并不应用于不同的服务端之间消息数据传输，所以对于消息的并行性的要求可以低一些。所以，如果为消息数据强制设置发送时间间隔，会对单个客户端1的消息数据发送与响应成功率带来极大的提升。

每个消息数据发送的间隔设置为10ms

表5. 1000个请求，客户端1超时时间设为200ms

通信协议	客户端1响应超时	服务器接收超时	总耗时
				UDP	0％	0％	10071.72ms
GRPC	0％	0％	10080.83ms
				实施例	0％	0％	10078.40ms

表6. 10000个请求，客户端1超时时间设为200ms

通信协议	客户端1响应超时	服务器接收超时	总耗时
				UDP	0％	0％	1min 40.706s
GRPC	0％	0％	1min 40.791s
				实施例	0％	0％	1min 40.712s

每个消息数据发送的间隔设置为5ms

表7. 1000个请求，客户端1超时时间设为200ms

通信协议	客户端1响应超时	服务器接收超时	总耗时
				UDP	0％	0％	5080.89ms
GRPC	0％	0％	5075.73ms
				实施例	0％	0％	5078.49ms

表8. 10000个请求，客户端1超时时间设为200ms

通信协议	客户端1响应超时	服务器接收超时	总耗时
				UDP	1.4％	0％	50.7074s
GRPC	0％	0％	50.7376s
				实施例	0％	0％	50.7713s

可以发现，在每个消息数据之间具有一定的时延之后，每一种协议的丢包率都几乎没有，而且基本传输的耗时都基本接近，而且实施例无论在何种网络状态下，传输速率和报文完整传输率都跟GRPC持平，可见实施例的稳定性可以得到保证。

多客户端1连接通信测试。

需要测试各类协议在多客户端1连接的情况下对服务端机器的内存占用大小，判断在服务端最多能够承载的客户端1连接个数。

表9. 100个客户端1

通信协议	服务端内存占用(vmRSS)	客户端1启动耗时
			UDP	8896KB	0.1s
GRPC	27872KB	0.1s
			实施例	10649KB	0.1s

表10. 1000个客户端

通信协议	服务端内存占用(vmRSS)	客户端1启动耗时
			UDP	11500KB	0.1s
GRPC	199858KB	0.1s
			实施例	33175KB	0.1s

表11.每种协议最多连接数量

通信协议	最多可以同时接入的客户端1数量
		UDP	1656
GRPC	1017
		实施例	1394

GRPC协议连接上限的原因是建立连接超时，可见这对于GRPC协议来说已经到达了单机GRPC协议客户端1连接数的上限。UDP协议达到上限的原因是系统内核资源不能够创建更多的客户端1，所以在服务器拥有更多CPU(Central Processing Unit，中央处理器)的情况下，同样的内存可以连接的客户端1数量将会更多。

在不同发送量下的对比测试。

如图11，在小数据(800并发)范围内可以分成两种情况讨论，当并发数在300以下的时候，这种时候消息数据的数量不多，对于UDP协议和GRPC协议的性能是一种凸显，因为他们不需要发送ack消息数据来确认消息是否收到。当超过300之后实施例的性能跟GRPC协议不相上下，甚至优于GRPC协议，其作为以UDP协议为基础协议的通信机制，占用内存一直低于GRPC协议，对于服务器来说，能够同时承载更多连接，同时处理更多人的消息。

如图12，在大数据(10000并发)范围内，当消息数据并发数量超过5000条的时候，由于ack判断需要锁的原因，客户端1探测到的相应时间开始变长，不过如此大量的并发已经不是单个客户端1可能出现的情况(一般客户端1上限为100)所以对于单个客户端1来说，组合协议机制可以获取更高的通信效率，服务器可以做到同时响应更多的客户端1消息数据。很显然，对于单人使用的单个客户端1来说，消息数据的并发量很难超过100，上千上万的并发稳定性对于单人客户端1是不需要的，但是可以被应用在服务端之间同步消息数据的时候使用。并且对比GRPC协议较为沉重的客户端1来说，实施例的客户端1占用内存更小，节约了不必要的内存，报文传输的无用报头被省略，也节省了传输过程中对网络环境的资源占用，所以实施例可广泛应用于整个通信系统的客户端1与服务端的交互上，用于实现客户端1收发消息数据的功能，而服务端的网络环境较为稳定，通信带宽更足，通信地址不会出现太多次的变化，并且承载的交互消息数据量数百倍甚至上千倍于客户端1，所以它们之间的交互通信将会使用GRPC协议。

Protobuf(Google Protocol Buffers，是Google提供一个具有高效的协议数据交换格式工具库。可用于通讯协议、数据存储等领域的语言无关、平台无关、可扩展的序列化结构数据格式)和json(JavaScript Object Notation,JS对象简谱，是一种轻量级的数据交换格式)的性能对比测试。

序列化算法的选型也是非常重要的，一个序列化算法的性能直接影响了通信协议的通信效率(会直接影响到同一个消息序列化之后的长度)。

json作为一个在互联网RPC中十分常用的序列化方式，它的优点是可读性高，而且整个json的结构十分简单，并且可拓展性高，可以用一个元组对应map[string]Object来标识json。但是json也有缺点，就是无法直接标识二进制元素，二进制元素如果需要使用json传输，就需要通过base64算法进行加码，让二进制用ascii码标识出来，不过如此处理之后的二进制串也比原先的二进制串长度更长，损失了传输效率。

与json作比较的是protobuf协议，它是Google开源的一种序列化协议，它的优点是序列化之后的串为二进制串，而且json中，如果一个元素的key太长，则序列化之后的json文本中依旧含有一个非常长的key字符串，而protobuf不会有这种问题，对于protobuf来说，每个key都是一个数字id，key的长度不会被体现在序列化之后的串中。但是protobuf对于每一个规定好的协议接口需要生成若干个对应的序列化工具文件，并不能像json一样方便的自由更改传输的参数的key。

用作测试的结构体:

t1:＝&BenchBody{

T1:"abbbbcddc",

T2:"assadswww",

T3:[]byte("10103eig23r6r8 wfefwefieoifi"),

T4:111223,

T5:3434583748,

Arr1:[]int32{3,1,2,3,5,6},

Arr2:[]string{"d1"，"d2"，"d3"},

ReplyArr:make([]*TestMsgReply，10)，

}

序列化之后的长度:

BenchmarkBenchBody_protoEncode-8 1000000000 0.000630 ns/op Protobuf序列化之后的长度是102,

BenchmarkBenchBody_jsonEncode-8 1000000000 0.000997 ns/op json序列化之后的长度是219，远高于protobuf。

反序列化性能:

执行100000次反序列化,protobuf耗时0.28s,json耗时0.36s。

经过上面的若干试验可以看出，protobuf的序列化与反序列化性能优于json，并且序列化之后的串长度远远小于json。

由上述测试可以确定，protobuf是较为理想的序列化方式。

包大小控制算法与传统拥塞控制的传输性能测试。

TCP协议的拥塞控制算法在超过ssthresh(慢启动阈值)的时候就会进入拥塞避免的状态，这对于当前的网络环境是一种浪费，同样的还有超时之后慢开始的操作，同样也是降低了通信效率。

如果使用实施例中的消息数据包大小控制算法，则可以在传输超时的时候直接将消息数据包大小变为超时消息数据包大小的一半，如果再超时则继续折半，如果不超时就将消息数据包大小变为原先的1.5倍，而且设置了消息数据包大小上限。如图13的变动状态也可以看出，在包大小上限为50，丢包率为5％的时候，消息数据传输速率很快就可以到达上限，并且丢包之后的恢复速度也很快，只需要次50次稳定传输即可。

下面的实验用于测试在各种丢包率环境下TCP协议与实施例的传输速率对比。每次发送10000个包。

表12.丢包率5％

通信协议	运行耗时	发送失败次数
			TCP	485ms	0
实施例	415ms	0

表13.丢包率10％

通信协议	运行耗时	发送失败次数
			TCP	523ms	0
实施例	428ms	0

表14.丢包率15％

通信协议	运行耗时	发送失败次数
			TCP	552ms	0
实施例	433ms	0

有上述测试数据可知，实施例相比于相关技术中的通信协议具有一定优势。

基于同一发明构思，与上述任意实施例所述的方法相对应的，本申请还提供了一种管理节点2，用于实现上述任意实施例的方法。

基于同一发明构思，与上述任意实施例方法相对应的，本申请还提供了一种电子设备，包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序，所述处理器执行所述程序时实现上任意一实施例所述的即时通讯方法。

图14示出了本实施例所提供的一种更为具体的电子设备硬件结构示意图，该设备可以包括：处理器1010、存储器1020、输入/输出接口1030、通信接口1040和总线1050。其中处理器1010、存储器1020、输入/输出接口1030和通信接口1040通过总线1050实现彼此之间在设备内部的通信连接。

处理器1010可以采用通用的CPU(Central Processing Unit，中央处理器)、微处理器、应用专用集成电路(Application Specific Integrated Circuit，ASIC)、或者一个或多个集成电路等方式实现，用于执行相关程序，以实现本说明书实施例所提供的技术方案。

存储器1020可以采用ROM(Read Only Memory，只读存储器)、RAM(Random AccessMemory，随机存取存储器)、静态存储设备，动态存储设备等形式实现。存储器1020可以存储操作系统和其他应用程序，在通过软件或者固件来实现本说明书实施例所提供的技术方案时，相关的程序代码保存在存储器1020中，并由处理器1010来调用执行。

输入/输出接口1030用于连接输入/输出模块，以实现信息输入及输出。输入输出/模块可以作为组件配置在设备中(图中未示出)，也可以外接于设备以提供相应功能。其中输入设备可以包括键盘、鼠标、触摸屏、麦克风、各类传感器等，输出设备可以包括显示器、扬声器、振动器、指示灯等。

通信接口1040用于连接通信模块(图中未示出)，以实现本设备与其他设备的通信交互。其中通信模块可以通过有线方式(例如USB、网线等)实现通信，也可以通过无线方式(例如移动网络、WIFI、蓝牙等)实现通信。

总线1050包括一通路，在设备的各个组件(例如处理器1010、存储器1020、输入/输出接口1030和通信接口1040)之间传输信息。

需要说明的是，尽管上述设备仅示出了处理器1010、存储器1020、输入/输出接口1030、通信接口1040以及总线1050，但是在具体实施过程中，该设备还可以包括实现正常运行所必需的其他组件。此外，本领域的技术人员可以理解的是，上述设备中也可以仅包含实现本说明书实施例方案所必需的组件，而不必包含图中所示的全部组件。

上述实施例的电子设备用于实现前述任一实施例中相应的即时通讯方法方法，并且具有相应的方法实施例的有益效果，在此不再赘述。

基于同一发明构思，与上述任意实施例方法相对应的，本申请还提供了一种非暂态计算机可读存储介质，所述非暂态计算机可读存储介质存储计算机指令，所述计算机指令用于使所述计算机执行如上任一实施例所述的即时通讯方法方法。

本实施例的计算机可读介质包括永久性和非永久性、可移动和非可移动媒体可以由任何方法或技术来实现信息存储。信息可以是计算机可读指令、数据结构、程序的模块或其他数据。计算机的存储介质的例子包括，但不限于相变内存(PRAM)、静态随机存取存储器(SRAM)、动态随机存取存储器(DRAM)、其他类型的随机存取存储器(RAM)、只读存储器(ROM)、电可擦除可编程只读存储器(EEPROM)、快闪记忆体或其他内存技术、只读光盘只读存储器(CD-ROM)、数字多功能光盘(DVD)或其他光学存储、磁盒式磁带，磁带磁磁盘存储或其他磁性存储设备或任何其他非传输介质，可用于存储可以被计算设备访问的信息。

上述实施例的存储介质存储的计算机指令用于使所述计算机执行如上任一实施例所述的即时通讯方法方法，并且具有相应的方法实施例的有益效果，在此不再赘述。

基于同一发明构思，与上述任意实施例方法相对应的，本申请还提供了一种即时通讯系统。

参考图3，即时通讯系统，包括：

发送客户端101，被配置为发送登录请求；还被配置为发送消息数据。

注册配置中心4，被配置为接收登录请求，并发送调用指令。还被配置为响应于确定身份验证通过，则发送通信连接指令。

用户认证中心3，被配置为接收调用指令，对发送客户端101进行身份验证。

如上述实施例提供的管理节点2，被配置为接收通信连接指令，与发送客户端101建立通信连接；还被配置为接收消息数据并转发送。

接收客户端102，被配置为接收管理节点2转发送的消息数据并展示。

可选的，即时通讯系统采用用户层、业务层和持久层的三层结构。接收端包括接收管理节点202和接收客户端102；发送客户端101和接收客户端102布置在用户层，发送管理节点201、接收管理节点202、用户认证中心3和注册配置中心4布置在业务层。

可选的，业务层还布置有文件服务器5。持久层布置数据库服务器6。

如图3所示，当发送客户端101需要使用即时通讯系统时，先向注册配置中心4发送登录请求，注册配置中心4通过用户认证中心3对发送客户端101的用户身份进行验证。若身份验证通过，注册配置中心4为发送客户端101分配一个管理节点2作为发送管理节点201，发送管理节点201与用户端建立通信连接。发送客户端101将想要传输的消息数据发送给发送管理节点201。发送管理节点201再将消息数据发送给与接收客户端102通信连接的接收管理节点202，最终，消息数据通过接收管理节点202传输给接收客户端102，进行展示。

注册配置中心4会定时请求集群中的各个管理节点2，对一致性哈希环7进行维护。此外，当新增或者删除管理节点2时，新增的管理节点2或将被删除的管理节点2会向注册配置中心4进行注册。注册配置中心4与管理节点2之间的通信连接为短连接而不是长连接，在图3中使用虚线表示。

注册配置中心4和用户认证中心3对用户信息具有本地缓存，因此不必与数据库服务器6保持长连接。管理节点2与数据库服务器6之间只在保存消息数据传输记录时进行通信连接，当不需要存储时两者之间无需保持通信连接。

为防止同一份文件在系统中多次传输，可将该文件存储于文件服务器5中，并将文件编号发送给需要该文件的用户，根据文件编号，用户可通过客户端1从文件服务器5拉取即可。

需要说明的是，本申请实施例的方法可以由单个设备执行，例如一台计算机或服务器等。本实施例的方法也可以应用于分布式场景下，由多台设备相互配合来完成。在这种分布式场景的情况下，这多台设备中的一台设备可以只执行本申请实施例的方法中的某一个或多个步骤，这多台设备相互之间会进行交互以完成所述的方法。

需要说明的是，上述对本申请的一些实施例进行了描述。其它实施例在所附权利要求书的范围内。在一些情况下，在权利要求书中记载的动作或步骤可以按照不同于上述实施例中的顺序来执行并且仍然可以实现期望的结果。另外，在附图中描绘的过程不一定要求示出的特定顺序或者连续顺序才能实现期望的结果。在某些实施方式中，多任务处理和并行处理也是可以的或者可能是有利的。

上述实施例的系统用于实现前述任一实施例中相应的即时通讯方法，并且具有相应的方法实施例的有益效果，在此不再赘述。

所属领域的普通技术人员应当理解：以上任何实施例的讨论仅为示例性的，并非旨在暗示本申请的范围(包括权利要求)被限于这些例子；在本申请的思路下，以上实施例或者不同实施例中的技术特征之间也可以进行组合，步骤可以以任意顺序实现，并存在如上所述的本申请实施例的不同方面的许多其它变化，为了简明它们没有在细节中提供。

另外，为简化说明和讨论，并且为了不会使本申请实施例难以理解，在所提供的附图中可以示出或可以不示出与集成电路(IC)芯片和其它部件的公知的电源/接地连接。此外，可以以框图的形式示出装置，以便避免使本申请实施例难以理解，并且这也考虑了以下事实，即关于这些框图装置的实施方式的细节是高度取决于将要实施本申请实施例的平台的(即，这些细节应当完全处于本领域技术人员的理解范围内)。在阐述了具体细节(例如，电路)以描述本申请的示例性实施例的情况下，对本领域技术人员来说显而易见的是，可以在没有这些具体细节的情况下或者这些具体细节有变化的情况下实施本申请实施例。因此，这些描述应被认为是说明性的而不是限制性的。

尽管已经结合了本申请的具体实施例对本申请进行了描述，但是根据前面的描述，这些实施例的很多替换、修改和变型对本领域普通技术人员来说将是显而易见的。例如，其它存储器架构(例如，动态RAM(DRAM))可以使用所讨论的实施例。

本申请实施例旨在涵盖落入所附权利要求的宽泛范围之内的所有这样的替换、修改和变型。因此，凡在本申请实施例的精神和原则之内，所做的任何省略、修改、等同替换、改进等，均应包含在本申请的保护范围之内。

Claims

1.一种即时通讯方法，其特征在于，包括：

2.根据权利要求1所述的方法，其特征在于，响应于确定所述消息数据的长度大于预设阈值，通过GRPC协议接口向接收端发送所述消息数据；

3.根据权利要求1所述的方法，其特征在于，接收所述发送客户端发送的消息数据并解析前，还包括：

4.根据权利要求3所述的方法，其特征在于，所述响应于注册配置中心的分配算法，与所述发送客户端建立通信连接，包括：

所述注册配置中心生成一致性哈希环；

5.根据权利要求1所述的方法，其特征在于，

所述接收所述发送客户端发送的消息数据并解析前，还包括：

6.根据权利要求1所述的方法，其特征在于，还包括：

7.根据权利要求1所述的方法，其特征在于，还包括：

设置发送时延；

8.根据权利要求1所述的方法，其特征在于，还包括：

所述发送客户端生成第一密钥；

9.一种管理节点，其特征在于，用于实现上述权利要求1至8所述的方法。

10.一种即时通讯系统，其特征在于，包括：

如权利要求9所述的管理节点，被配置为接收所述通信连接指令，与所述发送客户端建立通信连接；还被配置为接收所述消息数据并转发送；