zoukankan      html  css  js  c++  java
  • DAY 24 PYTHON入门

    一、socket通信
    Socket是应用层与TCP/IP协议族通信的中间软件抽象层,它是一组接口。在设计模式中,Socket其实就是一个门面模式,它把复杂的TCP/IP协议族隐藏在Socket接口后面,对用户来说,一组简单的接口就是全部,让Socket去组织数据,以符合指定的协议。

    基于TCP协议的socket
    server端
    import socket
    sk = socket.socket()
    sk.bind(('127.0.0.1',8898)) #把地址绑定到套接字
    sk.listen() #监听链接
    conn,addr = sk.accept() #接受客户端链接
    ret = conn.recv(1024) #接收客户端信息
    print(ret) #打印客户端信息
    conn.send(b'hi') #向客户端发送信息
    conn.close() #关闭客户端套接字
    sk.close() #关闭服务器套接字(可选)

    client端
    import socket
    sk = socket.socket() # 创建客户套接字
    sk.connect(('127.0.0.1',8898)) # 尝试连接服务器
    sk.send(b'hello!')
    ret = sk.recv(1024) # 对话(发送/接收)
    print(ret)
    sk.close() # 关闭客户套接字

    问题:有的同学在重启服务端时可能会遇到报错
    #加入一条socket配置,重用ip和端口
    import socket
    from socket import SOL_SOCKET,SO_REUSEADDR
    sk = socket.socket()
    sk.setsockopt(SOL_SOCKET,SO_REUSEADDR,1) #就是它,在bind前加
    sk.bind(('127.0.0.1',8898)) #把地址绑定到套接字
    sk.listen() #监听链接
    conn,addr = sk.accept() #接受客户端链接
    ret = conn.recv(1024) #接收客户端信息
    print(ret) #打印客户端信息
    conn.send(b'hi') #向客户端发送信息
    conn.close() #关闭客户端套接字
    sk.close() #关闭服务器套接字(可选)

    tcp是基于链接的,必须先启动服务端,然后再启动客户端去链接服务端

    二、基于UDP协议的socket
    server端
    import socket
    udp_sk = socket.socket(type=socket.SOCK_DGRAM) #创建一个服务器的套接字
    udp_sk.bind(('127.0.0.1',9000)) #绑定服务器套接字
    msg,addr = udp_sk.recvfrom(1024)
    print(msg)
    udp_sk.sendto(b'hi',addr) # 对话(接收与发送)
    udp_sk.close() # 关闭服务器套接字

    client端
    import socket
    ip_port=('127.0.0.1',9000)
    udp_sk=socket.socket(type=socket.SOCK_DGRAM)
    udp_sk.sendto(b'hello',ip_port)
    back_msg,addr=udp_sk.recvfrom(1024)
    print(back_msg.decode('utf-8'),addr)

    udp是无链接的,启动服务之后可以直接接受消息,不需要提前建立链接

    三、黏包现象
    res=subprocess.Popen(cmd.decode('utf-8'),
    shell=True,
    stderr=subprocess.PIPE,
    stdout=subprocess.PIPE)

    输出的结果的编码是以当前所在的系统为准的,如果是windows,那么res.stdout.read()读出的就是GBK编码的,在接收端需要用GBK解码,且只能从管道里读一次结果

    同时执行多条命令之后,得到的结果很可能只有一部分,在执行其他命令的时候又接收到之前执行的另外一部分结果,这种显现就是黏包

    基于tcp协议实现的黏包
    Server端
    #_*_coding:utf-8_*_
    from socket import *
    import subprocess

    ip_port=('127.0.0.1',8888)
    BUFSIZE=1024

    tcp_socket_server=socket(AF_INET,SOCK_STREAM)
    tcp_socket_server.setsockopt(SOL_SOCKET,SO_REUSEADDR,1)
    tcp_socket_server.bind(ip_port)
    tcp_socket_server.listen(5)

    while True:
    conn,addr=tcp_socket_server.accept()
    print('客户端',addr)

    while True:
    cmd=conn.recv(BUFSIZE)
    if len(cmd) == 0:break

    res=subprocess.Popen(cmd.decode('utf-8'),shell=True,
    stdout=subprocess.PIPE,
    stdin=subprocess.PIPE,
    stderr=subprocess.PIPE)

    stderr=res.stderr.read()
    stdout=res.stdout.read()
    conn.send(stderr)
    conn.send(stdout)

    Client端
    #_*_coding:utf-8_*_
    import socket
    BUFSIZE=1024
    ip_port=('127.0.0.1',8888)

    s=socket.socket(socket.AF_INET,socket.SOCK_STREAM)
    res=s.connect_ex(ip_port)

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

    s.send(msg.encode('utf-8'))
    act_res=s.recv(BUFSIZE)

    print(act_res.decode('utf-8'),end='')

    四、黏包成因
    TCP面向流的通信特点和Nagle算法
    TCP(transport control protocol,传输控制协议)是面向连接的,面向流的,提供高可靠性服务。
    收发两端(客户端和服务器端)都要有一一成对的socket,因此,发送端为了将多个发往接收端的包,更有效的发到对方,使用了优化方法(Nagle算法),将多次间隔较小且数据量小的数据,合并成一个大的数据块,然后进行封包。
    这样,接收端,就难于分辨出来了,必须提供科学的拆包机制。 即面向流的通信是无消息保护边界的。
    对于空消息:tcp是基于数据流的,于是收发的消息不能为空,这就需要在客户端和服务端都添加空消息的处理机制,防止程序卡住,而udp是基于数据报的,即便是你输入的是空内容(直接回车),也可以被发送,udp协议会帮你封装上消息头发送过去。
    可靠黏包的tcp协议:tcp的协议数据不会丢,没有收完包,下次接收,会继续上次继续接收,己端总是在收到ack时才会清除缓冲区内容。数据是可靠的,但是会粘包。

    UDP不会发生黏包
    UDP(user datagram protocol,用户数据报协议)是无连接的,面向消息的,提供高效率服务。
    不会使用块的合并优化算法,, 由于UDP支持的是一对多的模式,所以接收端的skbuff(套接字缓冲区)采用了链式结构来记录每一个到达的UDP包,在每个UDP包中就有了消息头(消息来源地址,端口等信息),这样,对于接收端来说,就容易进行区分处理了。 即面向消息的通信是有消息保护边界的。
    对于空消息:tcp是基于数据流的,于是收发的消息不能为空,这就需要在客户端和服务端都添加空消息的处理机制,防止程序卡住,而udp是基于数据报的,即便是你输入的是空内容(直接回车),也可以被发送,udp协议会帮你封装上消息头发送过去。
    不可靠不黏包的udp协议:udp的recvfrom是阻塞的,一个recvfrom(x)必须对唯一一个sendinto(y),收完了x个字节的数据就算完成,若是y;x数据就丢失,这意味着udp根本不会粘包,但是会丢数据,不可靠。

    会发生黏包的两种情况
    情况一 发送方的缓存机制
    发送端需要等缓冲区满才发送出去,造成粘包(发送数据时间间隔很短,数据了很小,会合到一起,产生粘包)

    情况二 接收方的缓存机制
    接收方不及时接收缓冲区的包,造成多个包接收(客户端发送了一段数据,服务端只收了一小部分,服务端下次再收的时候还是从缓冲区拿上次遗留的数据,产生粘包)

    总结
    黏包现象只发生在tcp协议中:

    1.从表面上看,黏包问题主要是因为发送方和接收方的缓存机制、tcp协议面向流通信的特点。

    2.实际上,主要还是因为接收方不知道消息之间的界限,不知道一次性提取多少字节的数据所造成的

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


    存在的问题:
    程序的运行速度远快于网络传输速度,所以在发送一段字节前,先用send去发送该字节流长度,这种方式会放大网络延迟带来的性能损耗

    解决方案进阶
    刚刚的方法,问题在于我们我们在发送

    我们可以借助一个模块,这个模块可以把要发送的数据长度转换成固定长度的字节。这样客户端每次接收消息之前只要先接受这个固定长度字节的内容看一看接下来要接收的信息大小,那么最终接受的数据只要达到这个值就停止,就能刚好不多不少的接收完整的数据了。

    struct模块
    该模块可以把一个类型,如数字,转成固定长度的bytes
    import struct
    obj = struct.pack('i',123456)
    print(len(obj)) # 4
    obj = struct.pack('i',898898789)
    print(len(obj)) # 4
    # 无论数字多大,打包后长度恒为4

    使用struct解决黏包
    借助struct模块,我们知道长度数字可以被转换成一个标准大小的4字节数字。因此可以利用这个特点来预先发送数据长度。

    我们还可以把报头做成字典,字典里包含将要发送的真实数据的详细信息,然后json序列化,然后用struct将序列化后的数据长度打包成4个字节(4个自己足够用了)

  • 相关阅读:
    scgi_params
    ngin 模块及模板
    nginx常用模块
    HTML
    nginx部署网页小游戏
    nginx的server标签还有日志管理
    关于使用yum安装的nginx的主从配置文件的碎碎念
    判断所ping主机的操作系统
    CentOS 7修改主机名
    CentOS7 设置系统时间
  • 原文地址:https://www.cnblogs.com/DEJAVU888/p/14295322.html
Copyright © 2011-2022 走看看