1. 粘包拆包问题概述

各位同学好，我是你们的老朋友。今天咱们来聊聊网络编程里一个绕不开的话题——TCP粘包与拆包。

说实话，我刚开始做网络编程那会儿，第一次遇到粘包问题，整个人是懵的。明明我发了两次数据，对端怎么一次就全收走了？后来查了三天资料，才搞明白是怎么回事。今天我就把这点经验分享给大家。

什么是TCP粘包与拆包

先看个最简单的场景。你写了一个客户端，连续发了两次数据：

• 第一次发送："Hello"
• 第二次发送："World"

你期望服务端收到的是两条独立的消息。但实际呢？服务端可能一次就收到了 "HelloWorld"——这就是粘包。

反过来，如果一条消息太大，被拆成了多个TCP包发送，服务端分多次才收全——这就是拆包。

问题产生的根本原因

为什么会这样？说白了，TCP是流式协议。

你想想看，TCP不关心你发的是什么数据，它只负责把字节流从A端送到B端。就像水管里的水，你倒进去的是"Hello"和"World"两杯水，但水管里流的是连续的水流，对端接到的也是一整段水。

具体原因有这几个：

1. Nagle算法：TCP默认开启Nagle算法，它会把小包合并成大包再发送。我遇到过好几次，关了Nagle算法粘包就消失了。
2. TCP缓冲区：发送方和接收方都有缓冲区。数据先到缓冲区，攒够了才发送或读取。
3. MSS（最大报文段长度）：如果数据超过MSS，TCP会自动拆包。
4. 网络延迟：多个小包在传输过程中可能被合并。

为什么UDP没有这个问题

这个问题我经常被问到。答案其实很简单——UDP是报文协议。

UDP每个sendto()调用对应一个独立的报文，接收方recvfrom()一次只能读一个完整的报文。报文之间是有边界的，不会粘在一起。

打个比方：

• TCP就像快递公司把多个包裹拆开混装，你收到一堆零件得自己拼
• UDP就像每个包裹独立寄送，你收到什么就是什么

但别高兴太早。UDP虽然不粘包，但它会丢包、乱序。嗯，这里要注意，没有银弹。

知识体系结构

下面这张图，是我画的本章节知识体系。你可以看到粘包拆包在整个网络编程中的位置：

一个简单的复现Demo

光说不练假把式。下面我写一个最简单的粘包复现Demo。你可以在自己的机器上跑一下试试。

服务端代码（server.c）：

#include <stdio.h>
#include <string.h>
#include <unistd.h>
#include <sys/socket.h>
#include <netinet/in.h>

int main() {
    int sockfd = socket(AF_INET, SOCK_STREAM, 0);
    
    struct sockaddr_in addr;
    addr.sin_family = AF_INET;
    addr.sin_port = htons(8888);
    addr.sin_addr.s_addr = INADDR_ANY;
    
    bind(sockfd, (struct sockaddr*)&addr, sizeof(addr));
    listen(sockfd, 5);
    
    int connfd = accept(sockfd, NULL, NULL);
    
    char buf[1024] = {0};
    int n = read(connfd, buf, sizeof(buf));
    
    printf("收到数据: %s\n", buf);
    printf("数据长度: %d\n", n);
    
    close(connfd);
    close(sockfd);
    return 0;
}

客户端代码（client.c）：

#include <stdio.h>
#include <string.h>
#include <unistd.h>
#include <sys/socket.h>
#include <netinet/in.h>
#include <arpa/inet.h>

int main() {
    int sockfd = socket(AF_INET, SOCK_STREAM, 0);
    
    struct sockaddr_in addr;
    addr.sin_family = AF_INET;
    addr.sin_port = htons(8888);
    inet_pton(AF_INET, "127.0.0.1", &addr.sin_addr);
    
    connect(sockfd, (struct sockaddr*)&addr, sizeof(addr));
    
    // 连续发送两条消息
    write(sockfd, "Hello", 5);
    write(sockfd, "World", 5);
    
    close(sockfd);
    return 0;
}

运行结果：

$ ./server
收到数据: HelloWorld
数据长度: 10

看到了吗？客户端明明发了两次，服务端一次就收完了10个字节。"Hello"和"World"粘在了一起。

这就是最典型的粘包现象。你想想看，如果这是两条业务逻辑完全不同的消息，服务端怎么区分？

小结

这一章我们搞清楚了几个核心问题：

问题	原因	影响
粘包	TCP流式传输 + Nagle算法	多条消息合并，无法区分边界
拆包	MSS限制 + 缓冲区策略	一条消息被拆分，需要重组
UDP无此问题	报文协议，自带边界	但丢包乱序是新的挑战

说白了，粘包拆包问题的本质就是：TCP不保留应用层的消息边界。下一章我们会深入探讨如何用GDB来调试和分析这些问题。

可可精品资料库