因为自己造一个RPC框架的轮子时，需要解决TCP的粘包问题，特此记录，希望方便他人。这是我写的RPC框架的 GitHub地址 https://github.com/yangzhenkun/krpc。  欢迎star，fork。已经写了多篇文章对这个框架的原理进行说明。对原理有兴趣的欢迎交流。

1.1 什么是TCP粘包

TCP粘包就是在TCP数据传输过程中，因为某些原因，接收方收到读取的数据并不是但存的一次数据，而是多个数据包的字节流组装在一起，导致多个数据粘在一起，接收端在读取的时候不知道怎么样把数据分成预期的多组数据，这就是粘包。

1.2 形成原因

TCP之所以造成粘包现象是因为其发送端和接收端的缓冲区及TCP数据流引起的。

例如nagle算法，会将瞬间的很多小包数据拼装称一个大的数据，以提高的带宽的利用率。（具体nagle算法就不展开将）。

但即使关闭了nagle算法，粘包依旧存在。因为这不是造成tcp粘包的根本原因。因为有缓冲区的存在，在缓存区没有打满之前是不会发送出去的，同时接收端也是利用缓存区接收数据，在接着从缓存区读取接收的数据解析。这时有人问，如果数据量很小，总是没有打满缓冲区那怎么办，这就依赖发送和接收端的定时器了，他们会定时的处理数据，要不这不就成了bug了。

就是因为缓冲区的存在以及tcp数据流的形式，造成了多组数据的拼接，形成了粘包，半 包问题。

1.3 如何解决

目前常用的方法是定义 起始 边届符+数据长度来告诉接收端一个数据包具体的长度。

不过也有定义固定长度的，不过这样可能会造成的空白字节的浪费以及超出长度这种不易扩展的方式。纯边界符的方式 怕发生实际消息体与边界符的碰撞，造成消息的误截断。

netty对NIO模式的TCP通信的封装可谓是完美。可让人快速写出可用的tcp通信的服务端和客户端，并且很简单的解决粘包问题。

netty有提供基于分隔符和长度的编解码器，方便开发者使用。  DelimiterBaseFrameDecoder是可以用户自定义数据分隔符来分割的，LineBaseFrameDecoder是由行尾符（\n或者\r\n）分割，速度比前者还要块。  还有基于长度的FixedLengthFrameDecoder定长的解码器，LengthFieldBasedFrameDecoder动态长度的解码器。这4中方式都有对应的编解码器。

同时对于数据类型的边界吗，netty也支持byte，string，protobuf等，大家可以去看MessageToMessageDecoder的子类，就能发现netty提供很多编解码的规则。

在自己写KRPC时，一开始没有把NIO的计划提这么早，奈何在第一版用同步IO写客户端，压测时发现竟然那么不堪，遂决定用NIO改写，一开始觉得用Netty写客户端不方便（当时没到怎么写），便决定用java原生的NIO来写客户端，写到最后发现处理粘包特别困难，需要自己定义 特殊分界符号，然后设置长度，在客户端和服务端解析起来特别繁杂。于是尝试用netty写，发现特别简单。

这就是服务端的代码，有没有特别简单，因为TCP将传输的数据序列化由压缩后的数据为 字节数组，所以使用的自带的ByteArray编解码器，使用了动态长度的LengthFieldBaseFrame来解决粘包问题。就这样解决了粘包问题。

如果想了解更具体的代码,可以去github下载，包含了krpc所有的代码。欢迎大家交流学习。

对CSDNJava架构技术，对架构技术感兴趣的同学，欢迎加QQ群859729143，一起学习，相互讨论。 群内已经有小伙伴将知识体系整理好（源码，笔记，PPT，学习视频），欢迎?加群免费领取 分享给喜欢Java，喜欢编程，有梦想成为架构师的程序员们，希望能够帮助到你们。