TCP 为什么会有粘包和拆包？应用层如何做消息边界？
简化版
TCP 是面向字节流的协议，不保留应用层消息边界。应用层一次 send 的数据，接收方可能一次收到多条、半条或任意组合，这就是常说的粘包和拆包。解决方式是在应用层设计消息边界，如固定长度、分隔符、长度字段或 TLV 协议。
详细版
粘包不是 TCP 的 bug，而是 TCP 的字节流语义。TCP 只保证字节按序可靠到达，不保证“发送几次，接收就读几次”。操作系统缓冲区、Nagle 算法、MSS 分段、接收方读取速度都会让数据重新组合。
常见解决方案：
- 固定长度：每条消息长度固定，简单但浪费；
- 分隔符：如
\n结尾，适合文本协议，但要处理转义； - 长度字段：先读固定头部，再按长度读 body，最常用；
- TLV：Type-Length-Value，适合可扩展协议。
完整版教学
一、TCP 的核心语义是字节流
TCP 提供的是一条可靠、有序、全双工的字节流。你可以把它想成一根管道：发送方不断往管道里塞字节，接收方不断从管道里取字节。TCP 不知道你的业务里“一条消息”从哪里开始、到哪里结束。
send("hello")
send("world")
recv() may get "helloworld"
recv() may get "hel"
recv() may get "lo wor"这就是粘包和拆包的根源。它不是丢数据，也不是乱序，而是应用层边界丢失。
二、为什么会发生粘包
粘包通常是多条应用消息被一次读到。比如客户端快速连续发送两条 5 字节消息，服务端一次 recv(1024) 很可能直接读到 10 字节。
应用消息: [abcde][12345]
TCP 字节流: abcde12345
recv(1024): abcde12345TCP 为了效率会合并小包，操作系统发送缓冲区和接收缓冲区也会积累数据。接收方读得慢时，更容易一次读到多条消息。
三、为什么会发生拆包
拆包是应用层一条消息被分多次读到。原因可能是消息大于 MSS、发送缓冲区分段、网络传输分片，或者接收方的缓冲区太小。
应用消息: [content-length=1000 body...]
recv(512): first half
recv(488): second half所以网络程序不能假设一次 recv 就能拿到完整消息。只要是流式协议，就必须循环读并维护解析状态。
四、长度字段协议怎么设计
生产中最常见的是“固定头 + 变长体”。头部包含 body 长度，接收方先读固定长度头部，再根据长度读完整 body。
| length: 4 bytes | body: length bytes |如果头部长度是 4 字节，body 长度是 100，解析器要先凑齐 4 字节，再等到至少 100 字节 body 才能交给业务。读多了也不能丢，要留在缓冲区解析下一条。
五、分隔符协议的边界
文本协议常用分隔符，例如 Redis 的 RESP、HTTP 头部里的 CRLF。分隔符方案可读性好，但要考虑内容里本身出现分隔符的问题。
message1\nmessage2\n如果消息体允许任意二进制，单纯按 \n 分隔就不够安全，必须做转义或换成长度字段。否则内容里的换行会被误认为消息结束。
六、接收缓冲区和状态机
健壮的解码器通常维护一个应用层 buffer。每次从 socket 读到数据后追加到 buffer，然后循环尝试解析完整消息。解析不到完整消息就等待下一次读事件。
socket recv -> append buffer -> parse one or more frames -> keep remainder这种状态机能同时处理半包和粘包。高性能框架如 Netty、libevent、nginx 模块也都离不开类似思想。
七、协议设计的安全边界
长度字段不能无限信任。攻击者可以声明一个 2GB 的长度，让服务端分配巨大内存或一直等待，造成 DoS。因此协议要限制最大包长、读超时和异常连接关闭。
| 风险 | 防护 |
|---|---|
| 超大 length | 设置最大包长 |
| 半包不结束 | 读超时 |
| 分隔符逃逸 | 转义或长度字段 |
| 解码异常 | 关闭连接并计数 |
记忆钩子：TCP 只管“字节可靠到达”，不管“消息如何分界”；消息边界永远是应用层协议的责任。
协议升级时也要考虑兼容性。可以在头部预留版本号、类型字段和 flags，避免未来加字段时旧客户端完全无法识别。
| magic | version | type | length | body |八、常见误区与追问
- 误区：TCP 粘包是 TCP 的缺陷。 TCP 本来就是字节流协议，不承诺应用消息边界。
- 误区：一次 send 对应一次 recv。 send/recv 只和缓冲区交互，次数没有一一对应关系。
- 误区：加大 recv 缓冲区就能解决拆包。 大缓冲区不能保证一次读到完整消息，协议边界仍要设计。
- 追问：UDP 会不会粘包？ UDP 保留报文边界，但可能丢包、乱序或截断。
- 追问：长度字段放几字节？ 常见 2/4/8 字节，要结合最大消息大小和协议兼容性。
- 追问：读到多条消息怎么办？ 循环解析完整帧，剩余字节留在 buffer。
- 追问：如何防恶意超大包？ 限制最大长度、读超时、异常计数和连接关闭。
九、加强记忆
粘包拆包的核心不是“包乱了”，而是 TCP 不懂应用消息。网络程序要自己定义边界：固定长度、分隔符、长度字段或 TLV。真正写代码时，要维护接收缓冲区和解析状态机，既能吃掉多条完整消息，也能等待半条消息补齐，同时限制最大包长和读超时，避免协议被攻击者拖垮。