精华内容
下载资源
问答
  • 粘包

    2020-07-10 00:00:41
    粘包一、什么是粘包二、为什么会粘包三、粘包解决思路 一、什么是粘包 粘包是指发送方发送的若干数据到接收方,而接收方在接收数据时这些数据粘在一起,后一包数据头紧接着前一包数据尾部。 二、为什么会粘包 首先...

    一、什么是粘包

    粘包是指发送方发送的若干数据到接收方,而接收方在接收数据时这些数据粘在一起,后一包数据头紧接着前一包数据尾部。

    二、为什么会粘包

    首先了解一下socket收发消息原理:
    底层原理参考另一篇:socket收发消息底层原理
    socket收发消息原理
    在发数据时,一条数据的大小对应用程序是不可见的,即接收端从自己缓存区接收数据时,根本不知道自己要从缓存区接受多少数据。

    那为什么只用TCP有粘包现象,而UDP没有?

    1. TCP 是面向连接的,面向流的,提供高可靠性服务。收发两端(客户端和服务器端)都要有一一成对的socket,因此,发送端为了将多个发往接收端的包,更有效的发到对方,使用了优化方法(Nagle算法),将多次间隔较小且数据量小的数据,合并成一个大的数据块,然后进行封包。这样,接收端,就难于分辨出来了,必须提供科学的拆包机制。 即面向流的通信是无消息保护边界的。
    2. UDP 是没有连接的,面向消息的,提供高效率服务。不会使用块的合并优化算法, 由于UDP支持的是一对多的模式,所以接收端的skbuff(套接字缓冲区)采用了链式结构来记录每一个到达的UDP包,在每个UDP包中就有了消息头(消息来源地址,端口等信息),这样,对于接收端来说,就容易进行区分处理了。 即面向消息的通信是有消息保护边界的。

    TCP 协议的数据不会丢失,没有接收完的包,下次会继续接收,传输可靠,但是会造成粘包。

    两种粘包情况:

    1. 发送端发送间隔小,数据量小,为了有效发送数据,使用Nagle算法,合成一个大的数据包。
    2. 发送端数据量大,但接受端接收数据量小。

    三、粘包解决思路

    1. 在数据发送前,计算数据量大小,并将结果发送给接收端
    #服务端
    from socket import *
    import subprocess
    ip_port=('127.0.0.1',8080)
    back_log=5
    buffer_size=1024
    
    tcp_server=socket(AF_INET,SOCK_STREAM)
    tcp_server.bind(ip_port)
    tcp_server.listen(back_log)
    
    while True:
        conn,addr=tcp_server.accept()
        print('新的客户端链接',addr)
        while True:
            #收
            try:
                cmd=conn.recv(buffer_size)
                if not cmd:break
                print('收到客户端的命令',cmd)
    
                #执行命令,得到命令的运行结果cmd_res
                res=subprocess.Popen(cmd.decode('utf-8'),shell=True,
                                     stderr=subprocess.PIPE,
                                     stdout=subprocess.PIPE,
                                     stdin=subprocess.PIPE)
                err=res.stderr.read()
                if err:
                    cmd_res=err
                else:
                    cmd_res=res.stdout.read()
    
                #发
                if not cmd_res:
                    cmd_res='执行成功'.encode('gbk')
    
                length=len(cmd_res)
                conn.send(str(length).encode('utf-8'))
                client_ready=conn.recv(buffer_size)
                if client_ready == b'ready':
                    conn.send(cmd_res)
            except Exception as e:
                print(e)
                break
    
    #客户端
    from socket import *
    ip_port=('127.0.0.1',8080)
    back_log=5
    buffer_size=1024
    
    tcp_client=socket(AF_INET,SOCK_STREAM)
    tcp_client.connect(ip_port)
    
    while True:
        cmd=input('>>: ').strip()
        if not cmd:continue
        if cmd == 'quit':break
    
        tcp_client.send(cmd.encode('utf-8'))
    
    
        #解决粘包
        length=tcp_client.recv(buffer_size)
        tcp_client.send(b'ready')
    
        length=int(length.decode('utf-8'))
    
        recv_size=0
        recv_msg=b''
        while recv_size < length:
            recv_msg += tcp_client.recv(buffer_size)
            recv_size=len(recv_msg) 
    
    
        print('命令的执行结果是 ',recv_msg.decode('gbk'))
    tcp_client.close()
    
    1. 直接使用固定的四个字节来表示数据长度
    展开全文
  • 文章目录tcp粘包第一种粘包第二种粘包udp粘包解决粘包现象 粘包现象是指发送方发送的若干数据到接收方接收时粘成一包,从接收缓冲区看,后一包数据的头紧接着前一包数据的尾。粘包现象只会在tcp中出现,udp中不会有...
  • 粘包现象与解决粘包问题 文章目录粘包现象与解决粘包问题一、引入一、粘包现象介绍1.socket收发消息的原理1.1缓冲区的作用:存储少量数据1.2收发的本质:不一定是一收一发2.为什么产生黏包3.什么是粘包?4.产生黏包...

    粘包现象与解决粘包问题

    一、引入

    粘包问题主要出现在用TCP协议传输中才会出现的问题,UDP不会出现,因为TCP传输中他会服务端会一次性把所有东西一并丢入缓存区,而读取的内容大小有时候没法准确的做到一一读取,所有会存在粘包。

    UDP他传输的时候是吧一个个内容丢过去,不管客户端能否完全接受到内容他都会接受他制定大小的内容,而内容大于他接受设定的大小时候多余的东西会被丢到

    注意:只有TCP才会出现粘包现象,UDP永远不会出现粘包现象

    一、粘包现象介绍

    1.socket收发消息的原理

    其实我们发送数据并不是直接发送给对方, 而是应用程序将数据发送到本机操作系统的缓存里边, 当数据量小, 发送的时间间隔短, 操作系统就会在缓存区先攒够一个TCP段再通过网卡一起发送, 接收数据也是一样的, 先在操作系统的缓存存着, 然后应用程序再从操作系统中取出数据

    image-20210118142809055

    1.1缓冲区的作用:存储少量数据

    • 如果你的网络出现短暂的异常或波动,接受数据就会出现短暂的中断,影响你的下载或者上传的效率,但是缓冲区解决了上传下载的传输效率的问题,带来了粘包问题

    1.2收发的本质:不一定是一收一发

    2.为什么产生黏包

    • 主要原因 : TCP称为流失协议, 数据流会杂糅在一起, 接收端不清楚每个消息的界限, 不知道每次应该去多少字节的数据
    • 次要原因 : TCP为了提高传输效率会有一个nagle优化算法, 当多次send的数据字节都非常少, nagle算法就会将这些数据合并成一个TCP段再发送, 这就无形中产生了黏包

    3.什么是粘包?

    1. 接收方没有及时接收缓冲区的包,造成多个包接收(客户端发送了一段数据,服务端只收了一小部分,服务端下次再收的时候还是从缓冲区拿上次遗留的数据,产生粘包)recv会产生黏包(如果recv接受的数据量(1024)小于发送的数据量,第一次只能接收规定的数据量1024,第二次接收剩余的数据量)
    2. 发送端需要等缓冲区满才发送出去,造成粘包(发送数据时间间隔很短,数据也很小,会合到一起,产生粘包)send 也可能发生粘包现象。(连续send少量的数据发到输出缓冲区,由于缓冲区的机制,也可能在缓冲区中不断积压,多次写入的数据被一次性发送到网络)

    4.产生黏包的两种情况 :

    • 发送端需要等待缓冲区满了才将数据发送出去, 如果发送数据的时间间隔很短, 数据很小, 就会合到一起, 产生黏包
    • 接收方没有及时接收缓冲区的包, 造成多个包一起接收, 如果服务端一次只接收了一小部分, 当服务端下次想接收新的数据的时候, 拿到的还是上次缓冲区里剩余的内容

    注意:粘包不一定发生,如果发生了:

    1. 可能是在客户端已经粘了。
    2. 客户端没有粘,可能是在服务端粘了。

    二、解决粘包问题的两种方式

    1、通过send数据长度的方式来控制接收(low版)

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

    • 服务端
    from socket import *
    import subprocess
    
    server = socket(AF_INET,SOCK_STREAM)
    server.bind(("127.0.0.1",8090))
    server.listen(5)
    
    while True:
        print("等待连接...")
        conn,addr = server.accept()
        print(f"来自{addr}的连接")
        while True:
            try:
                cmd = conn.recv(1024)
                if not cmd:
                    '''
                    当你的程序运用在linux系统中,客户端强制断开链接,服务端会收到空的数据,在这种情况下就会退出与当前客户端的通讯循环,并关闭与该客户端的连接, 并回收当前客户端在服务端当前所占的系统资源,
                    还有另一种情况就是客户端正常使用close()断开连接, 服务端也会收到空的数据,
                    '''
                    break
                obj = subprocess.Popen(
                    cmd.decode("utf-8"),
                    shell=True,
                    stdout=subprocess.PIPE,
                    stderr=subprocess.PIPE,
                )
                stdout = obj.stdout.read()
                stderr = obj.stderr.read()
                date = stdout + stderr
                date_len = str(len(date)).encode("utf-8")  # 得到数据长度
                conn.send(date_len)  # 将数据的长度先发送
                conn.send(date)      # 再发送真实数据
            except Exception:
                '''
                这里解决的问题是:
                当你的程序运行在windows系统中,客户端强制断开链接,服务端就会引发异常. 因此,就可以使用异常处理机制来监测这种异常,此时一旦监测出这种异常,就代表客户端强制断开了链接.
                在这种情况下就会退出与当前客户端的通讯循环,并关闭与该客户端的连接, 并回收当前客户端在服务端当前所占的系统资源,
                '''
                break
        conn.close()
        
    
    • 客户端
    from socket import *
    
    client = socket(AF_INET,SOCK_STREAM)
    client.connect(("127.0.0.1",8090))
    
    while True:
        cmd = input("请输入命令 >>").strip()
        if not cmd:
            # 这里解决的问题:
            """
            当客户端输入为空的时候,在客户端的操作系统缓存中,并没有数据能发送给服务端. 硬件不能识别你这个空的数据,只有我们这种逻辑层面才有这种空的数据的存在.
            因此服务端的recv操作会在服务端的操作缓存中拿取数据,但是与此同时,服务端的操作系统缓存中并没有数据,于是服务端一直在recv堵塞状态.
            接着客户端因为send发送了数据,处于recv等待服务端发送回来的数据的状态,因而两者会处于一种recv堵塞的状态,
            """
            continue
        client.send(cmd.encode("utf-8"))
        """
        粘包问题出现:
        
        问题1: 服务端发送回来的数据很多收不完,剩下的数据会保存在客户端的操作系统缓存中并不会丢失.
        问题2: 有可能服务端的数据过大,服务端并不是一次性的给你发送过来,可能分多次发送过来,
                所以这里接收的话可能接收的是部分.(这里是服务端的问题)
        """
        date_len = int(client.recv(1024).decode("utf-8"))  # 先接收数据长度
        recv_len = 0
        '''
        粘包问题出现的原因:
        1、TCP是流式协议,数据像流水一样黏在一起,没有任何边界区分
        2、收数据没有收干净有残留, 就会与下次结果混淆在一起.
        
        解决核心: 保证每次都收干净, 不要任何残留
            - 服务端发送给客户端所需要发送数据的总大小,客户端拿到这个总大小,然后进行循环接收, 
                直至收取完毕, 结束本次收取数据的循环.
        '''
        while True:
            date = client.recv(1024)
    
            recv_len += len(date)
            print(date.decode("gbk"),end="")
            '''
            问题解决:尽最大量的收取客户端传输过来的数据量.
                - 缺点: 操作系统缓存有一定的容量,如果服务端发送过的数据量过大,本地操作系统缓存并不能一次性容纳,服务端的数据将会继续发送,
                    因此,这种时候也不是一个好的解决方案,收取的数据也不一定收取全.
            '''
            if recv_len == date_len: break  # 当数据长度与接收到的数据长度相等则结束
    

    为何low?

    效率低 : 程序运行的速度远快于网络传输的速度, 如果在发送真实数据之前先send该数据的字节流长度, 那么就会放大网络延迟带来的性能损耗

    2、使用struct模块实现精准数据字节接收(比较高效解决tcp协议的黏包方法)

    解决粘包问题的核心就是:为字节流加上一个自定义固定长度的报头, 报头中就包含了该字节流长度, 然后只需要将整个数据加报头 send 一次到对端, 对端先取出固定长度的报头, 然后在取真实的数据

    【温馨提示】:struct模块在前面已经介绍过了,👻struct模块传送门

    • 服务端
    from socket import *
    import subprocess
    import struct
    import json
    
    server = socket(AF_INET, SOCK_STREAM)
    server.bind(("127.0.0.1", 8080))
    server.listen(5)
    while True:
        print("Wait...")
        conn, client_addr = server.accept()
        print("已经连接:", client_addr)
        while True:
            try:
                cmd = conn.recv(1024)
                if not cmd: break
                obj = subprocess.Popen(
                    cmd.decode('utf-8'),
                    shell=True,
                    stderr=subprocess.PIPE,
                    stdout=subprocess.PIPE)
                stdout = obj.stdout.read()
                stderr = obj.stderr.read()
    
                '''
                 1. 定制头部字典. 头部字典里面放,数据内容的大小,数据的描述信息,数据的md5值,等等数据,
                 2. 接着将定制的头部json格式化成字符串,将字符串encode解码成bytes类型为了可以进行send操作
                 3. 再使用struct将获取到的bytes数据的长度打包成固定长度, 这个第一个发送, 让客户端可以获取固定长度的bytes数据. 客户端获取到这个bytes类型的数据, 先decode解码, 再进行json反序列化拿到头部字典
                 4. 客户端就可以通过获取到的头部字典拿到需要准备接收的数据的长度, 循环recv接收数据. 最终, 完美解决了黏包问题.
                 '''
                # 制作一个报头字典(模板)
                header_dic = {
                    "header_name": "jack",
                    "total_size": len(stderr) + len(stdout),
                    "md5": "f3062575e23dbeb73c315ea525999295",
                }
                # 将报头(字典)序列化成字符串类型
                header_json = json.dumps(header_dic)
                # 将报头(字符串)转化成byte类型
                header_byte = header_json.encode("utf-8")
                # 将报头信息打包成4字节大小,里面包含的报头的长度
                header_size = struct.pack("i", len(header_byte))
    
                # 先发送打包的4bytes,4bytes包含了报头长度
                conn.send(header_size)
                # 在发送报头(客户端已经拿到了(解包出)报头的长度)
                conn.send(header_byte)
                # 发送真实数据
                data = stdout + stderr
                conn.send(data)
                # 可以合并到一起只send一次,但字符拼接又降低了效率(不推荐)
                # msg = header_size + header_byte + stdou t+ stderr
                # conn.send(msg)
            except Exception:
                break
        conn.close()
    
    

    问题: 前面说到多次send会扩大网络延迟带来的效率问题, 那为什么还要分四次 send ?

    • 其实在前面socket收发消息的原理图哪里就给出了答案,数据是先发送到字节操作系统的缓存内,时间间隔短,数据量小的会被和在一起发送,这就是TCP协议nagle优化算法做的事(有提升效率的功能,当然也带来了黏包问题)
    • 客户端
    from socket import *
    import json
    import struct
    
    client = socket(AF_INET, SOCK_STREAM)
    client.connect(('127.0.0.1', 8080))
    while True:
        cmd = input("请输入你要执行的命令>>>:").strip()
        if not cmd: continue
        """
         接收头部, 解析头部, 获取有用信息:
            1. 使用struct获取自定义固定长度, 
            2. 再拿到bytes格式json格式的dic内容, 
            3. 接着通过decode解码, 
            4. 然后再使用json反序列化获取dic, 
            5. 再由dic拿到数据量的大小,接着再通过循环收取数据,
        """
        client.send(cmd.encode("utf-8"))
    
        # 接受byte_4
        byte_4 = client.recv(4)
        # 解包出报头长度
        header_len = struct.unpack("i", byte_4)[0]
        # 使用长度接受byte
        header_byte = client.recv(header_len)
        # byte---->str
        header_str = header_byte.decode("utf-8")
        # str---->dic
        header_dic = json.loads(header_str)
        # 拿到真正数据的大小
        tatal_size = header_dic["total_size"]
    
        recv_size = 0
        while True:
            data = client.recv(1024)
            recv_size += len(data)
            print(data.decode("gbk"), end="")
            if recv_size == tatal_size: break
    
    

    3、UDP没有粘包问题

    udp 被称为数据报协议, 每次发送的数据都是一个数据报, 一次 sendto 对应一次 recvfrom, 不会产生黏包

    udp 又被称为不可靠协议, 不可靠在哪里? 比如发送方发送了 10bytes 的数据, 而接收方只接收 8bytes 的数据, 那么剩下的两个 bytes 将会被丢弃, 并且在不同的平台有不同的表现, 下面我们来进行试验 :

    • windows平台下实验客户端
    from socket import *
    
    client = socket(AF_INET,SOCK_DGRAM)
    
    msg = "1234567890".encode("utf-8")  # "utf-8"编码格式的数字和字母都是1bytes
    msg2 = "12345".encode("utf-8")      # 发送 5bytes
    msg3 = "123".encode("utf-8")        # 发送 3bytes
    
    client.sendto(msg,("127.0.0.1",8989))
    client.sendto(msg2,("127.0.0.1",8989))
    client.sendto(msg3,("127.0.0.1",8989))
    
    • 服务端
    from socket import *
    
    server = socket(AF_INET,SOCK_DGRAM)
    server.bind(("127.0.0.1",8989))
    
    date,addr = server.recvfrom(8)    # 发送方发送 10bytes 只接收 8bytes
    date2,addr2 = server.recvfrom(3)  # 发送方发送 5bytes 只接收 3bytes
    date3,addr3 = server.recvfrom(1)  # 发送方发送 3bytes 只接收 1bytes
    
    print(date.decode("utf-8"))
    print(date2.decode("utf-8"))
    print(date3.decode("utf-8"))
    
    • 运行结果如下:

    image-20210121193118955

    • linux平台运行下实验客户端
    from socket import *
    
    client = socket(AF_INET,SOCK_DGRAM)
    
    msg = "1234567891".encode("utf-8")
    msg2 = "12345".encode("utf-8")
    msg3 = "123".encode("utf-8")
    
    client.sendto(msg,("192.168.12.53",8848))
    client.sendto(msg2,("192.168.12.53",8848))
    client.sendto(msg3,("192.168.12.53",8848))
    
    • 服务端
    from socket import *
    server=socket(AF_INET,SOCK_DGRAM)
    server.bind(("192.168.12.53",8848))
    date,addr=server.recvfrom(8)
    date2,addr2=server.recvfrom(3)
    date3,addr3=server.recvfrom(1)
    print(date.decode("utf-8"))  # 注意:如果发送方发送的是汉字, 一个汉字三个字节, >如果接受不完整解码出来会报错
    print(date2.decode("utf-8"))
    print(date3.decode("utf-8"))
    
    
    • 运行结果如下:

    image-20210121202839709

    展开全文
  • 通过之前的学习,我们知道基于传输层开发通讯程序,会出现粘包粘包,所以今天通过Wireshark抓包工具来看看具体的传输内容。 TCP可靠传输的建立 定义 一开始主机A和主机B 处于close(关闭)状态,然后B的TCP服务器...

    前言

    通过之前的学习,我们知道基于传输层开发通讯程序,会出现粘包和粘包,所以今天通过Wireshark抓包工具来看看具体的传输内容。

    TCP可靠传输的建立

    定义

    一开始主机A和主机B 处于close(关闭)状态,然后B的TCP服务器进程先创建传输控制块(TCP),处于LISTEN状态来监听客户机A的连接。
    在这里插入图片描述
    三次握手的大概流程

    • A的TCP客户进程也是首先创建传输控制块TCB,然后打算建立TCP连接时,向B发送请求报文段,这时候首部的同步位SYN=1,同时选择一个初始序号seq=x,TCP规定,SYN报文段(SYN=1的报文段)不能携带数据,但是必须消耗掉一个序号,这时候,客户端进入了SYN-SEND(同步已发送)状态
    • B收到连接请求的时候,如果同意建议连接,则会向A发送确认。在确认报文中应把SYN和ACK置为1,确认号是ack=x+1(表示下次B期待收到A的seq为x+1),同时也会为自己选择一个最初的seq=y,也不能携带数据且消耗一个序列号。这时候服务器进入SYN-RCVD状态。
    • 客户端收到B的确认后,还要给服务器发送确认已收到确认。确认报文段的ACK置1,确认号ack=y+1,而自己的序号ack=x+1.TCP的标准规定,ACK报文段可以携带数据,单如果不携带数据则不消化序号,在这种情况,下一个数据报文段的序号仍是seq=x+1,这时,TCP已建立连接。A进入ESTABLISHED(已经建立连接)状态。

    利用工具查看

    在这里插入图片描述
    第5~7 是TCP的三次握手
    第8行客户端发送数据
    在这里插入图片描述

    第9行服务器端回复数据
    在这里插入图片描述
    第10和第11,客户端连续发送2次数据
    在这里插入图片描述
    10和11两次连续发到TCP缓冲区中,但是从socket从缓冲区中读到的数据并不一点是上面那种情况

    服务器发送和服务器接收

    客户端发送内容

            String xml = "hi,blueheart,hello world";
            while (true){
                out.write(xml.getBytes());
                out.flush();
            }
    

    服务器端收到的打印内容
    在这里插入图片描述
    客户端从套接字写入到TCP缓冲区中,然后TCP 中通过的某些机制,发送到服务器中TCP的缓冲区中,最好通过套接字读到服务器程序里,输出为上面的内容。通过上面,我们可以知道客户端发送的数据和服务器接收的数据不是一样的,这就是我们下面要讨论的粘包和粘包的现象。

    粘包和粘包

    handler组件会根据分隔符或者长度从缓冲区里面读出数据

    三级目录

    展开全文
  • 粘包问题

    2019-10-06 14:22:17
    目录 粘包问题 一、什么是粘包 二、TCP发送数据的四种情况 ...注意:只有TCP有粘包现象,UDP永远不会粘包,为何,且听我娓娓道来。 首先需要掌握一个socket收发消息的原理 发送端可以是...

    粘包问题

    一、什么是粘包

    注意:只有TCP有粘包现象,UDP永远不会粘包,为何,且听我娓娓道来。

    首先需要掌握一个socket收发消息的原理

    1739658-20190909184300180-142464030.jpg

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

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

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

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

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

    udp的recvfrom是阻塞的,一个recvfrom(x)必须对唯一一个sendinto(y),收完了x个字节的数据就算完成,若是y>x数据就丢失,这意味着udp根本不会粘包,但是会丢数据,不可靠

    TCP的协议数据不会丢,没有收完包,下次接收,会继续上次继续接收,己端总是在收到ack时才会清除缓冲区内容。数据是可靠的,但是会粘包。

    二、TCP发送数据的四种情况

    假设客户端分别发送了两个数据包D1和D2给服务端,由于服务端一次读取到的字节数是不确定的,故可能存在以下4种情况。

    1. 服务端分两次读取到了两个独立的数据包,分别是D1和D2,没有粘包和拆包;
    2. 服务端一次接收到了两个数据包,D1和D2粘合在一起,被称为TCP粘包;
    3. 服务端分两次读取到了两个数据包,第一次读取到了完整的D1包和D2包的部分内容,第二次读取到了D2包的剩余内容,这被称为TCP拆包;
    4. 服务端分两次读取到了两个数据包,第一次读取到了D1包的部分内容D1_1,第二次读取到了D1包的剩余内容D1_2和D2包的整包。

    特例:如果此时服务端TCP接收滑窗非常小,而数据包D1和D2比较大,很有可能会发生第五种可能,即服务端分多次才能将D1和D2包接收完全,期间发生多次拆包。

    三、粘包

    1. server

      import socket
      #生成一个socket对象
      soc=socket.socket(socket.AF_INET,socket.SOCK_STREAM)
      #绑定地址跟端口号
      soc.bind(('127.0.0.1',8001))
      #监听(半连接池的大小),不是连接数
      soc.listen(3)
      #等着客户端来连接,conn相当于连接通道,addr是客户端的地址
      while True:
          print('等待客户端连接')
          conn,addr=soc.accept()    #卡主,如果没有客户端连接,会一直卡在这,当有连接,才继续往下走
          print('有个客户端连接上了',addr)
          while True:
              try:
                  data=conn.recv(1024)
                  print(data)
                  data2=conn.recv(1024)
                  print(data2)
                  data3=conn.recv(1024)
                  print(data3)
              except Exception:
      
                  break
          # 关闭通道
          conn.close()
      
      
      # 关闭套接字
      soc.close()
    2. client

    import socket
    
    soc=socket.socket()
    
    soc.connect(('127.0.0.1',8001))
    while True:
        in_s=input('请输入要发送的数据:')
        soc.send(b'a')
        soc.send(b'b')
        soc.send(b'c')
    

    四、解决粘包

    1. 补充模块

      import struct
      #把一个数字打包成固定长度的4字节
      obj=struct.pack('i',1098)
      print(obj)
      print(len(obj))
      
      l=struct.unpack('i',obj)[0]
      print(l)
    2. server

      import socket
      import subprocess
      import struct
      soc=socket.socket(socket.AF_INET,socket.SOCK_STREAM)
      soc.bind(('127.0.0.1',8001))
      soc.listen(3)
      while True:
          print('等待客户端连接')
          conn,addr=soc.accept()
          print('有个客户端连接上了',addr)
          while True:
              try:
                  data=conn.recv(1024)
                  if len(data)==0:
                      break
                  print(data)
                  obj = subprocess.Popen(str(data,encoding='utf-8'),
                                         shell=True, stdout=subprocess.PIPE, stderr=subprocess.PIPE)
                  #执行正确的结果 b 格式,gbk编码(windows平台)
                  msg=obj.stdout.read()
                  #发送的时候需要先把长度计算出来
                  #头必须是固定长度
                  #10
                  #100
                  #先取出要发送数据长度l
      
                  l=len(msg)
                  #head 是固定四个字节
                  head=struct.pack('i',l)
                  #发了头
                  conn.send(head)
                  #发了内容
                  conn.send(msg)
              except Exception:
      
                  break
          # 关闭通道
          conn.close()
      
      
      # 关闭套接字
      soc.close()
    3. client

      import socket
      import struct
      soc=socket.socket()
      
      soc.connect(('127.0.0.1',8001))
      while True:
          in_s=input('请输入要执行的命令:')
          soc.send(in_s.encode('utf-8'))
          head=soc.recv(4)
          l=struct.unpack('i',head)[0]
          # data=soc.recv(l)
          count=0
          data_total=b''
      
          while count<l:
              if l<1024: #如果接受的数据小于1024 ,直接接受数据大小
                  data=soc.recv(l)
              else:#如果接受的数据大于1024
                  if l-count>=1024: #总数据长度-count(目前收到多少,count就是多少) 如果还大于1024  ,在收1024
                      data=soc.recv(1024)
                  else: #总数据长度-count(目前收到多少,count就是多少) 如果小于1024,只收剩下的部分就可
                      data=soc.recv(l-count)
      
              data_total+=data
              count+=len(data)
      
          print(str(data_total,encoding='gbk'))

      五、解决粘包问题的最终方案

      1. struct

        # import struct
        # #把一个数字打包成固定长度的4字节
        # obj=struct.pack('i',10980000000)
        # print(obj)
        # print(len(obj))
        #
        # l=struct.unpack('i',obj)[0]
        # print(l)
        import json
        import struct
        
        # head={'size':100999999999999999999999990000000000000000
        # 000000000000000000000000,'md5':'sdfsdfasdf','filename':'a.txt'}
        # head_str=json.dumps(head)
        # head_bytes=head_str.encode('utf-8')
        # print(len(head_bytes))
        # obj=struct.pack('i',len(head_bytes))
        # print(obj)
        # print(len(obj))
        
        #发
        send(obj)
        send(head_bytes)
        send(b'ddddddddddddddddddd')
        #收
        obj=recv(4)
        head_len=struct.unpack('i',obj)[0]
        head_bytes=recv(head_len)
        
        head_dic=json.loads(head_bytes)
        l=head_dic['size']
        
        
        
      2. server

        import socket
        import subprocess
        import struct
        soc=socket.socket(socket.AF_INET,socket.SOCK_STREAM)
        soc.bind(('127.0.0.1',8001))
        soc.listen(3)
        while True:
            print('等待客户端连接')
            conn,addr=soc.accept()
            print('有个客户端连接上了',addr)
            while True:
                try:
                    data=conn.recv(1024)
                    if len(data)==0:
                        break
                    print(data)
                    obj = subprocess.Popen(str(data,encoding='utf-8'), shell=True, stdout=subprocess.PIPE, stderr=subprocess.PIPE)
                    #执行正确的结果 b 格式,gbk编码(windows平台)
                    msg=obj.stdout.read()
        
                    #发送的时候需要先把长度计算出来
                    #头必须是固定长度
                    #先发4位,头的长度
                    import json
                    dic={'size':len(msg)}
                    dic_bytes=(json.dumps(dic)).encode('utf-8')
                    #head_count是4个字节的长度
                    head_count=struct.pack('i',len(dic_bytes))
                    print(dic)
                    conn.send(head_count)
                    #发送头部内容
                    conn.send(dic_bytes)
                    #发了内容
                    conn.send(msg)
                except Exception:
        
                    break
            # 关闭通道
            conn.close()
        
        
        # 关闭套接字
        soc.close()
      3. client

        import socket
        import struct
        import json
        soc=socket.socket()
        
        soc.connect(('127.0.0.1',8001))
        while True:
            in_s=input('请输入要执行的命令:')
            soc.send(in_s.encode('utf-8'))
            #头部字典的长度
            head_dic_len=soc.recv(4)
            #解出真正的长度
            head_l=struct.unpack('i',head_dic_len)[0]
            #byte 字典的长度
            #收真正的头部字典
            dic_byte=soc.recv(head_l)
            head=json.loads(dic_byte)
            print(head)
            l=head['size']
            count=0
            data_total=b''
            print(l)
            while count<l:
                if l<1024: #如果接受的数据小于1024 ,直接接受数据大小
                    data=soc.recv(l)
                else:#如果接受的数据大于1024
                    if l-count>=1024: #总数据长度-count(目前收到多少,count就是多少) 如果还大于1024  ,在收1024
                        data=soc.recv(1024)
                    else: #总数据长度-count(目前收到多少,count就是多少) 如果小于1024,只收剩下的部分就可
                        data=soc.recv(l-count)
        
                data_total+=data
                count+=len(data)
        
            print(str(data_total,encoding='gbk'))

    转载于:https://www.cnblogs.com/SkyOceanchen/p/11502980.html

    展开全文
  • netty粘包

    2019-09-18 16:45:54
    文章目录netty粘包粘包是什么解决方案FixedLengthFrameDecoderLineBasedFrameDecoderDelimiterBasedFrameDecoderLengthFieldBasedFrameDecoder netty粘包 粘包是什么 ctx.writeAndFlush("hello world"); ctx....
  • TCP粘包

    2020-02-02 15:46:11
    什么是TCP粘包?UDP会粘包么?2. 粘包、拆包表现形式 原文链接:https://blog.csdn.net/Scythe666/article/details/51996268 1. 什么是TCP粘包?UDP会粘包么?   如果客户端连续不断的向服务端发送数据包时,...
  • tcp粘包

    2020-08-26 18:00:30
    tcp粘包 tcp是是流式的传输协议, 基于这特点就会导致数据传输的时候造成粘包的现象。 什么是粘包 tcp传输时,因为网络环境的原因不会每一次发送的数据都是既定的大小,若每一个数据块是1k,那么发送过去就可能是很多...
  • Netty 粘包

    2017-04-13 17:47:12
    TCP粘包 tcp是一个“流”的协议,一个完整的包可能会被TCP拆分成多个包进行发送,也可能把小的封装成一个大的数据包发送,这就是所谓的TCP粘包和拆包问题。 粘包、拆包问题说明假设客户端分别发送数据包D1和D2给...
  • 粘包现象

    2019-10-08 02:21:35
    什么是粘包 须知:只有TCP有粘包现象,UDP永远不会粘包 粘包不一定会发生 如果发生了:1。可能是在客户端已经粘了  2.客户端没有粘,可能是在服务端粘了 首先需要掌握一个socket收发消息的原理 应用程序...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 7,154
精华内容 2,861
关键字:

粘包