前言如果你在用Netty做长连接通信IM聊天、RPC调用、设备上报、消息推送大概率遇到过这两种诡异问题服务端一次读取到多条客户端消息拼接在一起的数据一条完整的业务消息被分成两次甚至多次读取导致解析报错、数据缺失。这就是网络编程最经典、面试最高频、线上问题最多的TCP粘包、拆包问题。很多初学者最大的误区认为是Netty的BUG。大错特错粘包拆包是TCP协议本身的特性导致的和Netty无关、和代码写法无关。Netty只是帮我们提供了成熟的解决方案而非制造问题。本篇彻底刨到底层不讲废话、不背结论真正弄懂为什么TCP一定会粘包拆包什么场景触发有什么危害一、先搞懂核心TCP的本质特性1.1 TCP是面向字节流、无边界的协议TCP协议的核心定义面向连接的、可靠的、字节流协议。重点两个关键词字节流、无消息边界。我们业务层发送的是「一条一条独立的消息」但是在TCP传输层看来所有数据都只是一串连续的二进制字节流没有第一条、第二条的区分标记。举个通俗的例子你给朋友分两次寄两箱苹果两次业务消息发送但是快递运输的时候把两箱苹果倒进了同一个大集装箱TCP字节流合并。收货的人服务端拿到的是一堆混在一起的苹果根本分不清原本是两箱这就是粘包。反之集装箱太大、运力不足一箱苹果被分两辆车运输收货方分两次收到这就是拆包。1.2 对比UDP彻底破除误区UDP是面向报文、有消息边界的协议。UDP每次发送的报文都是独立的接收方一次接收一个完整报文UDP只会丢包不会粘包、不会拆包。这也是为什么IM、RPC、金融长连接优先TCP可靠不丢包但必须解决粘包拆包的根本原因。二、通俗定义什么是粘包什么是拆包假设客户端连续发送两条独立业务消息消息1Hello Netty 1消息2Hello Netty 22.1 TCP粘包服务端一次读取到多条消息数据发生粘连Hello Netty 1Hello Netty 2本质多条独立业务消息被TCP合并成一段字节流交付给应用层。2.2 TCP拆包一条完整消息被TCP拆分服务端分多次读取第一次读到Hello N第二次读到etty 1Hello Netty 2本质单条消息字节过长被TCP分片传输应用层无法一次性获取完整数据。三、底层深度剖析粘包拆包产生的3大核心原因所有粘包拆包现象全部来自TCP底层机制一共3种全覆盖所有线上场景。3.1 发送端Nagle算法最主要原因TCP默认开启Nagle算法目的是减少网络小包数量、提升网络吞吐量、降低网络拥堵。算法逻辑如果当前发送缓冲区中有待确认数据暂时不发送新的小包积攒足够多的字节后合并为一个大报文统一发送。后果客户端连续发送多条小包会被TCP自动合并成一个包发送服务端直接产生严重粘包。3.2 接收端缓冲区未及时读取TCP有接收缓冲区数据先进入内核缓冲区再由应用程序读取。如果服务端业务处理较慢、读取不及时多次客户端数据持续进入缓冲区数据在缓冲区堆积、合并应用下一次读取直接读到堆积的多条数据产生粘包。3.3 链路MTU限制导致拆包最大传输单元网络链路存在MTU最大传输单元以太网默认MTU为1500字节。当单次发送的消息字节长度超过MTU时TCP会自动对数据包进行分片拆分保证单次传输不超限。后果一条大消息被拆分成多个TCP报文分片传输服务端分多次读取产生拆包现象。终极总结小包多发、算法攒包、读取滞后 →粘包消息过大、超出MTU限制 →拆包四、粘包拆包带来的线上严重问题很多新手觉得只是数据拼在一起无伤大雅实际线上后果非常严重报文解析异常JSON、Protobuf、自定义协议解析报错直接丢数据、报错熔断业务逻辑错乱多条消息合并导致重复处理、参数错乱、业务脏数据消息丢失卡死拆包导致报文不完整解析器一直等待剩余数据连接假死、堆积高并发雪崩大量异常报文触发重试、异常日志刷屏拖垮整个服务。所以所有TCP长连接项目必须强制处理粘包拆包没有例外五、高频误区纠正面试必考误区1关闭Nagle算法就能彻底解决粘包答案不能关闭Nagle只能避免「发送端攒包合并」但是接收端缓冲区堆积、链路MTU分片导致的粘包拆包依然存在。生产环境绝对不建议关闭Nagle算法会产生大量网络小包极大增加网络IO压力。误区2每次发送sleep延时就能避免粘包答案伪解决方案本地测试可用线上必崩sleep只是降低发包频率无法改变TCP字节流本质高并发、网络抖动场景依然会出现粘包拆包属于掩耳盗铃的写法。误区3UDP也会粘包拆包答案不会UDP面向报文一次发送一个报文、一次接收一个报文边界完整只会丢包、乱序无粘包拆包。六、真正的解决方案核心思路既然TCP没有消息边界那我们的解决思路就一句话人为给消息加上边界。让Netty可以精准识别哪一段字节是一条完整的消息。行业通用四种标准方案下一篇实战全覆盖固定长度报文每条消息长度一致读到固定字节即判定为完整消息特殊分隔符每条消息末尾添加指定分隔符如换行符、自定义标记长度域协议企业主流报文头部存储消息长度解码器根据长度读取完整报文自定义协议编解码Protobuf、JSON长度头商用终极方案。七、本篇面试高频必背题TCP为什么会出现粘包拆包根本原因是什么粘包和拆包分别在什么场景下产生UDP为什么不会粘包拆包关闭Nagle算法能否彻底解决问题为什么为什么sleep延时规避粘包是错误方案解决TCP粘包拆包的核心思路是什么下篇预告下一篇进入全网最细实战Netty五种粘包拆包解决方案落地实战逐个编码演示、对比优缺点、给出企业选型方案学完直接用于生产项目
Netty进阶篇四：彻底搞懂TCP粘包拆包底层原理（90%开发者都踩过的坑）
前言如果你在用Netty做长连接通信IM聊天、RPC调用、设备上报、消息推送大概率遇到过这两种诡异问题服务端一次读取到多条客户端消息拼接在一起的数据一条完整的业务消息被分成两次甚至多次读取导致解析报错、数据缺失。这就是网络编程最经典、面试最高频、线上问题最多的TCP粘包、拆包问题。很多初学者最大的误区认为是Netty的BUG。大错特错粘包拆包是TCP协议本身的特性导致的和Netty无关、和代码写法无关。Netty只是帮我们提供了成熟的解决方案而非制造问题。本篇彻底刨到底层不讲废话、不背结论真正弄懂为什么TCP一定会粘包拆包什么场景触发有什么危害一、先搞懂核心TCP的本质特性1.1 TCP是面向字节流、无边界的协议TCP协议的核心定义面向连接的、可靠的、字节流协议。重点两个关键词字节流、无消息边界。我们业务层发送的是「一条一条独立的消息」但是在TCP传输层看来所有数据都只是一串连续的二进制字节流没有第一条、第二条的区分标记。举个通俗的例子你给朋友分两次寄两箱苹果两次业务消息发送但是快递运输的时候把两箱苹果倒进了同一个大集装箱TCP字节流合并。收货的人服务端拿到的是一堆混在一起的苹果根本分不清原本是两箱这就是粘包。反之集装箱太大、运力不足一箱苹果被分两辆车运输收货方分两次收到这就是拆包。1.2 对比UDP彻底破除误区UDP是面向报文、有消息边界的协议。UDP每次发送的报文都是独立的接收方一次接收一个完整报文UDP只会丢包不会粘包、不会拆包。这也是为什么IM、RPC、金融长连接优先TCP可靠不丢包但必须解决粘包拆包的根本原因。二、通俗定义什么是粘包什么是拆包假设客户端连续发送两条独立业务消息消息1Hello Netty 1消息2Hello Netty 22.1 TCP粘包服务端一次读取到多条消息数据发生粘连Hello Netty 1Hello Netty 2本质多条独立业务消息被TCP合并成一段字节流交付给应用层。2.2 TCP拆包一条完整消息被TCP拆分服务端分多次读取第一次读到Hello N第二次读到etty 1Hello Netty 2本质单条消息字节过长被TCP分片传输应用层无法一次性获取完整数据。三、底层深度剖析粘包拆包产生的3大核心原因所有粘包拆包现象全部来自TCP底层机制一共3种全覆盖所有线上场景。3.1 发送端Nagle算法最主要原因TCP默认开启Nagle算法目的是减少网络小包数量、提升网络吞吐量、降低网络拥堵。算法逻辑如果当前发送缓冲区中有待确认数据暂时不发送新的小包积攒足够多的字节后合并为一个大报文统一发送。后果客户端连续发送多条小包会被TCP自动合并成一个包发送服务端直接产生严重粘包。3.2 接收端缓冲区未及时读取TCP有接收缓冲区数据先进入内核缓冲区再由应用程序读取。如果服务端业务处理较慢、读取不及时多次客户端数据持续进入缓冲区数据在缓冲区堆积、合并应用下一次读取直接读到堆积的多条数据产生粘包。3.3 链路MTU限制导致拆包最大传输单元网络链路存在MTU最大传输单元以太网默认MTU为1500字节。当单次发送的消息字节长度超过MTU时TCP会自动对数据包进行分片拆分保证单次传输不超限。后果一条大消息被拆分成多个TCP报文分片传输服务端分多次读取产生拆包现象。终极总结小包多发、算法攒包、读取滞后 →粘包消息过大、超出MTU限制 →拆包四、粘包拆包带来的线上严重问题很多新手觉得只是数据拼在一起无伤大雅实际线上后果非常严重报文解析异常JSON、Protobuf、自定义协议解析报错直接丢数据、报错熔断业务逻辑错乱多条消息合并导致重复处理、参数错乱、业务脏数据消息丢失卡死拆包导致报文不完整解析器一直等待剩余数据连接假死、堆积高并发雪崩大量异常报文触发重试、异常日志刷屏拖垮整个服务。所以所有TCP长连接项目必须强制处理粘包拆包没有例外五、高频误区纠正面试必考误区1关闭Nagle算法就能彻底解决粘包答案不能关闭Nagle只能避免「发送端攒包合并」但是接收端缓冲区堆积、链路MTU分片导致的粘包拆包依然存在。生产环境绝对不建议关闭Nagle算法会产生大量网络小包极大增加网络IO压力。误区2每次发送sleep延时就能避免粘包答案伪解决方案本地测试可用线上必崩sleep只是降低发包频率无法改变TCP字节流本质高并发、网络抖动场景依然会出现粘包拆包属于掩耳盗铃的写法。误区3UDP也会粘包拆包答案不会UDP面向报文一次发送一个报文、一次接收一个报文边界完整只会丢包、乱序无粘包拆包。六、真正的解决方案核心思路既然TCP没有消息边界那我们的解决思路就一句话人为给消息加上边界。让Netty可以精准识别哪一段字节是一条完整的消息。行业通用四种标准方案下一篇实战全覆盖固定长度报文每条消息长度一致读到固定字节即判定为完整消息特殊分隔符每条消息末尾添加指定分隔符如换行符、自定义标记长度域协议企业主流报文头部存储消息长度解码器根据长度读取完整报文自定义协议编解码Protobuf、JSON长度头商用终极方案。七、本篇面试高频必背题TCP为什么会出现粘包拆包根本原因是什么粘包和拆包分别在什么场景下产生UDP为什么不会粘包拆包关闭Nagle算法能否彻底解决问题为什么为什么sleep延时规避粘包是错误方案解决TCP粘包拆包的核心思路是什么下篇预告下一篇进入全网最细实战Netty五种粘包拆包解决方案落地实战逐个编码演示、对比优缺点、给出企业选型方案学完直接用于生产项目
