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。
本文分享自微信公众号 - 糖果的实验室(mycandylab)。
如有侵权,请联系 support@oschina.cn 删除。
本文参与“OSC源创计划”,欢迎正在阅读的你也加入,一起分享。