socket（二）

在学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收数据，数据丢失

待更新中。。。。