499问题思考

499状态码解释：

Nginx中 499状态码的定义是 client has closed connection，也就是客户端断开了连接。

一般发生499的有几种原因：

1.客户端觉得服务端太慢了，主动断开了，这个时候客户端设置了链接超时时间

2.在客户端操作有时候，关闭了页面和取消了请求。

第2种情况在服务器日志里面看到Broken pipe 完全可以忽略。但是第1种情况为什么客户端会觉得服务端太慢呢？有可能是服务端接口返回时间特别长，有可能阻塞，还有可能是网络问题。

如果真的是接口性能问题，这个还好解决，如果超时时间超过了客户端设置的超时时间，偶发的499问题？我们该怎么排查。先看一下业务场景客户端通过网关转发到上游服务，具体简单时序图如下：

如果七层网关和api网关都不设置超时时间，客户端到上游的超时时间就是，SDK里面设置的链接超时时间。我们看几个比较重要的时间参数：

• upstream_response_timekeeps time spent on receiving the response from the upstream server; the time is kept in seconds with millisecond resolution. Times of several responses are separated by commas and colons like addresses in the upstream_addr variable.
• upstream_statuskeeps status code of the response obtained from the upstream server. Status codes of several responses are separated by commas and colons like addresses in the upstream_addr variable. If a server cannot be selected, the variable keeps the 502 (Bad Gateway) status code.
• upstream_connect_timekeeps time spent on establishing a connection with the upstream server (1.9.1); the time is kept in seconds with millisecond resolution. In case of SSL, includes time spent on handshake. Times of several connections are separated by commas and colons like addresses in the upstream_addr variable.
• ngx.req.start_time 语法: secs = ngx.req.start_time() 环境: set_by_lua*, rewrite_by_lua*, access_by_lua*, content_by_lua*, header_filter_by_lua*, body_filter_by_lua*, log_by_lua* 返回当前请求创建时的时间戳，格式为浮点数，其中小数部分代表毫秒值。

ngx.req.start_time这个参数不是标准的Nginx内置参数，ngx_http_lua_module - 嵌入强有力的 Lua 到 Nginx HTTP 服务中。该模块不是随着 Nginx 源码发行。

有了这么多重要的时间参数和全链路追踪ID，发现一个奇怪的现象，就是API网关和上游服务建立连接时间比较久，导致触发超时时间然后返回499。

问题来了怎么分析为什么建立连接时间长呢？当然必须用抓包来验证TCP三次握手是否正常。具体那一段传输出现问题，必须上下游协同一起抓包，抓包策略一定不能影响生产环境。当然到用到抓包的方式，也是所有的方法都排查了，果真到最后找到了问题，果然是没有回包。

在我们和上下游排查问题或者跨部门协作排查问题的时候，首先要证明自己没问题，你自己的日志全不全？你能证明你没有问题，能给上下游提供一些解决问题的思路？你自己对你出示的数据和材料最好能帮助别人排查问题。

当然可能大家都不会承认自己的问题，至于到最后是谁的问题其实并不重要，最重要的是排查问题的过程。反思自己说过不合适的话和做过不合适的事，关注重要的事情，不断成长才是最重要的。