CN111683069A - 一种基于netty框架的自定义通信协议及服务方法 - Google Patents

Abstract

本发明公开了一种基于netty框架的自定义通信协议及服务方法。本发明包括如下步骤：步骤1、客户端发起连接并和服务端建立加密的TCP传输通道；步骤2、服务端并发接收来自多个客户端的连接；步骤3、发送方用TLV编码器把业务信令解析成字节流；发送方包括客户端或服务端；步骤4、接收方用TLV解码器把接收到的字节流解析成业务信令；步骤5、服务端并发处理海量业务逻辑。本发明有益效果如下通过扩展netty框架提高系统的数据监控能力。基于TCP层传输实现保证了数据流的准确性。自定义TLV协议的特性提高了数据传输效率，降低客户端和服务端系统版本迭代的耦合性。提出了一种大规模并发网络请求处理的解决能力。

Description

一种基于netty框架的自定义通信协议及服务方法

技术领域

本发明涉及网络字节流传输、高并发业务处理等领域，提出了一种基于netty框架的自定义通信协议及服务系统。

背景技术

在互联网在线应用服务中，一般产品中采用http传输协议和json数据协议较为普遍。这种实现模式的好处是开发实现门槛较低，数据简单直观不容易出错，容易测试，比较符合人一般直观思维，有利也有弊，它的局限性在于传输过程中数据冗余性较高，数据并发处理性能不佳，在一些要求低延迟和高并发的应用场景下使用这套技术组合则会显得非常吃力。如游戏、聊天和证券交易等高并发操作的网络应用场景，传输交互频繁，交互信令内容小，交互的每个信令对传输时效性要求很高对准确度要求很高。通过在netty网络框架基础上实现的这类通信功能，可以满足低延迟和高稳定性，做到事半功倍，能够很好满足上面这些特定要求。

发明内容

本发明的目的是针对现有技术实现上的不足和局限性，提供一种基于netty框架的自定义通信协议及服务系统。

一种基于netty框架的自定义通信协议及服务系统，包括协议规范定义，数据解码器，数据编码器，数据通道，io事件处理器，线程处理模型。netty是一种高效的网络通信框架和一种能灵活集成自定义数据协议编解码器的框架。本发明通过netty直观的bytebuf访问机制、内存回收机制、内存泄露追踪、支持开启TCPNODELAY等特性，本发明能够支持大规模高并发的请求响应，适合实时性稳定性要求高的网络游戏和证券交易等场景，本发明利用处理器链扩展了自定义数据通信协议，能有效压缩通信数据包，充分利用网络空间，通过减少通信带宽占用量，进一步提高了数据传输与接收效率。本发明用的自定义数据通信协议格式，相比通用的json，xml等格式，有更加快速高效的解析性能。

本发明实现了在TCP/IP层之上的应用层通信协议，可以用自定义协议负责编解码和粘包等处理，这是一种语言中立的数据传输格式，数据格式主体为Tag-Length-Value(以下概称TLV)的自定义协议，是传统Length-Value协议的变种，增加了Tag值，使网络传输的两端相对更加灵活。使用TLV协议格式传输后，编码器端可以自由增减不需要的字段而不会引起解码端的出错，降低服务版本升级迭代的耦合性。该自定义TLV协议规范的核心技术有2点，一是Value属性字段支持内嵌TLV格式，一个字段是复杂类型时候，一般就没办法用基本的TLV格式来表示，用循环内嵌的subTLV可以极大提升了该自定义协议的数据的表示能力。理论上支持一个subTLV里面可以再包含一个subTLV格式。二是Length属性字段长度支持动态扩展，一个字节为8位，在二进制中最大为:1111111111111111，等于十进制65535。在预设TLV协议中，我们定义，表示L值(即长度域值)的每个字节中，最高位不代表符号位也不代表数值，剩余15位用来表示L值；所以一个字节可表示的V区长度范围对应十进制为0～32767，对应十六进制的L值为0～7F。所以一个字节可以表示的L值最大为7F，当L值大于等于十六进制的80时，超出了两个字节可表示范围，则扩容到四个字节表示L值，80。首先判断第一长度域值本身所占的字节数是否大于预设字节数，如果第一长度域值本身所占的字节数大于预设字节数，则证明预设字节数不能完整的表示第一长度域值的本身大小；如果第一长度域值本身所占的字节数小于或等于预设字节数，则证明预设字节数可以完整的表示第一长度域值的本身大小。其中，在发明本实施例中，预设字节数为2。约定可以扩容到4字节来表示长度，一般在传输多媒体文件的场景中会使用到4字节长度表示。

一种基于netty框架的自定义通信协议及服务方法，包括如下步骤：

步骤1、客户端发起连接并和服务端建立加密的TCP传输通道；

步骤2、服务端并发接收来自多个客户端的连接；

步骤3、发送方(客户端或服务端)用TLV编码器把业务信令解析成字节流；

步骤4、接收方用TLV解码器把接收到的字节流解析成业务信令；

步骤5、服务端并发处理海量业务逻辑。

步骤详细的实现说明

步骤1实现如下：

1-1.建立连接，客户端主动向服务端指定的socket端口发送建立连接的请求，服务端根据当前资源占用情况，创建一个文件描述符，指派一个随机的端口和客户端建立TCP长连接。并维护一份全局的session信息，广播和通知等信令需要用到全局session；

1-2.获取动态密钥，为了消息传输的安全性和高效性，数据传输需既要加密又要求加解密速度快，用公私钥形式的非对称加密安全有保证，但是效率会有影响，故首次请求先使用预先内置在客户端的公钥加密业务信令，服务端收到业务信令后用对应的私钥解密，再生成一个动态密钥，再用私钥加密该动态密钥并返回给客户端，客户端收到响应后用公钥解密出动态密钥并缓存本次临时动态密钥，而服务端维护所有临时连接的动态密钥，一个动态密钥在一次tcp断开连接后就会失效；

1-3.加密通信，接下来的请求响应的数据加解密都是用对称加密算法，并在对称加密算法中使用上一步生成的动态密钥，这样分两步的做法即保证了密钥交互的安全性，又保证了加解密的时间效率；

根据步骤1-2和1-3所示，不同阶段切换使用不同加解密逻辑依赖到netty中pipeline处理链的动态替换的特性，可方便从RSA算法handler到AES算法handler的删除和添加。

步骤2所述的服务端并发接收来自多个客户端的连接实现如下：

2-1.创建一个ServerSocketChannel后指定一个服务监听端口，然后把ServerSocketChannel注册绑定到一个bossseletor中，bossselector只监听连接事件；

2-2.把bossseletor监听到每一个和客户端相关的socketChannel注册绑定到一组workselector中，workselector主要监听读事件；

2-3.在workselector监听到数据可读事件后会通知应用程序去读取保留在系统内核的字节流；

2-4.应用程序会调用channelRead方法读取数据，每一个socketChannel在生命周期内都会绑定关联唯一一个workeventloop线程中，这样保证了事件按顺序处理，不需要额外同步开销就是线程安全的；

2-5.把耗时的业务处理器指定到专用业务线程池，使从io线程中独立分开。

步骤3实现如下：

3-1.发送方按照业务上的需要，把业务信令包装转化成一个个字节流数组，按照自定义数据协议格式：

首先对象属性按照事先定义的TAG值打包成一个个TLV，并把多个TLV字节流并成一个总的包体，加密包体内容，然后根据业务code和包体length计算打包一个24字节长度的固定包头，最后把包头和包体内容合并成要发送的字节流数组；

3-2.通过网络通道发送字节流，在业务上相互独立没有次序要求的数据包可以同时并行发送，客户端设置超时时间，在超过指定时间没有收到响应则放弃等待；

3-3.客户端并发收到多个响应信令可通过uuid来关联区分特定业务。

步骤4实现如下：

4-1.通道可读事件触发channelRead开始尝试读取24个字节数组作为协议包头，当可读取字节数组不够24，说明字节流还没有读取结束，也有可能是传输出现异常，这种情况直接返回不做任何处理，等待后面该通道新的可读事件；

4-2.当可读取字节数组等于或者超过24个字节，读取24个字节按协议格式依次解析出Version，Length，UUID，Type，Code；

4-3.根据步骤4-2中解析得到的Length数据，在计算出需要读取的包体大小，读取策略判断方式与步骤4-2相同，可读字节流不够则缓存包头对象并暂时退出等待下次可读事件,在可读字节流达到需要的包体大小长度时则执行读取整个包体到bytebuf数组中，用动态密钥解密该bytebuf字节流数组；

4-4.根据Code找到预先约定定义的业务对象来解析存储收到的包体数据；

所述的用自定义的TLV解析包体内容，这里接收方是基于netty框架实现的自定义协议解码器handler，使用TLV协议格式传输后，编码器端可以自由增加和删除不需要的字段而不会引起解码端的出错混乱，降低服务升级迭代的成本，降低耦合性。

步骤5实现如下：

5-1.通过BOSSGROUP线程组监听来自客户端的连接事件，创建客户端对应的socketChannel；

5-2.通过WORKGROUP线程组监听5-1步骤中创建的socketChannel通道的读事件，可轮询并发读取多个socketChannel中的数据到bytebuf中，解码bytebuf转换成POJO对象；

5-3.通过biz线程池来处理从5-2中得到的POJO对象，根据业务逻辑进行一些耗时的操作，比如读写数据库，文件访问，资源同步等待等耗时操作，独立业务线程池的使用避免了耗时业务线程影响到字节流读写线程和协议编解码线程；

5-4.通过5-3步骤处理后得出需要返回给客户端POJO对象，通过操作socketChannel的write方法将此POJO对象再交还给WORKGROUP线程处理，取出socketChannel绑定的线程并由该线程处理对象编码和字节流输出。每一个socketChannel在生命周期内都只会绑定关联唯一一个workeventloop线程中，这样保证了事件按顺序处理，不需要额外同步开销就能做到线程的安全运行。

本发明有益效果如下：

1.通过扩展框架提高系统的监控能力。

2.基于TCP层实现可保证了传输的准确性。

3.自定义TLV协议的特性提高了数据传输效率，降低客户端和服务端系统版本迭代的耦合性。

4.提出了一种大规模并发网络请求处理的解决能力。

附图说明

图1不同阶段数据加密传输示意图；

图2同步非阻塞IO多路复用时序图；

图3netty数据流向及处理器链路图；

图4TLV自定义协议格式规范图；

图5Netty数据流转及线程处理模型图。

具体实施方式

为了加深对本发明的理解，下面结合附图对本发明进一步说明，该实施仅用于解释本发明，并不对本发明的保护范围构成限定。

如图1-图5所示，本发明所述的是一种基于netty框架的自定义通信协议及服务系统。

如图1所示，客户端和服务端建立TCP长连接后的，不同的阶段会使用不同的加密算法来传输数据，如图所示加密算法分对称加密和非对称加密。客户端首次向服务端请求得到本连接使用的动态密钥，首次请求交互使用非对称公私钥加密算法，客户端收到响应后用公钥解密出动态密钥并缓存临时动态密钥，而服务端维护所有连接的动态密钥，一个动态密钥在一次tcp断开连接后就会失效。在接下来的请求响应的数据加解密都是用对称加密算法，使用对应生成的动态密钥，这样分两步的做法即保证了密钥交互的安全性，又保证了加解密的时间效率，切换不同加密算法依赖到netty中pipeline处理器链的可动态删除和添加的特性。

如图2所示，在netty框架中，我们可以采用基于jdknio包实现的IO多路复用模型的事件驱动来支持多客户端并发读取数据，以buffer块形式把字节流数据从系统内核拷贝到应用内存，不需要流式阻塞读取。

如图3所示，在netty中我们采用了一种合理规范的数据处理器链式结构，只有在约定的位置放置自定义通信协议处理器及业务处理器，整个数据流程才能正确运转起来。

如图4所示，这是一个自定义通信协议的完整格式规范、通过网络传输的一个完整包由固定长度的包头和不定长的包体组成，包头格式介绍：Version(协议版本)，当前固定为1。Length(包头加包体总长度)，3个字节表示长度[24,2^24-1]，包头固定24字节，可计算出剩余包体长度length-24。UUID(信令唯一标识)，一条完整的消息链接有一个独立唯一的id用来标示自己，异步化的业务场景需要唯一id来关联请求和回来的响应。Type(消息类型)，可以表示请求(1)，响应(2)，通知(3)。Code(业务标识)，一个code代表一个具体业务接口，根据code匹配预先定义的业务对象来解析接收到的包体数据。数据读取解析如下：

步骤1根据自定义协议中的约定格式，尝试读取24个字节数组作为协议包头header，当可读取字节不够24，说明字节流还没有读取结束，也有可能是消息传输出现异常，这种情况直接返回不做任何处理，等待后面该通道新的可读事件。当可读取字节数组等于或者超过24个字节，读取前24个字节作为包头的内容，该字节流按协议格式依次解析出Version，Length，UUID，Type，Code这5个值。

步骤2解析完header数据后根据上一步中解析得到的Length数据，再计算出需要读取的包体大小，读取策略判断同步骤1，可读字节流不够则缓存header对象并暂时退出等待下次可读事件。在可读字节流达到需要的包体大小长度时则读取整个包体到bytebuf数组中。

步骤3用动态密码解密还原该bytebuf字节流数组。

步骤4用自定义的nettyhandler解码器解析包体内容，按照TLV协议格式逐个解析，依据TLV的编码特性，编码器端可以增加和移除不需要的字段而不引起解码端的混乱，降低服务升级迭代的成本，可降低耦合性。支持数据类型有简单类型和复杂类型：简单类型指一般的整数，浮点型数据，及字符串；复杂类型包括2类，由简单类型组成的集合类型，如int[],list<double>，set<string>，map<string,string>,及自定义结构体类型,如struct{int,char,list}。

如图5所示，在采用netty的线程组处理模型后，基于异步事件的数据流处理能达到一种高并发处理信令的能力。为了达到这一目的，可通过BOSSGROUP线程组监听接收来自客户端的连接事件并创建对应的socketChannel通道，通过WORKGROUP线程组监听该socketChannel的读事件，轮询读取该通道中的数据到bytebuf对象中并解码该字节数组为POJO对象，根据不同的业务场景通过事先创建的业务线程组来处理一些耗时的操作，独立的业务线程组池的使用避免了耗时业务线程影响到字节流读写和协议编解码，最后业务线程计算得出需要返回给客户端POJO对象，通过操作socketChannel的write方法将此POJO对象再交还给WORKGROUP线程组处理。

以上内容和结构描述了本发明产品的基本原理、主要特征和本发明的优点，本行业的技术人员应该了解。上述实例和说明书中描述的只是说明本发明的原理，在不脱离本发明精神和范围的前提下，本发明还会有各种变化和改进，这些变化和改进都属于要求保护的本发明范围之内。本发明要求保护范围由所附的权利要求书及其等效物界定。

Claims (7)

1.一种基于netty框架的自定义通信协议及服务方法，其特征在于包括如下步骤：

步骤1、客户端发起连接并和服务端建立加密的TCP传输通道；

步骤2、服务端并发接收来自多个客户端的连接；

步骤3、发送方用TLV编码器把业务信令解析成字节流；发送方包括客户端或服务端；

步骤4、接收方用TLV解码器把接收到的字节流解析成业务信令；

步骤5、服务端并发处理海量业务逻辑。

2.根据权利要求1所述的一种基于netty框架的自定义通信协议及服务方法，其特征在于步骤1具体实现如下：

1-1.建立连接，客户端主动向服务端指定的socket端口发送建立连接的请求，服务端根据当前资源占用情况，创建一个文件描述符，指派一个随机的端口和客户端建立TCP长连接；并维护一份全局的session信息，广播和通知等信令需要用到全局session；

1-2.获取动态密钥，为了消息传输的安全性和高效性，数据传输需既要加密又要求加解密速度快，用公私钥形式的非对称加密安全有保证，但是效率会有影响，故首次请求先使用预先内置在客户端的公钥加密业务信令，服务端收到业务信令后用对应的私钥解密，再生成一个动态密钥，再用私钥加密该动态密钥并返回给客户端，客户端收到响应后用公钥解密出动态密钥并缓存本次临时动态密钥，而服务端维护所有临时连接的动态密钥，一个动态密钥在一次tcp断开连接后就会失效；

1-3.加密通信，接下来的请求响应的数据加解密都是用对称加密算法，并在对称加密算法中使用上一步生成的动态密钥，这样分两步的做法即保证了密钥交互的安全性，又保证了加解密的时间效率；

根据步骤1-2和1-3所示，不同阶段切换使用不同加解密逻辑依赖到netty中pipeline处理链的动态替换的特性，方便从RSA算法handler到AES算法handler的删除和添加。

3.根据权利要求1或2所述的一种基于netty框架的自定义通信协议及服务方法，其特征在于步骤2所述的服务端并发接收来自多个客户端的连接实现如下：

2-1.创建一个ServerSocketChannel后指定一个服务监听端口，然后把ServerSocketChannel注册绑定到一个boss seletor中，boss selector只监听连接事件；

2-2.把boss seletor监听到每一个和客户端相关的socketChannel注册绑定到一组work selector中，work selector主要监听读事件；

2-3.在work selector监听到数据可读事件后会通知应用程序去读取保留在系统内核的字节流；

2-4.应用程序会调用channelRead方法读取数据，每一个socketChannel在生命周期内都会绑定关联唯一一个work eventloop线程中，这样保证了事件按顺序处理，不需要额外同步开销就是线程安全的；

2-5.把耗时的业务处理器指定到专用业务线程池，使从io线程中独立分开。

4.根据权利要求3所述的一种基于netty框架的自定义通信协议及服务方法，其特征在于步骤3实现如下：

3-1.发送方按照业务上的需要，把业务信令包装转化成一个个字节流数组，按照自定义数据协议格式：

首先对象属性按照事先定义的TAG值打包成一个个TLV，并把多个TLV字节流并成一个总的包体，加密包体内容，然后根据业务code和包体length计算打包一个24字节长度的固定包头，最后把包头和包体内容合并成要发送的字节流数组；

3-2.通过网络通道发送字节流，在业务上相互独立没有次序要求的数据包可以同时并行发送，客户端设置超时时间，在超过指定时间没有收到响应则放弃等待；

3-3.客户端并发收到多个响应信令可通过uuid来关联区分特定业务。

5.根据权利要求4所述的一种基于netty框架的自定义通信协议及服务方法，其特征在于步骤4实现如下：

4-1.通道可读事件触发channelRead开始尝试读取24个字节数组作为协议包头，当可读取字节数组不够24，说明字节流还没有读取结束，也有可能是传输出现异常，这种情况直接返回不做任何处理，等待后面该通道新的可读事件；

4-2.当可读取字节数组等于或者超过24个字节，读取24个字节按协议格式依次解析出Version，Length，UUID，Type，Code；

4-3.根据步骤4-2中解析得到的Length数据，在计算出需要读取的包体大小，读取策略判断方式与步骤4-2相同，可读字节流不够则缓存包头对象并暂时退出等待下次可读事件,在可读字节流达到需要的包体大小长度时则执行读取整个包体到bytebuf数组中，用动态密钥解密该bytebuf字节流数组；

4-4.根据Code找到预先约定定义的业务对象来解析存储收到的包体数据；

所述的用自定义的TLV解析包体内容，这里接收方是基于netty框架实现的自定义协议解码器handler，使用TLV协议格式传输后，编码器端可以自由增加和删除不需要的字段而不会引起解码端的出错混乱。

6.根据权利要求5所述的一种基于netty框架的自定义通信协议及服务方法，其特征在于步骤5实现如下：

5-1.通过BOSSGROUP线程组监听来自客户端的连接事件，创建客户端对应的socketChannel；

5-2.通过WORKGROUP线程组监听5-1步骤中创建的socketChannel通道的读事件，可轮询并发读取多个socketChannel中的数据到bytebuf中，解码bytebuf转换成POJO对象；

5-3.通过biz线程池来处理从5-2中得到的POJO对象，根据业务逻辑进行一些耗时的操作，比如读写数据库，文件访问，资源同步等待等耗时操作，独立业务线程池的使用避免了耗时业务线程影响到字节流读写线程和协议编解码线程；

5-4.通过5-3步骤处理后得出需要返回给客户端POJO对象，通过操作socketChannel的write方法将此POJO对象再交还给WORKGROUP线程处理，取出socketChannel绑定的线程并由该线程处理对象编码和字节流输出；每一个socketChannel在生命周期内都只会绑定关联唯一一个work eventloop线程中，这样保证了事件按顺序处理，不需要额外同步开销就能做到线程的安全运行。

7.根据权利要求6所述的一种基于netty框架的自定义通信协议及服务方法，其特征在于完整包由固定长度的包头和不定长的包体组成，包头格式介绍：Version(协议版本)，当前固定为1；Length(包头加包体总长度)，3个字节表示长度[24,2^24-1]，包头固定24字节，可计算出剩余包体长度length-24；UUID(信令唯一标识)，一条完整的消息链接有一个独立唯一的id用来标示自己，异步化的业务场景需要唯一id来关联请求和回来的响应；Type(消息类型)，可以表示请求(1)、响应(2)、通知(3)；Code(业务标识)，一个code代表一个具体业务接口，根据code匹配预先定义的业务对象来解析接收到的包体数据。

Images