socktet粘包问题解决

socket粘包问题

socket系统调用会将要发送的数据从用户空间copy到内核空间，这样频繁的交换操作会耗费资源，为提高效率，会收集到较多的数据才一起发送。如果数据少的几个包一起发送就会造成粘包。

• 只有tcp可能存在粘包问题：
  TCP基于字节流，没有消息边界、数据包的概念，应用层协议如果没有使用基于长度或基于终结符的消息边界，就会导致多个消息粘连，接收端无法。
• udp永远不会粘包：
  udp保留了消息边界，每次操作发送一个IP数据报，不考虑分片。接收端每次都会收到一个完整的udp数据包，因此不会产生多个消息粘连的情况。

出现粘包的原因

socket 为提高传输效率，发送方往往要收集到足够多的数据后才发送一次数据给对方。若连续几次需要send的数据都很少，通常TCP socket 会根据优化算法把这些数据合成一个TCP段后一次发送出去，这样接收方就收到了粘包数据

发送方引起的粘包是由TCP协议本身造成的，TCP为提高传输效率，发送方往往要收集到足够多的数据后才发送一个TCP段。若连续几次需要send的数据都很少，通常TCP会根据优化算法把这些数据合成一个TCP段后一次发送出去，这样接收方就收到了粘包数据。

• TCP和UDP:

1、TCP（transport control protocol，传输控制协议）是面向连接的，面向流的，提供高可靠性服务。收发两端（客户端和服务器端）都要有一一成对的socket，因此，发送端为了将多个发往接收端的包，更有效的发到对方，使用了优化方法（Nagle算法），将多次间隔较小且数据量小的数据，合并成一个大的数据块，然后进行封包。这样，接收端，就难于分辨出来了，必须提供科学的拆包机制。 即面向流的通信是无消息保护边界的。
2、UDP（user datagram protocol，用户数据报协议）是无连接的，面向消息的，提供高效率服务。不会使用块的合并优化算法，, 由于UDP支持的是一对多的模式，所以接收端的skbuff(套接字缓冲区）采用了链式结构来记录每一个到达的UDP包，在每个UDP包中就有了消息头（消息来源地址，端口等信息），这样，对于接收端来说，就容易进行区分处理了。 即面向消息的通信是有消息保护边界的。
3、tcp是基于数据流的，于是收发的消息不能为空，这就需要在客户端和服务端都添加空消息的处理机制，防止程序卡住，而udp是基于数据报的，即便是你输入的是空内容（直接回车），那也不是空消息，udp协议会帮你封装上消息头

• 为何TCP是可靠的，而UDP不可靠?
  1、tcp在数据传输时，发送端先把数据发送到自己的缓存中，然后协议控制将缓存中的数据发往对端，对端返回一个ack=1，发送端则清理缓存中的数据，对端返回ack=0，则重新发送数据，所以tcp是可靠的
  2、UDP发送数据，对端是不会返回确认信息的，因此不可靠

• send（字节流）和recv(1024）及sendall是什么意思？

  • recv里指定的1024意思是从缓存里一次拿出1024个字节的数据
  • send的字节流是先放入己端缓存，然后由协议控制将缓存内容发往对端，如果字节流大小大于缓存剩余空间，那么数据丢失
  • sendall会循环调用send，数据不会丢失

粘包导致的问题

粘包问题主要还是因为接收方不知道消息之间的界限，不知道一次性提取多少字节的数据。

粘包出现的场景

• 1 发送端需要等到本机的缓冲区满了以后才发出去，造成粘包
  （发送数据时间间隔很短，数据很小，python使用了优化算法，合在一起，产生粘包）

s.send('hello'.encode('utf-8'))
s.send('feng'.encode('utf-8'))

• 2 接收端不及时接受缓冲区的包，造成多个包接受
  （客户端发送一段数据，服务端只收了一小部分，服务端下次再收的时候还是从缓冲区拿上次遗留的数据，就产生粘包）

data1=conn.recv(2) #一次没有收完整
data2=conn.recv(10)#下次收的时候,会先取旧的数据,然后取新的

占包问题的解决方案

方案一、 使用sleep()睡眠

在两个连续send()之间增加sleep()，这样包会分开发送
在两个连续recv()之间增加sleep(),多个包分开接收
该解决方案会出现很多纰漏，因为你不知道什么时候传输完，时间暂停的长短都会有问题(长的话效率低，短的话不合适)，所以这种方法是不合适的

方案二、 在数据包的头部加上内容的长度

为字节流加上自定义固定长度报头，报头中包含字节流长度，然后依次send到对端，对端在接受时，先从缓存中取出定长的报头，然后再取真实数据

使用struct模块对打包的长度为固定4个字节或者八个字节, struct.pack.format参数是“i”时，只能打包长度为10的数字.
为了解决长度限制的问题，可以使用JSON将长度转为JSON字符串并转为bytes用于网络传输

json.dumps(12345678900).encode('utf8')

把自己将要发送的字节流总大小让接收端知晓，伪码:

...
total_size = struct.pack('i', len(data)
coon.send(total_size) # 先发送data的总长度
coon.send(data)  # 再发送结果
...

接收端在接受时，先从缓存中取出定长的报头，然后一个死循环中取得所有数据:

...
total_size = struct.unpack('i', socket.recv(4))
while recv_size<total_size: #循环接收
    recv_data = sock.recv(1024) 
    recv_size+=len(recv_data) 
    total_data+=recv_data 
...

本方案的问题在于缺乏的灵活度，仅能够通过报头获取数据的长度，而没有关于数据的其它信息

方案三

服务端将报头信息(数据长度、名称、md5等)优化，存储为字典并转化后发送给客户端；客户端接收到固定长度的报头信息解码为字典，接收数据。

服务端将报头信息优化:
1、 将要发送的数据用字典进行描述，包括数据的大小、文件名、md5校验值等需要的数据相关信息
2、 将字典编码为JSON字符串格式
3、 将JSON字符串编码为字节码，用于网络传输
4、 使用struck将字节码的长度转为固定长度

服务端伪码:

# body_data是需要发送的数据体
header = {'total_size': len(body_data),
          'filename': None,
          'md5': None}
header_json = json.dumps(header).encode('utf8')

# 发送报头长度和报头
self.request.send(struct.pack('i', len(header_json)))
self.request.send(header_json)

# 发送数据
self.request.sendall(f'{data}'.encode('utf8')) # 发送全部数据

客户端接收报头信息:
1、接收报头的固定长度(比如为4)信息，得到报头的长度
2、按报头长度接收报头，并解码为JSON字符串
3、反序列化，将JSON字符串解码为dict
4、使用报头dict信息获取需要接收的数据体的大小，死循环接收。

客户端伪码:

# 1. 接收固定长度的报头
header_length = struct.unpack('i', tcpCliSock.recv(4))[0]
print(f'header_length={header_length}')

# 2. 接收报头,并解码、JSON反序列化得到dict
header_json = tcpCliSock.recv(header_length).decode('utf8')
header = json.loads(header_json)

length = header['total_size']
while recv_num < length:
    mes = tcpCliSock.recv(1024).decode('utf8')
    recv_num += len(mes)
    data += mes