python 解决粘包问题

客户端发送hello,如果服务端 recv(1) ,那只能接收到 h 这一个字符，然后再recv(1) 一下，可以再接收一个 e ，

因为客户端发送的结果长，所以只能把其他的先缓存下来，下次recv的时候再去接收。

这就是粘包，即两次结果粘到一起了。

粘包发生的原因是 socket 缓冲区导致的，如图：

​

你的程序实际上无权直接操作网卡的，你操作网卡都是通过操作系统给用户程序暴露出来的接口，那每次你的程序要给远程发数据时，其实是先把数据从用户态copy到内核态，这样的操作是耗资源和时间的，频繁的在内核态和用户态之前交换数据势必会导致发送效率降低， 因此socket 为提高传输效率，发送方往往要收集到足够多的数据后才发送一次数据给对方。若连续几次需要send的数据都很少，通常TCP socket 会根据优化算法把这些数据合成一个TCP段后一次发送出去，这样接收方就收到了粘包数据。

粘包问题只存在于TCP中，Not UDP

还是看上图，发送端可以是一K一K地发送数据，而接收端的应用程序可以两K两K地提走数据，当然也有可能一次提走3K或6K数据，或者一次只提走几个字节的数据，也就是说，应用程序所看到的数据是一个整体，或说是一个流（stream），一条消息有多少字节对应用程序是不可见的，因此TCP协议是面向流的协议，这也是容易出现粘包问题的原因。而UDP是面向消息的协议，每个UDP段都是一条消息，应用程序必须以消息为单位提取数据，不能一次提取任意字节的数据，这一点和TCP是很不同的。怎样定义消息呢？可以认为对方一次性write/send的数据为一个消息，需要明白的是当对方send一条信息的时候，无论底层怎样分段分片，TCP协议层会把构成整条消息的数据段排序完成后才呈现在内核缓冲区。

例如基于tcp的套接字客户端往服务端上传文件，发送时文件内容是按照一段一段的字节流发送的，在接收方看了，根本不知道该文件的字节流从何处开始，在何处结束

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

​

​

总结

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

两种情况下会发生粘包。

• 发送端需要等缓冲区满才发送出去，造成粘包（发送数据时间间隔很短，数据了很小，会合到一起，产生粘包）
• 接收方不及时接收缓冲区的包，造成多个包接收（客户端发送了一段数据，服务端只收了一小部分，服务端下次再收的时候还是从缓冲区拿上次遗留的数据，产生粘包）

# 客户端
import socket
ip_port = ('127.0.0.1',9980)
tcp_socket_client = socket.socket(socket.AF_INET, socket.SOCK_STREAM)

tcp_socket_client.connect(ip_port)

tcp_socket_client.send('hello'.encode('utf-8'))
tcp_socket_client.send('gudo'.encode('utf-8'))



----------------------------------------------------------------------------

服务端：
import socket
ip_port=('127.0.0.1', 9980)
tcp_socket_server = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
tcp_socket_server.setsockopt(socket.SOL_SOCKET, socket.SO_REUSEADDR, 1)
tcp_socket_server.bind(ip_port)
tcp_socket_server.listen(5)

conn, addr = tcp_socket_server.accept()

data1 = conn.recv(10)
data2 = conn.recv(10)

print('data1:', data1.decode('utf-8'))
print('data2:', data2.decode('utf-8'))

conn.close()

# server 端接收结果：

# data1: hellogudo
# data2: 

​

---

UDP 不存在粘包问题：

client:

#!/usr/bin/env python
# -*-coding:utf-8 -*-
from socket import *

import time

ip_port = ('127.0.0.1', 9019)
bufsize = 1024

udp_client = socket(AF_INET, SOCK_DGRAM)

while True:
    msg = input('>>: ').strip()
    if len(msg) == 0:
        continue

    udp_client.sendto(msg.encode('utf-8'), ip_port)
    data, addr = udp_client.recvfrom(bufsize)
    print(data.decode('gbk'), end='')

server：

#!/usr/bin/env python
# -*-coding:utf-8 -*-
import socket
import subprocess

ip_port = ('127.0.0.1', 9019)
bufsize = 1024

udp_server = socket.socket(socket.AF_INET, socket.SOCK_DGRAM)
udp_server.setsockopt(socket.SOL_SOCKET,socket.SO_REUSEADDR,1) #就是它，在bind前加
udp_server.bind(ip_port)

while True:
    # 收消息
    cmd, addr = udp_server.recvfrom(bufsize)
    print('用户命令----->', cmd,addr)

    # 逻辑处理
    res = subprocess.Popen(cmd.decode('utf-8'), shell=True, stderr=subprocess.PIPE, stdin=subprocess.PIPE,
                           stdout=subprocess.PIPE)
    stderr = res.stderr.read()
    stdout = res.stdout.read()

    # 发消息
    udp_server.sendto(stdout + stderr, addr)

udp_server.close()

结果：

>>: ip
'ip' 不是内部或外部命令，也不是可运行的程序
或批处理文件。
>>: ipconfig
Traceback (most recent call last):
  File "D:/Python/python_learning/luffy/code/part3/02网络编程/udp不存在粘包问题/c.py", line 18, in <module>
    data, addr = udp_client.recvfrom(bufsize)
OSError: [WinError 10040] 一个在数据报套接字上发送的消息大于内部消息缓冲区或其他一些网络限制，或该用户用于接收数据报的缓冲区比数据报小。

解决粘包问题：

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

客户端：

import socket, json, struct

ip_port = ('127.0.0.1',9991)
client = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
client.connect(ip_port)

while True:
    cmd=input('>>: ').strip()
    if not cmd : continue
    client.send(bytes(cmd,encoding='utf-8'))

    head = client.recv(4)  # 先收4个bytes，这里4个bytes里包含了报头的长度
    head_json_len = struct.unpack('i', head)[0]  # 解出报头的长度

    head_json = json.loads(client.recv(head_json_len).decode('utf-8'))  # 拿到报头
    data_len = head_json['data_size']  # 取出报头内包含的信息

    # 开始接收数据
    recv_size = 0
    recv_data = b''
    while recv_size < data_len:
        recv_data += client.recv(1024)
        recv_size += len(recv_data)

    print(recv_data.decode('gbk'))  # 命令结果的编码是以当前所在的系统为准的，如果是windows，那么res.stdout.read()读出的就是GBK编码的,mac 默认 utf-8 编码

​

服务端：

import socket,struct,json
import subprocess
gd_server=socket.socket(socket.AF_INET,socket.SOCK_STREAM)
gd_server.setsockopt(socket.SOL_SOCKET,socket.SO_REUSEADDR,1) #就是它，在bind前加

gd_server.bind(('127.0.0.1',9991))
gd_server.listen(5)

while True:
    conn, addr = gd_server.accept()
    while True:
        cmd = conn.recv(1024)
        if not cmd: break
        print('cmd: %s' % cmd)
        #  命令操作
        res=subprocess.Popen(cmd.decode('utf-8'),
                             shell=True,
                             stdout=subprocess.PIPE,
                             stderr=subprocess.PIPE)
        err=res.stderr.read()
        print(err)
        if err:
            back_msg=err
        else:
            back_msg=res.stdout.read()

        headers = {'data_size': len(back_msg)}
        head_json = json.dumps(headers)  # 字典转换成字符串
        head_json_bytes = bytes(head_json, encoding='utf-8')

        conn.send(struct.pack('i', len(head_json_bytes)))  # 先发报头长度
        conn.send(head_json_bytes)  # 再发报头
        conn.sendall(back_msg)  # 再发正式内容
    conn.close()

​

---

​

拆包的发生情况

当发送端缓冲区的长度大于网卡的MTU时，tcp会将这次发送的数据拆成几个数据包发送出去。

补充问题一：为何tcp是可靠传输，udp是不可靠传输

tcp在数据传输时，发送端先把数据发送到自己的缓存中，然后协议控制将缓存中的数据发往对端，对端返回一个ack=1，发送端则清理缓存中的数据，对端返回ack=0，则重新发送数据，所以tcp是可靠的

而udp发送数据，对端是不会返回确认信息的，因此不可靠

补充问题二：send(字节流)和recv(1024)及sendall

recv里指定的1024意思是从缓存里一次拿出1024个字节的数据

send的字节流是先放入己端缓存，然后由协议控制将缓存内容发往对端，如果待发送的字节流大小大于缓存剩余空间，那么数据丢失，用sendall就会循环调用send，数据不会丢失

​

​