网络分层模型回顾：OSI七层与TCP/IP四层
聊粘包拆包之前，我建议咱们先把地基夯实一下。你想想看，TCP 数据在网络上到底是怎么「走」的？为什么会有「包」这个概念？
说白了，这一切都得从网络分层模型说起。我刚开始做网络编程时，总觉得分层是理论课上的东西，跟实际写代码关系不大。直到有一次排查一个诡异的连接超时问题，抓了包愣是看不懂——嗯，从那以后我再也不敢跳过分层模型了。
OSI七层模型：教科书里的完美蓝图
OSI（Open Systems Interconnection）七层模型，是国际标准化组织在1984年提出的。它把网络通信拆成了七个层次，每一层各司其职。
| 层次 | 名称 | 核心职责 | 典型协议/设备 |
|---|---|---|---|
| 7 | 应用层 | 为用户应用提供网络服务 | HTTP、FTP、SMTP |
| 6 | 表示层 | 数据格式转换、加密、压缩 | SSL/TLS、JPEG |
| 5 | 会话层 | 建立、管理、终止会话 | NetBIOS、RPC |
| 4 | 传输层 | 端到端可靠传输、流量控制 | TCP、UDP |
| 3 | 网络层 | 路由选择、逻辑寻址 | IP、ICMP、路由器 |
| 2 | 数据链路层 | 帧封装、介质访问控制 | 以太网、交换机 |
| 1 | 物理层 | 比特流传输、电气信号 | 网线、集线器 |
我的经验：实际工作中没人会背七层模型，但你必须知道传输层（第4层）和网络层（第3层）的分界线在哪。粘包拆包的问题，就卡在第4层和第3层的交界处。
TCP/IP四层模型：工业界的实战标准
OSI 七层太「重」了，工业界更喜欢用 TCP/IP 四层模型。它把七层压缩成了四层，更贴近实际协议栈的实现。
- 应用层：对应 OSI 的 5/6/7 层。HTTP、DNS、WebSocket 都在这一层。
- 传输层：对应 OSI 的第 4 层。TCP 和 UDP 的战场。
- 网络层：对应 OSI 的第 3 层。IP 协议在这里决定数据包怎么走。
- 网络接口层：对应 OSI 的 1/2 层。网卡驱动、物理介质都在这一层。
关键认知：我们常说的「TCP 粘包」，其实发生在应用层和传输层的交界处。应用层发送的数据，到了 TCP 层会被「切碎」或「合并」——这就是粘包拆包的根本原因。
数据包的封装与解封装：数据在网线里到底长什么样？
我打个比方。你寄快递，先把东西装进纸箱（应用层数据），再贴上快递单（TCP 头），然后套上防水袋（IP 头），最后贴上运输标签（以太网帧头）。每一层都在原始数据外面「套」了一层头。
这个过程，就叫封装。
应用层数据: [HTTP请求体]
↓ 传输层封装: [TCP头][HTTP请求体]
↓ 网络层封装: [IP头][TCP头][HTTP请求体]
↓ 链路层封装: [以太网头][IP头][TCP头][HTTP请求体][以太网尾]接收端收到数据后，反过来一层层「拆」掉这些头，最终拿到原始数据。这就是解封装。
我曾经踩过的坑：有一次调试一个 HTTP 长连接服务，客户端总是收到不完整的响应。抓包一看，TCP 层把两个 HTTP 响应包合并到了一个 TCP 段里发送。应用层按「一次 recv 等于一个请求」的逻辑去读，自然就出错了。这就是典型的粘包。
核心逻辑：分层模型与粘包拆包的关系
下面这张图，是我自己画的分层封装与粘包拆包关系图。你看完应该能明白，问题到底出在哪一层。
为什么分层模型跟粘包拆包有关？
原因其实很简单。应用层看到的是「消息」，TCP 层看到的是「字节流」。TCP 不关心你的消息边界在哪，它只负责把字节流可靠地从 A 传到 B。
这就带来了两个问题：
- 粘包：多个小消息被 TCP 合并到一个段里发送，接收端一次读到多个消息。
- 拆包：一个大消息被 TCP 拆成多个段发送，接收端需要多次读取才能拼完整。
一句话总结：粘包拆包的本质，是「应用层消息边界」与「传输层字节流特性」之间的不匹配。分层模型把这两层隔开了，但隔开的同时也带来了边界丢失的问题。
我个人习惯把这个问题记在心里：TCP 不保证消息边界。每次写网络程序，我都会问自己一句——我的应用层协议，有没有办法让接收端知道「一条消息从哪开始、到哪结束」？
这个问题，就是我们后面 29 章要深入探讨的核心。