在学socket有时候我们会遇到这种问题：
解决方法一：
在服务端中加入：severTCP.setsockopt(socket.SOL_SOCKET, socket.SO_REUSEADDR, 1)
方法二(liunx)：
发现系统存在大量TIME_WAIT状态的连接，通过调整linux内核参数解决，
vi /etc/sysctl.conf
编辑文件，加入以下内容：
net.ipv4.tcp_syncookies = 1net.ipv4.tcp_tw_reuse = 1net.ipv4.tcp_tw_recycle = 1net.ipv4.tcp_fin_timeout = 30
然后执行 /sbin/sysctl -p 让参数生效。
net.ipv4.tcp_syncookies = 1 表示开启SYN Cookies。当出现SYN等待队列溢出时，启用cookies来处理，可防范少量SYN攻击，默认为0，表示关闭；
net.ipv4.tcp_tw_reuse = 1 表示开启重用。允许将TIME-WAIT sockets重新用于新的TCP连接，默认为0，表示关闭；
net.ipv4.tcp_tw_recycle = 1 表示开启TCP连接中TIME-WAIT sockets的快速回收，默认为0，表示关闭。
net.ipv4.tcp_fin_timeout 修改系統默认的 TIMEOUT 时间
问题二
客户端发送空，卡住，主要是在原因：缓冲区为空，recv就卡住：
当客户端异常断开连接,看见服务端（图3）：
图1
服务端：
图2
图3
服务端：
客户端：
、
一个简单聊天功能（没有并发效果）：
服务端
客户端：
运行结果
客户端：
服务端：
模拟简单ssh远程控制
服务端：
客户端：
运行结果：
粘包问题只存在于TCP中，UDP没有：
udp服务端：
客户端：
TCP VS UDP
tcp基于链接通信
基于链接，则需要listen（backlog），指定连接池的大小
基于链接，必须先运行的服务端，然后客户端发起链接请求
对于mac系统：如果一端断开了链接，那另外一端的链接也跟着完蛋recv将不会阻塞，收到的是空(解决方法是：服务端在收消息后加上if判断，空消息就break掉通信循环)
对于windows/linux系统：如果一端断开了链接，那另外一端的链接也跟着完蛋recv将不会阻塞，收到的是空(解决方法是：服务端通信循环内加异常处理，捕捉到异常后就break掉通讯循环)
udp无链接
无链接，因而无需listen（backlog），更加没有什么连接池之说了
无链接，udp的sendinto不用管是否有一个正在运行的服务端，可以己端一个劲的发消息，只不过数据丢失
recvfrom收的数据小于sendinto发送的数据时，在mac和linux系统上数据直接丢失，在windows系统上发送的比接收的大直接报错
只有sendinto发送数据没有recvfrom收数据，数据丢失
待更新中。。。。
