Nginx反向代理配置

时间:2022-05-23 zhangxm_qz 人气:0

本文旨在测试 nginx对 http服务 https 服务的代理方式。

部署测试 http服务

准备测试服务程序 gintest 并启动如下

[root@localhost ~]# sudo nohup ./gintest 9000 &
[1] 4229
[root@localhost ~]# nohup: 忽略输入并把输出追加到"nohup.out"

[root@localhost ~]# 
[root@localhost ~]# curl http:localhost:9000
curl: (6) Could not resolve host: http:localhost; 未知的错误
[root@localhost ~]# curl http://localhost:9000
{"message":"测试程序,服务器ip：192.168.90.9,端口：9080"}[

nginx反向代理 http服务

安装 nginx 并修改配置文件，对 web服务进行代理如下

server {
        listen       80;
        server_name  localhost;
        #charset koi8-r;
        #access_log  logs/host.access.log  main;
        location / {
            proxy_pass http://192.168.90.9:9000;
            root   html;
            index  index.html index.htm;
        }

        #error_page  404              /404.html;
        # redirect server error pages to the static page /50x.html
        #
        error_page   500 502 503 504  /50x.html;
        location = /50x.html {
            root   html;
        }

启动 nginx 并访问，结果如下代理成功

nginx 通过 https反向代理 http服务

使用 https 服务需要安装http_ssl_module 否则会报错『ssl parameter requires ngx_http_ssl_module』

重新编译安装 nginx

nginx源码根目录执行如下命令，重新编译，输出目录保持不变

 ./configure   --with-http_stub_status_module --with-http_ssl_module
 
 make && make install 安装

成功后可以看到我们的 nginx 目录下已经安装了新版本的 nginx

配置 nginx

提前准备好一套证书和私钥， tls.crt tls.key

nginx http 模块配置中，增加如下配置

  server {
        listen       443 ssl;
        server_name  www.mytest.com;

        ssl_certificate      /root/tls.crt;
        ssl_certificate_key  /root/tls.key;
        ssl_session_cache    shared:SSL:1m;
        ssl_session_timeout  5m;

        ssl_ciphers  HIGH:!aNULL:!MD5;
        ssl_prefer_server_ciphers  on;

        location / {
            proxy_pass http://192.168.90.9:9000;
            root   html;
            index  index.html index.htm;
        }
    }

重新加载配置

[root@localhost conf]# ../sbin/nginx -s   reload

访问测试

通过https访问应用成功，如下：

这种情况下需要将应用的证书配置到nginx，如果 nginx代理了很多应用，每个应用证书不同，那么需要配置很多证书。

nginx提供了 stream 模块用于 tcp/udp 请求直接转发后台服务器处理，不用配置证书。如下

Nginx Stream模块负载均衡测试

准备测试用 https服务

准备一个 java https 服务

部署 tomcat及 web示例应用

生成tomcat 证书

[root@mysql tomcat]# keytool -genkey -v -alias tomcat -keyalg RSA -keystore /root/tomcat/certs/tomcat.keystore -validity 365
输入密钥库口令:  
再次输入新口令: 
您的名字与姓氏是什么?
  [Unknown]:  zhang
您的组织单位名称是什么?
  [Unknown]:  pcitc
您的组织名称是什么?
  [Unknown]:  ptitc
您所在的城市或区域名称是什么?
  [Unknown]:  bj
您所在的省/市/自治区名称是什么?
  [Unknown]:  bj
该单位的双字母国家/地区代码是什么?
  [Unknown]:  bj
CN=zhang, OU=pcitc, O=ptitc, L=bj, ST=bj, C=bj是否正确?
  [否]:  y

正在为以下对象生成 2,048 位RSA密钥对和自签名证书 (SHA256withRSA) (有效期为 365 天):
         CN=zhang, OU=pcitc, O=ptitc, L=bj, ST=bj, C=bj
输入 <tomcat> 的密钥口令
        (如果和密钥库口令相同, 按回车):  
[正在存储/root/tomcat/certs/tomcat.keystore]

Warning:
JKS 密钥库使用专用格式。建议使用 "keytool -importkeystore -srckeystore /root/tomcat/certs/tomcat.keystore -destkeystore /root/tomcat/certs/tomcat.keystore -deststoretype pkcs12" 迁移到行业标准格式 PKCS12。
[root@mysql tomcat]# ll certs
总用量 4
-rw-r--r-- 1 root root 2201 3月   3 00:14 tomcat.keystore

配置 tomcat SSL 连接

tomcat 配置文件 server.xml中增加如下内容 :

https服务访问测试

通过 https 访问web服务成功

https://192.168.90.20:8443/testWeb/index.jsp

nginx stream 安装配置

nginx 安装 stream 模块

重新编译安装 nginx

./configure   --with-stream

make && make install

配置 nginx stream

nginx.conf配置文件中增加 stream配置（和 http 模块并列）

访问测试

通过 nginx 443 端口可以在没有配置证书的情况下可以通过 https访问后台的应用。

负载均衡策略

该模块支持的负载均衡策略如下：

Round Robin 轮询– 默认情况下，NGINX 使用 Round Robin 算法对流量进行负载平衡，将其按顺序定调用上游组中的服务器。因为是默认方法，所以没有 round‑robin 指令不配置即为轮询。

Least Connections 最少连接数：( least_conn) - NGINX 选择当前活动连接数较少的服务器。

Least Time ( least_time;仅适用于 NGINX Plus ) – 选择具有最低平均延迟和最少活动连接数的服务器。用于计算最低平均延迟的方法取决于 least_time 指令中包含以下哪些参数：

connect – 连接上游服务器的时间

first_byte – 接收第一个数据字节的时间

last_byte – 从服务器接收完整响应的时间

示例如下：

upstream stream_backend {
    least_time first_byte;
    server backend1.example.com:12345;
    server backend2.example.com:12345;
    server backend3.example.com:12346;
}

Hash ( hash) – NGINX 根据用户定义的header选择服务器，例如源 IP 地址 ( $remote_addr)，如下：

upstream stream_backend {
    hash $remote_addr;
    server backend1.example.com:12345;
    server backend2.example.com:12345;
    server backend3.example.com:12346;
}

哈希负载平衡方法常用于保持会话。指定一个 consistent 选项可以使用 ketama 一致性hash算法：

hash $remote_addr consistent;

默认采用轮询算法

nginx stream 中upstream 配置两个后台服务器如下：

upstream testjava{
    server 192.168.90.20:8443;
    server 192.168.90.21:8443;
}
server {
    listen 443;
    proxy_connect_timeout 1s;
    proxy_timeout 3s;
    proxy_pass testjava;
}

进行访问测试两个后台服务器轮流被访问

一致性 hash 算法测试

nginx.conf stream 模块中配置如下

upstream testjava{
    hash $remote_addr consistent;
    server 192.168.90.20:8443;
    server 192.168.90.21:8443;
}

server {
    listen 443;
    proxy_connect_timeout 1s;
    proxy_timeout 3s;
    proxy_pass testjava;
}

多次访问都访问到同一个后台服务器，证明会话保持成功

参考文档：http://www.wjhsh.net/felixzh-p-8696552.html

附：负载均衡四层和七层的区别

1.区别：四层负载，说的是基于IP+端口的负载均衡；七层负载，说的是基于WEB请求，URL等应用信息的负载均衡。同理，还有基于二层和三成的。二层的就是基于MAC地址，二层负载均衡会通过一个虚拟MAC地址接受请求，然后再分配到真实的MAC地址。三层负载就是通过一个虚拟IP地址，然后再分配到真实的IP。四层就是通过虚机的IP+端口接收请求，然后再分配到真实的服务器；七层就是通过虚机主机名或者URL接收请求，再根据一些规则分配到真实的服务器，常见的应用是nginx。

2.所谓的负载均衡，就是根据请求的信息不同，来决定怎么样转发流量。四层负载均衡，就是根据请求的ip+端口，根据设定的规则，将请求转发到后端对应的IP+端口上。七层负载均衡，则是在四层基础上，再去考虑应用层的特征。比如说一个WEB服务器的负载均衡，除了根据IP+80端口来判断之外，还可以根据七层URL，浏览器类别，来决定如何去转发流量。

3.四层交换机主要分析IP层和TCP/UDP层，实现四层流量负载，这种负载不关心七层的应用协议。七层的交换机除了支持四层之外，还要分析应用层，如HTTP协议、URL、cookie等信息。四层常见软件是haproxy，LVS，七层常见软件是nginx。

总结

加载全部内容