其他相关文章：http://c.biancheng.net/view/2350.htmlhttps://blog.csdn.net/seamanj/article/details/40063093https://www.cnblogs.com/sun-10387834/p/10790999.html

TCP是面向连接的运输层协议

简单来说，在使用TCP协议之前，必须先建立TCP连接，就是我们常说的三次握手。在数据传输完毕之后，必须是释放已经建立的TCP连接，否则会发生不可预知的问题，造成服务的不可用状态。

每一条TCP连接都是可靠连接，且只有两个端点

TCP连接是从Server端到Client端的点对点的，通过TCP传输数据，无差错，不重复不丢失。

TCP协议的通信是全双工的

TCP协议允许通信双方的应用程序在任何时候都能发送数据。TCP 连接的两端都设有发送缓冲区和接收缓冲区，用来临时存放双向通信的数据。发送数据时，应用程序把数据传送给TCP的缓冲后，就可以做自己的事情，而TCP在合适的时候将数据发送出去。在接收的时候，TCP把收到的数据放入接收缓冲区，上层应用在合适的时候读取数据。

TCP协议是面向字节流的

TCP中的流是指流入进程或者从进程中流出的字节序列。所以向Java，golang等高级语言在进行TCP通信是都需要将相应的实体序列化才能进行传输。还有就是在我们使用Redis做缓存的时候，都需要将放入Redis的数据序列化才可以，原因就是Redis底层就是实现的TCP协议。

TCP并不知道所传输的字节流的含义，TCP并不能保证接收方应用程序和发送方应用程序所发出的数据块具有对应大小的关系（这就是TCP传输过程中产生的粘包问题）。但是应用程序接收方最终受到的字节流与发送方发送的字节流是一定相同的。因此，我们在使用TCP协议的时候应该制定合理的粘包拆包策略。

下图是TCP的协议传输的整个过程：

下面这个图是从老钱的博客里面取到的，非常生动 

理论推敲 如下图所示，出现的粘包问题一共有三种情况

第一种情况：  如上图中的第一根bar所示，服务端一共读到两个数据包，每个数据包都是完成的，并没有发生粘包的问题，这种情况比较好处理，服务器只需要简单的从网络缓冲区去读就好了，每次服务端读取到的消息都是完成的，并不会出现数据不正确的情况。

第二种情况：  服务端仅收到一个数据包，这个数据包包含客户端发出的两条消息的完整信息，这个时候基于第一种情况的逻辑实现的服务端就蒙了，因为服务端并不能很好的处理这个数据包，甚至不能处理，这种情况其实就是TCP的粘包问题。

第三种情况：  服务端收到了两个数据包，第一个数据包只包含了第一条消息的一部分，第一条消息的后半部分和第二条消息都在第二个数据包中，或者是第一个数据包包含了第一条消息的完整信息和第二条消息的一部分信息，第二个数据包包含了第二条消息的剩下部分，这种情况其实是发送了TCP拆包问题，因为发生了一条消息被拆分在两个包里面发送了，同样上面的服务器逻辑对于这种情况是不好处理的。

为什么会发生TCP粘包、拆包：

1.应用程序写入的数据大于套接字缓冲区大小，这将会发生拆包。

2.应用程序写入数据小于套接字缓冲区大小，网卡将应用多次写入的数据发送到网络上，这将会发生粘包。

3.进行MSS（最大报文长度）大小的TCP分段，当TCP报文长度-TCP头部长度>MSS的时候将发生拆包。

4.接收方法不及时读取套接字缓冲区数据，这将发生粘包。

5.当连续发送数据时，由于tcp协议的nagle算法，会将较小的内容拼接成大的内容，一次性发送到服务器端，因此造成粘包

处理粘包、拆包的方法：

通常会有以下一些常用的方法：

1.使用带消息头的协议、消息头存储消息开始标识及消息长度信息，服务端获取消息头的时候解析出消息长度，然后向后读取该长度的内容。

2.设置定长消息，服务端每次读取既定长度的内容作为一条完整消息，当消息不够长时，空位补上固定字符。

3.设置消息边界，服务端从网络流中按消息编辑分离出消息内容，一般使用‘\n’。

4.更为复杂的协议，例如楼主最近接触比较多的车联网协议808,809协议。

TCP粘包拆包的代码实践 下面代码楼主主要演示了使用规定消息头，消息体的方式来解决TCP的粘包，拆包问题。

server端代码： server端代码的主要逻辑是接收客户端发送过来的消息，重新组装出消息，并打印出来。  

client端代码：客户端代码主要逻辑是组装要发送的消息，确定消息头，消息体，然后发送到服务端。