[线上问题] “服务端长连接与客户端短连接引起Nginx产生大量"TIME_WAIT"状态的线程”的问题分析解决

近期，线上Nginx服务器的TPS未超过100，但其Writing、Active连接数有时却超过了300。因为服务对响应时间要求较高，同时每个调用方使用的IP地址有限（即总的不同的连接地址有限），所以使用HTTPs长连接技术。（HTTP长连接与短连接）

 

问题现象：使用"sudo netstat -antp | grep 80"发现，存在大量的"TIME_WAIT" socket等待中断请求确认的线程（8000+）
原因：使用Wireshark分析tcpdump.txt发现，eleme使用短连接请求（非长连接，Keep-Alive），而服务器端使用的却是长连接。eleme每次请求都会新开一个连接，请求完之后就把该连接关闭了；而服务端线程在处理完请求后却一直打开等待着下一个请求的到来（5min最长存活时间），同时对新的请求又需要新建一个线程，致使大量线程出现"TIME_WAIT"现象，所有请求处理线程都等待5min后才会被服务器关闭。

解决方法：让eleme改为长连接请求

[参考]

1. Apache服务器的 FIN_WAIT1 过多 TIME_WAIT 过多问题解决
2. UNIX / Linux: 10 Netstat Command Examples
3. netstat命令详解 (10 Netstat Command Examples 中文版)
4. netstat(8) - Print network connections, routing tables, interface statistics - Linux manual page

 

[RFC] 服务端无状态的传输层安全(TLS)会话恢复协议

无状态TLS会话恢复机制概述

先说说TLS会话恢复机制的出现是为了解决什么问题？

【背景】

      SSL会话恢复的原理是在服务端缓存所有的session，客户端之后在每次和服务端握手时通过Session ID完成session状态恢复。这种机制对服务端有如下挑战：

 

1. 如果是在本机缓存session，必须保证同一个客户端的请求要落到同一台服务器，这无疑给前端负载均衡策略增大了压力。

2. 如果是为一个集群单独建立一个shared的session cache，同样也增加了请求的处理环节，并增加了系统的成本（都是money啊）。

 

之所以如此纠结是因为SSL觉得session信息必须放在服务端缓存，而SSL的替代者TLS则提供了新的选择，服务端无状态的会话恢复机制。

【原理】

       简单的说，就是服务端不再缓存session的状态信息，而是将其加密并分发和转存到客户端，缓存在客户端的session状态信息叫Ticket（船票，你懂得）。客户端每次请求时同时发送ticket到服务端，服务端将其解密并reuse之前的session状态信息。

[参考]

1. 服务端无状态的TLS session resumption机制 - 淘宝千石
2. Optimizing for TLS - Chapter 4. Transport Layer Security (TLS)
3. TLS优化 - Optimizing for TLS

 

1. 触发新的会话票证的完整握手的消息流

 

 

真实的网络数据包：

 

“Message Flow for Full Handshake Issuing New Session Ticket”适合HTTPS短连接场景。

 

3. 不触发新的会话票证的服务器完成完整握手的消息流

 

真实的网络数据包：

 

“Message Flow for Server Completing Full Handshake Without Issuing New Session Ticket”适合HTTPS长连接场景。

 

待解决“存在TCP重复ACK和丢包现象”：

 

参考

[PDF] Transport Layer Security (TLS) Session Resumption without Server-Side State

RFC 5077

RFC 4507

 

 

玩的开心！^_^