nginx 反向代理与缓存功能

一理论说明

（一）反向代理简介

反向代理：reverse proxy，指的是代理外网用户的请求到内部的指定的服务器，并将数据返回给用户的一种方式，这是用的比较多的一种方式。

即代理服务机

Nginx 除了可以在企业提供高性能的web服务之外，另外还可以将 nginx 本身不具备的请求通过某种预定义的协议转发至其它服务器处理，不同的协议就是Nginx服务器与其他服务器进行通信的一种规范，主要在不同的场景使用以下模块实现不同的功能

（二）相关模块

ngx_http_proxy_module	#将客户端的请求以http协议转发至指定服务器进行处理
ngx_http_upstream_module	#用于定义为proxy_pass,fastcgi_pass,uwsgi_pass等指令引用的后端服务器分组（负载均衡）
ngx_stream_proxy_module	#将客户端的请求以tcp协议转发至指定服务器处理
ngx_http_fastcgi_module	#将客户端对php的请求以fastcgi协议转发至指定服务器助理（语言不同接口不同）
ngx_http_uwsgi_module	#将客户端对Python的请求以uwsgi协议转发至指定服务器处理（语言不同接口不同）

（三）架构图

1，反向代理

2，同构代理异构代理

同构协议：客户机服务机协议一样

异构：不一样

二单台代理

（一）具体步骤

实验环境：66是代理服务器 77 是真实服务器

66 配置文件：

表示开启代理真服务机是77

访问 66 也能看到77 真服务器的内容

（二）出现504

1，出现504 的情况

在真实服务器上做防火墙规则
iptables -A INPUT -s 192.168.91.66 -j DROP
客户端再次访问会出现504网关超时（有可能只是处理时间久，服务器不一定挂了），时间较长1分钟，没有定义代理超时时间

2， 504 解释

drop 丢弃真实服务机一直丢弃代理服务机

代理服务机会以为真实服务机没收到会一直发

大概持续一分钟超时然后返回504

（三）出现502

1，出现502 的情况

在真实服务器上做防火墙规则

iptables -A INPUT -s 192.168.91.66 -j REJECT
客户端再次访问会出现502，一般出现502 代表后端真实服务器挂了

2,502 解释

网关不可达 reject 拒绝

基本判定真实服务机挂了

三针对某个uri 进行反向代理

（一）实验步骤

66代理服务机：

访问66/api 等于访问真是服务器77/api

77 真实服务机主页面内容：

客户机访问：

（二）注意加/ 和不加/ 区别

http://192.168.91.77 不加/ 是将location上的url 追加在后面

http://192.168.91.77/ 加上/ 是将location上的url 替换后proxy配置里的连接

即访问真实服务机的主页面

四，反向代理缓存功能

（一）作用

加快速度

万一真实服务器挂了救急

（二）语法结构

1，主配置文件

在http配置定义缓存信息

proxy_cache_path /var/cache/nginx/proxy_cache	#定义缓存保存路径，proxy_cache会自动创建
levels=1:2:2	#定义缓存目录结构层次，1:2:2可以生成2^4x2^8x2^8=2^20=1048576个目录
keys_zone=proxycache:20m	#指内存中缓存的大小，主要用于存放key和metadata（如：使用次数）,一般1M可存放8000个左右的key
inactive=120s	#缓存有效时间
max_size=10g;	#最大磁盘占用空间，磁盘存入文件内容的缓存空间最大值

2，子配置文件

#调用缓存功能，需要定义在相应的配置段，如server{...};或者location等

proxy_cache zone_name | off; 默认off

#指明调用的缓存，或关闭缓存机制;

#zone_name 表示缓存的名称.需要由proxy_cache_path事先定义

proxy_cache_key $request_uri;

#对指定的数据进行MD5的运算做为缓存的key （理解为记住路径）

proxy_cache_valid 200 302 301 10m;

proxy_cache_valid 401 1m;

#指定的状态码返回的数据缓存多长时间

对状态码不同缓存时间不同 200 302 正常访问时间长

404 不正常

proxy_cache_valid any 1m;

#除指定的状态码返回的数据以外的缓存多长时间,必须设置,否则不会缓存

不是上面的状态码同一缓存1分钟

#默认是off

#在被代理的后端服务器出现哪种情况下，可直接使用过期的缓存响应客户端

#示例
proxy_cache_use_stale error http_502 http_503;
缓存过期也能使用

proxy_cache_methods GET | HEAD | POST ...;

#对哪些客户端请求方法对应的响应进行缓存，GET和HEAD方法总是被缓存

对方法缓存

（三）清理缓存

缓存不会自动清理需要手动清理

方法1: rm -rf 缓存目录
方法2: 第三方扩展模块ngx_cache_purge

注意：在rm -rf proxycache 后需要nginx -s reload 再次生成proxycache文件夹

（四）示例

66 代理服务机配置文件

当客户机访问代理服务器时可以看到生成缓存文件

当我们关闭真实服务器时，发现客户机仍能看到内容

五， IP 透传

（一）一级代理

1，实验环境

66 是代理服务器 99是真实服务器

目前99 服务器查看访问日志是看不到真实ip的

只能看到66 代理服务器的ip

2, 步骤

第一步

99 真实服务器需要将日志中的“referer” 开启（yum安装的nginx 默认开启编译安装的，需要手动开启）

如果真实服务器是 httpd 在主配置文件改如图所示：

第二步

66 代理服务器需要改配置文件： proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; #添加客户端IP和反向代理服务器IP到请求报文头部

第三步：

此时我们再去让客户机访问查看99真实服务机的日志发现可以看到客户机ip 为11

（二）多级代理

1，架构

2，步骤

步骤与一级代理一致

2.1

客户机不需要做配置

2.2

客户机访问代理1 服务器等于访问代理服务器2

代理1 在主配置文件加 proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; #添加客户端IP和反向代理服务器IP到请求报文头部

2.3

代理1服务器访问代理服务器2 等于访问真实服务器

代理2 在主配置文件加 proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; #添加客户端IP和反向代理服务器IP到请求报文头部

2.4

真实服务器改日志格式

六，http反向代理负载均衡

Nginx 可以基于ngx_http_upstream_module模块提供服务器分组转发、权重分配、状态监测、调度算法等高级功能

官方文档： https://nginx.org/en/docs/http/ngx_http_up

简单理解就是一台代理服务器后面假如有两台真实服务器，怎么最合理分配任务

（一）模块

模块是默认安装的

（二）语法格式

#自定义一组服务器，配置在http块内
upstream   web { server 192.168.91.100    调度算法server 192.168.91.101
}location  / {
pass_proxy  http://web/
}#示例
upstream backend {server backend1.example.com weight=5;     权重server 127.0.0.1:8080       max_fails=3  fail_timeout=30s;server unix:/tmp/backend3;server backup1.example.com backup;
}

server address [parameters];
#配置一个后端web服务器，配置在upstream内，至少要有一个server服务器配置。
#server支持的parameters如下：
weight=number #设置权重，默认为1,实现类似于LVS中的WRR,WLC等
max_conns=number  #给当前后端server设置最大活动链接数，默认为0表示没有限制
max_fails=number  #后端服务器的下线条件,当客户端访问时,对本次调度选中的后端服务器连续进行检测多少次,如果都失败就标记为不可用,默认为1次,当客户端访问时,才会利用TCP触发对探测后端服务器健康性检查,而非周期性的探测
fail_timeout=time #后端服务器的上线条件,对已经检测到处于不可用的后端服务器,每隔此时间间隔再次进行检测是否恢复可用，如果发现可用,则将后端服务器参与调度,默认为10秒
backup  #设置为备份服务器，当所有后端服务器不可用时,才会启用此备用服务器 sorry server   自己不能转自己
down    #标记为down状态
resolve #当server定义的是主机名的时候，当A记录发生变化会自动应用新IP而不用重启Nginxhash KEY [consistent];
#基于指定请求报文中首部字段或者URI等key做hash计算，使consistent参数，将使用ketama一致性www.kgc.com/test1   hash  test1      103  hash算法，适用于后端是Cache服务器（如varnish）时使用，consistent定义使用一致性hash运算，一
致性hash基于取模运算
hash $request_uri consistent; #基于用户请求的uri做hash
hash $cookie_sessionid  #基于cookie中的sessionid这个key进行hash调度,实现会话绑定ip_hash;
#源地址hash调度方法，基于的客户端的remote_addr(源地址IPv4的前24位或整个IPv6地址)做hash计算，以实现会话保持least_conn;
#最少连接调度算法，优先将客户端请求调度到当前连接最少的后端服务器,相当于LVS中的WLC

（三）负载均衡实验示例

1，实验环境

66为代理服务器 77,99 为两台真实服务器

2，步骤

66 代理服务器的主配置文件：

3，实验结果

此为轮询算法一人一次总共7种算法，下面依次介绍

（四）健康性检查

1，健康性检查

nginx 非常聪明，把77停了只会去99

原因：在轮询前会三次握手握不到就不发过去

2，实验

关闭99 真实服务器，发现代理服务器只会去到77 真实服务器

（五）调度算法

轮询加权轮询 ip hash url hash cookie hash 最少连接数 fair根据响应时间

总共7 种调度算法

1，轮询

默认算法一人一次

2，加权轮询

2.1 语法

不写默认 weight=1

2.2 实验结果

大概按3比1

3， ip hash

3.1 实现方式

通过客户端的ip 地址计算出一个值算出来访问真实服务机1 永远访问1

3.2 意义

实现会话保持

3.3 实验步骤

可以看到第一次在77 服务器永远在77服务器

3.4 ip hash 弊端

hash 算法后还要除总权重

如果你动了权重可能会导致不正确

4，uri hash

根据访问路径

5，cookie hash

5.1 cookie 原理

5.2 更新的技术

令牌技术

5.3 实验步骤

6，最少连接数

least_conn;

7，fair 根据响应时间

（六）一些其他设置

这些都是加在真实服务机后面例如这样：

weight=number	#设置权重，默认为1,实现类似于LVS中的WRR,WLC等
max_conns=number	#给当前后端server设置最大活动链接数，默认为0表示没有限制最大连接数
max_fails=number	#后端服务器的下线条件,当客户端访问时,对本次调度选中的后端服务器连续进行检测多少次,如果都失败就标记为不可用,默认为1次,当客户端访问时,才会利用TCP触发对探测后端服务器健康性检查,而非周期性的探测 max_fails=3 检测3次 3次检测都不回才觉得死了
fail_timeout=time	#后端服务器的上线条件,对已经检测到处于不可用的后端服务器,每隔此时间间隔再次进行检测是否恢复可用，如果发现可用,则将后端服务器参与调度,默认为10秒 fail_timeout=30s 活了先等30秒在上
backup	#设置为备份服务器，当所有后端服务器不可用时,才会启用此备用服务器 sorry server 自己不能转自己备份的真实服务机当其他服务器都挂了才会启用自己
down	#标记为down状态死了
resolve	#当server定义的是主机名的时候，当A记录发生变化会自动应用新IP而不用重启Nginx 记录域名域名对应的ip 变化
hash KEY [consistent];	#基于指定请求报文中首部字段或者URI等key做hash计算，使consistent参数，将使用ketama一致性