一、问题描述

某天，在对一个提供 http 接口的后台服务进行压力测试过程中，我们设定了几百 qps（每秒请求数）开始测试几分钟后，请求一端（我们后续简称为：客户端）的压力结果统计日志中开始连续出现大量的报错信息：

在压力测试前，根据之前的经验，同类服务的单机性能一般能够达到几千 QPS，然而此时测试设定的压力值还不足 200qps，这与预期存在 1 个数量级以上的性能差距，难道是被测服务存在问题么？

二、问题跟踪

为了确认被测服务的状态，我们首先登录了服务所在的机器，检查了服务资源的占用情况，结果是：CPU、内存、硬盘、I/O、网卡、fd、socket 等各项资源都不存在较大负载。看来服务本身还远没有达到它的负载瓶颈。

在排除服务端问题后，我们重新分析了统计日志中的错误--"can not assign requested address"，这是一个常见的 socket 的 error，报错信息说明无法为 socket 创建新的连接，很可能是：tcp 层的连接端口已经耗尽，无法为新的 http 请求分配端口建立连接。通过 netstat 命令，我们检查客户端，发现确实存在大量请求连接处于 TIME＿WAIT 状态下：

这里要说明一下，虽然理论上 tcp 连接可用端口号为 0~65535--大约 65536 个，但是实际在不指定端口情况下连接服务时可用端口默认为 32768~61000--大约只有 28000 多个，在 linux 系统中这个限制可以通过
/proc/sys/net/ipv4/ip＿local＿port_range 文件进行修改。

我们知道 http 协议主要是基于 tcp 协议之上的，为了解决 tcp 层连接通道复用的问题，在 http 协议中通过 header 中的 Connection 字段定义了对于 tcp 长连接的支持：

在 HTTP/1.0 版本中，默认情况下在 HTTP1.0 中所有连接不被保持，如果客户端浏览器支持 Keep-Alive，那么就在 HTTP 请求头中添加一个字段 Connection: Keep-Alive，当服务器收到附带有 Connection: Keep-Alive 的请求时，它也会在响应头中添加一个同样的字段来使用 Keep-Alive。这样一来，客户端和服务器之间的 HTTP 连接就会被保持，当客户端发送另外一个请求时，就使用这条已经建立的连接通道。
在 HTTP/1.1 版本中，默认情况下在 HTTP1.1 中所有连接都会被保持，除非在请求头或响应头中指明要关闭：Connection: Close，这也就是为什么 Connection: Keep-Alive 字段再没有意义的原因。

在压力测试过程中，我们模拟发送 http 请求的代码中使用的是 http/1.1 协议，应该会默认使用长连接，看来很可能是服务端不支持长连接，才会引起客户端频繁的创建 TCP 连接。通过 tcpdump 抓包，我们对此进行了证实：

三、跟进分析

到此，我们发现服务端确实返回不支持长连接的信息（header 中 connection:close），导致客户端每次发起请求都会重新创建 tcp 通道。但是根据以往测试经验来看，比较常见的是在服务端出现大量 time_wait 状态的，那么为什么大量的 time_wait 状态会在客户端出现呢？

了解这个问题我们之前，可以先来看一下 TCP 正常连接建立和关闭连接时的状态变化图：

上图是 TCP"三次握手"和"四次挥手"的过程，相信很多读者都比较了解，下面我们来说说为什么要存在 TIME_WAIT 状态吧：

可靠地实现 TCP 全双工连接的终止

TCP 协议在关闭连接的四次挥手中，在主动关闭方发送的最后一个 ack(fin) ，有可能丢失，这时被动方会重新发 fin, 如果这时主动方处于 CLOSED 状态，就会响应 rst 而不是 ack。所以主动方要处于 TIME_WAIT 状态，而不能是 CLOSED 。
允许老的报文段在网络中消失

TCP 报文段可能由于路由器异常而 “迷路”，在迷途期间，TCP 发送端可能因确认超时而重发这个报文，迷途的报文在路由器修复后也会被送到最终目的地，这个原来的迷途报文就称为 lost duplicate。在关闭一个 TCP 连接后，马上又重新建立起一个相同的 IP 地址和端口之间的 TCP 连接，后一个连接被称为前一个连接的化身（incarnation)，那么有可能出现这种情况，前一个连接的迷途重复报文在前一个连接终止后出现，从而被误解成从属于新的化身。为了避免这个情况，TCP 不允许处于 TIME＿WAIT 状态的连接启动一个新的化身，因为 TIME＿WAIT 状态持续 2MSL，就可以保证当成功建立一个 TCP 连接的时候，来自连接先前化身的重复报文已经在网络中消逝。

明白了 time_wait 的存在原因和出现时机，可以看到 TIME_WAIT 状态总是出现的主动关闭连接的一方，也就是说在我们压力测试过程中每次都是客户端主动关闭 tcp 连接的。从实际的抓包结果来看，确实如此：

但是我们实际遇到的多是 time_wait 出现在服务一端出现的，那么在 http 协议规定中，服务端返回connection:close 的信息后，到底是应该由客户端还是服务端来主动关闭连接呢？

Connection: close 是一个 general-header（ RFC 2616 - Hypertext Transfer Protocol -- HTTP/1.1 ）即：既可以作为 request header 也可以作为 response header。Connection: close 的作用在于"协商 (signal)"。在 RFC2616 14.10 中：

HTTP/1.1 defines the "close" connection option for the sender to
signal that the connection will be closed after completion of the
response.

通过 RFC 可以发现：请求和响应的双方都可以主动关闭 TCP 连接。

但是大多数的 web Service 实现是返回 connection:close 内容之后服务端会主动关闭连接。至于这样设计的原因，网上找到 2 个比较靠谱的解释：

server 主动关闭连接是历史原因：HTTP/0.9 协议中 response 是没有 header 的，所以 client 根本无从知道什么时候这个东西结束。
在 server 主动关闭连接的情况下，只要调用一次 close() 就可以释放连接，剩下的工作由内核 TCP 栈直接进行了处理，整个过程只有一次 syscall；如果是要求 client 关闭，则 server 在写完最后一个 response 之后需要把这个 socket 放入 readable 队列，调用 select / epoll 去等待事件；然后调用一次 read() 才能知道连接已经被关闭，这其中是两次 syscall，多一次用户态程序被激活执行，而且 socket 保持时间也会更长。

也许会有读者担心：如果客户端也不主动关闭 TCP 连接，服务端的 socket 资源会不会很快用完呢。这里留给读者们一个问题进行思考：在单个服务器上的服务端理论上能支持的最大 TCP 连接数是多少呢？