https://www.cnblogs.com/liufarui/p/11075630.html

·【场景描述】

HTTP1.1之后,HTTP协议支持持久连接,也就是长连接,优点在于在一个TCP连接上可以传送多个HTTP请求和响应,减少了建立和关闭连接消耗和延迟

如果我们使用了nginx去作为反向代理或者负载均衡,从客户端过来的长连接请求就会被转换成短连接发送给服务器端。

为了支持长连接,我们需要在nginx服务器上做一些配置。

·【要求】

使用nginx时,想要做到长连接,我们必须做到以下两点:

  1. 从client到nginx是长连接
  2. 从nginx到server是长连接

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

·【保持和 Client 的长连接】

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

  1. Client发送过来的请求携带"keep-alive"header
  2. 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连接 (即使此时keep alive已经在 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状态的连接。

第一种情况:

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

4. 第0.3s的时候,我们只有500个请求收到,有500个请求因为网络延迟等原因没有进来

这个时候,Nginx检测到连接池中有500个idle状态的连接,就直接关闭了(500-10)个连接

5. 第0.4s的时候,我们收到了1500个请求,但是现在池里面只有(500+10)个连接,所以Nginx不得不重新建立了(1500-510)个连接。

如果在第4步的时候,没有关闭那490个连接的话,只需要重新建立500个连接。

第二种情况:

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

4. 第0.3s的时候,我们一共有1500个请求收到

但是池里面只有1000个连接,这个时候,Nginx又创建了500个连接,一共1500个连接

5. 第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/

[转帖]nginx反向代理时保持长连接的更多相关文章

  1. nginx反向代理时保持长连接

    ·[场景描述] HTTP1.1之后,HTTP协议支持持久连接,也就是长连接,优点在于在一个TCP连接上可以传送多个HTTP请求和响应,减少了建立和关闭连接的消耗和延迟. 如果我们使用了nginx去作为 ...

  2. nginx 反向代理时丢失端口的解决方案

        今天,配置nginx反向代理时遇到一个问题,当设置nginx监听80端口时转发请求没有问题.但一旦设置为监听其他端口,就一直跳转不正常:如,访问欢迎页面时应该是重定向到登录页面,在这个重定向的 ...

  3. nginx 反向代理时丢失端口的解决方案(转)

    今天,配置nginx反向代理时遇到一个问题,当设置nginx监听80端口时转发请求没有问题.但一旦设置为监听其他端口,就一直跳转不正常:如,访问欢迎页面时应该是重定向到登录页面,在这个重定向的过程中端 ...

  4. nginx反向代理时有无”/”的辨析

    nginx反向代理是日常使用nginx时最常用到的功能之一.在配置url的过程中,“/”的有无经常是影响我们配置成功的关键,也是困扰我们的问题所在.在此,结合实际例子,作简要辨析. 场景一:利用根目录 ...

  5. 使用nginx反向代理时,如何正确获取到用户的真实ip

    在记录日志的的时候,获取用户的信息,比如用户的ip,浏览器等等信息是十分重要的. 但是在使用nginx反向代理的时候,可能经过转发无法获取到用户的真实的ip, 在此情况下需要配置nginx,让其在转发 ...

  6. Nginx 反向代理时获取用户的真实 IP

    在平时我们开发后端程序的过程中,应该多多少少都会碰到记录客户端 IP 的场景,例如我之前写过的 APP 用户的一个审计功能,就需要获取用户的 IP 地址:还有广告系统里面,也是需要获取用户的 IP 地 ...

  7. nginx反向代理时配置访问密码

    在有些情况下,我们需要对服务器上的某些资源进行限流或者禁止陌生人访问,我们可以通过nginx配置来对url添加访问密码. 效果如下 nginx 开启访问验证在 nginx 下,提供了 ngx_http ...

  8. Nginx反向代理时tomcat日志获取真实IP

    对于nginx+tomcat这种架构,如果后端tomcat配置保持默认,那么tomcat的访问日志里,记录的就是前端nginx的IP地址,而不是真实的访问IP.因此,需要对nginx.tomcat做如 ...

  9. 如何取得nginx做反向代理时的真实IP?

    1. 编译 对于client -> nginx reverse proxy -> apache, 要想在程序中取得真实的IP,在执行nginx的configure时,必须指定参数" ...

  10. nginx做反向代理时获取真实IP

    原文:http://blog.csdn.net/aquester/article/details/48657395 1. 编译 对于client -> nginx reverse proxy - ...

随机推荐

  1. ElasticSearch之文件描述符的数量

    ElasticSearch在运行过程中,涉及大量文件的打开.关闭.读.写等操作.因此当ElasticSearch进程的文件描述符数量不足时可能导致丢失数据等故障现象. 因此为保障ElasticSear ...

  2. IntelliJ IDEA官方宣布中文汉化包正式发布-intellijidea-guan-fang-xuan-bu-zhong-wen-han-hua-bao-zheng-shi-fa-bu

    title: IntelliJ IDEA官方宣布中文汉化包正式发布 date: 2021-07-27 16:42:21.823 updated: 2021-12-26 17:43:12.204 url ...

  3. Sliver 二开准备

    cs被杀麻了,最近打算看看一下sliver的源码进行一下二开,这篇是记录遇到的一些问题 编译sliver Windows下 官方说用MingW,但是我自己用他带的make不行, ​​ ‍ 下载make ...

  4. DVWA Brute Force(暴力破解)全等级

    Brute Force(暴力破解) 目录: Brute Force(暴力破解) 1.Low 2.Medium 3.High 方法1--Burp爆破 方法2--Python脚本爆破 4.Impossib ...

  5. 用Python写一个简单的TCP客户端和服务端

    在渗透测试过程中,经常需要创建一个TCP客户端,用来测试服务.发送数据.进行 fuzz 等等.如果黑客潜伏在某大型企业的内网环境中,则不太可能直接获取网络工具或编译器,有时甚至连复制/粘贴或者连接外网 ...

  6. 神经网络优化篇:梯度检验应用的注意事项(Gradient Checking Implementation Notes)

    梯度检验应用的注意事项 分享一些关于如何在神经网络实施梯度检验的实用技巧和注意事项. 首先,不要在训练中使用梯度检验,它只用于调试.意思是,计算所有\(i\)值的\(d\theta_{\text{ap ...

  7. uni-app+vue3+ts项目搭建完整流程

    项目代码同步更新至码云 uni-vue3-ts-template 开发前准备 利用 uni-app 开发,有两种方法: 通过 HBuilderX 创建(需安装 HBuilderX 编辑器) 通过命令行 ...

  8. Linux SNMP监控配置

    1, 安装SNMP服务 [root@zlm log]# yum -y install net-snmp net-snmp-utils 2, 编辑SNMP配置文件[root@zlm log]# vim ...

  9. Mybatis源码5 StatementHandler ,ParameterHandler

    Mybatis5 StatementHandler ,ParameterHandler 一丶概述 前面我们总结了SqlSession--->CachingExecutor--->BaseE ...

  10. Feign传递参数

    传递单个参数 1客户端 @RequestMapping("/one") public BaseResp one(@RequestParam("id") Inte ...