Netty专栏 （七）——— LengthFieldBasedFrameDecoder - 参数说明

LengthFieldBasedFrameDecoder - 参数说明

@author 鲁伟林
网上诸多博客对于LengthFieldBasedFrameDecode解码器的使用，翻译和解释过于死板，难于理解，特别是其构造函数的6个参数的解释，过于字面化解释。该博客尽量保证通俗易懂，帮组读者理解和使用。读者可以选择读英文文档。
工作量:
1. 详细讲解LengthFieldBasedFrameDecode中6个参数的作用和使用。maxFrameLength, lengthFieldOffset, lengthFieldLength,
            lengthAdjustment, initialBytesToStrip, failFast。
2. 给出多个实例，帮助理解和使用LengthFieldBasedFrameDecode解码器。

GitHub项目地址: https://github.com/thinkingfioa/netty-learning/tree/master/netty-private-protocol
博客地址: https://blog.youkuaiyun.com/thinking_fioa
Netty专栏地址: https://blog.youkuaiyun.com/column/details/22861.html

1. LengthFieldBasedFrameDecoder作用

LengthFieldBasedFrameDecoder解码器自定义长度解决TCP粘包黏包问题。所以LengthFieldBasedFrameDecoder又称为: 自定义长度解码器

1.1 TCP粘包和黏包现象

  1. TCP粘包是指发送方发送的若干个数据包到接收方时粘成一个包。从接收缓冲区来看，后一个包数据的头紧接着前一个数据的尾。

  2. 当TCP连接建立后，Client发送多个报文给Server，TCP协议保证数据可靠性，但无法保证Client发了n个包，服务端也按照n个包接收。Client端发送n个数据包，Server端可能收到n-1或n+1个包。

1.2 为什么出现粘包现象

  1. 发送方原因: TCP默认会使用Nagle算法。而Nagle算法主要做两件事：1）只有上一个分组得到确认，才会发送下一个分组；2）收集多个小分组，在一个确认到来时一起发送。所以，正是Nagle算法造成了发送方有可能造成粘包现象。

  2. 接收方原因: TCP接收方采用缓存方式读取数据包，一次性读取多个缓存中的数据包。自然出现前一个数据包的尾和后一个收据包的头粘到一起。

1.3 如何解决粘包现象

1. 添加特殊符号，接收方通过这个特殊符号将接收到的数据包拆分开 - DelimiterBasedFrameDecoder特殊分隔符解码器

2. 每次发送固定长度的数据包 - FixedLengthFrameDecoder定长编码器

3. 在消息头中定义长度字段