赞
踩
反向代理: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协议转发至指定服务器处理 (语言不同 接口不同) |
同构协议:客户机 服务机协议一样
异构: 不一样
实验环境:66是代理服务器 77 是真实服务器
66 配置文件:
表示开启代理 真服务机是77
访问 66 也能看到77 真服务器 的内容
在真实服务器上 做防火墙规则
iptables -A INPUT -s 192.168.91.66 -j DROP
客户端再次访问 会出现504网关超时(有可能只是处理时间久,服务器不一定挂了),时间较长1分钟,没有定义代理超时时间
drop 丢弃 真实服务机一直丢弃代理服务机
代理服务机会以为 真实服务机没收到 会一直发
大概持续一分钟 超时 然后返回504
在真实服务器上 做防火墙规则
iptables -A INPUT -s 192.168.91.66 -j REJECT
客户端再次访问 会出现502,一般出现502 代表后端真实服务器挂了
网关不可达 reject 拒绝
基本判定 真实服务机挂了
66代理服务机:
访问66/api 等于访问 真是服务器77/api
77 真实服务机 主页面内容:
客户机访问:
http://192.168.91.77 不加/ 是将location上的url 追加在后面
http://192.168.91.77/ 加上/ 是将location上的url 替换后proxy配置里的连接
即访问 真实服务机的主页面
加快速度
万一 真实服务器挂了 救急
在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; | #最大磁盘占用空间,磁盘存入文件内容的缓存空间最大值 |
#调用缓存功能,需要定义在相应的配置段,如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_methods GET | HEAD | POST ...; | #对哪些客户端请求方法对应的响应进行缓存,GET和HEAD方法总是被缓存 对方法 缓存 |
缓存不会自动清理 需要手动清理
方法1: rm -rf 缓存目录
方法2: 第三方扩展模块ngx_cache_purge
注意: 在rm -rf proxycache 后 需要nginx -s reload 再次生成proxycache文件夹
66 代理服务机 配置文件
当客户机 访问代理服务器时可以看到生成缓存文件
当我们 关闭真实服务器时,发现客户机 仍能看到内容
66 是代理服务器 99是真实服务器
目前99 服务器查看访问日志 是看不到真实ip的
只能看到66 代理服务器的ip
第一步
99 真实服务器 需要将日志中的“referer” 开启 (yum安装的nginx 默认开启 编译安装的,需要手动开启)
如果真实服务器是 httpd 在主配置文件改 如图所示:
第二步
66 代理服务器需要改配置文件: proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; #添加客户端IP和反向代理服务器IP到请求报文头部
第三步:
此时我们再去让客户机访问 查看99真实服务机的日志 发现可以看到 客户机ip 为11
步骤与一级代理一致
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
真实服务器 改日志格式
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
66为代理服务器 77,99 为两台真实服务器
66 代理服务器的主配置文件:
此为轮询算法 一人一次 总共7种算法,下面依次介绍
nginx 非常聪明,把77停了 只会去99
原因: 在轮询前 会三次握手 握不到 就不发过去
关闭99 真实服务器 ,发现代理服务器只会去到77 真实服务器
轮询 加权轮询 ip hash url hash cookie hash 最少连接数 fair根据响应时间
总共7 种调度算法
默认算法 一人一次
不写 默认 weight=1
大概 按3比1
通过客户端的ip 地址 计算出一个值 算出来 访问 真实服务机1 永远访问1
实现会话保持
可以看到 第一次在77 服务器 永远在77服务器
hash 算法 后还要除 总权重
如果你动了权重 可能会导致不正确
根据访问路径
令牌 技术
least_conn;
这些都是加在 真实服务机后面 例如这样:
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一致性 |
在 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]; 自定义响应报文头部信息
Copyright © 2003-2013 www.wpsshop.cn 版权所有,并保留所有权利。