Unix/Linux编程：应用层如何解决TCP 协议粘包、半包问题

àì夳堔傛蜴生んèń 2022-09-14 02:28 155阅读 0赞

# TCP协议是流式协议 #

\*\*[TCP是流式协议][TCP]\*\*这句话到底是什么意思呢？所谓流式协议，即协议的内容是像流水一样的字节流，内容与内容之间没有明确的分界标志，需要我们人为的去给这些协议划分边界。

举个例子，A 与 B 进行 TCP 通信，A 先后给 B 发送了一个 100 字节和 200 字节的数据包，那么 B 是如何收到呢？B 可能先收到 100 字节，再收到 200 字节；也可能先收到 50 字节，再收到 250 字节；或者先收到 100 字节，再收到 100 字节，再收到 100 字节；或者先收到 20 字节，再收到 20 字节，再收到 60 字节，再收到 100 字节，再收到 50 字节，再收到 50 字节……

从上面可以看出：A一共给B发送了300字节，B可能以一次或者多次任意形式的总数为300字节收到。假设A给B发送的100字节和200字节分别都是一共数据包，对于发送端B来说，这个是可以区分的，但是对B来说，如果不认为规定多长为一个数据包，B每次是不知道应该把收到的数据中多少字节作为一个有效的数据包的，而规定每次把多少数据当初一个包就是协议格式规范的内容之一。

经常会有新手写出类似下面这样的代码：

发送端：

//...省略创建socket，建立连接等部分不相关的逻辑...
    char buf[] = "the quick brown fox jumps over a lazy dog.";
    int n = send(socket, buf, strlen(buf), 0);
    //...省略出错处理逻辑...

接收端：

//省略创建socket，建立连接等部分不相关的逻辑...
    char recvBuf[50] = {
         0 };
    int n = recv(socket, recvBuf, 50, 0);
    //省略出错处理逻辑...
    printf("recvBuf: %s", recvBuf);

类似这样的代码在本机一般会工作的很好，接收端也如期打印出来预料的字符串，但是一放到局域网或者公网环境就出问题了，即接收端可能打印出来字符串并不完整；如果发送端连续多次发送字符串，接收端会打印出来的字符串不完整或出现乱码。不完整的原因很好理解，即对端某次收到的数据小于完整字符串的长度，recvBuf 数组开始被清空成 0，收到部分字符串后，该字符串的末尾仍然是 0，printf 函数寻找以 0 为结束标志的字符结束输出；乱码的原因是如果某次收入的数据不仅包含一个完整的字符串，还包含下一个字符串部分内容，那么 recvBuf 数组将会被填满，printf 函数输出时仍然会寻找以 0 为结束标志的字符结束输出，这样读取的内存就越界了，一直找到为止，而越界后的内存可能是一些不可读字符，显示出来后就乱码了。

正因为如此，所以我们需要人为的在发送端和接收端规定每一次的字节流边界，以便接收端知道从什么位置取出多少字节来当成一个数据包去解析，这就是我们设计网络通信协议格式要做的工作之一。

# 如何解决 #

网络通信程序实际开发中，或者技术面试时，面试官通常会问的比较多的一个问题是：网络通信时，如何解决粘包？

> 有的面试官可能会这么问：网络通信时，如何解决粘包、丢包或者包乱序问题？  
> 这个问题其实是面试官在考察面试者的网络基础知识
> 
>  *  如果是TCP协议，在大多数场景下，是不存在丢包和包乱序的问题的，TCP通信是可靠通信方式，TCP协议栈通过序列号和包重传确认机制保证数据包的有序和一定被正确发到目的地
>  *  如果是UDP协议，如果不能接受少量丢包，那就要自己在UDP的基础上实现类似TCP这种有序和可靠传输机制（比如RTP协议、RUDP协议）。所以，问题拆解后，只剩下如何解决粘包的问题了

先来解释一下什么是粘包，所谓粘包就是连续给对端发送两个或者两个以上的数据包，对端在一次收取中可能收到的数据包大于 1 个，大于 1 个，可能是几个（包括一个）包加上某个包的部分，或者干脆就是几个完整的包在一起。当然，也可能收到的数据只是一个包的部分，这种情况一般也叫半包。

无论是半包还是粘包问题，其根源就是上文介绍的TCP协议是流式数据格式。解决方法可以[请先参考这里][Link 1]，这里我们来详细说一下应用层的解决思路思路，其最关键的方法在于**需要想办法从收到的数据中包包与包的边界给区分出来**。那如何区别呢？目前主要有三种方法：

> 固定包长的数据包

顾名思义，即每个协议包的长度都是固定的。举个例子，比如我们可以规定协议包的大小是64个字节，每次收满64个字节，就取出来解析（如果不够，就先存起来）。

这种通信协议的格式简单但灵活性差。**如果包内容不足指定的字节数，剩余的空间需要填充特殊的信息，如 \\0**（如果不填充特殊内容，如何区分包里面的正常内容与填充信息呢？）；如果包内容超过指定字节数，又得分包分片，需要增加额外处理逻辑-------在发送端进行分包分片，在接收端重新组装包片。

> 以指定字符(串)为包的结束标志

这种协议包比较常见，即字节流中遇到特殊的符号值时就认为到一个包的末尾了。比如，我们熟悉的FTP协议，发邮件的SMTP协议，一个命令或者一段数据后面加上"\\r\\n"（即所谓的 CRLF）表示一个包的结束。对端收到后，每遇到一个"\\r\\n"就把之前的数据当做一个数据包。

这种协议一般用于一些包含各种命令控制的应用中，其不足之处就是如果协议数据包内容部分需要使用包结束标志字符，就需要对这些字符做转码或者转义操作，以免被接收方错误地当成包结束标志而误解析。

> 包头 + 包体格式

这种格式的包一般分为两部分，即包头和包体，包头是固定大小的，而且包头中必须含有一个字段来说明接下来的包体有多大。

比如：

struct msg_header{
        
    	int32_t bodySize;
    	int32_t cmd;
    };

这就是一个典型的包头格式，bodySize 指定了这个包的包体是多大。由于包头大小是固定的（这里是 size(int32\_t) + sizeof(int32\_t) = 8 字节），对端先收取包头大小字节数目（当然，如果不够还是先缓存起来，直到收够为止），然后解析包头，根据包头中指定的包体大小来收取包体，等包体收够了，就组装成一个完整的包来处理。在有些实现中，包头中的 bodySize可能被另外一个叫 packageSize 的字段代替，这个字段的含义是整个包的大小，这个时候，我们只要用 packageSize 减去包头大小（这里是 sizeof(msg\_header)）就能算出包体的大小，原理同上。

> 备注：

*  在使用大多数网络库时，通常你需要根据协议格式自己给数据包分界和解析，一般的网络库不提供这种功能是处于需要支持不同的协议，由于协议的不确定性，因此没法预先提供具体的解包代码。当然，这不是绝对的，也有一些网络库提供了这种功能

# 解包与处理 #

在理解了前面介绍的数据包的三种格式后，我们来介绍一下针对上述三种格式的数据包技术上应该如何处理。其处理流程都是一样的，这里我们以包头 + 包体 这种格式的数据包来说明。处理流程如下：  
![在这里插入图片描述][watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBAT2NlYW4mJlN0YXI_size_16_color_FFFFFF_t_70_g_se_x_16]  
假设我们的包头格式如下：

//强制一字节对齐
    #pragma pack(push, 1)
    //协议头
    struct msg
    {
           
        int32_t  bodysize;         //包体大小  
    };
    #pragma pack(pop)

\---------------待续-------

[TCP]: https://blog.csdn.net/zhizhengguan/article/details/118085115
[Link 1]: https://blog.csdn.net/zhizhengguan/article/details/119452571
[watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBAT2NlYW4mJlN0YXI_size_16_color_FFFFFF_t_70_g_se_x_16]: /images/20220828/057f23e5eba24d809048fd88719f2288.png