一、为什么使用haproxy
后端检测将挂了的主机访问打到正常的主机上，就是我们所说的负载均衡，保证业务的高可用性，方便业务后期的水平动态扩展
二、七层负载和四层负载及正反向代理的含义
1、四层负载
（1）通过IP+PORT决定负载均衡的去向
（2）对流量请求进行NAT处理，转发至后台服务器。
（3）记录tcp、udp流量分别是由哪台服务器处理
（4）支持四层代理的软件
LVS：重量级四层负载均衡器。
Nginx：轻量级四层负载均衡器，可缓存，通过upstream模块
Haproxy：模拟四层妆发
2、七层负载
（1）通过虚拟URL或主机IP进行流量识别，根据应用层信息进行解析，决定是否需要进行负载均衡。
（2）代理后台服务器与客户端建立连接，如nginx可代理前后端，与前端客户端tcp连接，与后端服务tcp连接
（3）支持七层代理的软件
Nginx：基于http协议，通过proxy_pass
Haproxy：七层代理，会话保持、标记、路径转移等
3、四层和七层的区别
四层的负载均衡是通过发布三层的IP地址+端口号来识别流量需不需要做负载均衡，并且需要对处理的流量进行NAT处理，转发至后台服务器并记录下这个TCP或者UDP的流量由哪台服务器处理的，后续这个连接的所有流量都同样转发到同一台服务器处理。
七层的负载均衡是在四层的基础上，例如一个Web服务器的负载均衡，除了根据VIP+端口辨别还可以可以根据URL、浏览器类别、语言来识别流量是否需要负载均衡
（1）分层位置：四层负载均衡实在传输层及以下，七层负载均衡在应用层及以下
（2）性能：四层负载均衡不能解析报文消息内容，在网络吞吐量和处理能力上较高，七层能解析应用层报文消息，识别URL、Cookie、HTTPheader等信息。
（3）功能类别：四层负载均衡类似于路由器；七层类似于代理服务器
（4）原理：四层负载均衡是基于ip+prot；七层是基于url或主机ip
（5）安全性：四层负载均衡无法识别DDos攻击；七层可防御SYN Cookie/Flood攻击
4、正反向代理
（1）正向代理：是一个位于客户端和目标服务器之间的服务器（代理服务器），为了从目标服务器取得内容，客户端向代理服务器发送一个请求并指定目标，然后代理服务器向目标服务器转交请求并将获得的内容返回给客户端。例如你想要租房子，可以通过中介来寻求一些房源，这个中介就是所谓的正向代理。
（2）反向代理：指服务器来接受internet上的连接请求，然后将请求转发给内部网络上的服务器，并将从服务器上得到的结果返回给internet上请求连接的客户端，此时代理服务器对外就表现为一个反向代理服务器。例如你作为客户想去租房找一个房东，结果对面是一个二房东，就是真实房东找的代理房东，这个代理房东就是反向代理。
三、HAProxy简介
HAProxy是法国开发者Willy Tarreau在2000年使用C语言开发的一个开源软件
是一款具备高并发（万级以上）、高性能的TCP和HTTP负载均衡器
支持基于cookie的持久性，自动故障切换，支持正则表达式及web状态统计
四、实验环境准备
1、三台rhel9.1的虚拟机
2、IP
Haproxy：172.25.254.100
Webserver1：172.25.254.10
Webserver2：172.25.254.20
3、提前关闭防火墙和selinux
4、为了后续体现不同web的配置不同，我们在两台Webserver上分别安装nginx和apache
（1）webserver1:
[root@Webserver ~]# dnf install nginx -y
[root@Webserver ~]# echo webserver1 - 172.25.254.10 > /usr/share/nginx/html/index.html
[root@Webserver ~]# systemctl enable --now nginx
Created symlink /etc/systemd/system/multi-user.target.wants/nginx.service → /usr/lib/systemd/system/nginx.service.
（2）webserver2:
[root@Webserver ~]# dnf install nginx -y
[root@Webserver ~]# echo webserver2 - 172.25.254.20 > /usr/share/nginx/html/index.html
[root@Webserver ~]# systemctl enable --now nginx
Created symlink /etc/systemd/system/multi-user.target.wants/nginx.service → /usr/lib/systemd/system/nginx.service.
五、HAProxy的基本部署方法及负载均衡的实现
1、软件的安装
HAProxy：
[root@HAProxy ~]# dnf install haproxy -y
[root@HAProxy ~]# systemctl enable --now haproxy
Created symlink /etc/systemd/system/multi-user.target.wants/haproxy.service → /usr/lib/systemd/system/haproxy.service.———将vim格式设置成haproxy配置文件需要的格式
[root@HAProxy ~]# cat ~/.vimrc
set ts=4 ai sw=4
2、基本配置信息
2.1全局配置段global
进程及安全配置相关的参数
性能调整相关参数
Debug参数
2.2代理配置段proxies
defaults：为frontend、backend、listen提供默认配置
frontend：前端，相当于nginx中的server{}
backend：后端，相当于nginx中的upstream{}
listen：同时拥有前端和后端配置，配置简单，生产推荐使用
2.3global配置
2.3.1配置参数
| 参数 | 作用 |
|---|---|
| chroot | 锁定运行目录 |
| deamon | 以守护进程运行 |
| user, group, uid, gid | 运行haproxy的用户身份 |
| stats socket | 套接字文件 |
| nbproc N | 开启的haproxy worker 进程数，默认进程数是一个 |
| nbthread 1 （和nbproc 互斥） | 指定每个haproxy进程开启的线程数，默认为每个进程一个 线程 |
| cpu-map 1 0 | 绑定haproxy worker 进程至指定CPU，将第1个work进程绑 定至0号CPU |
| cpu-map 2 1 | 绑定haproxy worker 进程至指定CPU，将第2个work进程绑 定至1号CPU |
| maxconn N | 每个haproxy进程的最大并发连接数 |
| maxsslconn N | 每个haproxy进程ssl最大连接数,用于haproxy配置了证书的 场景下 |
| maxconnrate N | 每个进程每秒创建的最大连接数量 |
| spread-checks N | 后端server状态check随机提前或延迟百分比时间，建议2 5(20%-50%)之间，默认值0 |
| pidfile | 指定pid文件路径 |
| log 127.0.0.1 local2 info | 定义全局的syslog服务器；日志服务器需要开启UDP协议， 最多可以定义两个 |
2.3.2配置文件global的介绍
2.3.3示例
2.3.3.1nbproc参数开启多进程
开启前
编辑配置文件
开启后的进程
注意：开启进程不是越多越好，看你的cpu核心数量，你的cpu有几核才能开几个
固定进程的cpu内核使用，避免cpu使用的飘逸
2.3.3.2nbthread参数开启多线程
开启前
编辑配置文件
开启后
2.3.3.3自定义日志
编辑rsyslog配置文件
[root@HAProxy ~]# vim /etc/rsyslog.conf
重启服务
先启动rsyslog再启动haproxy，就可以看到自定义的日志文件已经生成了
注意：global中的参数在defaults中也能写，但是匹配下来后两个配置段中都有的参数defaults会覆盖掉global中的参数
2.4proxies配置
2.4.1proxies-defaults
mode http #HAProxy实例使用的连接协议
log global #指定日志地址和记录日志条目的
syslog/rsyslog日志设备
#此处global表示使用global配置段中设定的log值
option httplog #日志记录选项，httplog表示记录与http会话相关的各种数学
#包括http请求、会话状态、连接数、源地址及连接时间等
option dontlognull #表示不吉利空会话连接日志
option http-server-close #等待客户端完整HTTP请求的时间
option forwardfor except 127.0.0.0/8 #透传客户端真实IP至后端web服务器
option redispatch #当server id 对应的服务器挂掉后，强制定向到其他健康的服务器，重新派发
option http-keep-alive #开启与客户端的会话保持
retries 3 #连接后端服务器失败次数
timeout http-request 1000s #等待客户端请求完全被接收和处理的最 长时间
timeout queue 60s #设置删除连接和客户端收到503或服务不可 用等提示信息前的等待时间
timeout connect 120s #设置等待服务器连接成功的时间
timeout client 600s #设置允许客户端处于非活动状态，即既不发 送数据也不接收数据的时间
timeout server 600s #设置服务器超时时间，即允许服务器处于既 不接收也不发送数据的非活动时间
timeout http-keep-alive 60s #session 会话保持超时时间，此时间段内 会转发到相同的后端服务器
timeout check 10s #指定后端服务器健康检查的超时时间
maxconn 3000 #可承受的最大并发连接量
default-server inter 1000 weight 3 #对后端检测的默认参数，inter每隔多长时间，weight访问多少次
介绍配置文件
2.4.2proxies-frontend
frontend配置参数：
bind：指定监听地址，IPV4或IPV6，可以监听多个IP或端口
#格式：
bind [<address>]:<prot_range>[,...]
——注意，如果需要绑定在非本机的IP,需要开启内核参数：net.ipv4.ip_nonlocal_bind=1
2.4.3proxies-backend
定义一组后端服务器，backend服务器将被frontend进行调用。
backend的名称必须唯一，并且必须在listen或frontend中事先定义才可以使用,否则服务无法 启动
mode http|tcp
option server #指定负载协议类型,和对应的frontend必须一致 #配置选项 #定义后端real server,必须指定IP和端口
代码示例：
测试效果：
2.4.3.1server配置
#针对一个server配置
check #对指定real进行健康状态检查，如果不加此设置，默认不开启检查,只有check后面没 有其它配置也可以启用检查功能
#默认对相应的后端服务器IP和端口,利用TCP连接进行周期性健康性检查,注意必须指定 端口才能实现健康性检查
addr <IP> #可指定的健康状态监测IP，可以是专门的数据网段，减少业务网络的流量
port <num> #指定的健康状态监测端口
inter <num> #健康状态检查间隔时间，默认2000 ms
fall <num> #后端服务器从线上转为线下的检查的连续失效次数，默认为3
rise <num> #后端服务器从下线恢复上线的检查的连续有效次数，默认为2
weight <weight> #默认为1，最大值为256，0(状态为蓝色)表示不参与负载均衡，但仍接受持久连接
backup #将后端服务器标记为备份状态,只在所有非备份主机down机时提供服务，类似SorryServer
disabled #将后端服务器标记为不可用状态，即维护状态，除了持久模式
#将不再接受连接,状态为深黄色,优雅下线,不再接受新用户的请求
redirect prefix http://www.baidu.com/ #将请求临时(302)重定向至其它URL，只适用于http模式
maxconn <maxconn> #当前后端server的最大并发连接数
示例：
（1）check
（2）用backup参数实现sorryserver的设置
配置一个做sorryserver的主机，这里不想开另外一台客户端所以使用了HAproxy的主机做，所以需要改端口号为8080
首先安装http
[root@HAProxy ~]# dnf install httpd -y
[root@HAProxy ~]# vim /etc/httpd/conf/httpd.conf
为了实现我们的sorryserver，先关掉两台后台服务器的nginx
[root@webserver1 ~]# systemctl stop nginx
[root@webserver2 ~]# systemctl stop nginx
可以测试一下访问我们的Haproxy
为了我们设置的sorryserver生效我们还需要配置haproxy的配置文件
测试效果：
重启后就会跳出我们之前设置的日志信息
那如果我们有时需要维护一台后端服务器，就用disabled指定服务器下线
先将两台nginx开启
[root@webserver1 ~]# systemctl start nginx
[root@webserver2 ~]# systemctl start nginx
编辑配置文件
测试效果：
就不会访问到10主机上了
设置请求重定向
编辑配置文件
测试效果：
maxconn设置最大并发连接
测试效果：
可以看到，当两台服务器一起访问的时候另一台后端服务器就已经访问不到了
我们关掉一台的死循环访问才会逐渐有出现10 20轮询访问的情况
2.4.4proxies-listen简化配置
使用listen替换 frontend和backend的配置方式，可以简化设置，通常只用于TCP协议的应用
listen配置示例：
示例效果：
六、HAProxy热更新方法
1、socat工具
因为我们的配置文件中不止一个集群，如果像以上那种改法，每次改一个集群都要重启一遍服务器，也就会刷新配置文件中全部的集群，可能会导致影响其他集群，所以我们用socat工具来一条一条的更改我们需要改的集群而不影响其他集群。
2、socat使用方法
需要HAProxy主机配置文件中有一条来记录状态的文件，通过给这个文件提权来方便控制HAProxy中的配置
重启服务
在HAProxy主机中安装socat工具
[root@HAProxy ~]# dnf install socat -y
查看帮助文档
socat -h
echo "help" | socat stdio /var/lib/haproxy/stats
常用示例：
（1）查看haproxy状态
（2）查看后端主机（集群）状态
[root@HAProxy ~]# echo "show servers state" | socat stdio /var/lib/haproxy/stats
（3）查看并设置集群权重
查看两台主机的权重
[root@HAProxy ~]# echo "get weight webcluster/web1" | socat stdio /var/lib/haproxy/stats 1 (initial 1)
[root@HAProxy ~]# echo "get weight webcluster/web2" | socat stdio /var/lib/haproxy/stats
1 (initial 1)——将主机2的权重改为2
[root@HAProxy ~]# echo "set weight webcluster/web2 2" | socat stdio /var/lib/haproxy/stats
[root@HAProxy ~]# echo "get weight webcluster/web2" | socat stdio /var/lib/haproxy/stats 2 (initial 1)
测试看是生效的：
（4）设置下线后端服务器
设置下线两台服务器
[root@HAProxy ~]# echo "disable server webcluster/web1" | socat stdio /var/lib/haproxy/stats
[root@HAProxy ~]# echo "disable server webcluster/web2" | socat stdio /var/lib/haproxy/stats
测试效果出现sorryserver表示成功下线两台服务器：
开启后端服务器
[root@HAProxy ~]# echo "enable server webcluster/web2" | socat stdio /var/lib/haproxy/stats
[root@HAProxy ~]# echo "enable server webcluster/web1" | socat stdio /var/lib/haproxy/stats
访问一下：
（5）针对多进程处理方法
首先更改配置文件
[root@HAProxy ~]# systemctl restart haproxy
[root@HAProxy ~]# ll /var/lib/haproxy/
total 0
srw------- 1 root root 0 Aug 11 12:12 stats
srw------- 1 root root 0 Aug 11 12:55 stats1
srw------- 1 root root 0 Aug 11 12:55 stats2——可以看到之前的状态文件不能使用了
[root@HAProxy ~]# echo "show info" | socat stdio /var/lib/haproxy/stats 2024/08/11 12:56:56 socat[34419] E connect(5, AF=1 "/var/lib/haproxy/stats", 24): Connection refused
进程1
[root@HAProxy ~]# echo "show info" | socat stdio /var/lib/haproxy/stats1
Name: HAProxy
Version: 2.4.17-9f97155
Release_date: 2022/05/13
Nbthread: 1
Nbproc: 2
Process_num: 1
Pid: 34415
进程2
[root@HAProxy ~]# echo "show info" | socat stdio /var/lib/haproxy/stats2
Name: HAProxy
Version: 2.4.17-9f97155
Release_date: 2022/05/13
Nbthread: 1
Nbproc: 2
Process_num: 2
Pid: 34416
七、HAProxy中的算法
1、静态算法
静态算法：按照事先定义好的规则轮询公平调度，不关心后端服务器的当前负载、连接数和响应速度 等，且无法实时修改权重(只能为0和1,不支持其它值)，只能靠重启HAProxy生效。
1.1static-rr:基于权重的轮询调度
不支持热处理和慢启动，慢启动是指在服务器刚刚启动上不会把他所应该承担的访问压力全部给它，而是先给一部分，当没 问题后在给一部分
后端主机数量没有限制
编辑配置文件
不支持热处理测试：
[root@HAProxy ~]# echo "set weight webcluster/web1 1" | socat stdio /var/lib/haproxy/statsBackend is using a static LB algorithm and only accepts weights '0%' and '100%'.
1.2first
自上而下的进行调度，只会当第一台服务器的连接数达到上限，新请求才会分配给下一台服务器，会忽略服务器的权重设置
不支持热处理
测试效果：
在多台主机上死循环访问看效果
2、动态算法
基于后端服务器状态进行调度适当调整， 新请求将优先调度至当前负载较低的服务器 权重可以在haproxy运行时动态调整无需重启
2.1roundrobin 谁闲给谁
1. 基于权重的轮询动态调度算法
2. 支持权重的运行时调整,不同于lvs中的rr轮训模式
3. HAProxy中的roundrobin支持慢启动(新加的服务器会逐渐增加转发数)
4. 其每个后端backend中最多支持4095个real server
5. 支持对real server权重动态调整
6. roundrobin为默认调度算法,此算法使用广泛
编辑配置文件
支持热处理测试：
[root@HAProxy ~]# echo "set weight webcluster/web1 1" | socat stdio /var/lib/haproxy/stats
[root@HAProxy ~]# echo "get weight webcluster/web1" | socat stdio /var/lib/haproxy/stats 1 (initial 2)
2.2leastconn谁链接最少给谁
leastconn加权的最少连接的动态
支持权重的运行时调整和慢启动，即:根据当前连接最少的后端服务器而非权重进行优先调度(新客户 端连接)
比较适合长连接的场景使用，比如：MySQL等场景。
编辑配置文件
支持热处理
[root@HAProxy ~]# systemctl restart haproxy
[root@HAProxy ~]# echo "set weight webcluster/web1 2" | socat stdio /var/lib/haproxy/stats
[root@HAProxy ~]# echo "set weight webcluster/web1 1" | socat stdio /var/lib/haproxy/stats
[root@HAProxy ~]# echo "get weight webcluster/web1" | socat stdio /var/lib/haproxy/stats 1 (initial 2)
非权重优先调度
3、其他算法
其它算法即可作为静态算法，又可以通过选项成为动态算法
源地址hash，基于用户源地址hash并将请求转发到后端服务器，后续同一个源地址请求将被转发至同一 个后端web服务器。默认为静态方式，但是可以通过hash-type支持的选项更改这个算法一般是在不插入Cookie的TCP 模式下使用。适用于session会话保持但不支持 cookie和缓存的场景源地址有两种转发客户端请求到后端服务器的服务器选取计算方式，分别是取模法 和一致性hash。
3.1source
编辑配置文件
配置后的效果：
相同hash值的流量被定向到同一台服务器
3.1.1map-base取模法
对source地址进行hash计算，再基于服务器总权重的取模，最终结果决定将此请 求转发至对应的后端服务器。
此方法是静态的，即不支持在线调整权重，不支持慢启动，可实现对后端服务器均衡调度 缺点是当服务器的总权重发生变化时，即有服务器上线或下线，都会因总权重发生变化而导致调度结果 整体改变
所谓取模算法，就是计算两个数相除之后的余数
map-base算法：基于权重取模 hash（source_ip）%所有后端服务器相加的总权重
比如当源hash值是1111，1112，1113，三台服务器abc的权重均为1，即abc的调度标签分别会被设定为0 1 2（1111%3=1，1112%3=2，1113%3=0）
1111---->b
1112---->c
1113---->a
如果a下线后，权重数量发生变化（1111%2=1，1112%0，1113%2=1）
1112和1113都被调度到的主机发生变化，这样会导致原本没有挂掉的服务器与客户机的会话丢失
示例：
3.1.2一致性hash
一致性哈希，当服务器的总权重发生变化时，对调度结果影响是局部的，不会引起大的变动hash（o） mod n
该hash算法是动态的，支持使用 socat等工具进行在线权重调整，支持慢启动
示例：
3.2uri
基于对用户请求的URI的左半部分或整个uri做hash，再将hash结果对总权重进行取模后 根据最终结果将请求转发到后端指定服务器
适用于后端是缓存服务器场景
默认是静态算法，也可以通过hash-type指定map-based和consistent，来定义使用取模法还是一致性 hash
此算法基于应用层，支持mode http，不支持mode tcp
一致性hash配置：
编辑配置文件
设置不同的uri
[root@webserver1 ~]# echo web1index1 - 172.25.254.10 >
/usr/share/nginx/html/index.html
[root@webserver1 ~]# echo web1index1 - 172.25.254.10 > /usr/share/nginx/html/index1.html
[root@webserver1 ~]# echo web1index2 - 172.25.254.10 > /usr/share/nginx/html/index2.html
[root@webserver1 ~]# echo web1index3 - 172.25.254.10 > /usr/share/nginx/html/index3.html
[root@webserver2 ~]# echo web1index1 - 172.25.254.20 > /usr/share/nginx/html/index1.html
[root@webserver2 ~]# echo web1index2 - 172.25.254.20 > /usr/share/nginx/html/index2.html
[root@webserver2 ~]# echo web1index3 - 172.25.254.20 > /usr/share/nginx/html/index3.html
测试效果：
只要uri不变，最后访问的主机不变
3.3url_param
url_param对用户请求的url中的 params 部分中的一个参数key对应的value值作hash计算，并由服务器 总权重相除以后派发至某挑出的服务器,后端搜索同一个数据会被调度到同一个服务器，多用与电商 通常用于追踪用户，以确保来自同一个用户的请求始终发往同一个real server 如果无没key，将按roundrobin算法
一致性hash配置示例：
测试效果：
3.4hdr(User-Agent)
针对用户每个http头部(header)请求中的指定信息做hash， 此处由 name 指定的http首部将会被取出并做hash计算， 然后由服务器总权重取模以后派发至某挑出的服务器，如果无有效值，则会使用默认的轮询调度。
一致性hash配置示例：
测试效果：
3.5算法总结
静态 不支持热处理和慢启动
static-rr------>tcp/http 不管服务器的状态直接轮询
first----------->tcp/http 先访问满一个再访问另一个
动态 支持热处理和慢启动
roundrobin------>tcp/http 谁负载小权重高就访问谁
leastconn--------->tcp/http 谁链接少权重高就访问谁
以下静态和动态取决于hash_type是否consistent
source------------>tcp/http 源地址hash，用hash环保持hash一致性
Uri--------------->http 基于访问地址的内容进行hash
url_param--------->http 基于访问发送的请求进行hash
hdr--------------->http 基于（http报文头）不同的浏览器进行hash
八、高级功能及配置
1、Haproxy的状态页
通过web界面，显示当前HAProxy的运行状态
通过配置子配置文件设定状态页
[root@HAProxy ~]# cd /etc/haproxy/conf.d
[root@HAProxy conf.d]# ls
[root@HAProxy conf.d]# vim webcluster.cfg
测试：
关掉一个后端服务器
2、基于cookie的会话保持
当浏览器发送给haproxy时都带一个cookie值，使调度算法对客户端的粒度更精准，但同时也加大了haproxy负载，目前已经被session共享服务器代替，session使保存在服务器上。
注意：不支持tcp 支持http
配置示例：
测试效果：
通过命令验证
3、IP透传
web服务器中需要记录客户端的真实IP地址，用于做访问统计、安全防护、行为分析、区域排行等场景。
3.1七层IP透传
看没有IP透传参数的效果：
将参数注释去掉后：
如果后端服务器使用apache需要对其配置文件设定
[root@webserver1 ~]# vim /etc/httpd/conf/httpd.conf
3.2四层IP透传
编辑配置文件设置tcp
编辑nginx配置文件：
编辑haproxy配置文件：
只用给nginx服务器添加代理参数
因为apache现在不支持四层透传了，所以将10服务器的apache关闭，开启nginx，同时haproxy中代理加上
查看日志文件：
[root@webserver1 ~]# tail -n 3 /var/log/nginx/access.log
172.25.254.100 - - [11/Aug/2024:17:42:31 +0800] "GET / HTTP/1.1" 200 27 "-" "curl/8.4.0" "-" "172.25.254.1"
172.25.254.100 - - [11/Aug/2024:17:42:31 +0800] "GET / HTTP/1.1" 200 27 "-" "curl/8.4.0" "-" "172.25.254.1"
172.25.254.100 - - [11/Aug/2024:17:42:31 +0800] "GET / HTTP/1.1" 200 27 "-" "curl/8.4.0" "-" "172.25.254.1"
[root@webserver2 ~]# tail -n 3 /var/log/nginx/access.log
172.25.254.100 - - [11/Aug/2024:17:42:31 +0800] "GET / HTTP/1.1" 200 27 "-" "curl/8.4.0" "-" "172.25.254.1"
172.25.254.100 - - [11/Aug/2024:17:42:31 +0800] "GET / HTTP/1.1" 200 27 "-" "curl/8.4.0" "-" "172.25.254.1"
172.25.254.100 - - [11/Aug/2024:17:42:31 +0800] "GET / HTTP/1.1" 200 27 "-" "curl/8.4.0" "-" "172.25.254.1"
4、ACL
访问控制列表ACL，Access Control Lists）
是一种基于包过滤的访问控制技术
它可以根据设定的条件对经过服务器传输的数据包进行过滤(条件匹配)即对接收到的报文进行匹配和过 滤，基于请求报文头部中的源地址、源端口、目标地址、目标端口、请求方法、URL、文件后缀等信息内 容进行匹配并执行进一步操作，比如允许其通过或丢弃。
4.1ACL配置选项
acl <aclname> <criterion> [flags] [operator] [<value>]
acl 名称 匹配规范 匹配模式 具体操作符 操作对象类型
4.1.1ACL-Name名称
可以使用大字母A-Z、小写字母a-z、数字0-9、冒号：、点.、中横线和下划线，并且严格区分大 小写，比如:my_acl和My_Acl就是两个完全不同的acl5.8.1.2 ACL-criterion
4.1.2ACL-criterion 匹配规范
(1)hdr:提取在一个HTTP请求报文的首部, <occ>表示在多值中使用的值的出 现次数
| hdr_beg（[<name> [，<occ>]]） | 前缀匹配，header中指定匹配内容的begin |
| hdr_end（[<name> [，<occ>]]） | 后缀匹配，header中指定匹配内容end |
| hdr_dom（[ <name>[，<occ>]]） | 域匹配，header中的dom（host） |
| hdr_dir（[<name> [，<occ>]]） | 路径匹配，header的uri路径 |
| hdr_len（[ <name>[，<occ>]]） | 长度匹配，header的长度匹配 |
| hdr_reg（[ <name>[，<occ>]]） | 正则表达式匹配，自定义表达式(regex)模糊匹配 |
| hdr_sub（[<name> [，<occ>]]） | 子串匹配，header中的uri模糊匹配 模糊匹配c 报文中a/b/c也会匹 配 |
(2)base:返回第一个主机头和请求的路径部分的连接，该请求从主机名开始，并在问号之前结束,对虚拟主机有用
<scheme>://<user>:<passwd>@#<host>:<port>/<path>;<params>#?<query>#<frag>
| base_beg | prefix match |
| base_dir | subdir match |
| base_dom | domain match |
| base_end | suffix match |
| base_len | length match |
| base_reg | regex match |
| base_sub | substring match |
(3)path:提取请求的URL路径，该路径从第一个斜杠开始，并在问号之前结束（无主机部分）
| path_beg | 请求的URL开头，如/static、/images、/img、/css |
| path_end | 请求的URL中资源的结尾，如 .gif .png .css .js .jpg .jpeg |
| path_dom | domain match |
| path_dir | subdir match |
| path_len | length match |
| path_reg | regex match |
| path_sub | substring match |
(4)url:提取请求中的整个URL。
| url_beg | prefix match |
| url_dir | subdir match |
| url_dom | domain match |
| url_end | suffix match |
| url_len | length match |
| url_reg | regex match |
| url_sub | substring match |
4.1.3ACL-flags匹配模式
-i 不区分大小写
-m 使用指定的正则表达式匹配方法
-n 不做DNS解析
-u 禁止acl重名，否则多个同名ACL匹配或关系
4.1.4ACL-operator 具体操作符
| exact match (-m str) | 字符串必须完全匹配模式 |
| substring match (-m sub) | 在提取的字符串中查找模式，如果其中任何一个被发现，ACL将匹配 |
| prefix match (-m beg) | 在提取的字符串首部中查找模式，如果其中任何一个被发现，ACL将匹配 |
| suffix match (-m end) | 将模式与提取字符串的尾部进行比较，如果其中任何一个匹配，则ACL进行 匹配 |
| subdir match (-m dir) | 查看提取出来的用斜线分隔（“/"）的字符串，如其中任一个匹配，则ACL 进行匹配 |
| domain match (-m dom) | 查找提取的用点（“."）分隔字符串，如果其中任何一个匹配，则ACL进行 匹配 |
4.1.5ACL-value 操作对象
| Boolean | 布尔值 |
| integer or integer range | 整数或整数范围，比如用于匹配端口范围 |
| IP address / network | IP地址或IP范围, 192.168.0.1 ,192.168.0.1/24 |
| exact | 精确比较 |
| substring | 子串 |
| suffix | 后缀比较 |
| prefix | 前缀比较 |
| subdir | 路径， /wp-includes/js/jquery/jquery.js |
| domain | 域名，www.timinglee.org |
| regular expression | 正则表达式 |
| hex block | 16进制 |
4.2 多个ACL的组合调用方式
逻辑处理
与：隐式（默认）使用
或：使用“or" 或 “||"表示
否定：使用 "!" 表示
4.3ACL示例-域名匹配
编辑子配置文件
[root@HAProxy conf.d]# vim ACL.cfg
[root@HAProxy conf.d]# systemctl restart haproxy
[root@HAProxy conf.d]# pwd
/etc/haproxy/conf.d
给windows的host文件添加域名
如果没有权限需要在下面这个目录点击文件
测试结果：
编辑子配置文件
再添加域名
测试结果：
中间没访问到是因为服务器还没反应过来
4.4ACL示例-基于子串访问
测试：
[root@webserver1 ~]# mkdir /var/www/html/jcl -p
[root@webserver1 ~]# echo 172.25.254.10 jcl > /var/www/html/jcl/index.html
测试：
4.5ACL示例-基于path匹配（/后的内容）
测试：
4.6ACL示例-逻辑处理
[root@webserver2 ~]# mkdir -p /usr/share/nginx/html/jcl
[root@webserver2 ~]# echo 172.25.254.20 jcl > /usr/share/nginx/html/jcl/index.html
测试：
测试：
4.6ACL示例-基于源IP或子网调度访问
测试：
用172.25.254.10测试
用172.25.254.20测试
用172.25.254.1测试
4.7ACL示例-匹配浏览器类型
测试：
拒绝访问
可以访问
4.8ACL示例-基于文件后缀名实现动静分离
[root@webserver1 ~]# dnf install php -y
[root@webserver1 ~]# systemctl restart httpd[root@webserver1 ~]# vim /var/www/html/index.php
设完这边要访问得到网页
测试：
4.9ACL-匹配访问路径实现动静分离
[root@webserver1 ~]# mkdir -p /var/www/html/php
[root@webserver1 ~]# echo php - 172.25.254.10 > /var/www/html/php/inde.html
[root@webserver2 ~]# mkdir -p /usr/share/nginx/html/static
[root@webserver2 ~]# echo static - 172.25.254.20 > /usr/share/nginx/html/static/index.html
5、自定义HAProxy 错误界面
5.1 基于自定义的错误页面文件
关掉两台后端主机的nginx或者http
编辑错误文件
[root@HAProxy conf.d]# mkdir /haproxy/errorpages/ -p
[root@HAProxy conf.d]# cp /usr/share/haproxy/503.http /haproxy/errorpages/503page.http
[root@HAProxy conf.d]# vim /haproxy/errorpages/503page.http
编辑配置文件
浏览器中测试：
5.2 基于http重定向错误页面
再次在浏览器中访问就跳转到百度了
6、HAProxy 四层负载
针对除HTTP以外的TCP协议应用服务访问的应用场景
MySQL 、Redis 、Memcache 、RabbitMQ
安装mariadb-server
编辑配置文件
添加远程登录用户
查看端口是否开启
编辑配置文件
测试远程登录：
7、HAProxy https 实现
haproxy可以实现https的证书安全,从用户到haproxy为https,从haproxy到后端服务器用http通信 但基于性能考虑,生产中证书都是在后端服务器比如nginx上实现
7.1证书制作
编辑配置文件
浏览器访问
查看证书
全站加密
扫一扫
702
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
