Openresty主动关闭连接与KeepAlive Requests

keepalive_requests

作者：tweyseo (T神发稿件）

01最近客户端（APP）换了新的网络库，几轮测试下来，功能和性能上都是正常的，只是网络库对应的日志里会有连接被关闭的提示，开始以为新的网络库踩到坑了，客户端的同学排查了几轮下来，过滤抓包发现是服务端发fin包主动关闭的连接，于是找到我说帮忙排查下。

02先说下我们测试环境里的服务端的架构，客户端使用基于HTTP/1.1的长连接直连服务端的一个基于lor的APIServer，APIServer再对应后端的其他服务。

03我这里就直接在APIServer上抓包，发现果然是APIServer上发起的fin包。仔细观察，发现fin包的前一个包，是一个响应客户端请求的包，而且让人比较困惑的是，这个包用HTTP协议解析出来，里面的status竟然还是200（这样就排除了是因为请求出错，NGX主动关闭的这个连接），然后间隔200ms后就是fin包了，再来观察这个响应包，发现HTTP协议解析出来的头，有connection: close的字段：

可是在APIServer里打印了该响应包在ngx.print之前的具体的头部信息，发现并没有connection: close的字段，那么这个字段应该就算NGX内部添加的，并且还在200ms后主动发起fin包关闭了连接。

于是我想到是不是长连接超时了，查看ngx的配置，发现确实有配 keepalive_timeout 2m;。但是按照客户端同学的反馈的现象看来跟keepalive_timeout的NGX官方描述又不一致，因为是一直有在请求的。

04正当我一筹莫展的时候，突然发现keepalive_timeout上面的一个keepalive_requests的配置：

Sets the maximum number of requests that can be served through one keep-alive connection. After the maximum number of requests are made, the connection is closed.

而且他的默认值是100，也就是说当前连接在处理完100个请求后将会关闭掉这个连接。

于是在我自己的机器上配置keepalive_requests 2;，然后做简单的ping-pong测试，并且抓包：

从抓包的结果来看，在第二个ping的响应包的包头里添加了connection: close的字段，随后NGX主动发起了fin包关闭了这个连接。

05总结，在NGX对客的HTTP/1.1的长连接的配置里，不仅有控制连接超时的keepalive_timeout，也还有控制针对单条连接的最大请求数的keepalive_requests。