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

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在自己这段的缓冲区为空时，就收一个空？？？？

不同的协议端口不会冲突

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的时候限制字节数量，这时就算客户端发的时候数据连在一起，接收的也可以分开。