什么是TCP粘包问题？如何解决TCP粘包问题？

通用头部字段（General Headers）：

Cache-Control：指定缓存策略。

Connection：控制连接的行为。

Date：指定日期和时间。

请求头部字段（Request Headers）：

Accept：指定客户端能够接受的响应的MIME类型。

Accept-Encoding：指定客户端支持的内容编码方式。

Authorization：用于进行身份验证的凭据。

Host：指定请求的目标主机和端口。

User-Agent：标识客户端的用户代理（浏览器或其他工具）。

什么是TCP粘包问题？如何解决TCP粘包问题？

TCP粘包和拆包问题

TCP是一个“流”协议，所谓流，就是没有界限的一长串二进制数据。TCP作为传输层协议并不了解上层业务数据的具体含义，它会根据TCP缓冲区的实际情况进行数据包的划分，所以在业务上认为是一个完整的包，可能

会被TCP拆分成多个包进行发送，也有可能把多个小的包封装成一个大的数据包发送，这就是所谓的TCP粘包和拆包问题。

产生TCP粘包和拆包的原因

我们知道TCP是以流动的方式传输数据的，传输的最小单位为一个报文段（Segment）。TCP Header中有个 Options标识位。常见的标识位为MSS（Maximum Segment Size）指的是，连接层每次传输的数据有个最大

限制MTU（Maximum Transmission Unit），一般是1500bit，超过这个量要分成多个报文段，MSS则是这个最大限制减去TCP的header，光是要传输的数据的大小，一般为1460bit。换算成字节，也就是180多字

节。 TCP为提高性能，发送端会将需要发送的数据发送到缓冲区，等待缓冲区满了以后，再将缓冲中的数据发送到接收方。同理，接收方也有缓冲区这样的机制来接受数据。发生TCP粘包、拆包主要是以下原因：

（1）应用程序写入数据大于套接字缓冲区大小，会发生拆包；（2）应用程序写入数据小于套接字缓冲区大小，网卡将应用多次写入的数据发送到网络上，这将会发送粘包；（3）进行MSS（最大报文长度）大小的

TCP分段，当TCP报文长度——TCP header长度>MSS 的时候会发生拆包；（4）接收方法不及时读取套接字缓冲区数据，这将发生粘包。

为了防止ip层分片，tcp每次只会发送50k的数据，一共发了4个tcp数据包。如果我又访问了另一个网站，这个网站给我发了100k的数据，这次tcp会发出2个包，问题是，客户端收到6个包，怎么知道前4个包是一个页

面，后两个是一个页面。既然是tcp将这些包分开了，那tcp会将这些包重组吗，它送给应用层的是什么？这是我自己想的一个场景，正式一点讲的话，这个现象叫拆包。

我们再考虑一个问题。

tcp中有一个negal算法，用途是这样的：通信两端有很多小的数据包要发送，虽然传送的数据很少，但是流程一点没少，也需要tcp的各种确认，校验。这样小的数据包如果很多，会造成网络资源很大的浪费，negal算法

做了这样一件事，当来了一个很小的数据包，我不急于发送这个包，而是等来了更多的包，将这些小包组合成大包之后一并发送，不就提高了网络传输的效率的嘛。这个想法收到了很好的效果，但是我们想一下，如果是

分属于两个不同页面的包，被合并在了一起，那客户那边如何区分它们呢？这就是粘包问题。

从粘包问题我们更可以看出为什么tcp被称为流协议，因为它就跟水流一样，是没有边界的，没有消息的边界保护机制，所以tcp只有流的概念，没有包的概念。

我们还需要有两个概念：

（1）长连接： Client方与Server方先建立通讯连接，连接建立后不断开，然后再进行报文发送和接收。

（2）短连接：Client方与Server每进行一次报文收发交易时才进行通讯连接，交易完毕后立即断开连接。此种方式常用于一点对多点通讯，比如多个Client连接一个Server。

实际，我想象的关于粘包的场景是不对的，http连接是短连接，请求之后，收到回答，立马断开连接，不会出现粘包。拆包现象是有可能存在的。

处理拆包这里提供两种方法：

（1）通过包头+包长+包体的协议形式，当服务器端获取到指定的包长时才说明获取完整。（2）指定包的结束标识，这样当我们获取到指定的标识时，说明包获取完整。

处理粘包我们从上面的分析看到，虽然像http这样的短连接协议不会出现粘包的现象，但是一旦建立了长连接，粘包还是有可能会发生的。处理粘包的方法如下：

（1）发送方对于发送方造成的粘包问题，可以通过关闭Nagle算法来解决，使用TCP_NODELAY选项来关闭算法。

（2）接收方没有办法来处理粘包现象，只能将问题交给应用层来处理。应用层的解决办法简单可行，不仅能解决接收方的粘包问题，还可以解决发送方的粘包问题。解决办法：循环处理，应用程序从接收缓存中读取分组时，读

完一条数据，就应该循环读取下一条数据，直到所有数据都被处理完成，判断每条数据的长度的方法有两种：

1. 格式化数据：每条数据有固定的格式（开始符，结束符），这种方法简单易行，但是选择开始符和结束符时一

定要确保每条数据的内部不包含开始符和结束符。

1. 发送长度：发送每条数据时，将数据的长度一并发送，例如规定数据的前4位是数据的长度，应用层在处理时

可以根据长度来判断每个分组的开始和结束位置。