netty有什么用（netty系列之:protobuf在UDP协议中的使用）

本文目录

• netty系列之:protobuf在UDP协议中的使用
• netty系列之:一口多用,使用同一端口运行不同协议
• 数据交换平台是用netty还是消息中间件
• 如何使用netty实现tcp的双向通信
• 使用Netty开发web项目可以吗
• spark为什么用netty 替代akka

netty系列之:protobuf在UDP协议中的使用

netty中提供的protobuf编码解码器可以让我们直接在netty中传递protobuf对象。同时netty也提供了支持UDP协议的channel叫做NioDatagramChannel。如果直接使用NioDatagramChannel，那么我们可以直接从channel中读写UDP对象：DatagramPacket。

但是DatagramPacket中封装的是ByteBuf对象，如果我们想要向UDP channel中写入对象，那么需要一个将对象转换成为ByteBuf的方法，很明显netty提供的protobuf编码解码器就是一个这样的方法。

那么可不可以将NioDatagramChannel和ProtobufDecoder,ProtobufEncoder相结合呢？

NioDatagramChannel中channel读写的对象都是DatagramPacket。而ProtobufDecoder与ProtobufEncoder是将protoBuf对象MessageLiteOrBuilder跟ByteBuf进行转换，所以两者是不能直接结合使用的。

怎么才能在UDP中使用protobuf呢？今天要向大家介绍netty专门为UDP创建的编码解码器DatagramPacketEncoder和DatagramPacketDecoder。

UDP的数据包在netty中是怎么表示呢？

netty提供了一个类DatagramPacket来表示UDP的数据包。netty中的UDP channel就是使用DatagramPacket来进行数据的传递。先看下DatagramPacket的定义：

DatagramPacket继承自DefaultAddressedEnvelope，并且实现了ByteBufHolder接口。

其中的ByteBuf是数据包中需要传输的数据，InetSocketAddress是数据包需要发送到的地址。

而这个DefaultAddressedEnvelope又是继承自AddressedEnvelope:

DefaultAddressedEnvelopee中有三个属性，分别是message,sender和recipient：

这三个属性分别代表了要发送的消息，发送方的地址和接收方的地址。

DatagramPacketEncoder是一个DatagramPacket的编码器，所以要编码的对象就是DatagramPacket。上一节我们也提到了DatagramPacket实际上继承自AddressedEnvelope。所有的DatagramPacket都是一个AddressedEnvelope对象，所以为了通用起见，DatagramPacketEncoder接受的要编码的对象是AddressedEnvelope。

我们先来看下DatagramPacketEncoder的定义：

DatagramPacketEncoder是一个MessageToMessageEncoder，它接受一个AddressedEnvelope的泛型，也就是我们要encoder的对象类型。

那么DatagramPacketEncoder会将AddressedEnvelope编码成什么呢？

DatagramPacketEncoder中定义了一个encoder,这个encoder可以在DatagramPacketEncoder初始化的时候传入：

实际上DatagramPacketEncoder中实现的encode方法，底层就是调用encoder的encode方法，我们来看下他的实现：

上面的逻辑就是从AddressedEnvelope中调用 msg.content() 方法拿到AddressedEnvelope中的内容，然后调用encoder的encode方法将其编码并写入到out中。

最后调用out的get方法拿出编码之后的内容，再封装到DatagramPacket中去。

所以不管encoder最后返回的是什么对象，最后都会被封装到DatagramPacket中，并返回。

总结一下，DatagramPacketEncoder传入一个AddressedEnvelope对象，调用encoder将AddressedEnvelope的内容进行编码，最后封装成为一个DatagramPacket并返回。

鉴于protoBuf的优异对象序列化能力，我们可以将ProtobufEncoder传入到DatagramPacketEncoder中，做为真实的encoder：

这样就把ProtobufEncoder和DatagramPacketEncoder结合起来了。

DatagramPacketDecoder是和DatagramPacketEncoder相反的操作,它是将接受到的DatagramPacket对象进行解码，至于解码成为什么对象，也是由传入其中的decoder属性来决定的：

DatagramPacketDecoder要解码的对象是DatagramPacket，而传入的decoder要解码的对象是ByteBuf。

所以我们需要一个能够解码ByteBuf的decoder实现，而和protoBuf对应的就是ProtobufDecoder。

先来看下DatagramPacketDecoder的decoder方法是怎么实现的：

可以看到DatagramPacketDecoder的decoder方法很简单，就是从DatagramPacket中拿到content内容，然后交由decoder去decode。

如果使用ProtobufDecoder作为内置的decoder,则可以将ByteBuf对象decode成为ProtoBuf对象，刚好和之前讲过的encode相呼应。

将ProtobufDecoder传入DatagramPacketDecoder也非常简单，我们可以这样做：

这样一个DatagramPacketDecoder就完成了。

可以看到，如果直接使用DatagramPacketEncoder和DatagramPacketDecoder加上ProtoBufEncoder和ProtoBufDecoder，那么实现的是DatagramPacket和ByteBuf直接的互相转换。

当然这里的ProtoBufEncoder和ProtoBufDecoder可以按照用户的需要被替换成为不同的编码解码器。

可以自由组合编码解码方式，就是netty编码器的最大魅力。

netty系列之:一口多用,使用同一端口运行不同协议

在之前的文章中，我们介绍了在同一个netty程序中支持多个不同的服务，它的逻辑很简单，就是在一个主程序中启动多个子程序，每个子程序通过一个BootStrap来绑定不同的端口，从而达到访问不同端口就访问了不同服务的目的。

但是多个端口虽然区分度够高，但是使用起来还是有诸多不便，那么有没有可能只用一个端口来统一不同的协议服务呢？

今天给大家介绍一下在netty中使用同一端口运行不同协议的方法,这种方法叫做port unification。

在讲解自定义port unification之前，我们来看下netty自带的port unification，比如SocksPortUnificationServerHandler。

我们知道SOCKS的主要协议有3中，分别是SOCKS4、SOCKS4a和SOCKS5，他们属于同一种协议的不同版本，所以肯定不能使用不同的端口，需要在同一个端口中进行版本的判断。

具体而言，SocksPortUnificationServerHandler继承自ByteToMessageDecoder，表示是将ByteBuf转换成为对应的Socks对象。

那他是怎么区分不同版本的呢？

在decode方法中，传入了要解码的ByteBuf in，首先获得它的readerIndex：

我们知道SOCKS协议的第一个字节表示的是版本，所以从in ByteBuf中读取第一个字节作为版本号：

有了版本号就可以通过不同的版本号进行处理，具体而言，对于SOCKS4a，需要添加Socks4ServerEncoder和Socks4ServerDecoder：

对于SOCKS5来说，需要添加Socks5ServerEncoder和Socks5InitialRequestDecoder两个编码和解码器：

这样，一个port unification就完成了，其思路就是通过传入的同一个端口的ByteBuf的首字节，来判断对应的SOCKS的版本号，从而针对不同的SOCKS版本进行处理。

在本例中，我们将会创建一个自定义的Port Unification，用来同时接收HTTP请求和gzip请求。

在这之前，我们先看一下两个协议的magic word，也就是说我们拿到一个ByteBuf，怎么能够知道这个是一个HTTP协议，还是传输的一个gzip文件呢？

先看下HTTP协议，这里我们默认是HTTP1.1,对于HTTP1.1的请求协议，下面是一个例子：

HTTP请求的第一个单词就是HTTP请求的方法名，具体而言有八种方法，分别是：

OPTIONS
返回服务器针对特定资源所支持的HTTP请求方法。也可以利用向Web服务器发送’*’的请求来测试服务器的功能性。
HEAD
向服务器索要与GET请求相一致的响应，只不过响应体将不会被返回。这一方法可以在不必传输整个响应内容的情况下，就可以获取包含在响应消息头中的元信息。
GET
向特定的资源发出请求。注意：GET方法不应当被用于产生“副作用”的操作中，例如在Web Application中。其中一个原因是GET可能会被网络蜘蛛等随意访问。
POST
向指定资源提交数据进行处理请求（例如提交表单或者上传文件）。数据被包含在请求体中。POST请求可能会导致新的资源的建立和/或已有资源的修改。
PUT
向指定资源位置上传其最新内容。
DELETE
请求服务器删除Request-URI所标识的资源。
TRACE
回显服务器收到的请求，主要用于测试或诊断。
CONNECT
HTTP/1.1协议中预留给能够将连接改为管道方式的代理服务器。

那么需要几个字节来区分这八个方法呢？可以看到一个字节是不够的，因为我们有POST和PUT，他们的第一个字节都是P。所以应该使用2个字节来作为magic word。

对于gzip协议来说，它也有特殊的格式，其中gzip的前10个字节是header，其中第一个字节是0x1f，第二个字节是0x8b。

这样我们用两个字节也能区分gzip协议。

这样，我们的handler逻辑就出来了。首先从byteBuf中取出前两个字节，然后对其进行判断，区分出是HTTP请求还是gzip请求：

对应的，我们还需要对其添加相应的编码和解码器，对于gzip来说，netty提供了ZlibCodecFactory：

对于HTTP来说，netty也提供了HttpRequestDecoder和HttpResponseEncoder还有HttpContentCompressor来对HTTP消息进行编码解码和压缩。

添加了编码和解码器之后，如果你想自定义一些操作，只需要再添加自定义的对应的消息handler即可，非常的方便。

本文的例子可以参考： learn-netty4

数据交换平台是用netty还是消息中间件

中间件是一种独立的系统软件或服务程序，分布式应用软件借助这种软件在不同的技术之间共享资源。中间件位于客户机/服务器的操作系统之上，管理计算机资源和网络通讯。是连接两个独立应用程序或独立系统的软件。相连接的系统，即使它们具有不同的接口，但通过中间件相互之间仍能交换信息。执行中间件的一个关键途径是信息传递。通过中间件，应用程序可以工作于多平台或OS环境。

消息中间件利用高效可靠的消息传递机制进行平台无关的数据交流，并基于数据通信来进行分布式系统的集成。通过提供消息传递和消息排队模型，它可以在分布式环境下扩展进程间的通信。

说白了，就像打电话一样，现在不仅仅能电话和电话打，电话和网络这间也能打，你可以把网络和电话线，理解成中间件，他就是那么一个转换平台

ke./view/3118541.htm消息中单件

ke./view/23710.htm中间件

如何使用netty实现tcp的双向通信

一、什么是Netty Netty是一个高性能 事件驱动、异步非堵塞的IO(NIO)Java开源框架，Jboss提供，用于建立TCP等底层的连接，基于Netty可以建立高性能的Http服务器，快速开发高性能、高可靠性的网络服务器和客户端程序。

使用Netty开发web项目可以吗

***隐藏网址***
netty是中间件。你要用netty开发web项目可以用webserver连netty通信实现业务处理。但是单独用netty是不行的，他不具备webserver的一些特性。

spark为什么用netty 替代akka

Jedis已经足够强大，它的网络连接是基于阻塞式IO，实现非常简单易懂，但是OIO和NIO相比性能上有劣势，于是决定通过NIO来实现和Redis服务器的网络连接，现在业界最优秀的NIO框架非Netty莫属了，正好以前也学过Netty框架，所以决定基于Netty来实现