nginx 反向代理 与缓存功能

一  理论说明

（一）反向代理简介

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

即 代理服务机

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

（二）相关模块

（三）架构图

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配置定义缓存信息

2， 子配置文件

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

（三）清理缓存

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

方法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而不用重启Nginx
 
 
 
hash 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 根据响应时间

（六）一些其他设置

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

七   自定义响应报文头部信息

在 sever 模块添加以下

add_header X-Via $server_addr;                                   当前nginx主机的IP

add_header X-Cache $upstream_cache_status;          是否缓存命中

add_header X-Accel $server_name;                             客户访问的FQDN

add_header name value [always];                              自定义响应报文头部信息