提高单机短连接QPS到20万

提高单机短连接QPS到20万

转载于http://weibo.com/ttarticle/p/show?id=2309404037884855362229。

      

一般的通讯协议在设计上都避免服务器端主动发起TCP连接关闭，让客户端来发起close socket，避免服务器端端口和内存的资源消耗

默认情况下，客户端关闭TCP连接后本地的临时端口会长时间进入TIME_WAIT状态（默认120s），TIME_WAIT状态是为了保护TCP协议的正确性，避免端口发生复用后老的TCP连接残留在网络上的报文进入新的连接里。但这也引入了一个问题，临时端口数量有限，耗尽后，新建连接就会报错EADDRNOTAVAIL

首先要增加临时端口的数量，增加可被消耗的临时端口资源
sysctl -w "net.ipv4.ip_local_port_range=1024 65535”

然后要加速临时端口回收

第一种方法是启用tw_reuse，tw_reuse能加速TIME_WAIT状态端口在几秒时间内安全的回收
sysctl -w net.ipv4.tcp_timestamps=1
sysctl -w net.ipv4.tcp_tw_reuse=1
2.6.32内核下启动tw_reuse短连接可以达到2w，性能并不稳定；

第二种方法更激进些，启用tw_recycle，tw_recycle允许在两个RTT。当多个客户端处于NAT后时，在服务器端开启tw_recycle会引起丢包问题，如果丢SYN包，就会造成新建连接失败
sysctl -w net.ipv4.tcp_timestamps=1
sysctl -w net.ipv4.tcp_tw_recycle=1
2.6.32内核下启动tw_recycle短连接可以达到6w，比较稳定；

第三种方法是给socket配置SO_LINGER，on设为1，linger设为0，这样关闭连接后TCP状态从ESTAB直接进入CLOSED，向服务器发rst包而不是fin包来关闭连接。这种方法风险最高，会丢弃buffer里未发送完的数据，不过通过设计协议（客户端和服务器协议上协商后再关闭TCP连接）可以规避这个问题，使用需要小心，选择合适的场景。
这个方法可以完全解掉TIME_WAIT问题，短连接达到20w，很稳定

短连接QPS达到20w后，网卡pps接近百万，耗时主要在软中断，内核spin_lock和网卡驱动里，也基本让内核态网络协议栈负载饱和了。

背景资料补充：

SO_LINGER作用
设置函数close()关闭TCP连接时的行为。缺省close()的行为是，如果有数据残留在socket发送缓冲区中则系统将继续发送这些数据给对方，等待被确认，然后返回。

利用此选项，可以将此缺省行为设置为以下两种
  a.立即关闭该连接，通过发送RST分组(而不是用正常的FIN|ACK|FIN|ACK四个分组)来关闭该连接。至于发送缓冲区中如果有未发送完的数据，则丢弃。主动关闭一方的TCP状态则跳过TIMEWAIT，直接进入CLOSED。网上很多人想利用这一点来解决服务器上出现大量的TIMEWAIT状态的socket的问题，但是，这并不是一个好主意，这种关闭方式的用途并不在这儿，实际用途在于服务器在应用层的需求。
  b.将连接的关闭设置一个超时。如果socket发送缓冲区中仍残留数据，进程进入睡眠，内核进入定时状态去尽量去发送这些数据。
    在超时之前，如果所有数据都发送完且被对方确认，内核用正常的FIN|ACK|FIN|ACK四个分组来关闭该连接，close()成功返回。
    如果超时之时，数据仍然未能成功发送及被确认，用上述a方式来关闭此连接。close()返回EWOULDBLOCK。

SO_LINGER选项使用如下结构：

struct linger {

     int l_onoff;

     int l_linger;

};

l_onoff为0，则该选项关闭，l_linger的值被忽略，close()用上述缺省方式关闭连接。

l_onoff非0，l_linger为0，close()用上述a方式关闭连接。

l_onoff非0，l_linger非0，close()用上述b方式关闭连接。

值得一说的是，不管你用什么方式使用SO_LINGER，都需要大量耐心的测试来确保你的服务器程序确实是按照你的意愿在跑，因为这个选项对服务器处理小量请求的行为影响非常细微，简单的功能测试很难验证它的行为，上线后量大的情况下可能会出问题，让你的服务器马上下线，大并发量的模拟实际场景压测才能保证其正确性:)。