nginx http 499,其实没有很可怕
背景
499作为nginx自定义的状态码,不像400、401、500、502等常见的http状态码,很多不太常用nginx的人可能并不能清楚理解他的含义,本文将简单介绍一下499状态码的含义,以及出现后的排查和处理思路,以及proxy_ignore_client_abort参数是否能有效。
499是什么
nginx 对499的定义是 client has closed connection。这个定义比较模糊,简单来说就是nginx在完成响应之前客户端断开了连接。
499是如何产生的
根据上面的定义,499产生的核心原因是客户端在nginx完成响应之前断开了连接。可以不太严谨的概括就是nginx完成的响应时间超过了客户端的超时时间。
排查思路
上面对499产生原因的概括其实不太准确,实际上造成499的原因有很多,接下来我就介绍主要的排查思路,以及我平时比较常见的几种情况。
nginx作为火了很多年的高性能web服务,有许多的应用场景,我选择比较常见的反向代理服务场景来介绍一下
在上述架构下,客户端发起一个请求大约要经历下面这些阶段
这只是一个比较简单的流程,实际上会更复杂一些,比如中间可能还是一些网络设备已经其他的基础服组件。
499的触发时机
由于499是nginx记录的状态码,所以客户端断开连接的时机是要在nginx接收HTTP请求行,到nginx发送响应这个区间内,所以如果客户端在DNS解析或者TCP建连之前就超时的话是不会触发499的,毕竟请求都没有到达nginx。如果nginx已经开始返回响应了,此时客户端就断开连接的话,不会记录499,会以响应的状态码为准,比如200。
499的影响
上面说过,499代表客户端超时断开了连接,大部分情况下499代表请求失败了,需要根据业务场景评估影响。比如如果客户端有重试逻辑, 499之后重试成功,那么实际上可能不会有很大的影响。
499还有一个比较容易被忽视的影响,由于499代表客户端断开了连接,那么客户端重试的时候意味着会重新建立tcp连接甚至重新tls握手,在一些高并发的场景下,大量的499导致的客户端重试可能会对服务端造成一定的压力,此时我们需要考虑在服务端做一些降级策略,减少499造成的重试压力。
499的排查方向
我们之前提到过,499触发的根本原因是nginx返回的响应时间超过了客户端的超时时间,所以我们一般有下面几个排查方向:
1. 后端响应时间是否过长
这里的后端是一个比较笼统的说法,实际的后端逻辑中可能还包含数据库的访问以及api的调用等,我们可以先通过查看nginx 499的访问日志中的upstream_response_time 字段确认后端处理时间是否明显增加,如果是的话可以再进一步定位异常的环节。
2. nginx处理时间是否过长
需要查看nginx服务器的负载,比如cpu idle,load,网卡流量,io等是否有明细的升高或不足, nginx一般作为统一的反向代理服务,会代理多个域名,可以通过分析nginx请求日志,查看499的是否具有普遍性,如果在不同的域名,不同的后端服务中均有大量出现。配合之前说的nginx负载问题再进一步深入定位。
3. 客户端超时时间是否过短
这种情况需要看下nginx的499的request_time是否都比较短,且几乎相等,需要去看客户端代码中的调用的超时时间是否设置的不合理。
对相应时间要求比较高的服务比较容易出现499,由于http协议的限制,客户端想提前终止请求必须关闭连接,所以比较容易出现499。
4. 客户端网络质量是否太差
这种情况服务端很难确认,需要有客户端的访问日志或者使用一些拨测工具。
以上是一些比较简单的定位思路,没涉及到一些性能问题的排查方向,这个涉及到服务、网络和操作系统等很多方向的内容,这里不展开详谈了。
此外网上还有个传言是快速post的请求会导致触发nginx 499 。但是这个说法我从未找到具体的代码支持和复现,并且nginx是以性能著称的web服务,感觉不会有这种限制,个人倾向是以讹传讹。
如何解决
通过上面的排查思路的介绍,我们其实可以发现产生499的原因有很多,核心解决思路就是增加客户端的超时时间,加快后端的响应速度,提供一些边缘加速服务优化客户端的访问链路等等。但是499终究是一个客户端行为,我们在服务端侧是很难完全解决的,根据业务场景的不同,可以自行评估499的重要程度,一般的业务场景少量偶发的499不需要特别关注。
proxy_ignore_client_abort 有用吗?
然后就是简单聊一下 nginx的 proxy_ignore_client_abort 这个参数。nginx官方的解释是:
Determines whether the connection with a proxied server should be closed when a client closes the connection without waiting for a response.proxy_ignore_client_aborthttp://nginx.org/en/docs/http/ngx_http_proxy_module.html#proxy_ignore_client_abort
nginx默认会在client关闭连接的时候,同时关闭nginx向上游服务(后端)的连接,这个参数开启后,nginx将不会同步关闭后端服务连接,后端服务完成响应后,此次请求nginx也将不会记录499状态码,而是记录后端对应的响应状态码。
不知道从什么时候这个参数被传为可以是“解决”499的方法,然后如果你阅读了我上面写的内容后,应该会明白,这个参数不是解决499而是忽略499。并且一般我是不建议开启此参数的。主要有这几个原因:
1. 修改了响应的状态码,掩盖异常请求
开启这个参数后nginx的请求日志便和客户端的记录不一致。比如如果客户端已经超时,但是nignx这边仍然记录的一条200状态码的访问日志,这种后续问题排查和定位的时候,可能会提高排查难度。并且掩盖了499这一异常状态码,不利于及时发现异常。
2. 会浪费后端资源
客户端发起了一些很重的请求超时后,可能会不断重试,开启此参数nginx则不会中断之前向后端发起的请求,可能会导致加重对后端资源的使用。
所以proxy_ignore_client_abort并不是解决499的方法,大家一定要注意。
总结
499是由于nginx响应完成前客户端就断开了连接导致的,排查原因一般从客户端网络状态,超时时间以及服务端的响应时间来排查。常见的业务场景下,少量的499其实不需要过多的关注。
proxy_ignore_client_abort可以忽略499,但不是解决方法,不建议大家开启。没有证据能证明快速post导致nginx499,这个应该是谣传。