1. 网络基础回顾：OSI七层模型与TCP/IP四层模型，数据封装与解封装过程

说实话，每次带新人做网络编程，我第一件事就是让他们把OSI模型和TCP/IP模型搞清楚。为什么？因为你不懂数据是怎么一层层包装、一层层拆开的，后面遇到粘包拆包问题，你根本无从下手。

我自己刚入行那会儿，也犯过这个错。上来就写socket代码，结果数据收发总出乱子。后来被老工程师按着头补了这课，才恍然大悟——原来网络通信就像寄快递，每一层都在做打包和拆包的工作。

OSI七层模型，说白了就是国际标准化组织（ISO）给网络通信画的一张「理想蓝图」。它把通信过程拆成了七个层次，每一层各司其职。

层级	名称	核心职责	我眼中的比喻
第7层	应用层	为用户提供网络服务接口	你写代码调用的API
第6层	表示层	数据格式转换、加密压缩	翻译官，把数据变成双方都懂的样子
第5层	会话层	建立、管理、终止会话	像打电话时的「喂，能听到吗？」
第4层	传输层	端到端可靠传输（TCP/UDP）	快递公司的运输调度
第3层	网络层	路由选择、IP寻址	地图导航，决定走哪条路
第2层	数据链路层	帧封装、MAC地址、差错检测	快递员在小区里找门牌号
第1层	物理层	比特流传输、电气信号	快递车在公路上跑

我个人习惯：面试时问OSI七层，很多人能背出来。但你要问他「TCP在哪一层？IP在哪一层？」就卡壳了。记住一个口诀——「物链网传会表应」，从上往下记也行，从下往上记也行，关键是理解每一层解决什么问题。

OSI七层模型虽然完美，但太复杂了。工业界更喜欢TCP/IP四层模型。说白了，就是把七层合并成了四层，更实用。

我记得有一次调试一个跨机房的服务，数据总是丢包。用OSI模型分析太费劲，直接用TCP/IP模型定位到传输层，发现是TCP窗口设置不合理。嗯，这就是实战和理论的区别。

  重点来了：我们做TCP网络编程，天天打交道的就是传输层（TCP）和应用层。粘包拆包问题，本质上就是应用层和传输层之间的数据边界问题。你想想看，TCP是流式协议，它不关心你发了几条消息，它只关心字节流。

数据封装，就是发送方从应用层开始，一层层往下给数据「打包」。每经过一层，就加一个头部（Header）。

解封装正好反过来，接收方从物理层开始，一层层往上「拆包」，每经过一层就剥掉一个头部。

我经常跟团队说：「你发一个HTTP请求，实际上经历了四次打包、四次拆包。」

我曾经踩过的坑：有一次写一个文件传输程序，客户端发完数据直接close了socket。服务端收数据时发现少了一段。为什么？因为TCP是流式传输，最后一段数据还在内核缓冲区里没来得及发出去，连接就断了。后来我加了个优雅关闭（shutdown），问题解决。这就是不懂封装过程吃的亏。

下面这张SVG图，是我自己梳理的。每次讲网络基础，我都会先画这张图。你仔细看，数据封装和解封装的过程，其实就是「加头」和「去头」的对称操作。

你想想看，TCP是流式协议。它不管你的应用层消息边界在哪里。你发两次send，底层可能合并成一个包发出去（粘包）。你发一次send，底层可能拆成多个包发出去（拆包）。

为什么会这样？因为TCP的传输层只负责可靠传输字节流，它不关心你的消息结构。而我们的应用层，需要自己定义消息边界。

  核心结论：粘包拆包问题的根源，就在于TCP传输层和应用层之间的「语义鸿沟」。传输层看的是字节流，应用层看的是消息。这个鸿沟，就是我们后面要花大量篇幅去填平的东西。

我个人习惯，在开始讲粘包拆包的具体解决方案之前，先让大家把OSI和TCP/IP模型刻在脑子里。这样后面讲到「为什么TCP是流式协议」「为什么UDP没有粘包问题」时，你才能理解背后的设计逻辑。

一个小建议：如果你现在对OSI七层和TCP/IP四层的对应关系还不太熟，可以自己画一张图。画一遍，比看十遍都管用。我当年就是这么干的。

好了，网络基础就回顾到这里。记住一句话：数据封装是加头，数据解封装是去头。TCP是流，不是消息。带着这个认知，我们后面再深入粘包拆包的具体场景和解决方案。