nginx在代理到upstream时转换http1.1为http1.0，长连接转为短连接

Posted 2023-06-02 低级知识传播者

nginx在代理到upstream时的默认行为

最近准备用openresty替换nginx，替换的效果当然是需要保证效果和nginx一致，不然可能就会导致线上在用的服务出现问题。

替换成openresty后，在本地进行了一个请求，header如下：

POST /servlet/json HTTP/1.1
Host: 10.80.121.xxx:9900
Connection: keep-alive
Content-Length: 423
Content-Type: application/x-www-form-urlencoded
Cookie: JSESSIONID=abcciHlT1nqAi571RB6Hy
Accept: */*
User-Agent: maios/3.9.0 (iPhone; iOS 13.5.1; Scale/2.00)
Accept-Language: zh-Hans-CN;q=1

Accept-Encoding: gzip, deflate

在经过nginx转发到upstream后，发现请求竟然变了：

POST /servlet/json HTTP/1.0
Host: 10.80.121.xxx
Connection: close
Content-Length: 423
Content-Type: application/x-www-form-urlencoded
Cookie: JSESSIONID=abcciHlT1nqAi571RB6Hy
Accept: */*
User-Agent: maios/3.9.0 (iPhone; iOS 13.5.1; Scale/2.00)
Accept-Language: zh-Hans-CN;q=1
Accept-Encoding: gzip, deflate

主要的变化有两处，一个是版本从1.1变成1.0，另一个是keep-alive变成了close。

一开始，还以为是openresty搞的鬼，结果发现nginx自己也是这样。

背后原因

在nginx文档，http://nginx.org/en/docs/http/ngx_http_proxy_module.html#proxy_http_version，显示：

网上一搜，有相关的文档，里面也有强制使用http1.1的方案：

Mistake 3: Not Enabling Keepalive Connections to Upstream Servers

https://www.nginx.com/blog/avoiding-top-10-nginx-configuration-mistakes/#no-keepalives

upstream 模块

一、upstream 模块简介

(1) Nginx 的负载均衡功能依赖于 ngx_http_upstream_module 模块，所支持的代理方式包括 proxy_pass 、fastcgi_pass 、memcached_pass 等
(2) ngx_http_upstream_module 允许 Nginx 定义一组或多组节点服务器组，使用时可以通过 proxy_pass 代理方式把网站的请求发送到事先定义好的对应 Upstream 组的名字上，具体写法为 "proxy_pass http://www_server_pools" ，其中 www_server_pools 就是一个 Upstream 节点服务器组名字

二、upstream 模块语法

1、基本的 upstream 配置案例

upstream www_server_pools {                    # upstream 是关键词，www_server_pools 是 upstream 集群组的名字
    server 192.168.123.103:80 weight=5;        # server 是关键词，后面接域名或IP
    server 192.168.123.104:80 weight=10;       # weight 是权重，数值越大被分配的请求越多
    server 192.168.123.105:80 weight=5;
}

2、完整的 upstream 配置案例

upstream blog_server_pools {
    server 192.168.123.103:80
    server 192.168.123.104:80 weight=1 max_fails=1 fail_timeout=10s;          # max_fails=1 表示 Nginx 尝试连接后端主机失败的次数
    server 192.168.123.105:80 weight=1 max_fails=2 fail_timeout=20s backup;   # fail_timeout 表示在 max_fails 失败次数后，距离下次检查的间隔时间
    server 192.168.123.105:80 weight=1 max_fails=2 fail_timeout=20s backup;   # backup 表示备份，当前面的 RS 都失败后会自动启用热备 RS
    server 192.168.123.106:80 down;　　　　　　　　　　　　　　　　　　　　　　　　  # down 表示该 RS 永不可用
}

3、使用域名或 socket 的 upstream 配置案例

upstream backend {
    server backend1.example.com weight=5;
    server backend2.example.com:8080;      # 域名加端口，server 后面如果接域名，需要内网有 DNS 服务器或在负载均衡器的 hosts 文件做域名解析
    server unix:/tmp/backend3;             # 指定 socket 文件
}

 

三、upstream 模块调度算法

1、分类

(1) 调度算法分为静态调度算法和动态调度算法
(2) 静态调度算法即负载均衡器根据自身规定的规则进行分配，不考虑后端节点服务器的情况，静态调度算法有 rr 、wrr 、ip_hash 等
(3) 动态调度算法即负载均衡器会根据后端节点的当前状态来决定是否分发请求，动态调度算法有 least_conn 、fair 等

2、静态调度算法

(1) rr ：默认调度算法，按客户端请求顺序把客户端的请求逐一分配到不同的后端节点服务器
(2) wrr ：权重轮询算法，按比例进行分配，可以根据服务器的配置和性能指定权重值大小
(3) ip_hash ：每个请求按客户端 IP 的 hash 结果分配，当新的请求到达时，先将其客户端 IP 通过哈希算法哈希出一个值，在随后的客户端请求中，客户 IP 的哈希值只要相同，就会分配至同一台服务器，该调度算法可以解决动态网页的 session 共享问题，当使用该算法时，后端服务器再负载均衡调度中的状态不能有 weight 和 backup ，即使有也不会生效，配置实例

3、动态调度算法

(1) fair ：此算法会根据后端节点服务器的响应时间来分配请求，响应时间短的优先分配，如果需要使用这种调度算法，必须安装 Nginx 的 upstream_fair 模块，配置实例
(2) least_conn ：该算法会根据后端节点的连接数来决定分配情况，哪个机器连接数少就分发给哪个
(3) url_hash ：与 ip_hash 类似，会根据访问 URL 的 hash 结果来分配请求，如果要使用这种调度算法，必须安装 Nginx 的 hash 模块，配置实例
(4) 一致性 hash 算法：一般用于代理后端业务为缓存服务的场景，通过将用户请求的 URI 或指定的字符串进行计算，然后调度到后端的服务器上，此后任何用户查找同一个 URI 或者指定字符串都会被调度到这一台服务器上，配置实例