TCP粘包问题：原理、解决方法与UDP为什么没有粘包

一、什么是TCP粘包问题？

1.1 从一个实际例子开始

假设我们正在编写一个 TCP 客户端和服务端程序，客户端连续发送两条消息：

send(sockfd, "Hello", 5, 0);
send(sockfd, "World", 5, 0);

按照我们的代码逻辑，客户端发送了两次数据：

• 第一次发送：Hello

• 第二次发送：World

那么服务端接收数据时，是不是也一定会调用两次 recv()，第一次得到 Hello，第二次得到 World 呢？

答案是不一定。

服务端可能出现下面几种情况。

情况一：两次接收，恰好对应两条消息。

客户端发送                  服务端接收

Hello      ──────────────>  Hello
World      ──────────────>  World

情况二：一次接收，拿到了两条消息的数据。

客户端发送                  服务端接收

Hello      ──┐
             ├───────────>  HelloWorld
World      ──┘

情况三：一条消息被分成多次接收。

客户端发送                  服务端接收

Hello      ──────────────>  Hel
                            lo

甚至还可能出现这样的情况：

客户端发送                  服务端接收

Hello      ──┐
             ├───────────>  Hel
World      ──┘              loWor
                            ld

可以发现，客户端调用几次 send()，并不能决定服务端需要调用几次 recv()，也不能决定每次 recv() 能够读到多少数据。

这就是 TCP 粘包问题所涉及的核心现象。

1.2 粘包到底是什么意思？

TCP 是一种面向连接的、可靠的、基于字节流的传输层协议。

这里最重要的是四个字：字节流。

所谓字节流，就是 TCP 只负责按照顺序传输字节，并不理解这些字节在应用程序中分别代表什么。

例如，客户端连续发送：

HelloWorld123456

对于 TCP 来说，这就是一串需要可靠传输的字节。TCP 并不知道：

• Hello 是第一条消息；

• World 是第二条消息；

• 123456 是第三条消息。

这些消息边界是应用程序自己定义的，而不是 TCP 协议定义的。

因此，当多条应用层消息连续写入 TCP 连接时，接收端可能一次读取到多条消息的数据，也可能只读取到一条消息的一部分。

通常，我们把前一种现象称为粘包，把后一种现象称为拆包。

严格来说，粘包和拆包并不是 TCP 协议出现了错误，而是应用程序对 TCP 字节流的读取方式与自身的消息边界设计之间存在差异。

1.3 为什么会出现粘包和拆包？

要理解这个问题，需要先了解 TCP 的工作方式。

TCP 发送数据时，并不是简单地将一次 send() 调用原封不动地交给对端的一次 recv() 调用。数据在发送和接收过程中，还会经过内核缓冲区、TCP 分段、网络传输以及接收端缓冲区等环节。

可以将整个过程理解为：

客户端应用程序
       |
       | send("Hello")
       | send("World")
       v
客户端发送缓冲区
       |
       v
TCP协议处理
       |
       | 分段、发送
       v
网络传输
       |
       v
服务端TCP接收缓冲区
       |
       | recv()
       v
服务端应用程序

在这个过程中，应用程序的每次 send() 调用只是将数据交给本机内核处理，并不代表 TCP 必须立即发送一个独立的数据包。

同样，服务端调用 recv() 时，读取的是接收缓冲区中当前可读取的数据，而不是按照客户端的 send() 调用次数来读取。

出现粘包和拆包，主要有以下几个原因。

第一，TCP 不保留应用层消息边界。

这是最根本的原因。TCP 只保证字节可靠、有序地到达，不保证消息之间的边界。

第二，发送缓冲区可能积累多次写入的数据。

如果应用程序连续调用 send()，数据可能在发送缓冲区中积累，再由 TCP 根据实际情况发送。多次写入的数据可能连续出现在接收端的字节流中。

第三，一条消息可能被拆分传输。

例如，一条消息有 10 KB，而传输过程中 TCP 可能将其划分为多个 TCP 段。接收端读取数据时，也可能只读到其中一部分。

需要注意，TCP 分段与应用程序的 send() 调用没有一一对应的关系。

第四，接收端每次读取多少数据，由实际条件决定。

recv() 的第三个参数指定的是本次最多读取多少字节，并不是要求内核必须读取指定数量，也不是指定读取一条完整消息。

例如：

char buffer[1024];

ssize_t n = recv(sockfd, buffer, sizeof(buffer), 0);

这里的 sizeof(buffer) 是 1024，表示本次最多读取 1024 字节。

如果当前只有 20 字节可读，正常情况下就可能返回 20；如果有更多数据可读，也可能读取其中一部分。对于阻塞式 TCP 套接字，recv() 通常不会为了凑满 1024 字节而一直等待。

因此，不能通过固定一次 recv() 的缓冲区大小，来判断一条应用层消息是否接收完整。

二、TCP粘包问题应该怎么解决？

既然 TCP 不会自动帮我们区分应用层消息的边界，那么解决粘包问题的关键就很明确了：

我们需要在应用层制定一套消息格式，让接收端能够判断一条消息从哪里开始、到哪里结束。

TCP 不负责识别消息边界，但我们可以自己规定消息边界。只要发送端和接收端遵守同一套规则，就能够从连续的 TCP 字节流中正确地还原出一条条完整消息。

常见的解决方案有三种：

1. 固定长度消息；

2. 特殊分隔符；

3. 消息头携带数据长度。

2.1 解决方案一：固定长度消息

固定长度消息，就是规定每一条应用层消息必须具有相同的长度。

例如，我们规定每条消息固定为 10 字节：

消息1：Hello12345    10字节
消息2：World67890    10字节
消息3：Linuxabcde    10字节

客户端发送三条消息：

Hello12345World67890Linuxabcde

即使服务端一次 recv() 读取到了全部 30 字节，也没有关系。

因为双方事先约定了每条消息的长度是 10 字节，所以服务端只需要每次累计读取 10 字节，就可以得到一条完整消息。

TCP接收字节流

Hello12345World67890Linuxabcde
|---------|---------|---------|
    10字节    10字节    10字节

      消息1     消息2     消息3

但是，这种方法有一个问题：每条消息都必须固定长度，灵活性比较差。

假设实际消息只有 3 个字节：

Hi!

如果协议规定每条消息必须为 10 字节，那么就需要补齐剩余空间，或者通过其他方式处理不足的部分。

而当消息长度超过固定长度时，还需要额外设计拆分规则。

因此，固定长度消息适合数据结构固定、报文长度明确的场景，例如某些固定格式的设备通信协议。

2.2 解决方案二：使用特殊分隔符

第二种方法是使用特殊字符标记一条消息的结束。

例如，我们规定每条消息都以换行符 \n 结尾。

客户端发送：

Hello\n
World\n
Linux\n

对应的 TCP 字节流就是：

Hello\nWorld\nLinux\n

服务端不再要求一次 recv() 必须读取一条完整消息，而是持续读取字节，并检查是否出现了 \n。

当找到一个分隔符时，就说明已经获得了一条完整消息。

TCP接收字节流

Hello\nWorld\nLinux\n
     ^      ^      ^
     |      |      |
    消息1   消息2   消息3
    结束    结束    结束

假设第一次 recv() 只读取到了：

Hello\nWor

此时，服务端可以先取出完整的 Hello，同时将尚未处理的 Wor 保存在接收缓存中。

下一次又读取到：

ld\nLinux\n

将新数据拼接到缓存后：

World\nLinux\n

服务端就可以继续解析出 World 和 Linux。

这里要注意：接收端必须保留尚未组成完整消息的数据，不能因为一次 recv() 返回了，就直接将缓存中的所有数据当成一条消息处理。

这种方案实现起来比较简单，常见于文本协议，例如使用换行符分隔的命令、日志或交互式文本通信。

不过，它也有一个问题：如果消息内容本身就包含分隔符，应该怎么办？

例如：

Hello
World\n

如果消息正文中允许出现换行符，那么接收端可能无法判断这个换行符究竟是正文的一部分，还是消息结束标记。

解决方法包括转义分隔符、限制正文不能包含该字符，或者改用长度字段。

2.3 解决方案三：消息头携带数据长度

对于需要传输任意长度数据的 TCP 应用程序，常用的方法是让每条消息在正文前面携带一个消息头，消息头中记录正文的长度。

例如，我们规定：

+----------------------+------------------------+
|     消息头（4字节）   |       消息正文         |
+----------------------+------------------------+
| 正文长度：00000005   | Hello                  |
+----------------------+------------------------+

这里的 00000005 只是为了便于理解而使用的示意表示，实际协议通常使用 4 字节整数存储长度。

假设消息头使用一个 4 字节的无符号整数表示正文长度，那么发送一条 Hello 消息时，数据结构就是：

┌──────────────────────────────┐
│ 消息头：正文长度 = 5          │  4字节
├──────────────────────────────┤
│ 消息正文：Hello               │  5字节
└──────────────────────────────┘

整条消息长度 = 4 + 5 = 9字节

接收端读取数据时，就可以按照以下流程进行处理。

              开始接收数据
                   |
                   v
          读取固定长度的消息头
                   |
                   v
          解析出正文长度 length
                   |
                   v
        根据 length 读取完整正文
                   |
                   v
           得到一条完整消息
                   |
                   v
       继续读取下一条消息的消息头

这种方式的核心是：接收端不再依赖一次 recv() 收到了多少数据，而是根据消息头提供的长度，判断自己还需要接收多少字节。

例如，客户端连续发送两条消息：

消息1：[长度=5][Hello]
消息2：[长度=5][World]

TCP 传输过程中，服务端可能一次读取到：

[长度=5][Hello][长度=5][World]

也可能分多次读取：

第一次： [长度=5][He
第二次： llo][长度=5][W
第三次： orld]

无论数据如何分段，只要接收端正确地解析消息头，并且累计读取指定长度的数据，就能还原出两条完整消息。

这也是很多二进制通信协议常用的设计思路。

2.3.1 使用长度字段时，需要注意什么？

首先，消息头必须有明确的格式。例如，规定消息头固定为 4 字节，不能让接收端连消息头本身有多长都无法判断。

其次，需要统一长度字段的字节序。比如，网络协议经常使用网络字节序，也就是大端序。发送端和接收端必须按照相同规则编码、解析长度。

第三，需要限制消息的最大长度。不能盲目相信收到的长度字段，否则错误数据或恶意数据可能让接收端尝试申请过大的内存。

最后，读取消息头和读取正文时，都要正确处理不完整的读取结果。

TCP 是字节流协议，即使我们只想读取 4 字节的消息头，也不能假定一次 recv() 一定能返回 4 字节。

例如：

期望读取消息头：4字节

第一次 recv()：2字节
第二次 recv()：1字节
第三次 recv()：1字节

累计读取：4字节

只有累计读取满 4 字节，才能解析消息头。

正文同样如此。假设消息头告诉我们正文有 100 字节，那么接收端就需要持续读取，直到累计得到完整的 100 字节，或者出现连接关闭、错误等情况。

2.4 三种解决方案应该如何选择？

方案	消息边界的判断方式	优点	局限
固定长度	每条消息长度固定	实现简单	不适合长度变化较大的数据
特殊分隔符	查找约定的结束标记	文本协议比较方便	需要处理正文中的分隔符
长度字段	根据消息头中的长度解析	适合变长消息、二进制数据	需要正确处理消息头和正文的累计读取

实际开发时，应根据应用协议的特点选择合适的方案。

例如，简单的文本命令可以使用换行符分隔；固定格式的设备报文可以采用固定长度；需要传输任意长度的二进制数据时，通常可以考虑长度字段方案。

无论采用哪种方式，核心思想都一样：TCP 负责可靠传输字节流，应用层负责定义和识别消息边界。

三、UDP为什么没有粘包问题？

前面我们分析了 TCP 的粘包问题。接下来就会产生一个疑问：既然 TCP 存在粘包问题，那么 UDP 为什么通常没有这个问题？

要回答这个问题，需要先了解 TCP 和 UDP 在数据组织方式上的区别。

3.1 TCP是面向字节流的，UDP是面向数据报的

TCP 和 UDP 都属于传输层协议，但它们对应用程序数据的组织方式不同。

TCP 是面向字节流的协议。应用程序写入 TCP 的多段数据，在接收端表现为连续的字节流，TCP 不会保留应用层每次发送消息的边界。

UDP 则是面向数据报的协议。应用程序每次通过 UDP 发送的数据报，都具有独立的边界。接收端通过一次正常的 UDP 接收操作，读取一个数据报，而不是从多个数据报拼成的连续字节流中任意读取一段数据。

我们用同样的方式分别发送两条消息。

TCP：

发送端：

send("Hello")
send("World")
       |
       v
TCP字节流：

HelloWorld
       |
       v
接收端：

recv() 可能读取 HelloWorld

UDP：

发送端：

sendto("Hello")
sendto("World")
       |
       v
两个独立的数据报：

┌─────────────┐
│    Hello    │
└─────────────┘

┌─────────────┐
│    World    │
└─────────────┘
       |
       v
接收端：

recvfrom() 读取一个数据报
recvfrom() 读取另一个数据报

可以看到，UDP 的数据报边界由协议本身保留，因此不会像 TCP 那样，把多次发送的数据作为一条没有边界的连续字节流交给接收端。

3.2 UDP接收时，为什么不会把两条消息合并？

假设客户端连续调用两次 sendto()：

sendto(sockfd, "Hello", 5, 0,
       (struct sockaddr *)&server_addr,
       sizeof(server_addr));

sendto(sockfd, "World", 5, 0,
       (struct sockaddr *)&server_addr,
       sizeof(server_addr));

UDP 会形成两个独立的数据报。

服务端使用 recvfrom() 接收数据时，每次接收对应一个数据报。即使两个数据报先后到达，UDP 也不会因为它们连续到达，就把它们合并成一个更大的数据报。

因此，UDP 不存在 TCP 意义上的粘包问题。

不过，这并不意味着 UDP 不会出现其他问题。

3.3 UDP没有粘包，不代表UDP一定可靠

UDP 的数据报边界是明确的，但 UDP 本身不保证数据一定送达，也不保证数据报一定按照发送顺序到达。

例如，客户端发送了三个数据报：

发送顺序：

数据报A
数据报B
数据报C

服务端实际收到的情况可能是：

数据报A
数据报C

数据报 B 可能在网络传输过程中丢失。

也可能出现：

发送顺序：A → B → C

接收顺序：A → C → B

所以，UDP 解决的是消息边界问题，而不是可靠传输问题。

另外，UDP 还有一个容易忽略的细节：如果接收缓冲区小于收到的数据报的长度，数据报剩余的部分可能会被截断丢弃。 这并不是粘包，而是接收缓冲区容量不足导致的数据截断。

例如，发送端发送了一个 100 字节的数据报，接收端却只提供了 20 字节的接收缓冲区，那么这次接收可能只得到前 20 字节，剩余数据无法通过下一次接收继续读取。

因此，使用 UDP 时同样需要合理设计报文格式，并确保接收缓冲区足够容纳预期的数据报。

3.4 TCP与UDP的区别总结

对比项	TCP	UDP
数据组织方式	字节流	数据报
是否保留应用层消息边界	不保留	保留数据报边界
是否存在传统意义上的粘包问题	存在	不存在
可靠性	提供可靠、有序的字节流传输	不保证送达与顺序
接收数据的特点	每次读取可得到任意数量的可用字节	每次接收对应一个数据报
常见用途	文件传输、网页访问、数据库连接	实时音视频、DNS查询、部分游戏通信

四、进一步理解：TCP粘包并不是网络数据包粘在了一起

很多人第一次接触粘包问题时，会把它理解成网络传输过程中，两个 TCP 数据包真的粘在了一起。

实际上，这并不是粘包问题的本质。

TCP 仍然按照自己的协议规则处理数据，并通过序号、确认应答、重传等机制保证可靠、有序的字节流传输。

问题出在应用层：发送端认为自己发送的是一条条独立的消息，而 TCP 接收端提供给应用程序的是连续的字节流。

例如：

应用层发送：

消息A       消息B       消息C
  |           |           |
  v           v           v

TCP传输：

A的字节 + B的字节 + C的字节
          连续字节流

应用层接收：

需要自行识别 A、B、C 的边界

因此，即使网络上每个 TCP 段都正常传输，也依然可能出现应用层所谓的粘包或拆包现象。

同样，即使发送端每次只调用一次 send()，接收端也不能依赖某次 recv() 恰好得到一条完整消息。

真正可靠的解决方式，不是试图控制 TCP 每次发送多少数据，而是为应用层设计清晰的消息格式，并让接收端按照协议解析数据。

五、总结

TCP 粘包问题的根源，是 TCP 面向字节流的设计。TCP 只保证字节可靠、有序地传输，并不保留应用程序每次发送数据时的消息边界。因此，发送端调用多少次 send()，与接收端需要调用多少次 recv()，不存在一一对应的关系。

解决粘包问题，通常有三种思路：固定长度消息、特殊分隔符、消息头携带数据长度。它们本质上都是通过应用层协议明确消息的开始与结束。

而 UDP 不存在传统意义上的粘包问题，是因为 UDP 以独立数据报为基本传输单位，接收端能够识别每个数据报的边界。但 UDP 仍然可能丢包、乱序，也可能因为接收缓冲区不足而发生数据截断。

最后记住这句话：

TCP 传输的是连续的字节流，消息边界需要应用层自己定义；UDP 传输的是独立的数据报，每个数据报天然具有边界。