nginx 499错误处理及nginx的配置参数

阿里云国内75折回扣微信号：monov8

阿里云国际，腾讯云国际，低至75折。AWS 93折免费开户实名账号代冲值优惠多多微信号：monov8 飞机：@monov6

nginx 499错误处理及nginx的配置参数

背景

近期响应集团降本增效节省ci,stg机器我们项目开始容器化在改造过程中链路的访问发生了变化导致出现了499解决方如下

访问链路: 域名—> ELB (内网访问) —> openrestry stg环境支持自定义lua脚本 —> ELB(提供服务固定ip) —> 容器集群POd

499处理

nignx报499的原因是服务端响应超时nginx主动断开连接。例如nginx配置默认超时时间为60s当服务端接口响应为62s才返回结果那么当60s时nginx主动断开连接。
1. 调整如下proxy_xxx_timeout
2. 优化接口提高接口的响应速度

server{
    location / {
        proxy_connect_timeout 200;
        proxy_send_timeout 200;
        proxy_read_timeout 200;
    }
}

proxy_connect_timeout: 控制与后端服务器建立连接的超时时间单位是秒默认是60秒。

proxy_read_timeout: 控制等待后端服务器响应的超时时间单位是秒默认是60秒。

proxy_send_timeout: 控制发送请求到后端服务器的超时时间单位是秒默认是60秒。

这三个参数都是在使用 nginx 作为反向代理时用于限制与后端服务器通信的超时时间从而避免代理服务器被后端服务器的响应阻塞而无法响应客户端的请求。例如如果后端服务器出现了异常或网络故障会导致响应的延迟或永远不返回此时代理服务器会等待超时时间然后返回错误响应。

注意在使用这些超时设定时应当考虑应用程序的网络和运行环境以便确定适当的超时时间。超时时间设置过短可能导致请求失败而设置过长可能导致前端网站的响应变慢。可以适当根据实际情况调整并进行测试以确保可靠性和性能。参数值也不是越大越好对于确实响应慢的接口要进行性能优化。

知识扩展: nginx配置参数

server{
    location / {
        proxy_ignore_client_abort  on;
        proxy_connect_timeout 200;
        proxy_send_timeout 200;
        proxy_read_timeout 200;
    }
}

proxy_ignore_client_abort: 用于实现“忽略客户端终止”功能。默认情况下“nginx”会将与客户端的连接请求转发到后端服务器但如果客户端中途断开请求服务则通常会导致到后端的连接被提前关闭。这时后端程序可能会继续执行一段时间但已经无法将响应发送回代理服务器因此可能导致代理服务器上的错误响应。

proxy_ignore_client_abort: off 默认配置客户端断开连接会中止响应
proxy_ignore_client_abort: on 客户端断开连接不会中止响应代理服务器将忽略客户端请求终止并让后端服务器继续响应直到响应完成。

http:{

    fastcgi_connect_timeout 200;
    fastcgi_send_timeout 200;
    fastcgi_read_timeout 200; 
}

以上参数当你的技术选型里有包含FastCGI,可以考虑开启上述fastcgi_xx_timeout参数。

如未接触过我们来简单介绍下: FastCGIFast Common Gateway Interface是一种 Web 应用程序的接口协议它提出了一种新型的方式来处理动态 Web 内容。astCGI 和早期的 CGI 脚本处理方式不同CGI 脚本在每次请求时都会启动新的进程这可能造成性能损失和资源浪费。而 FastCGI 利用了一些进程复用技术使得每个应用程序可以一直保持在内存中的状态等待下一次请求大大提高了性能。

Tomcat容器并未内置FastCGI功能在标准的SpringBoot应用程序中你需要特别安装、配置和/或使用第三方 FastCGI 库或框架来实现与 FastCGI 协议的通信。例如可以使用 Mod_jk 来实现 Tomcat 与前端 Web 服务器之间的 FastCGI 通信。

http {

    client_max_body_size 500m; //限制客户端请求体超过配置的值超过返回413
    client_body_buffer_size 10M; //
    # client_body_temp: /xx // 大于client_body_buffer_size是存储的磁盘目录
    keepalive_timeout  65s; //
    client_header_timeout 600s; //
    client_body_timeout  600s;  // 
    proxy_connect_timeout 200s;
    proxy_send_timeout    200s;
    proxy_read_timeout    200s;
    proxy_max_temp_file_size 0;

    limit_req_zone $binary_remote_addr zone=burstLimit:10m rate=40r/s;

    gzip on;
    gzip_min_length 1k;
    gzip_buffers 4 16k;
    gzip_types text/plain text/css application/json application/x-javascript application/javascript text/javascript appliaction/xml;
    gzip_comp_level 3;
    gzip_disable "MSIE [1-6].(?!.*SV1)";
    gzip_vary off;
}

client_max_body_size 限制客户端请求体超过配置的值超过返回413 Request Entity Too Large,在http,server,location均可配置。这个参数是针对单个请求体的大小而不是控制所有请求的综合大小。

client_body_buffer_size 客户端请求体数据到内存时缓存区分配的大小。如果请求的数据小于这个配置直接将数据先在存在内存如果请求的值大于client_body_buffer_size小client_max_body_size就会将数据先存储到临时文件中临时文件默认路径是/tmp/也可通过配置client_body_temp指定目录

client_body_temp: 当请求体大于client_body_buffer_size小于client_max_body_size是配置这个参数存储到指定的磁盘路径注意这个需要修改权限chomd否则会报Permission denied

keepalive_timeout: 当使用http/1.1协议是可以使用keepalive复用tcp的连接减少tcp三次握手四次挥手建立网络连接的时间。keepalive_time的意思是每次请求完毕后保持指定时间的连接可以避免频繁创建和关闭连接的过程。默认值是75s若设置为0表示禁止keepalive连接

client_header_timeout 客户端像服务端发送一个完整的request header的超时时间默认60s如果客户端在指定时间内没有发送一个完整的request headernginx返回http 408(request time out)

client_body_timeout 户端像服务端发送一个完整的request body的超时时间, 默认60s如果客户端在指定时间内没有接受到请求体数据,注意不是整个请求提数据传输是在接受到header后到开始传输body这个过程的超时时间(官方文档: The timeout is set only for a period between two successive read operations, not for the transmission of the whole request body If a client does not transmit anything within this time, the request is terminated with the 408 (Request Time-out) error.) nginx返回http 408(request time out)。

proxy_max_temp_file_size: 缓存到磁盘的文件大小如果设置为0则不缓存到磁盘。如果超过了设置的值则nginx将与proxy的服务器同步的传递内容则不在还缓冲到磁盘

limit_req_zone nginx限流模块,$binary_remote_addr表明限制的目标remote_addr记录的是ip信息占用7~15个字节binary_remote_addr表示压缩的ip,仅占用4个字节。zone=name:size分配一个名为name的并且大小为size的内存空间用来存储访问的频次信息;rate=40r/s表示同一个ip每秒只允许40个请求通过

gzip: on开启gzip压缩静态资源, off关闭

gzip_min_length: 1k 配置开启压缩的大小资源大于这个的才压缩再小就不要压缩

gzip_buffers 4: 16k 缓冲压缩在内存缓冲几块每块多大

gzip_types: text/plain text/css application/json application/x-javascript application/javascript text/javascript appliaction/xml; 对那些类型的文件用压缩

gzip_comp_level: 3; 压缩级别[1-9]级别越高压的越小越耗费CPU计算时间

gzip_disable: “MSIE [1-6].(?!.*SV1)”; 正则匹配什么样的uri不进行gzip压缩此处表示ie6及一下不启用gzip因为这些版本不支持

gzip_vary: off 是否传输压缩标志

nginx增加健康检查

nginx开源版本没有自带负载均衡后端节点的健康检查但是通过额外的nginx_upstream_check_module模块对后端节点做健康检查。

upstream name{
 server 192.168.0.1:80;
 server 192.168.0.2:80;
 check interval=3000 rise=2 fail=5 timeout=1000 type=http;

}

对name的这个upstream负载均衡每个节点3s检测一次请求2次正常则标记realserver状态为up,如果检测5次都失败则标记ralserver状态为down超时时间为1s.

各种负载均衡软硬件

ELB HAproxy nginx openresty F5 LVS

HaProxy: 一款负载均衡软件与nginx角色一样支持TCP/HTTP两种协议的负载均衡使得其负载均衡功能非常丰富支持8种左右的负载均衡算法尤其是在http模式下有非常多的实用的均衡算法拥有一个功能出色的监控页面实时了解系统当前的状态;功能强大的ACL支持给用户极大的方便(ACL access control list访问控制列表符合ACL规则请求由backend指定的后端服务器池执行基于ACL规则的负载均衡不符合的可以直接中断响应也可以交由其他服务器执行)自带监控检查nginx需要增加额外的模块支持健康检查。缺点是配置文件比较繁琐需要一定的技术水平和经验进行部署和维护。

ELB AWS提供的云软件负载均衡服务实用云端的应用部署有点易于使用缺点是定制化自定义有限对企业级需要可能不够全面

F5 负载均衡硬件性能非常好每秒处理的请求数可以达到百万级采购价格也非常贵十几万到百万人民币都有适用于大型企业流量特别多的情况。

LVS 软件负载均衡由阿里的章文嵩博士研发是国内最早的自由软件配置方便抗负载能力强不足不支持正则处理不支持做动静分离对网络环境比较依赖

openresty 对nginx的扩展自由度高支持实用lua及大量的第三方模块方便的搭建能够处理高并发扩展性极高的web应用网关从而将nginx从简单的负载均衡变成一个强大的网关、通用的web应用平台。