TCP 粘包及其解决方案

首先，我们回顾一下 TCP 和 UDP 的头部信息：

TCP 头部

UDP 头部

我们知道，TCP 和 UDP 是 TCP/IP 协议族传输层中的两个具有代表性的协议。其中，TCP 是面向连接的复杂的、可靠的字节流传输协议，而 UDP 是面向无连接的简单的、不可靠的数据报传输协议。

“流”的概念就是指不间断的数据结构，可以把它想象成你们家里的自来水管道中的水流。什么意思呢？举个例子：TCP 发送端应用程序发送了10次100字节的消息，那么，在接收端的应用程序接收到的可能是一个1000字节的连续不间断的数据。但如果是 UDP 端口发送了一个100字节的消息，那么 UDP 接收端就会以100字节的长度来接收数据。正因为这样，我们可以看到 TCP 头部中并没有长度信息，而 UDP 头部包含长度信息。好了，现在你应该明白我们在创建套接字的时候，为什么 type 的类型是 SOCK_STREAM 和 SOCK_DGRAM 了吧！

正如文章标题所述，显然，你已经知道 UDP 数据包存在明确边界，是不存在粘包现象的，只有 TCP 才会出现粘包现象。那么，接下来我们逐步分析 TCP 的流传输特性所带来如粘包这样的一些问题及其解决方案。

按每次通信后是否闭关连接，可以分为两类情况：长连接和短连接。长连接——指的是客户端和服务端先建立通信连接，连接建立后不断开，然后再进行报文发送和接收。短连接——指的是客户端和服务端每进行一次报文收发交易时才进行通信连接，交易完毕后立即断开连接，比如 http 协议。

所以我们可以分析以下几种情况：

如果利用 TCP 每次发送数据，就与对方建立连接，然后双方发送完一段数据后，就关闭连接，这样就不会出现粘包问题（因为只有一种数据结构）。
如果发送数据无结构，如文件传输，这样发送端只管发送，接收端只管接收存储就行，也不用考虑粘包。
如果双方建立连接，需要在连接后一段时间内发送多个不同结构的数据，这时候接收端收到就可能是一堆粘在一起的数据，这样接收端应用程序就傻了，到底是要干嘛？不知道，因为协议并没有规定这么诡异的数据。

那么，可以认为 TCP 粘包问题并不是对所有应用都造成困扰的，只是对那些长连接并且需要传输多种数据结构的应用造成影响。仔细分析会发现，除了粘包问题，其实还可能会出现多包、少包、半包、断包等情况。

针对这些问题，一般会有如下解决方法：

调用发送函数之后都强制数据立即传送（PUSH 指令）。
对于接收端引起的粘包，则可通过优化程序设计、精简接收进程工作量、提高接收进程优先级等措施，使其及时接收数据，从而尽量避免出现粘包现象。
添加一个固定的消息头，该消息头包含数据长度信息，每次数据时先接收固定大小的消息头，再根据其携带的长度信息接收消息实体。也就是说，通过人为控制多次接收来避免粘包。
设置 TCP_NODELAY 选项，禁止 Nagle 算法。
设置 SO_RCVBUF 和 SO_SNDBUF 选项，根据应用需求修改一个合适的接收、发送缓冲区大小。
添加报文分隔标识，比如发送报文是在末尾添加 '\n' ，同时接收端使用 recv() 函数接收报文，并且设置参数 flags 的值为 MSG_PEEK。注意：当 flags 参数的值设置为 MSG_PEEK 时，recv() 可以从 socket 缓存中读取数据，但是不会将缓存中该部分数据清除，但如果使用 read() 函数直接读取 socket 缓存区中的内容，会清空缓存区中的内容。假设两段报文粘包，read() 会清空缓存区中所有内容，从而导致后一段报文中的粘包的部分数据丢失。

实际上，上述的几种解决方法都有不足之处，并且不一定能够完全避免 TCP 粘包问题。所以还是需要根据实际应用来进行应用场景和性能方面的衡量。