python网络编程知识点_wPython网络编程Day30部分知识点

fcbe573056ba5da2be68dcd9d0ffcceb.png

收发消息都是操作自己的缓冲区。类似队列的方式,先发的消息优先被收走了。

recv(1024)并不以为着一次一定收1024个字节,缓冲区只有1个字节那就只收一个。

队列是先进先出,堆栈是先进后出。

程序强行终止不是正常终止方式,用到的不是四次挥手,强制终止后失去conn双向链接,conn.recv失效报错。

客户端发送空信息,客户端自己的内核态内存是能收到的,但是由于信息为空,是不会通过Internet发到服务端的,造成程序卡住。

bind前加tcp_server.setsockopt(SOL_SOCKET,SO_REUSEADDR,1) #防止TIME_WAIT导致地址占用问题

发现系统存在大量TIME_WAIT状态的连接,通过调整Linux内核参数可以解决。

数据报套接字

—— 基于udp(socket.SOCK_DGRAM)

fd024e558b098c4990f8c57046d82831.png

listen是等待链接的建立,而udp没有链接的说法。

比起tcp少了链接循环,只有通讯循环。

recv在自己这段的缓冲区为空时,阻塞

recvfrom在自己这段的缓冲区为空时,就收一个空????

发送端的send和接收端的recv个数无关,应用程序不能直接作用操作系统,应用程序产生的数据送到内核态,然后才会作用操作系统。

不同的协议端口不会冲突

tcp不作处理不可并发,而udp可并发

subprocess模块

res=subprocess.Popen('dir',shell=True,stdout=subprocess.PIPE,stdin=subprocess.PIPE,stderr=subprocess.PIPE)  #输出结果交给管道,得到一个subprocess.Popen object(可以操作管道了)不打印就不会往屏幕上显示  第一个参数改成乱七八糟的错误信息,下一步res.stderr.read()

res.stdout.read()  #读取管道内容其实需要解码 res.stdout即subprocess.PIPE  读完管道为空,再读就没东西了

程序运行速度大于网络速度

粘包现象

tcp协议可能发生粘包现象,udp协议没有。

粘包的可能原因

1.发送端多次send间隔短,且数据量小,tcp协议有个nagle优化算法会把它们合成一个包发给接收端,接收端不知道包由部分组成由此粘包;

2.数据量较大的时候,接收一次没接收全,可能发生粘包。

udp不可靠,丢消息它不管,只运行客户端都行,因为没建立链接。udp永远不会粘包。

udp(面向消息的通信)有消息保护边界,每个UDP包有消息头(消息来源地址,端口等信息),因此不粘包,一个sendto就对应一个recvfrom。

recv和send是在自己的缓冲区做的,它们互相之间没联系,因为一个在服务器端一个在客户端。

如何解决粘包现象?

tcp客户端recv的时候限制字节数量,这时就算客户端发的时候数据连在一起,接收的也可以分开。

  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值