nginx反向代理时保持长连接

更新日期: 2021-06-02阅读: 1.3k标签: nginx

nginx反向代理,如何通过配置支持从client到server的长连接?
如何避免nginx线程池内线程数反复震荡导致性能不稳定的问题?

深入了解nginx,get到nginx的一些性能优化方向。除了了解如何保持长连接,也通过本案例学习到开源中间件的一些常用定位思路和优化方法。


场景描述

HTTP1.1之后,HTTP协议支持持久连接,也就是长连接,优点在于在一个TCP连接上可以传送多个HTTP请求和响应,减少了建立和关闭连接的消耗和延迟。如果我们使用了nginx去作为反向代理或者负载均衡,从客户端过来的长连接请求就会被转换成短连接发送给服务器端。为了支持长连接,我们需要在nginx服务器上做一些配置。


要求

到长连接,我们必须做到以下两点:

i.从client到nginx是长连接
ii.从nginx到server是长连接

对于客户端而言,nginx其实扮演着server的角色,反之,之于server,nginx就是一个client。


保持和Client的长连接

我们要想做到Client与Nginx之间保持长连接,需要:

i.Client发送过来的请求携带“keep-alive”header。
ii.Nginx设置支持keep-alive。


HTTP配置

默认情况下,nginx已经开启了对client连接的keepalive 支持。对于特殊场景,可以调整相关参数。

http {
keepalive_timeout 120s; #客户端链接超时时间。为0的时候禁用长连接。
keepalive_requests 10000; #在一个长连接上可以服务的最大请求数目。
#当达到最大请求数目且所有已有请求结束后,连接被关闭。
#默认值为100
}

大多数情况下,keepalive_requests = 100也够用,但是对于 QPS 较高的场景,非常有必要加大这个参数,以避免出现大量连接被生成再抛弃的情况,减少TIME_WAIT。QPS=10000 时,客户端每秒发送 10000 个请求 (通常建立有多个长连接),每个连接只能最多跑 100 次请求,意味着平均每秒钟就会有 100 个长连接因此被 nginx 关闭。同样意味着为了保持 QPS,客户端不得不每秒中重新新建 100 个连接。因此,如果用netstat命令看客户端机器,就会发现有大量的TIME_WAIT的socket连接 (即使此时keepalive已经在 Client 和 NGINX 之间生效)。


保持和Server的长连接

想让Nginx和Server之间维持长连接,最朴素的设置如下:

http {
upstream backend {
server 192.168.0.1:8080 weight=1 max_fails=2 fail_timeout=30s;
server 192.168.0.2:8080 weight=1 max_fails=2 fail_timeout=30s;
keepalive 300; // 这个很重要!
}
server {
listen 8080 default_server;
server_name "";

location / {
proxy_pass http://backend;
proxy_http_version 1.1;// 设置http版本为1.1
proxy_set_header Connection ""; //设置
Connection为长连接(默认为no)}
}
}
}

upstream配置

upstream中,有一个参数特别的重要,就是 keepalive 。 这个参数和之前http里面的 keepalive_timeout 不一样。 这个参数的含义是,连接池里面最大的空闲连接数量。

不理解?没关系,我们来举个例子:

场景:

有一个HTTP服务,作为upstream服务器接收请求,响应时间为100毫秒。 要求性能达到10000 QPS,我们需要在nginx与upstream服务器之间建立大概1000条HTTP请求。(1000/0.1s=10000)

最优情况:

假设请求非常的均匀平稳,每一个请求都是100ms,请求结束会被马上放入连接池并置为idle(空闲)状态。

我们以0.1s为单位:

1. 我们现在keepalive的值设置为10,每0.1s钟有1000个连接。
2. 第0.1s的时候,我们一共有1000个请求收到并释放。
3. 第0.2s的时候,我们又来了1000个请求,在0.2s结束的时候释放。

请求和应答都比较均匀,0.1s释放的连接正好够用,不需要建立新连接,且连接池中没有idle状态的连接。

第一种情况:

应答非常平稳,但是请求不平稳 的时候

1.第0.3s的时候,我们只有500个请求收到,有500个请求因为网络延迟等原因没有进来。 这个时候,Nginx检测到连接池中有500个idle状态的连接,就直接关闭了(500-10)个连接。

2.第0.4s的时候,我们收到了1500个请求,但是现在池里面只有(500+10)个连接,所以Nginx不得不重新建立了(1500-510)个连接。 如果在第4步的时候,没有关闭那490个连接的话,只需要重新建立500个连接。

第二种情况:

请求非常平稳,但是应答不平稳 的时候

1. 第0.3s的时候,我们一共有1500个请求收到。 但是池里面只有1000个连接,这个时候,Nginx又创建了500个连接,一共1500个连接。

2.第0.3s的时候,第0.3s的连接全部被释放,我们收到了500个请求。  Nginx检测到池里面有1000个idle状态的连接,所以不得不释放了(1000-10)个连接。造成连接数量反复震荡的一个推手,就是这个keepalive 这个最大空闲连接数。上面的两种情况说的都是 keepalive设置的不合理导致Nginx有多次释放与创建连接的过程,造成资源浪费。

keepalive 这个参数设置一定要小心,尤其是对于 QPS 要求比较高或者网络环境不稳定的场景,一般根据 QPS 值和 平均响应时间能大致推算出需要的长连接数量。 然后将keepalive设置为长连接数量的10%到30%。

location配置

http {
server {
location / {
proxy_pass http://backend;
proxy_http_version 1.1;// 设置http版本为1.1
proxy_set_header Connection ""; //设置
Connection为长连接(默认为no)
}
}
}

HTTP 协议中对长连接的支持是从 1.1 版本之后才有的,因此最好通过proxy_http_version 指令设置为 1.1。 HTTP1.0不支持keepalive特性,当没有使用HTTP1.1的时候,后端服务会返回101错误,然后断开连接。而“Connection” header 可以选择被清理,这样即便是 Client 和 Nginx 之间是短连接,Nginx 和 upstream 之间也是可以开启长连接的。

另外一种高级方式

http {
map $http_upgrade $connection_upgrade {
default upgrade;
'' close;
}

upstream backend {
server 192.168.0.1:8080 weight=1 max_fails=2 fail_timeout=30s;
server 192.168.0.2:8080 weight=1 max_fails=2 fail_timeout=30s;
keepalive 300;
}

server {
listen 8080 default_server;
server_name "";
location / {
proxy_pass http://backend;

proxy_connect_timeout 15; #与upstream server的连接超时时间(没有单位,最大不可以超过75s)
proxy_read_timeout 60s; #nginx会等待多长时间来获得请求的响应
proxy_send_timeout 12s; #发送请求给upstream服务器的超时时间

proxy_http_version 1.1;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection
$connection_upgrade;
}
}
}

http里面的map的作用是: 让转发到代理服务器的 "Connection" 头字段的值,取决于客户端请求头的"Upgrade" 字段值。

如果$http_upgrade没有匹配,那 "Connection" 头字段的值会是upgrade。

如果$http_upgrade为空字符串的话,那 "Connection" 头字段的值会是 close。

【补充】

NGINX支持WebSocket。 对于NGINX将升级请求从客户端发送到后台服务器,必须明确设置Upgrade和Connection标题。这也算是上面情况所非常常用的场景。HTTP的Upgrade协议头机制用于将连接从HTTP连接升级到WebSocket连接,Upgrade机制使用了Upgrade协议头和Connection协议头。为了让Nginx可以将来自客户端的Upgrade请求发送到后端服务器,Upgrade和Connection的头信息必须被显式的设置。

【注意】

在nginx的配置文件中,如果当前模块中没有proxy_set_header的设置,则会从上级别继承配置。 继承顺序为:http, server, location。如果在下一层使用proxy_set_header修改了header的值,则所有的header值都可能会发生变化,之前继承的所有配置将会被丢弃。所以,尽量在同一个地方进行proxy_set_header,否则可能会有别的问题。

【参考】

Nginx中文官方文档:  http://www.nginx.cn/doc/

测试参考文档:  https://www.lijiaocn.com/ 问题/2019/05/08/nginx-ingress-keep-alive-not-work.html

keep-alive参考文档: https://wglee.org/2018/12/02/nginx-keepalive/

原文来自:https://mp.weixin.qq.com/s/Q_sI-NGybro9lwoZtyQkpw


链接: https://www.fly63.com/article/detial/10377

Nginx常用配置--nginx之proxy_pass代理后端https请求完全解析

前提条件:nginx源码或nginx plus源码、一个代理服务器或一个代理服务器组、SSL证书和私钥,你可以从一个可信任证书颁发机构(CA)购买一个服务器证书,或者你可以使用openssl库创建一个内部CA签名

nginx:支持https

查看nginx模块,如果看到with-ssl那就是有的。注册ssl证书并下载,配置nginx就比如说,还没有配置https前你配置了80,那么你http://域名/直接默认访问80端口,那么一样的

nginx做http向https的自动跳转

首先让nginx服务器监听两个端口,分别是80端口和443端口,注意监听443端口的时候需要配置证书的认证以及创建自签名证书!关于证书的认证的以及创建自签名的证书,nginx的配置如下,只给出了两个server的配置,可以直接复制到http块中。

Nginx配置https和wss

常见的服务器有三种:Nginx、IIS、Apache,都可以配置https,但是没必要全部知道,因为Nginx可以起到反向代理的作用,会配置Nginx就足够了。在/etc/nginx/conf.d目录下新建https.conf

nginx加速_开启Gzip/文件做缓存

开启Gzip:给Nginx上 ngx_http_gzip_module 这个模块,用 nginx -V 命令查看 configure arguments 是否有,没有的话需要编译加载这个模块;给文件做缓存:图片文件,字体文件,js和css都是些可以用来缓存的文件

nginx和php-fpm的进程启停重载总结

ginx和php-fpm对于-USR2、-HUP信号的处理方式不一样:TERM, INT(快速退出,当前的请求不执行完成就退出),QUIT (优雅退出,执行完当前的请求后退出)

Nginx解析PHP的原理 | CGI、FastCGI及php-fpm的关系

php-fpm采用master/worker架构设计, master进程负责CGI、PHP公共环境的初始化及事件监听操作。worker进程负责请求的处理功能。在worker进程处理请求时,无需再次初始化PHP运行环境,这也是php-fpm性能优异的原因之一

Nginx 禁止某 IP 访问

总有一些不怀好意的人来访问我的网站,而且频率还很高,所以就用简单的方式禁止访问,就用 Nginx 来实现。想要添加黑名单,只要在 blocksip.conf 中添加 IP ,然后 reload 即可。

Nginx服务器 之反向代理与负载均衡

客户端就可以通过请求代理服务器,获取想要的资源,但客户端并不知道给他资源的是哪个服务器。这种方式就是反向代理。当一台服务器的单位时间内的访问量越大的时候,服务器的压力会越大。我们通常通过负载均衡的方式来分担服务器的压力。

前端如何通过Nginx代理做到跨域访问API接口

Nginx作为反向代理服务器,就是把http请求转发到另一个或者一些服务器上。通过把本地一个url前缀映射到要跨域访问的web服务器上,就可以实现跨域访问。对于浏览器来说,访问的就是同源服务器上的一个url

点击更多...

内容以共享、参考、研究为目的,不存在任何商业目的。其版权属原作者所有,如有侵权或违规,请与小编联系!情况属实本人将予以删除!