Openresty主动关闭连接与KeepAlive Requests
- 前端
- Stella981
- 0
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源创计划”，欢迎正在阅读的你也加入，一起分享。
免责申明：本站发布的内容（图片、视频和文字）以转载和分享为主，文章观点不代表本站立场，如涉及侵权请联系站长邮箱：xbc-online@qq.com进行反馈，一经查实，将立刻删除涉嫌侵权内容。
