1、粘包拆包概述：什么是粘包和拆包、为什么TCP会产生粘包、UDP为什么没有粘包

几年前我接手过一个即时通讯项目。客户端发消息，服务端收消息，看起来很简单对吧？

上线第一天就出问题了——用户发了两条消息，服务端却只收到一条。更诡异的是，那条消息的内容是两条消息拼在一起的。我当时第一反应是：代码写错了？

排查了半天，发现业务逻辑没问题。问题出在TCP的流式传输特性上。这就是典型的粘包现象。

你想想看，如果做的是文件传输、视频流这类应用，粘包拆包可能不是大问题。但要是做即时通讯、RPC调用、游戏协议——嗯，不处理粘包，系统根本跑不起来。

先给个直观的定义：

我习惯用一个比喻来解释：

你往河里扔了三块木头，每块代表一条消息。正常情况下，下游应该依次捞起三块。但有时候水流太急，三块木头漂到一起被捞起来——这就是粘包。有时候一块木头太大，被水流冲断成两截，分两次捞起——这就是拆包。

核心要点：粘包和拆包不是TCP的bug，而是TCP流式传输的固有特性。你没法消灭它，只能通过协议设计来应对它。

这个问题我面试过很多人，能答到点子上的不多。说白了，原因就三个层面：

TCP不关心你发的是什么。它只保证一件事：字节流的顺序和完整性。你调用三次send()，TCP可能把这三次的数据合并成一个TCP报文发出去。反过来，你一次send()了10KB数据，TCP可能拆成多个报文分段发送。

为什么会这样？因为TCP有个东西叫Nagle算法——它会攒数据，攒到一定量再发，提高网络利用率。我早期做游戏服务器时就被这个坑过，小包发出去迟迟不到，一查是Nagle在作祟。

应用程序调用send()，数据先进入内核的发送缓冲区。TCP从缓冲区取数据，按MSS（最大报文段长度）打包发送。如果多个小包在缓冲区里挨着，TCP可能一次全取走，打包成一个报文。

接收方也一样。数据到达后先进接收缓冲区，应用程序调用recv()时从缓冲区读。如果应用程序读得慢，多个报文的数据就会在缓冲区里堆积，一次读出来就是粘包。如果应用程序读得快，但缓冲区里只有半个报文的数据，那就是拆包。

场景	发送方行为	接收方行为	结果
连续发送小包	Nagle合并或缓冲区合并	一次读取多个包	粘包
发送大包	按MSS分片	多次读取	拆包
接收方处理慢	正常发送	缓冲区堆积后一次读取	粘包
接收缓冲区不足	正常发送	部分读取	拆包

这个问题我经常拿来考校新人。答案其实很简单：UDP是面向消息的协议。

UDP保留消息边界。你发一次sendto()，接收方一次recvfrom()读到的就是完整的一条消息。不多不少，不会粘也不会拆。

为什么？因为UDP的每个数据报都是独立发送的。内核在接收端为每个数据报分配独立的缓冲区，应用程序一次读一个。不存在"多个数据报合并读取"的情况。

个人经验：我做过一个日志采集系统，最初用UDP就是因为不想处理粘包。但UDP有丢包和乱序的问题，后来还是换成了TCP+自定义长度字段的方案。选哪个，得看业务对可靠性的要求。

下面这张图是我梳理的本章知识结构，方便你建立整体认知：

既然粘包拆包无法避免，那就得想办法解决。业界主流方案有三种：

避坑提醒：我曾经在一个项目中用了分隔符方案，结果用户消息里恰好包含了分隔符，导致消息被错误截断。后来不得不加转义逻辑。如果你做的是通用协议，建议优先考虑长度字段方案。

粘包拆包是TCP编程绕不开的话题。记住三个关键点：

后面的章节，我会用Go、Java、Python、C++、Rust五种语言，逐一实现这三种方案。到时候你会看到，同样的思路在不同语言里写出来差别还挺大的。