前言 从这篇文章开始，开始进入源码分析阶段。在之前的入门篇和实战篇中，通过代码的编写和各种特性的讲解，让我们对 Netty 有了充分的感性认知。那么接下来，通过对代码的详细走读，来细细查看哪些在感性直觉背后的实现原理。 Netty 的线程模型 Netty 的线程模型其实没有什么太特别的地方，属于比较自然而然的设计。 首先，基于Selector可以同时监控多个链接的特性，很容易想到将所有通道都注册到一个selector对象，然后死循环获取通道上的就绪事件并且进行处理。这就是最朴素的设计，也就是作为的单线程模型。这种模式，比较适合客户端，用于服务端的话，因为线程数太少，无法有效的利用多核 CPU ...

引言 在网络开发中，不可避免的会与许多标准通讯协议打交道。在这方面，Netty为开发者提供了很大的便利。Netty自身除了提供编解码机制外，还提供了大量现成协议的编解码支持，这部分支持的内容可以在包netty-codec中找到。当然也包括我们今天要讲述，对Http的支持。 有了对Http编解码协议的支持，我们完全可以使用Netty来开发一款web容器或者符合需求的Http容器。今天，我们就以文件的下载作为场景，介绍下Netty对Http的支持。本文中使用的相关代码存储于：https://gitee.com/eric_ds/learnNetty/tree/master/http 目录下。 Htt...

引言 上篇文章中，详细阐述了服务端核心功能的设计思路和实现逻辑。与服务端相比起来，客户端的实现就比较简单了。Netty为开发者尽最大可能保证了编程模型的一致性。服务端和客户端的区别仅仅只是在于Channel具体实现类和BootStrap引导类的区别。 客户端的代码托管于：https://gitee.com/eric_ds/learnNetty/tree/master/client 命令编码 和服务端一样，客户端需要发送消息，首要考虑的问题也是对命令对象Command的二进制编码问题。每个命令对象本身内部最清晰自身结构，因此这里采用和服务端编码Receive对象一样的思路，在Command接口上...

前言 前文中我们进行了需求澄清，协议制订，服务端设计，本文将在这些的基础上实现完整的服务端功能。 编解码器实现 消息的收发基础是编解码器。上文对协议的制订，最外围的结构是报文头加报文体的形式。针对这个结构，实现报文分割，我们可以直接接触Netty提供的内嵌支持LengthFieldBasedFrameDecoder进行报文体的长度确定和分割。 报文体中是具体的消息，我们需要根据消息的不同类型来进行具体的区分，这部分就需要自行实现解码器了，自定义解码器的类名制订为handler.CommandDecoder。解码器的核心思路读取第一个字节的协议类型，而后根据不同的协议类型，按照协议读取出对应的字...

前言 在入门篇中我们介绍了Netty的主要组件，线程模型，以及基本的使用方式；掌握了这些内容，就足以在实际的项目开发中使用Netty来进行网络程序的构建。从本章开始，我们将以实际中开发的项目作为例子，进行Netty实战讲解。 本篇文章我们将实现一个网络多人聊天程序。 需求澄清 对于该网络多人聊天项目，需要实现的功能有：  支持客户端以用户名发送注册申请，服务端响应是否成功，成功的注册名需要全局唯一。 支持客户端以用户名进行登陆。 支持单客户端对单客户端进行消息发送和接收。 支持客户端以群聊名发送群聊创建申请，服务端响应是否成功，注册的群聊名需要全局唯一。 支持客户端使用群聊名加入一个群聊。 在...

粘包和拆包现象 在网络通信中，客户端向服务端发送两个数据包，C1和C2.如下图  站在客户端的角度，它是发送了两个不同的数据包。但是从服务端接受数据的角度来看就不一定了。可能出现的情况有三种。 第一种也是最符合直觉的，服务端按照客户端发送的顺序收到了数据包：D1和D2. 第二种，服务端第一次读取数据时读到了D1的一部分，再次读取时读取到了D1的剩余部分，第三次读取，读取完毕了D2.用图来表达就是  第三种，服务端读取一次数据，就完全读取到了D1和D2.就如下图  以上的第二种现象被称之为拆包，也就是一个完整的业务数据包被拆分到多次socket读取的结果中。而第三种先想想被称之为粘包，也就是在一...

前言 Netty官网对自己的描述是一个异步的事件驱动的网络框架。异步如何表现和异步背后的线程模型在上文已经分析过了。 事件驱动是Netty中另外一个非常重要的概念。Netty框架中描述的事件是一种抽象概念，其将框架运行过程中会发生的许多“动作”以事件的概念定义。并且在事件发生时，触发对应的回调方法。对于开发者而言，只需要实现自己感兴趣的事件的回调方法。因此，对于事件的回调方法的实现，构成了对Netty的主要使用。 简单的说，了解了Netty中的事件，也就掌握了大部分在Netty中进行业务开发所要使用的API。下面就来逐一的介绍这些事件。 事件的线程触发机制 在分析事件的触发条件和触发内容之前，...

异步化的Netty Netty在官网首页有这么一句话介绍自己  Netty is an asynchronous event-driven network application frameworkfor rapid development of maintainable high performance protocol servers & clients.  异步的特性甚至还摆在事件驱动之前，可见其重要性。Netty的异步操作在代码中随处可见，几个比较重要的地方返回都是ChannelFuture接口。先来重温下在什么地方会遇到异步接口。 第一处，也是最为常见，在服务端引导程序绑定监...

前言 从上一个章节的学习，对使用Netty进行网络应用开发已经有了一个初步的感性的印象。但是仅仅依靠这种简单的介绍就上手Netty还是过于勉强了。所以本文会剖析Netty中的重点组件。通过对这些组件的理解和掌握，从底层熟悉和理解Netty。 核心组件分析 ByteBuf 在JDK的NIO中，我们学习到了其原生的数据承载组件ByteBuffer。ByteBuffer的体验着实不太好，读写状态的区别，还有flip这种乍看下不直观的操作。 Netty设计了自己的数据存储组件ByteBuf。和ByteBuffer一样，ByteBuf也是代表了一段连续的二进制数据空间。同样的，ByteBuf也按照数据存...

前言 从《使用Java NIO编写服务端应用》可以看到，使用Java原生的NIO接口编写一个服务端应用程序相对比较复杂，并且需要考虑许多的细节问题。而上文举的例子本身无论是在协议制定还是功能需求上都是比较简单的。而且这个例子还是一个功能定制化的应用。如果需要完成具备可扩展性的IO框架性质的程序，方便应用在其上进行二次开发，无疑更加困难。线程模型的设计，供二次开发的应用程序接口的设计，内存的管理，并发的控制等等一系列难度都在摆在面前。 让情况更糟糕的是，Java的NIO实现存在bug。选择器Selector的select方法在特定的情况会在没有IO事件发生的情况返回，且该bug触发后，selec...

需求分析 本文将实战如何使用Java NIO编写一个趋向于实际的echo应用。首先是明确这个echo服务器的需求，总结来说有以下几条：  服务器原样返回客户端发送的信息。 客户端发送的信息以'\r'作为一个消息的结尾，一个消息的最大长度不超过128。 客户端可能会一次发送多个消息，服务端需要按照收到的消息的顺序依次回复，不能乱序。 客户端可以在任意时刻关闭通道。 服务端不能主动关闭通道。  代码实战 很少有程序是一蹴而就的，一般都是在满足需求，再反复修改细节得到最终的成品。在这里，我们先以《Java的服务端编程进化史：从BIO到NIO，最后走向AIO》一文中NIO的代码作为基础蓝本进行改造。为...

前言 在前文中提到，Java在1.4版本的时候提供了NIO，实现了对IO的支持。在刚发布的时候，为了区别于原先的IO包，NIO的含义被定义New I/O。但是这么多年过去了，新事务也早就稀松平常了，再叫New I/O会觉得名不副实。现在大家一般都将NIO定义为NonBlocking I/O。 NIO相比于BIO而言，在概念上就复杂了许多，并且也引入了很多新的组件，需要熟悉使用这些组件才能使用NIO进行开发。但是掌握好这些概念后，在看NIO编写的程序和框架就比较容易了。 组件介绍 ByteBuffer 抽象类java.nio.Buffer定义了一个连续的，有限的元素空间，可用于数据的读写。在JD...

前言 Java语言诞生之初就提供了Socket套接字相关API，用于支撑网络编程需求。早期的Socket接口是同步阻塞式IO，性能并不是很高，在服务端编程这块一直处于劣势。直到JDK1.4发布，伴随而来的是新的NIO包以及其提供了IO复用模型下的API，极大提高了网络IO效率，很多服务器开始采用这种模型，处理能力也有了极大的提升。随着JD1.7的发布，JDK也提供了对异步IO的支持。理论上来说，异步IO是效率最高的。但是由于Java主要都是服务端程序，大部分都运行在Linux系统上，而Linux对AIO的支持较晚。因此现在采用异步IO的且有较大影响力的程序还不多。 Java的服务端编年史 鸿蒙...

前言 操作系统为了保护自身的稳定，会将内存空间划分为内核空间和用户空间。当我们需要通过TCP将数据发送出去时，在应用程序中实际上执行了将数据从用户空间拷贝至内核空间，再由内核进行实际的发送动作；而从TCP读取数据时则反过来，等待内核将数据准备好，再从内核空间拷贝至用户空间，应用数据才能处理。 针对在两个阶段上不同的操作，Unix定义了5种IO模型，分别是：  阻塞式IO 非阻塞式IO IO复用 信号驱动IO 异步IO  下面来逐一介绍。 模型介绍 阻塞式IO 阻塞式IO是最流行的IO模型了，在客户端上特别常见，因为其编写难度最低，也最好理解。其模型如下入所示  该图中，我们将recvfrom看...