keepalive_requests

keepalive_requests

作者:tweyseo

01

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

02

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

03

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

图1

可是在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测试,并且抓包:!

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

05

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

糖果

糖果
LUA从入门到放弃

F5收购Nginx

Published on March 12, 2019

Lapis快速入门

Published on March 12, 2019