Nginx 不常关注配置
配置nginx到后端upstream的最小空闲连接数
- 对于http代理配置如下
upstream http_backend {
server 127.0.0.1:8080;
keepalive 16;
}
server {
...
location /http/ {
proxy_pass http://http_backend;
proxy_http_version 1.1;
proxy_set_header Connection "";
...
}
}
For HTTP, the proxy_http_version directive should be set to “1.1” and the “Connection” header field should be cleared keepalive 保存在每个 worker 进程缓存中的到上游服务器的空闲
keepalive 连接数。官方的说法是尽可能的小,不要超过后端的最大连接数,防止后端服务不能承载更多的连接 官方建议将该参数设置为 upstream{} 块中列出的服务器数量的两倍
- 相关参数
keepalive_requests number;
# 通过One keepalive connection的最大请求数,超过这个数,这个连接关闭。有利于单连接的内存释放,不建议配置太大
# 如果后端服务也开启了keepalive,这个值需要小于后端服务的maxkeepalive_request,否则会导致nginx触发502
# 1.19.10之前默认值100,之后版本默认1000
keepalive_time time;
#1.19.10开始新增参数,默认值1h,单个连接在1小时内没达到keepalive_requests,连接也会关闭,指的是非空闲的连接
keepalive_timeout timeout;
# Sets a timeout during which an idle keepalive connection to an upstream server will stay open.空闲连接最长保留时间。
# 如果后端服务开启了keepalive,这里的timeout应该小于后端服务的timeout,否则会导致nginx触发502,因为后端先超时关闭连接了。
nginx请求错误重传
Syntax: proxy_next_upstream error | timeout | invalid_header | http_500 | http_502 | http_503 | http_504 | http_403 | http_404 | http_429 | non_idempotent | off ...;
Default:
proxy_next_upstream error timeout;
# 一个请求,应该被转发到下一个节点的场景
# error: an error occurred while establishing a connection with the server, passing a request to it, or reading the response header;发生在连接、请求、读取响应过程中的任何错误
# timeout: a timeout has occurred while establishing a connection with the server, passing a request to it, or reading the response header;发生在连接,请求,读取响应任何过程的超时
# non_idempotent(非幂等):默认非幂等方法(POST, LOCK, PATCH)不会将请求转发到另一台server,除非启用这个参数
# off 关闭请求错误重传
- 相关参数
Syntax: proxy_next_upstream_tries number;
Default:
proxy_next_upstream_tries 0;
Context: http, server, location
This directive appeared in version 1.7.5.
# 限制重试次数,0代表关闭限制,一直重试
参数延伸
- proxy_buffering off 指令
NGINX 默认启用代理缓冲(proxy_buffering 指令设置为 on)。代理缓冲意味着 NGINX 将来自服务器的响应存储在内部缓冲区中,并且在整个响应被缓冲之后才开始向客户端发送数据。缓冲有助于优化慢速客户端的性能 —— 因为 NGINX 缓冲响应的时间与客户端检索所有响应的时间一样长,代理服务器可以尽可能快地返回响应,然后返回到可用的状态以响应其他请求。因此proxy_buffering 不能改成off
nginx流量控制
1. nginx请求速率限制
- (1)limit_req 模块
http{
limit_req_zone $binary_remote_addr zone=ip_limit:20m rate=5r/s;
limit_req_log_level error;
limit_req_status 429;
server{
location / {
limit_req zone=ip_limit;
proxy_pass http://web;
}
}
}
limit_req 是 Nginx 常用的限速的模块,上图是一个简单的配置,它基于来源 IP 作为唯一的 Key,针对某个唯一的来源 IP 做速率控制,这里的速率控制配置是 5r/s( 1 秒内允许 5 个请求进来),基于这个模块的实现,再解释一下 5r/s,即每隔 200ms 能够允许进来一个请求,每个请求的间隔必须大于 200ms,如果小于 200ms 它就会帮你拒绝。
- (2) brust 功能参数
limit_req_zone $binary_remote_addr zone=ip_limit:20m rate=5r/s brust=4;
limit_req 模块中的一个功能参数 brust(突发),为了方便演示,这里设置 brust=4,表示在超过限制速率 5r/s 的时候,同时至多允许额外有 4 个请求排队等候,待平均速率回归正常后,队列前面的请求会优先被处理。在已经存在 4 个请求同时等候的情况下,此时“立刻”过来的请求就会被拒绝
- (3) nodelay 功能参数
limit_req_zone $binary_remote_addr zone=ip_limit:20m rate=5r/s brust=4 nodelay;
limit_req 模块引入了 nodelay 的功能参数,配合 brust 参数使用。nodelay 参数配合 brust=4 就可以使得突发时需要等待的请求立即得到处理,与此同时,模拟一个插槽个数为 4 的“令牌”队列(桶)。从抽象的角度描述下这个过程,该“令牌”桶会每隔 200ms 释放一个“令牌”,空出的槽位等待新的“令牌”进来,若桶槽位被填满,随后突发的请求就会被拒绝。
总结,在这个模式下,在控制请求速率的同时,允许了一定程度的突发,并且这些突发的请求由于不需要排队,它能够立即得到处理,改善了延迟体验。
- (4)delay 功能参数
支持 delay=number 和 brust=number 参数配合使用。在有些特定场景下,我们既需要保障正常的少量关联资源能够快速地加载,同时也需要对于突发请求及时地进行限制,而 delay 参数能更精细地来控制这类限制效果。
2、Nginx 并发连接数限制
http{
limit_conn_zone $binary_remote_addr zone=ip_count:20m;
server{
location / {
limit_conn ip_count 1;
proxy_pass http://web;
}
}
}
# 20m nginx worker间共享内存大小
3、Nginx 下载带宽限制
location /download/ {
limit_rate_after 500k;
limit_rate 20k;
}
在 ngx_http_core_module 模块里面有 limit_rate_after 和 limit_rate 参数,这个是下载带宽限制。如上图,意思是在下载完前面 500KB 数据后,对接下来的数据以每秒 20KB 速度进行限制,这个在文件下载、视频播放等业务场景中应用比较多,可以避免不必要的浪费。