tcp粘包拆包是因字节流无边界导致的应用层消息解析错位；根本解决需应用层协议设计，主流方案为长度前缀法，辅以禁用nagle算法、分隔符法及接收端缓冲区+状态机解析。
TCP 本身不保证消息边界，只保证字节流的有序交付。所谓“粘包”和“拆包”，其实是应用层对数据分界理解错位的表现——不是 TCP 出了问题，而是应用没告诉自己“一条消息到底多长”。解决思路分两层：内核行为可调，但真正可靠、通用的方案必须落在应用层协议设计上。
禁用 Nagle 算法减少小包合并
默认开启的 Nagle 算法会攒小数据等 ACK 或凑够 MSS 再发，容易导致多个短消息被合并发送。对实时性要求高的场景（如游戏指令、RPC 请求），应关闭它：
- 调用
setsockopt(sock_fd, IPPROTO_TCP, TCP_NODELAY, &flag, sizeof(flag))，其中flag = 1 - 注意：这会增加网络头部开销（约 40%），不适合高吞吐小包密集型服务（如日志上报）
- 仅缓解发送端粘包，无法解决接收端拆包或网络分片带来的问题
用长度前缀协议明确消息边界
最常用也最健壮的做法：每个消息开头加 2 字节或 4 字节长度字段，接收方先读长度，再按需读取正文。例如：
- 发送时：
[4-byte len][payload]，len 是 payload 的字节数（网络字节序） - 接收时：先调用
recv()读满 4 字节 → 解析出长度 → 再循环调用recv()直到收齐对应字节数 - 务必封装
readn()和writen()工具函数，避免系统调用返回少于预期字节数导致逻辑中断
慎用分隔符方案
在消息末尾加 \n 或 \r\n 作为边界标识（如 FTP、HTTP 原始请求），实现简单但有隐患：
- 若业务数据本身含该分隔符（比如用户输入含换行），就会误切消息
- 拆包时可能一次只收到半个分隔符（如只收到
\r），需缓存等待下一批数据 - 适合纯文本、内容可控的协议（如 Telnet、简单命令行交互），不适合二进制或任意内容传输
接收端必须维护缓冲区 + 解析状态机
无论采用哪种协议，接收逻辑都不能依赖单次 recv() 返回完整消息。正确做法是：
- 为每个连接分配一个字节缓冲区（如
std::vector<uint8_t></uint8_t>或char buf[65536]） - 每次
recv()到数据就追加进缓冲区 - 用状态机判断是否能解析出完整消息：找头（魔数）、读长度、校验长度是否足够、截取消息体、更新缓冲区剩余部分
- Netty 的
LengthFieldBasedFrameDecoder或 Linux 下手写类似逻辑，本质都是这个模型
