Netty介绍与实战(三)之粘包拆包

一、传统NIO架构

step1. 我们传统的nio架构已经解决了多路复用，零拷贝等问题，已经十分优秀了，那为什么我们现在Netty如此火热呢？

1) 首先他使用简单，基本上都是模板化，我们可以更专注业务。具体使用可参考Netty介绍及实战

2）社区活跃，成熟稳定。

3）提供编解码功能，和处理粘包、拆包的功能。

4）替我们修复了NIO的大量bug , 不需要考虑复杂的网络协议。

step2.什么是粘包、拆包？

1）上图我们可以看到，所有的message都会放到我们对应的缓冲区当中。

缓冲区：TCP在接受数据的时候，有一个滑动窗口来控制接受数据的大小，这个滑动窗口你就可以理解为一个缓冲区。
        case1:右上第一个消息：当一个消息过大，我们TCP缓冲区放不下了，那就会产生拆包，剩下的message会在下一次请求中传递过来。

        case2:右上第二第三条消息：每个message的长度比较小，TCP将多次写入的消息一次性的发送出去。

        case3:报文长度大于最大报文长度也会出现拆包。

二、Netty架构

step1.network application framework

 step2. Netty server architecture

 Step3.一个简单数据接收，响应的流程图

1）一个加密数据传输过来，首先经过我们的handler去找到对应的channel去处理，然后将报文交给解密的handler去解析报文，之后将数据传递给业务端，业务端处理之后，再次将响应报文encode之后传递出去(代码:Netty介绍及实战)。

Step4.netty如何处理粘包，拆包呢？

设想，如果一个数据来了如果我不知道数据的具体长度，我们怎么能精准的拆包呢。

所以我们可以在报文的头部，用一部分字节来去标记整条报文的长度，这样按照长度去读取，这样不就可以精准的获取到原始的每一条报文结构了么。于是Netty也提供了这个方法：

LengthFieldBasedFrameDecoder 它是基于消息头指定消息长度进行粘包拆包处理的。

还有其他不同类型的拆包方法，大家也可以再了解一下。如有错误欢迎指出，共同学习！