收发消息都是操作自己的缓冲区。类似队列的方式,先发的消息优先被收走了。
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)
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的时候限制字节数量,这时就算客户端发的时候数据连在一起,接收的也可以分开。