黏包问题的成因与解决方案

原文链接地址：https://www.cnblogs.com/kakawith/p/8378425.html

一、黏包成因

tcp协议的拆包机制

当发送端缓冲区的长度大于网卡的MTU时，tcp会将这次发送的数据拆成几个数据包发送出去。 
MTU是Maximum Transmission Unit的缩写。意思是网络上传送的最大数据包。MTU的单位是字节。大部分网络设备的MTU都是1500。
如果本机的MTU比网关的MTU大，大的数据包就会被拆开来传送，这样会产生很多数据包碎片，增加丢包率，降低网络速度

面向流的通信特点和Nagle算法

TCP（transport control protocol，传输控制协议）是面向连接的，面向流的，提供高可靠性服务。
收发两端（客户端和服务器端）都要有一一成对的socket，因此，发送端为了将多个发往接收端的包，更有效的发到对方，使用了优化方法（Nagle算法），将多次间隔较小且数据量小的数据，合并成一个大的数据块，然后进行封包。
这样，接收端，就难于分辨出来了，必须提供科学的拆包机制。 即面向流的通信是无消息保护边界的。 
对于空消息：tcp是基于数据流的，于是收发的消息不能为空，这就需要在客户端和服务端都添加空消息的处理机制，防止程序卡住，而udp是基于数据报的，即便是你输入的是空内容（直接回车），也可以被发送，udp协议会帮你封装上消息头发送过去。 
可靠黏包的tcp协议：tcp的协议数据不会丢，没有收完包，下次接收，会继续上次继续接收，己端总是在收到ack时才会清除缓冲区内容。数据是可靠的，但是会粘包。

总结：

黏包有两种：

一种是因为发送数据包时，每次发送的包小，因为系统进行优化算法，就将两次的包放在一起发送，减少了资源的重复占用。多次发送会经历多次网络延迟，一起发送会减少网络延迟的次数。因此在发送小数据时会将两次数据一起发送，而客户端接收时，则会一并接收。#即出现多次send会出现黏包

第二种是因为接收数据时，又多次接收，第一次接收的数据量小，导致数据还没接收完，就停下了，剩余的数据会缓存在内存中，然后等到下次接收时和下一波数据一起接收。

二、黏包的解决方案

1，问题的根源在于，接收端不知道发送端将要传送的字节流的长度，所以解决粘包的方法就是围绕，如何让发送端在发送数据前，把自己将要发送的字节流总大小让接收端知晓，然后接收端来一个死循环接收完所有数据。

server

client

2.使用time模块，在每次send的时候加入一个time.sleep(0.01),这种方法可以有效地隔开两次send，断开系统的优化，此种方法虽然可以解决黏包问题，但是会造成发送数据时间长

server

client

3，先读取文件的大小，然后将文件的大小发送给接收端，这样接收端就可以以文件大小来写入数据。

server

client

为什么会出现黏包问题？

首先只有在TCP协议中才会出现黏包现象

是因为TCP协议是面向流的协议

在发送的数据传输的过程中海油缓存机制来避免数据丢失

因为在连续发送小数据的时候、以及接收大小不符的时候都容易出现黏包现象

本质还是因为我们在接收数据的时候不知道发送的数据的长短

解决黏包问题

在传输大量数据之前先告诉数据量的大小。

4,使用struct解决黏包