zoukankan      html  css  js  c++  java
  • 29_网络编程-黏包

    一、黏包成因
        
    TCP(transport control protocol,传输控制协议)是面向连接的,面向流的,提供高可靠性服务。
    收发两端(客户端和服务器端)都要有一一成对的socket,因此,发送端为了将多个发往接收端的包,更有效的发到对方,使用了优化方法(Nagle算法),将多次间隔较小且数据量小的数据,合并成一个大的数据块,然后进行封包。
    这样,接收端,就难于分辨出来了,必须提供科学的拆包机制。 即面向流的通信是无消息保护边界的。
    对于空消息:tcp是基于数据流的,于是收发的消息不能为空,这就需要在客户端和服务端都添加空消息的处理机制,防止程序卡住,而udp是基于数据报的,即便是你输入的是空内容(直接回车),也可以被发送,udp协议会帮你封装上消息头发送过去。
    可靠黏包的tcp协议:tcp的协议数据不会丢,没有收完包,下次接收,会继续上次继续接收,己端总是在收到ack时才会清除缓冲区内容。数据是可靠的,但是会粘包。
    基于tcp的套接字客户端往服务端上传文件,发送时文件内容是按照一段一段的字节流发送的,在接收方看了,根本不知道该文件的字节流从何处开始,在何处结束
    此外,发送方引起的粘包是由TCP协议本身造成的,TCP为提高传输效率,发送方往往要收集到足够多的数据后才发送一个TCP段。若连续几次需要send的数据都很少,通常TCP会根据优化算法把这些数据合成一个TCP段后一次发送出去,这样接收方就收到了粘包数据。
     
    总结:黏包直接原因是接收方不知道消息的界限 不知道一次性提取多少数据;根本原因是tcp自身为提供效率,TCP会根据 优化算法 把这些数据合成一个TCP段后一次发送出去,这样接收方就收到了粘包数据
     
        只有TCP会黏包,UDP永远不会黏包(udp基于数据报的,但会出现接收数据超出自己设置的范围)
        粘包不一定会发生,如果发生了:1.可能是在客户端已经粘了    2.客户端没有粘,可能是在服务端粘了
    socket数据传输过程中的用户态与内核态说明
    你的程序实际上无权直接操作网卡的,你操作网卡都是通过操作系统给用户程序暴露出来的接口,那每次你的程序要给远程发数据时,其实是先把数据从用户态copy到内核态,这样的操作是耗资源和时间的,频繁的在内核态和用户态之前交换数据势必会导致发送效率降低, 因此socket 为提高传输效率,发送方往往要收集到足够多的数据后才发送一次数据给对方。若连续几次需要send的数据都很少,通常TCP socket 会根据优化算法把这些数据合成一个TCP段后一次发送出去,这样接收方就收到了粘包数据。
     
    发送端可以是一K一K地发送数据,而接收端的应用程序可以两K两K地提走数据,当然也有可能一次提走3K或6K数据,或者一次只提走几个字节的数据。
    也就是说,应用程序所看到的数据是一个整体,或说是一个流(stream),一条消息有多少字节对应用程序是不可见的,因此TCP协议是面向流的协议,这也是容易出现粘包问题的原因。
    而UDP是面向消息的协议,每个UDP段都是一条消息,应用程序必须以消息为单位提取数据,不能一次提取任意字节的数据,这一点和TCP是很不同的。
    怎样定义消息呢?可以认为对方一次性write/send的数据为一个消息,需要明白的是当对方send一条信息的时候,无论底层怎样分段分片,TCP协议层会把构成整条消息的数据段排序完成后才呈现在内核缓冲区。
     
        UDP永远不会黏包
     
    UDP(user datagram protocol,用户数据报协议)是无连接的,面向消息的,提供高效率服务。
    不会使用块的合并优化算法,, 由于UDP支持的是一对多的模式,所以接收端的skbuff(套接字缓冲区)采用了链式结构来记录每一个到达的UDP包,在每个UDP包中就有了消息头(消息来源地址,端口等信息),这样,对于接收端来说,就容易进行区分处理了。 即面向消息的通信是有消息保护边界的。
    对于空消息:tcp是基于数据流的,于是收发的消息不能为空,这就需要在客户端和服务端都添加空消息的处理机制,防止程序卡住,而udp是基于数据报的,即便是你输入的是空内容(直接回车),也可以被发送,udp协议会帮你封装上消息头发送过去。
    不可靠不黏包的udp协议:udp的recvfrom是阻塞的,一个recvfrom(x)必须对唯一一个sendinto(y),收完了x个字节的数据就算完成,若是y;x数据就丢失,这意味着udp根本不会粘包,但是会丢数据,不可靠。
     
    用UDP协议发送时,用sendto函数最大能发送数据的长度为:65535- IP头(20) – UDP头(8)=65507字节。用sendto函数发送数据时,如果发送数据长度大于该值,则函数会返回错误。(丢弃这个包,不进行发送)
     
    用TCP协议发送时,由于TCP是数据流协议,因此不存在包大小的限制(暂不考虑缓冲区的大小),这是指在用send函数时,数据长度参数不受限制。而实际上,所指定的这段数据并不一定会一次性发送出去,如果这段数据比较长,会被分段发送,如果比较短,可能会等待和下一次数据一起发送。
     
    2、发生黏包的两种情况
     
        (1) 发送端需要等缓冲区满才发送出去,造成粘包(发送数据时间间隔很短,数据了很小,会合到一起,产生粘包)
     
        服务端
     1 #_*_coding:utf-8_*_
     2 from socket import *
     3 ip_port=('127.0.0.1',8080)
     4 
     5 tcp_socket_server=socket(AF_INET,SOCK_STREAM)
     6 tcp_socket_server.bind(ip_port)
     7 tcp_socket_server.listen(5)
     8 
     9 conn,addr=tcp_socket_server.accept()
    10 
    11 data1=conn.recv(10)
    12 data2=conn.recv(10)
    13 
    14 print('----->',data1.decode('utf-8'))
    15 print('----->',data2.decode('utf-8'))
    16 
    17 conn.close()
     
        客户端
    1 import socket
    2 BUFSIZE=1024
    3 ip_port=('127.0.0.1',8080)
    4 
    5 s=socket.socket(socket.AF_INET,socket.SOCK_STREAM)
    6 res=s.connect_ex(ip_port)
    7 
    8 s.send('hello'.encode('utf-8'))
    9 s.send('egg'.encode('utf-8'))
        (2) 接收方不及时接收缓冲区的包,造成多个包接收(客户端发送了一段数据,服务端只收了一小部分,服务端下次再收的时候还是从缓冲区拿上次遗留的数据,产生粘包)
     
        服务端
     1 #_*_coding:utf-8_*_
     2 from socket import *
     3 ip_port=('127.0.0.1',8080)
     4 
     5 tcp_socket_server=socket(AF_INET,SOCK_STREAM)
     6 tcp_socket_server.bind(ip_port)
     7 tcp_socket_server.listen(5)
     8 
     9 
    10 conn,addr=tcp_socket_server.accept()
    11 
    12 
    13 data1=conn.recv(2) #一次没有收完整
    14 data2=conn.recv(10)#下次收的时候,会先取旧的数据,然后取新的
    15 
    16 print('----->',data1.decode('utf-8'))
    17 print('----->',data2.decode('utf-8'))
    18 
    19 conn.close()
     
        客户端
    1 #_*_coding:utf-8_*_
    2 import socket
    3 BUFSIZE=1024
    4 ip_port=('127.0.0.1',8080)
    5 
    6 s=socket.socket(socket.AF_INET,socket.SOCK_STREAM)
    7 res=s.connect_ex(ip_port)
    8 
    9 s.send('hello egg'.encode('utf-8'))
    总结:
        黏包现象只发生在tcp协议中:
        1.从表面上看,黏包问题主要是因为发送方和接收方的缓存机制、tcp协议面向流通信的特点。
        2.实际上,主要还是因为接收方不知道消息之间的界限,不知道一次性提取多少字节的数据所造成的
     
    二、黏包解决方案一
        
        问题的根源在于,接收端不知道发送端将要传送的字节流的长度,所以解决粘包的方法就是围绕,如何让发送端在发送数据前,把自己将要发送的字节流总大小让接收端知晓,然后接收端来一个死循环接收完所有数据。
        存在的问题:程序的运行速度远快于网络传输速度,所以在发送一段字节前,先用send去发送该字节流长度,这种方式会放大网络延迟带来的性能损耗
        服务端
     1 #_*_coding:utf-8_*_
     2 import socket,subprocess
     3 ip_port=('127.0.0.1',8080)
     4 s=socket.socket(socket.AF_INET,socket.SOCK_STREAM)
     5 s.setsockopt(socket.SOL_SOCKET, socket.SO_REUSEADDR, 1)
     6 
     7 s.bind(ip_port)
     8 s.listen(5)
     9 
    10 while True:
    11     conn,addr=s.accept()
    12     print('客户端',addr)
    13     while True:
    14         msg=conn.recv(1024)
    15         if not msg:break
    16         res=subprocess.Popen(msg.decode('utf-8'),shell=True,
    17                             stdin=subprocess.PIPE,
    18                          stderr=subprocess.PIPE,
    19                          stdout=subprocess.PIPE)
    20         err=res.stderr.read()
    21         if err:
    22             ret=err
    23         else:
    24             ret=res.stdout.read()
    25         data_length=len(ret)
    26         conn.send(str(data_length).encode('utf-8'))
    27         data=conn.recv(1024).decode('utf-8')
    28         if data == 'recv_ready':
    29             conn.sendall(ret)
    30     conn.close()

        客户端

     1 #_*_coding:utf-8_*_
     2 import socket,time
     3 s=socket.socket(socket.AF_INET,socket.SOCK_STREAM)
     4 res=s.connect_ex(('127.0.0.1',8080))
     5 
     6 while True:
     7     msg=input('>>: ').strip()
     8     if len(msg) == 0:continue
     9     if msg == 'quit':break
    10 
    11     s.send(msg.encode('utf-8'))
    12     length=int(s.recv(1024).decode('utf-8'))
    13     s.send('recv_ready'.encode('utf-8'))
    14     send_size=0
    15     recv_size=0
    16     data=b''
    17     while recv_size < length:
    18         data+=s.recv(1024)
    19         recv_size+=len(data)
    20 
    21     print(data.decode('utf-8'))
  • 相关阅读:
    176. Second Highest Salary
    175. Combine Two Tables
    172. Factorial Trailing Zeroes
    171. Excel Sheet Column Number
    169. Majority Element
    168. Excel Sheet Column Title
    167. Two Sum II
    160. Intersection of Two Linked Lists
    个人博客记录
    <meta>标签
  • 原文地址:https://www.cnblogs.com/hq82/p/9846259.html
Copyright © 2011-2022 走看看