socket之粘包

什么是粘包

粘包是一种现象  这种现象只出现在TCP中而不会出现在UDP中(TCP和UDP都是传输层中的协议)

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

粘包概念详解：

当发送网络数据时，tcp协议会根据Nagle算法将时间间隔短，数据量小的多个数据包打包成一个数据包，先发送到自己操作系统的缓存中，然后操作系统将数据包发送到目标程序所对应操作系统的缓存中，最后将目标程序从缓存中取出，而第一个数据包的长度，应用程序并不知道，所以会直接取出数据或者取出部分数据，留部分数据在缓存中，取出的数据可能第一个数据包和第二个数据包粘到一起。

想要了解粘包首先需要掌握一个socket收发消息的原理

发送端可以是1k，1k的发送数据而接受端的应用程序可以2k，2k的提取数据，当然也有可能是3k或者多k提取数据，也就是说，应用程序是不可见的，因此TCP协议是面来那个流的协议，这也是容易出现粘包的原因而UDP是面向笑死的协议，每个UDP段都是一条消息，应用程序必须以消息为单位提取数据，不能一次提取任一字节的数据，这一点和TCP是很同的。怎样定义消息呢？认为对方一次性write/send的数据为一个消息，需要命的是当对方send一条信息的时候，无论鼎城怎么样分段分片，TCP协议层会把构成整条消息的数据段排序完成后才呈现在内核缓冲区。

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

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

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

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

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

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

发生粘包的两种情况

1.发送端需要等本机的缓冲区满了以后才发送出去，造成粘包（发送数据时间间隔很端，数据很小，会合在一个起，产生粘包）

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

粘包实例：

服务端
import socket
import subprocess
din=socket.socket(socket.AF_INET,socket.SOCK_STREAM)
ip_port=(‘127.0.0.1‘,8080)
din.bind(ip_port)
din.listen(5)
conn,deer=din.accept()
data1=conn.recv(1024)
data2=conn.recv(1024)
print(data1)
print(data2)   

客户端
import socket
import subprocess
din=socket.socket(socket.AF_INET,socket.SOCK_STREAM)
ip_port=(‘127.0.0.1‘,8080)
din.connect(ip_port)
din.send(‘helloworld‘.encode(‘utf-8‘))
din.send(‘sb‘.encode(‘utf-8‘))

粘包实例

粘包解决方案

由于应用程序自己发送的数据可以进行打包处理，自己制作协议，对数据进行封装添加报头，然后发送数据部分。而报头必须是固定长度，对方接受时可以先接受报头，对报头进行解析，然后根据报头内的封装的数据的长度对数据进行读取，这样收取的数据就是一个完整的数据包

方案一

loser解决方案

在客户端发送下边添加一个时间睡眠，就可以避免粘包现象。在服务端接收的时候也要进行时间睡眠，才能有效的避免粘包情况

#客户端
import socket
import time
import subprocess
din=socket.socket(socket.AF_INET,socket.SOCK_STREAM)
ip_port=(‘127.0.0.1‘,8080)
din.connect(ip_port)
din.send(‘helloworld‘.encode(‘utf-8‘))
time.sleep(3)
din.send(‘sb‘.encode(‘utf-8‘))

#服务端
import socket
import time
import subprocess
din=socket.socket(socket.AF_INET,socket.SOCK_STREAM)
ip_port=(‘127.0.0.1‘,8080)
din.bind(ip_port)
din.listen(5)
conn,deer=din.accept()
data1=conn.recv(1024)
time.sleep(4)
data2=conn.recv(1024)
print(data1)
print(data2)

loser解决方案

注意  ***     在该程序当中  只是为了使初学者更加清晰的了解粘包  才加入了时间睡眠代码  在正真的程序开发当中是不会出现这种情况的***

方案二

大牛的解决方案

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

struct模块

该模块可以把一个类型，如数字，转成固定长度的bytes

>>> res=struct.pack(‘i‘,1111111111111)  #打包成固定长度的bytes

>>> struct.unpack(“I”,res)             #解包

1 #服务端
 2 import socket      #导入模块
 3 import struct      #导入模块
 4 import subprocess  #导入模块
 5 din=socket.socket(socket.AF_INET,socket.SOCK_STREAM)   #基于网路家族以数据流的形式传输
 6 ip=(‘127.0.0.1‘,8080)   #标识服务端唯一的地址
 7 din.bind(ip)            #绑定地址
 8 din.listen(5)           #设置链接缓冲池最大数量
 9 while True:
10     conn,addr=din.accept()   #等待链接进入
11     print(‘------>‘,addr)
12     while True:
13         try:                 #开始捕捉异常,在windows中使用
14             cmd=conn.recv(1024)   #把接收的内容赋值给变量cmd
15             res=subprocess.Popen(cmd.decode(‘utf-8‘),shell=True,stdout=subprocess.PIPE,stderr=subprocess.PIPE)    #设置一个管道，以shell的方式写入，判断如果是正确的命令就放到标准输出的管道中，否则就放到错误输出的管道中
16             dui=res.stdout.read()    #读取标准输出管道中的内容赋值给dui
17             cuo=res.stderr.read()    #读取错误输出管道中的内容赋值给cuo
18             data_bat=len(dui)+len(cuo)  #把dui和cuo的内容长度相加赋值给data_bat
19             conn.send(struct.pack(‘i‘,data_bat))  #通过模块模仿报头形式发送给客户端
20             conn.send(dui)    #把dui的发送给客户端
21             conn.send(cuo)    #把cuo的发送给客户端
22         except Exception:     #结束捕捉异常
23             break             #跳出
24     conn.close()              #断开链接
25 din.close()                   #关闭基于网络家族传输的链接

1 #客户端
 2 import socket
 3 import struct
 4 din=socket.socket(socket.AF_INET,socket.SOCK_STREAM)
 5 ip_port=(‘127.0.0.1‘,8080)
 6 din.connect(ip_port)
 7 while True:
 8     cmd=input(‘请输入命令：‘).strip()
 9     if not cmd:continue
10     din.send(bytes(cmd,encoding=‘utf-8‘))
11     baotou=din.recv(4)
12     data_size=struct.unpack(‘i‘,baotou)[0]
13     rec_size=0
14     rec_data=b‘‘
15     while rec_size < data_size:
16         data=din.recv(1024)
17         rec_size+=len(data)
18         rec_data+=data
19
20     print(rec_data.decode(‘gbk‘))
21
22 din.close()

大牛方案--自定义报头的形式

方案三

1 #服务端
 2 import struct   #导入模块
 3 import socket   #导入模块
 4 import json     #导入模块
 5 import subprocess   #导入模块
 6 din=socket.socket(socket.AF_INET,socket.SOCK_STREAM)   #基于网络家族以流的方式创建一个链接路
 7 ip=(‘127.0.0.1‘,8080)  #设定服务端唯一的地址
 8 din.bind(ip)  #绑定地址
 9 din.listen(5)  #激活启动，设置链接池最大缓数量
10 while True:
11     conn,addr=din.accept()   #等待接受数据链接
12     print(‘------->>>‘)
13     while True:
14         try:   #开始捕捉异常,在windows中使用
15             dr=conn.recv(1024)   #接收内容并赋值给dr
16             res=subprocess.Popen(dr.decode(‘utf-8‘),shell=True,stdout=subprocess.PIPE,stderr=subprocess.PIPE)   #设置一个管道，把对的内容一个对的管道中，把错误的放进一个错误的管道中。
17             dui=res.stdout.read()  #读取标准输出的内容并赋值给dui
18             cuo=res.stderr.read()  #读取错误输出的内容并赋值给cuo
19             data_lik=len(dui)+len(cuo)  #计算标准输出和错误输出的总长度并赋值给data_lik
20             head_dic={‘data_lik‘:data_lik}  #自己顶一个字典 并赋值给head_dic
21             head_json=json.dumps(head_dic)  #把自己定义的字典进行一个序列化
22             head_bytes=head_json.encode(‘utf-8‘)  #把序列化后的内容进行转码 ，因为网络传输都是通过字节进行传输
23             head_len=len(head_bytes)  #把转换成字节码的长度拿到 并赋值给head_len
24             #发送报头长度
25             conn.send(struct.pack(‘i‘,head_len))  #发送自己定义的报头长度
26             # 发送报头
27             conn.send(head_bytes)       #发送自己定义的报头
28             #发送真是数据
29             conn.send(dui)              #发送真实的数据
30             conn.send(cuo)              #发送真实的数据
31         except Exception:               #结束捕捉异常
32             break                       #跳出
33     conn.close()                        #断开链接
34 din.close()                             #关闭连接 

 1 #客户端
 2 import struct    #导入模块
 3 import socket    #导入模块
 4 import json      #导入模块
 5 din=socket.socket(socket.AF_INET,socket.SOCK_STREAM)   #基于网络家族和流的方式传输 创建连接
 6 ip=(‘127.0.0.1‘,8080)     #设置唯一的地址
 7 din.connect(ip)           #绑定地址
 8 while True:
 9     run=input(‘请输入命令：‘)      #用户交互界面
10     if not run:continue           #判断如果run为空就跳出
11     din.send(bytes(run,encoding=‘utf-8‘))   #通过字节形式发送用户输入的的内容
12     data=din.recv(4)          #接收内容长度为4，并赋值给data
13     head_len=struct.unpack(‘i‘,data)[0]  #解报头并索引出值赋值给head_len
14     head_bytes=din.recv(head_len)      #接收长度为head_len变量中的值，赋值给head_bytes
15     head_json=head_bytes.decode(‘utf-8‘)   #把刚刚接收的内容进行转换，转换成utf-8
16     head_dic=json.loads(head_json)       #在把转换成utf-8的内容 反序列化成字典的形式
17     data_lik=head_dic[‘data_lik‘]        #在把字典的查找的值赋值给data_lik
18     recv_size=0                         #设定变量并赋值为0
19     recv_data=b‘‘                      #设定变量并创建一个空字节的
20     while recv_size < data_lik:       #如果变量小于字典查找出来的值时，循环为真。
21         data=din.recv(1024)          #接收内容赋值给data
22         recv_size+=len(data)        #把得到的内容长度加到变量recv_size中，这样就能实现如果没有取完内容就一直取得效果
23         recv_data+=data           #把拿到的值加到新创建的字节中
24         print(recv_data.decode(‘gbk‘))   #打印以GBK转码的内容
25 din.close()   #关闭连接

大牛方案--终极版

时间： 2024-10-31 18:54:22

socket之粘包的相关文章

SOCKET TCP 粘包及半包问题

大家在使用SOCKET通信编程的时候,一般会采用UDP和TCP两种方式:TCP因为它没有包的概念,它只有流的概念,并且因为发送或接收缓冲区大小的设置问题,会产生粘包及半包的现象. 场景: 服务端向连续发送三个"HelloWorld"(三次消息无间隔),那么客户端接收到的情况会有以下三种: 1)HelloWorld HelloWorld HelloWorld (客户端接收三次) 2)HelloWorldHelloWor ldHelloWorld (客户端接收两次) 3)HelloWorl

网络编程 套接字socket 及 粘包

网络编程 套接字socket 及 粘包 sockt 初识 五层协议 : 从传输层包括传输层以下 , 都是操作系统帮我们封装的各种head socket套接字充当的就是内置模块的角色 socket 套接字,它存在于传输层与应用层之间的抽象层 避免你学习各层的接口以及协议的使用, socket已经封装好了所有的接口 . 直接使用这些接口或者方法即可 , 使用起来方便,提升开发效率 socket 就是一个模块 , 通过使用学习模块提供的功能 , 建立客户端与服务端的通信 套接字的工作流程(基于TCP和

socket tcp 粘包解决

何为粘包: 先看代码 session=socket.socket(socket.AF_INET,socket.SOCK_STREAM) 在定义socket对象的时候 有两个参数 一个是   socket地址家族,另一个是处理类型socket.SOCK_STREAM,注意是  'stream':流 那既然是流处理类型,理解上就是 水流式  处理数据. 这个时候数据是没有边界(也就是没有从头开始,到哪里)的概念就像下图 现在执行命令很正常: 执行了一个cat /etc/passwd   , 也能显示

Socket解决粘包问题2

在AsynServer中对接收函数增加接收判断,如果收到客户端发送的请求信息,则发送10个测试包给发送端,否则继续接收,修改后的接收代码如下: private void AsynReceive() { byte[] data = new byte[1024];//接收缓存 string receiveStr; string[] sendArr = PackageBuilder.BuildPackage(10);//生成发送数组,10个包 socket.BeginReceive(data, 0,

socket之粘包发生问题

粘包 注意注意注意: res=subprocess.Popen(cmd.decode('utf-8'),shell=True,stderr=subprocess.PIPE,stdout=subprocess.PIPE) 的结果的编码是以当前所在的系统为准的,如果是windows,那么res.stdout.read()读出的就是GBK编码的,在接收端需要用GBK解码 且只能从管道里读一次结果 注意:命令ls -l ; lllllll ; pwd 的结果是既有正确stdout结果,又有错误stder

Socket解决粘包问题1

粘包是指发送端发送的包速度过快,到接收端那边多包并成一个包的现象,比如发送端连续10次发送1个字符'a',因为发送的速度很快,接收端可能一次就收到了10个字符'aaaaaaaaaa',这就是接收端的粘包. 可能我们在平时练习时没觉的粘包有什么危害,或者通过把发送端发送的速率调慢来解决粘包,但在实时通信中,发送端常常是单片机或者其他系统的信息采集机,它们的发送速率是无法控制的,如果不解决接收端的粘包问题,我们无法获得正常的信息. 就以我自己正在做的项目来说,接收端是一台单频指标测量仪,它会把当前测

c# socket 解决粘包，半包

处理原理: 半包:即一条消息底层分几次发送,先有个头包读取整条消息的长度,当不满足长度时,将消息临时缓存起来,直到满足长度再解码 粘包:两条完整/不完整消息粘在一起,一般是解码完上一条消息,然后再判断是否有剩余字节,有的话缓存起来,循环半包处理 客户端接收代码: private void callReceived(object sender, SocketAsyncEventArgs args) { var socket = sender as Socket; var bb = args.Use

socket编程 粘包和半包 问题的及处理

一般在socket处理大数据量传输的时候会产生粘包和半包问题,有的时候tcp为了提高效率会缓冲N个包后再一起发出去,这个与缓存和网络有关系. 粘包 为x.5个包 半包 为0.5个包 由于网络原因 一次可能会来 0.5/1 /2/ 2.5/ ....个包 当接收到时 要先看看那这个包中有多少个完整的包.把完整的包都处理了 也就是说把x都处理了.剩下的0.5留在接收区中,等待下次接收. 这回接收到的就是0.5+1.5/0.5+1.3/0.5+0.5..... 把完整的包都处理了,有残缺的扔掉 0.8

socket 的粘包问题解决方案

粘包: 由于接受recv有最大限制,管道中有大于最大限制字节时, 第二次recv的会是之前残留的信息,这种现象叫做粘包. TCP协议是面向连接的,面向流的,当在发送数据时接受方不知道要收多少字节的数据,但由于缓存区大小的限制,我们又不可能设置很大的接受量,这时便需要有一个解决方案,避免产生粘包的现象. 解决方案:明确地告知接收端要收多大的数据,在开始循环的接受数据 实例: 原文地址:https://www.cnblogs.com/captain08/p/9074416.html