Netty 系列目录(https://www.cnblogs.com/binarylei/p/10117436.html)
由于 TCP 是面向字节流的，什么意思呢：虽然应用程序和 TCP 的交互是一次一个数据块（大小不等），但 TCP 把应用程序交下来的数据仅仅看成式一连串的无结构的字节流。TCP 并不知道所传送的字节流的含义。
因此 TCP 不保证接收方应用程序所收到的数据块和发送方应用程序所发出的数据块具有对应大小的关系（例如，发送方应用程序交给发送方的 TCP 共 10 个数据块，但接收方的 TCP 可能只用了 4 个就把收到的字节流交付上层的应用程序）。
同时，TCP 不关心应用进程一次把多长的报文发送到 TCP 的 缓存 中，而是根据对方给出的窗口值和当前网络阻塞的程度来决定一个报文段应包含多少个字节（UDP 发送的报文长度是应用进程给出的）。如果应用进程传送到 TCP 缓存的数据块太长，TCP 就可以把他划分短一点再传送。如果应用程序一次只发来一个字节，TCP 也可以等待积累有足够多的字节后再构成报文段发送出去。
TCP 发送报文一般是 3 个时机：
以上引自《计算机网络-----谢希仁》。
说了这么多，TCP 的这种机制，会导致什么问题呢？粘包问题。有了粘包，就需要拆包。
如何区分一个整包消息，业界通常有如下 4 种做法：
固定长度，例如每 120 个字节代表一个整包消息，不足的前面补零。解码器在处理这类定常消息的时候比较简单，每次读到指定长度的字节后再进行解码。
通过回车换行符区分消息，例如 FTP 协议。这类区分消息的方式多用于文本协议。
通过分隔符区分整包消息。
通过指定长度来标识整包消息。
Netty 作为一个网络框架，对 TCP 连接中的问题都做了全面的考虑，比如粘包拆包导致的半包问题，如何编解码，如何实现私有协议，序列化等等。本文主要针对这些问题做一个简单介绍，目的是想对整个 Netty 的编解码框架做一个全盘的审视，以确保在后面的源码学习中不会一叶障目不见泰山。
基于长度的实现有 2 个现成的类：
FixedLengthFrameDecoder 基于构造函数中的固定长度。
该类很简单，构造方法中，传入一个整数，该解码器就会按照这个数字对累积区的字节进行切分。
LengthFieldBasedFrameDecoder 基于流中动态的长度
该类比较复杂。构造函数参数多达 6 个，在构建私有协议栈时大有用处。
同样有 2 个：
DelimiterBasedFrameDecoder 用户提供分割符。
该类比较简单，根据用户提供的分割符对累积区的内容进行分割。性能相对不是那么完美。
LineBasedFrameDecoder 基于换行符,支持多种换行符 \n \r\n 速度相比自定义较快。
该类使用更简单，根据换行符进行拆包粘包。
Netty 中有很多序列化工具，比如 Jboss 的 Marshalling，同时也支持 Java 标准的序列化。 但我们重点关注 google 的 protobuf 库。因为它的性能最高。
上面的 4 个解码器都是基于 ByteToMessageDecoder，将粘包的字节转为用户需要的字节。而 ProtobufDecoder 不是继承自 ByteToMessageDecoder，而是继承自 MessageToMessageDecoder，名字都不同。MessageToMessageDecoder 的作用是什么呢？
从名字上看，该类用于将两个消息进行转换（比如一种 POJO 转成另一种）。后面我们将花大篇幅讲述这个类库。
(1) TooLongFrameException
由于 Netty 是一个异步框架，所以需要在字节可以解码之前在内存中缓冲他们。因此不能让解码器缓冲大量的数据以至于耗尽可用的内存。为了解决这个问题，Netty 提供了 TooLongFrameException 类，其将由解码器在帧超出指定的大小限制时抛出异常。
你可以设置一个最大的阈值，当超过该阈值，这抛出异常。
(2) 写大型数据的 FileRegion
有时候你可能需要写一个大型的数据，如果不停的写入，可能导致 OOM，所以在写大型数据时，需要准备好处理到远程节点的连接时慢速连接的情况，这种情况会导致内存释放的延迟。
我们可以使用 NIO 的零拷贝特性，这种特性消除了将文件内容从文件系统移动到网络栈的复制过程。而我们所需要做的就是使用一个 FileRegion 接口的实现。
官方定义：
通过支持零拷贝的文件传输的 Channel 来发送的文件区域。本文并没有刨析源码，主要是针对 Netty 中现有的或者设计的编解码，序列化等工具做一个介绍，方便后面有条不紊的按照这个路线研究他们的具体实现。
参考：
每天用心记录一点点。内容也许不重要，但习惯很重要！
