TCP传输中粘包/拆包问题

ゝ一世哀愁。 2022-12-07 11:45 235阅读 0赞

### 目录 ###

*  简介
 *  产生原因
 *  解决方法
 *   *  1. 改成短连接
     *  2. 封装成帧
 *  参考文章
 *  扩展阅读

# 简介 #

TCP 传输中，客户端发送数据，实际是把数据写入到了 TCP 的缓存中，粘包和半包也就会在此时产生。

客户端给服务端发送了两条消息ABC和DEF，服务端这边的接收会有多少种情况呢?有可能是一次性收到了所有的消息ABCDEF，有可能是收到了三条消息AB、CD、EF。

上面所说的一次性收到了所有的消息ABCDEF，类似于粘包。如果客户端发送的包的大小比 TCP 的缓存容量小，并且 TCP 缓存可以存放多个包，那么客户端和服务端的一次通信就可能传递了多个包，这时候服务端从 TCP 缓存就可能一下读取了多个包，这种现象就叫粘包。

上面说的后面那种收到了三条消息AB、CD、EF，类似于半包。如果客户端发送的包的大小比 TCP 的缓存容量大，那么这个数据包就会被分成多个包，通过 Socket 多次发送到服务端，服务端第一次从接受缓存里面获取的数据，实际是整个包的一部分，这时候就产生了半包(半包不是说只收到了全包的一半，是说收到了全包的一部分)。

# 产生原因 #

由上面的讨论，我大致可以了解到，**粘包**的主要原因：

1.  发送方每次写入数据 < 套接字(Socket)缓冲区大小；
2.  接收方读取套接字(Socket)缓冲区数据不够及时；

**半包** 的主要原因：

1.  发送方每次写入数据 > 套接字(Socket)缓冲区大小；
2.  发送的数据大于协议的 MTU (Maximum Transmission Unit，最大传输单元)，因此必须拆包；

其实我们可以换个角度看待问题：

从收发的角度看，便是一个发送可能被多次接收，多个发送可能被一次接收。  
从传输的角度看，便是一个发送可能占用多个传输包，多个发送可能共用一个传输包。

根本原因是：**TCP 是流式协议，消息无边界。**

(PS ： UDP 虽然也可以一次传输多个包或者多次传输一个包，但每个消息都是有边界的，因此不会有粘包和半包问题。)

# 解决方法 #

如上所述，UDP 之所以不会产生粘包和半包问题，主要是因为消息有边界。因此，我们也可以采取类似的思路处理tcp消息。

## 1. 改成短连接 ##

将 TCP 连接改成短连接，一个请求一个短连接。这样建立连接到释放连接之间的消息即为传输的信息，消息也就产生了边界。

优点：十分简单，不需要在我们的应用中做过多修改。  
缺点：效率低下，TCP 连接和断开都会涉及三次握手以及四次握手，每个消息都会涉及这些过程，十分浪费性能。

并不推介这种方式。

## 2. 封装成帧 ##

将传输消息封装成帧(Framing)，也就是原本发送消息的单位是缓冲大小，现在换成了帧，这样我们就可以自定义边界了。一般有以下4种方式：

1.  固定长度
    
    消息长度采用固定长度即可，较短的消息可采用默认值填充。
    
    优点：实现简单。  
    缺点：有极大的流量浪费，如果传递的消息中大部分都比较短，为了兼容最长的消息可能消息中有很多默认值作为无效的信息传输。
    
    一般也是不推介该方式。
2.  分隔符
    
    使用分隔符作为消息边界，通过获取分隔符将消息切割。
    
    优点：空间使用率高，实现也比较简单。  
    缺点：是当内容本身出现分割符时需要转义，所以无论是发送还是接受，都需要扫描整个内容做转义处理。
    
    消息体较短时，推荐使用该方式。
    
    例如，按行解析，遇到字符\\n、\\r\\n的时候，就认为是一个完整的数据包。对于以下二进制字节流：
    
        +--------------+ 
        | ABC\nDEF\r\n | 
        +--------------+
    
    那么根据协议，我们可以判断出来，这里包含了2个有效的请求报文
    
        +-----+-----+ 
        | ABC | DEF | 
        +-----+-----+
    
    在特殊字符分隔符协议中：
    
    发送方，需要在发送一个报文时，需要在报文尾部添加特殊分割符号;  
    接收方，在接收到报文时，需要对特殊分隔符进行检测，直到检测到一个完整的报文时，才能进行处理。  
    在使用特殊字符分隔符协议的时候，需要注意的是，我们选择的特殊字符，一定不能在消息体中出现，否则可能会出现错误的拆包。例如，发送方希望把”12\\r\\n34”，当成一个完整的报文，如果是按行拆分，那么就会错误的拆分为2个报文。一种解决策略是，发送方对需要发送的内容预先进行base64编码，由于base64编码只包含64个字符：0-9、a-z、A-Z、+、/，我们可以选择这64个字符之外的特殊字符作为分隔符。
3.  专门的 length 字段
    
    这种方式有点类似于Http 请求中的 Content-Length，有一个专门的字段存储消息的长度。作为服务端，接受消息时，先解析固定长度的字段(length字段)获取消息总长度，然后读取后续内容。
    
    优点：精确定位用户数据，内容也不用扫描转义。  
    缺点：长度理论上有限制，因为长度字段占用字节数为固定值要先定义， 因此限制了传输消息的最大长度。另外如果长度占用字节过多，在传输短消息时，会造成头部信息占比过长，影响传输效率。
    
    消息体较长时，推介用这种方式。
4.  其他方式
    
    其他方式多种多样，比如 JSON 可以看成是使用\{\}是否成对，xml可以看括号是否配对等等。

# 参考文章 #

1.  [TCP 粘包和半包 介绍及解决][TCP _]
2.  [TCP粘包、拆包与通信协议详解][TCP]，推荐阅读，该文章中关于粘包的解释原因比较详细，不过其中3.6查错校验码有可能是在协议不是over tcp，在普通不可靠传输中用于校验数据，不是文章中所说的基于tls的可靠传输。‘

# 扩展阅读 #

1.  [告知你不为人知的UDP-疑难杂症和使用][UDP-] 介绍udp的适用场景，以及区分于tcp的数据有界性。

[TCP _]: https://network.51cto.com/art/201910/604760.htm
[TCP]: https://network.51cto.com/art/201910/604438.htm
[UDP-]: https://zhuanlan.zhihu.com/p/25622691