HAProxy简介
HAProxy可以进行伪四层调度和七层调度,注意HAProxy只支持TCP/HTTP反向代理,nginx可以支持UDP
HAProxy架构中名词和LVS也不太一样
调度器后端的真实服务器:backend server(haproxy),real server(LVS)
四层调度
七层调度
HAProxy安装
我是docker安装的一条命令搞定
docker run -d --name my-running-haproxy \
-v /etc/docker/haproxy:/usr/local/etc/haproxy:ro \
-p 20006:23306 -p 30006:33306 -p 6888:7888 \
--sysctl net.ipv4.ip_unprivileged_port_start=0 haproxy:2.3
注意
- 在我们-v指定本地:容器目录映射的时候本地目录必须要有haproxy.cfg这个文件不然容器就运行不起来
- 还有就是要设置系统内核参数使其user用户也可以访问使用小于1024的端口号,因为2.4之后的haproxy容器以普通用户运行
为了测试后端的backend server我们创建2个httpd的容器
docker run -dit --name httpd1 -v /etc/docker/httpd1/html/:/usr/local/apache2/htdocs/ httpd:2.4
docker run -dit --name httpd2 -v /etc/docker/httpd2/html/:/usr/local/apache2/htdocs/ httpd:2.4
//注意/usr/local/apache2/htdocs/是httpd容器用来放置html文件的位置
haproxy没有自己的日志,其日志功能都是交给第三方日志管理,我们用rsyslog
rsyslog分为facility和priority2个概念
- facility就是将日志对象分类,比如kernel,user,ftp,secure等等,其中有local0到local7是用于自定义服务的haproxy用的就是local7
- priority分为7个等级(越高日志越详细)
0 Emergency
1 Alert
2 Critical
3 Error
4 Warning
5 Notice
6 Informational
7 Debug
所以,我们拉一个rsyslog镜像
HAproxy基本配置
haproxy的基本文件在/etc/haproxy/haproxy.cfg
中,如果haproxy是容器,那么配置文件在/usr/local/etc/haproxy/haproxy.cfg
中
HAproxy配置段
global全局配置段
- 进程及安全配置相关参数
- 性能相关参数
- debug参数
- 用户列表
- peers
proxies代理配置
- defaults:位fronted,listen,backend提供默认配置
- fronted:调度器前端
- backend:后端realserver
- listen:同时前端后端
fronted和backend可以分开配置表面可以让一个fronted专门对应一个backend或者一组
配置实例
vim haproxy.cfg
global #全局配置行
log 172.17.0.5 local2 #配置日志,日志容器ip为172.17.0.5,使用的时local2facility
frontend myweb #前端服务器(调度器,myweb为调度器的名字,只是内部使用)
bind *:80 (绑定到调度器的所有ip80端口)
default_backend websrvs (设置默认转发的backend server为websrvs,websrvs具体为啥看后面backend设置)
backend websrvs #设置backendserver websrvs,其中websevs只是haproxy内部名字可以是一个server也可以是一组server
server srv1 172.17.0.3:80 check #设置名字为websrvs的backend的第一个server srv1的ip为。。。check就是检查存活
server srv2 172.17.0.2:80 check #设置名字为websrvs的backend的第二个server srv2
balance roundrobin #设置调度算法为roundrobin也就是轮询
然后我们直接对调度器发起curl
root@workstastion:/etc/docker/haproxy# for i in {1..10}
> do
> curl 172.17.0.4
> done
<h1>backend server 1</h1>
<h1>backend server 2</h1>
<h1>backend server 1</h1>
<h1>backend server 2</h1>
<h1>backend server 1</h1>
<h1>backend server 2</h1>
<h1>backend server 1</h1>
<h1>backend server 2</h1>
<h1>backend server 1</h1>
<h1>backend server 2</h1>
root@workstastion:/etc/docker/haproxy#
global
cpu_map
可以把haproxy绑定到某个cpu上,参数如下
<“all”|“odd”|“even”|“process_num”><cpu_set>
uid
以什么uid运行haproxy,参数如下
< number >
user
以什么用户运行haproxy,参数如下
< user name >
gid
以什么gid运行haproxy,参数如下
< number >
group
以什么组运行haproxy,参数如下
< group name>
log
之前实例用过,将log发送给那个日志服务器,可以指定大小前多少字节,并且指定facility,参数如下
< ADDRESS > [len < length >] < facility > [ max level [ min level ] ]
log-send-hostname
在我们发送日志的时候是否指定hostname,参数如下
< string >
nbproc
指定我们的haproxy运行出多少个进程,默认haproxy单进程,也推荐单进程,因为单进程已经可以承接大量请求,但是不能使用多核cpu,参数如下
< number >
ulimit-n
指定我们的haproxy可以打开多少个文件,如果haproxy以普通用户执行,那么普通用户只能打开1024个文件,如果我们不设定这个参数那么会自动调整这个参数,所以不建议设置
< number >
maxconn
设置单进程最大连接并发数,haproxy总的最大连接数为nbproc*maxconn
< number >
maxconnrate
设置每个进程每秒可以创建的最大连接数
< number >
maxcomprate
设置每个进程压缩用户请求的速率 ,速率单位是每秒多少k
< number >
maxcompcpuusage
和上一个参数息息相关,指定压缩算法最大占据cpu的比例
< number >
maxsessrate
每个进程每秒钟可以接受的会话数量
< number >
maxsslconn
设置每个进程最大接受的ssl连接数列
< number >
noepoll
不用epoll相应请求
nopoll
不用poll相应请求
spread-checks
可以延迟健康检查的秒数,比如演唱百分之50,这个在backend机器非常多的时候有用
<0…50,in percent>
proxies
proxies不用和global一样前面必须写一个proxies,而是直接写proxies的子配置项defaults,listen,frontend,backend等等,接下来我们会列举 defaults,listen,frontend,backend常用的keyword,有的keyword只能用于其中一个或者两个,或者全部,我们会具体列出
bind
绑定到IP的端口,用于listen和frontend中
bind [< address >]:< pory_name >[,…]
e.g
listen http_proxy
binid :80,:443 //绑定80和443端口
bind 10.0.0.1:10080,10.0.0.1:10443 //绑定在固定ip固定端口中
bind /var/run/ssl-frontend.sock user root mode 600 accept-proxy
bind :443 ssl crt /etc/haproxy/site.pem //绑定在443端口且指定为ssl模式,并且给定证书位子
balance
指定调度算法用于frontend,listen,defaults中,因为前端不需要被调度
balance < algorithm > [< argument >]
balance url_param < param > [ check_post ]
一般来说balance后面直接加上算法,但是url_param后面需要加上一个param
可用算法:
roundrobin(默认加权轮询,如果每个server后面有weight就是加权轮询,如果没有写默认weight一样),haproxy的roundrobin的weight更改之后直接生效(动态算法的优势static-rr静态算法不支持),roundrobin支持运行时慢启动,也就是新加入一个主机发送给他的任务慢慢增加,而不是一下子把属于他的任务扔给他把他压垮,roundrobin只支持4095个后端服务器
static-rr和roundrobin一样但是不支持慢启动,而且对后端服务器没有上限,因为static-rr是静态算法不支持修改weight后直接生效
leastconn:此算法就是最少链接算法,计算后端的服务器那个负载最小就把请求给谁,他也是加权最小连接,也就是说计算负载最小的服务器除以权重,结果最小就给谁,而且建议leastconn用于长连接,支持慢启动,和权重调整
first:该算法就是先把第一台服务器的并发打满,再第二台,再第三台,以此将服务器的并发打满,e.groot@workstastion:~# vim /etc/docker/haproxy/haproxy.cfg global log 172.17.0.5 local2 frontend myweb bind *:80 default_backend websrvs backend websrvs server srv1 172.17.0.3:80 check maxconn 3 //设置最大同时连接数为3 server srv2 172.17.0.2:80 check balance first //选用调度算法为first root@workstastion:~# docker restart my-running-haproxy root@workstastion:~# for i in {1..10}; do curl 172.17.0.4; done <h1>backend server 1</h1> <h1>backend server 1</h1> <>h1>backend server 1</h1> <h1>backend server 1</h1> <h1>backend server 1</h1> <h1>backend server 1</h1> <h1>backend server 1</h1> <h1>backend server 1</h1> <h1>backend server 1</h1> <h1>backend server 1</h1> //因为最大并发连接数为3所以第一个这个一个一个打永远打不满,所以请求都给了server1,所以我们要用测压软件ab root@workstastion:~# apt-get install apache2-utils root@workstastion:~#ab -c 10 -n 100000 http://172.17.0.4/
source:源地址HASH,支持源地址HASH(map-based),一致性hash(consistent) ,所以其格式为balance source map-based|consistent
map-base就是根据每台服务器的权值,在hash表中分出多少台服务器,如果是服务器A的权值是10则在hash表中分出10台服务器,然后将请求根据hash函数后看映射到哪一台服务器上,但是服务器的变动,权值变动,我们的hash表就要重新的生成,hash的取余的值如果是固定的那么有的hash表元素就有可能访问不到 ,map-based是静态的(不支持慢启动,权值调整后只能重启服务),consistend(是动态的,支持慢启动,支持权值动态跳转)
uri:URI指的是http上某一个资源全程(Uniform Resource Identifier),他和url一样都是用来表示http上某一个独一无二的资源,但是url是通过位置层层定位比如/to/the/resource,而uri就是一个独一无二的数字来标识资源就和身份证号码一样,而我们haproxy中uri的算法就是将同一个uri发送给同一个服务器,首先一个请求请求猴哥uri这个uri是第一次被请求那么调度器就轮询调度给某个服务器并且记录在案,然后下一次某个请求还是这个uri就将这个请求发送给对应的服务器,用于缓存服务器,提高缓存命中率
url_param:我们可以看到前面url_param后面必须加上一个参数,所以我们先解释这个参数是干什么的,这个参数定位URL最后面一项的参数也就是URL等于号中前面的参数,然后将这个参数等于号后面的数值传递给调度器,调度器再HASH再发送给某个特定服务器。比如我们url为http://localhost:8080/api/v1/link?user=XXX 然后我们设置balance url_param user,user对应的是用户名,调度器将用户名hash后给某个特定的服务器,如果没有匹配上的默认轮询,url_param静态还是动态区域hash-type
hdr(< name >):根据头部hash给某个特定的服务器比如我们balance hdr(User-Agent) 说明将User-Agent这个值hash给某个特定的服务器,User-Agent代表用户使用的什么浏览器,静态还是动态取决于hash-type
hash-type
前面非常多的算法都会用到hash-type,所以我们可以直接指定hash-type
hash-type < method >
map-based
consistent
default_backend
用于listen,frontend,defaults中,为某个调度器指定默认后端,对应的还有以下参数
use_backend
用于listen,frontend,defaults中,为某个调度器指定特定后端
compression type
对那些存于backend的server内容进行压缩回传相应给各个请求,参数 ,对defaults,frontend,backend,listen都有效
< mime type >eg
compression type text/html text/plain #对超文本标记语言文本和普通文本进行压缩
compression algo
指定压缩的算法比如gzip,对defaults,frontend,backend,listen都有效
global log 172.17.0.5 local2 frontend myweb compression algo gzip compression type text/html text/plain application/xml application/javascript //对超文本语言文本,普通文本,xml文件,javascript文件进行压缩 bind *:80 >default_backend websrvs backend websrvs server srv1 172.17.0.3:80 check maxconn 3 server srv2 172.17.0.2:80 check balance roundrobin
disabled
暂时禁用某个前端或者前端,适用于defaults,frontend,backend,listen
enabled
和disabled对应,同样适用于defaults,frontend,backend,listen
server
定义backend各个服务器,只能用于listen和backend中,格式为
server < name > < address > [:[port]] [ param* ]
我们主要讲param参数,因为这个非常多,而且前面的name add之类非常好理解
param:
backup
备用主机sorry server,就是一个备用服务器只有其他的服务器down掉才使用这台sorry server,如果主服务器起来了sorry server自动又变成backup,请求又回到其他的server
check
对服务器进行健康检测,如果不加check默认每台服务器始终在线,加了check才会对服务器进行检测,检查又网络层检测(ping-pong),传输层检测(扫描端口),应用层检测(直接请求某个资源检测),这里的check只是简单的tcp端口周期检测,七层检测是最精准的
check也可以加上addr表示检测时使用的ip,
port后面加上端口表示针对端口进行check
inter < delay >表示check的间隔,默认为2000ms
rise < count >表示当前的server为problem状态检测多少次为成功才正真的使server变成up状态 ,默认为2
fall < count >表示连续检测server多少次失败后,才会标记为problem,默认为3
option httpchk
表示为http应用层检测,check option httpchk会发送请求页面返回200才会成功,或者**option httpchk < uri >**指定uri进行httpcheck,我们还可以指定http方法比如 option httpchk < method > < uri > 我们还可以基于什么方法,什么uri,什么版本进行请求 option httpchk < method > < uri > < version > egoption httpchk OPTIONS * HTTP/1.1\r\nHOST:\www #method是OPTIONS,URI是*代表所有,我们还发送了协议版本HTTP/1.1还连带发送了host主机www
不光有httpchk还有smtpchk,mysql-check,pqsql-check,ssh-hello-chk
egfrontend myweb *:80 compression algo gzip compression type text/html text/plain application/xml application/javascript default_backend websrvs backsend websrvs balabce roundrobin option httpchk server srv1 172.17.0.3:80 check inter 3000ms rise 1 fall 2
cookie
maxconn
设置服务器最大的并发连接数
< number >
maxqueue
当我们的最大连接数满了,我们就将超过的请求放入队列中,这个就是设置队列长度
< number >
minconn
前端服务器收到请求后最小给他调度minconn个
< number >
on-error
后端服务器error也就是坏掉后进行的操作,可选的mode有以下模式
fastinter:快速交互
fail-check :出发错误检测,然后快速交互
sudden-death:直接告诉haproxy挂掉了,并且标记为down
mark-down:标记为disabled
redir
重定向将ip地址重定向到另一个url比如
server srv1 10.0.0.1 redir http://image1.mydomain.com check
weight
定义权重,默认为1
< number >
stats
定义状态页,可用于listen,frontend,backend,defaults
我们在frontend开启stats,开启后会给出默认的url等参数,然后我们就可以进入frontend的stats页面,也可以自定义关于stats的相关配置frontend myweb *:80 mode http //对应的backend server也要开启http mode stats enable stats uri /haproxy?stats stats auth zhr:000000 #设置stats页面的账号密码 stats realm “REALM” #在认证的时候弹出对话框,设置对话框里面的话 stats admin if TRUE #设置如果登陆成功则可以通过stats页面管理集群 ... ...
然后我们直接在网站上输入url
IP/haproxy?stats
进入frontend的状态页面
这里有一个小坑,如果要使用haproxy?stats状态页面需要打开http mode,因为haproxy默认工作与tcp mode,,那么tcp mde 和tcp mode有哪些区别?tcp mode:客户端和服务器端之间将建立一个全双工的连接,且不会对7层报文做任何类型的检查
http mode:客户端请求在转发至后端服务器之前将被深度分析,所有不与RFC格式兼容的请求都会被拒绝
maxconn
最大并发连接数,默认2000
mode
设定haproxy的工作模式,有tcp,http,health,前面2个前面讲了,我们展开说一下tcp因为只是将报文普通的发出去,不进行解析,所以我们,可以代理mysql,ssh,ssl等等,下面实例代理ssh
listen ssh //使用listen就是frontend和backend都是这个配置 bind :22202 //绑定端口为22202 balance leastconn //调度算法为leastconn mode tcp //工作模式tcp,当然不写也行,因为默认 server sshserver1 XXX,XXX,XXX,XXX:22 check server sshserver2 XXX.XXX.XXX.XXX:22 check
cookie
管理用户发送过来的cookie信息,和发送给用户的cookie信息,在此之前先说一下http协议LB会话保持的机制
hash:
source ip :就像HAproxy的source调度算法一样,根据源地址进行HASH,在根据hash算法是consisten hash 还是map
cookie:根据cookie进行hash,cookie是非常精致的,就算同一个ip不同的浏览器也会被识别成不同的请求,
uri:根据uri进行hashsession server
专门用一个session进行session的存储比如使用在内存中进行存储的kv存储数据库,memcached,redis
在说haproxy的cookie原理之前先说一下http的cookie转发过程,首先client第一次发送http请求给服务器,服务器不知道client是谁所以,服务器会在相应报文中写上set-cookie字段,设置cookie的key-value值,client收到后,下次发送报文报文中的cookie字段会根据上一次服务器发送的set-cookie更改自己的cookie值,然后报文到达服务端服务器根据cookie以下就认出了client
haproxy这里cookie的原理非常简单,首先,服务器发送一个请求,调度器第一次根据轮询等算法调度给后端服务器,然后后端服务器返回一个相应报文,调度器拿到这个相应报文后,会更改这个报文的cookie,然后记录在案,最后返回用户,用户下次再发送http报文的时候cookie是被调度器更改过的,当http报文到达调度器上,调度器将其根据记录转发到对应的backend中,当调度器更改http响应报文的时候cookie是一长串键值对,所以我们对其更改的时候可以写一个新的键值对覆盖他,也可以放到所有键值对前面,也可以追加到键值对后面,这些我们都可以根据cookie的参数设定
[ rewrite | insert | prefix ] //分别表示重写,追加,放到前面
我们也可以对某个报文加上cookie,选择报文类型
[ indirect ] //临时重对象
[ nocache ] //http的nocache报文
[ postonly ] //仅对post方法的报文加cookie
[ httponly ] //对http报文做cookie
cookie的配置实例cookie SRV insert indirect nocache//给cookie中key-value中的key起名字,并且直接插入到cookie的key-value值之后,并且只对indirect报文和nocache报文才进行操作
cookie生产配置实例
backend server cookie WEBSRV insert nocache indirect //设置cookie的key,并且后续调用直接追加到cookie的key-value后面,这个操作只对nocache和indirect报文起作用 server srv1 172.X.X.X:80 weight 2 check rise 1 fall 2 maxconn 3000 cookie srv1 //定义这个srv1的ip,权重,从disable到up检查以此成功就up,从up到down2次检测判断为down就将server设为disable,最大并发连接设置成为3000,这里server设置的cookie是设置key-value中的value,前面设置cookie是key server srv2 172.x.x.x:80 weight 1 check rise 1 fall 2 maxconn 2000 cookie srv2 // ... #上面的配置srv1返回的cookie是set-cookie为WEBSRV=srv1,srv2返回的cookie是set-cookie为WEBSRV=srv2
errorfile
自定义错误页,但是只能针对错误代码200,400,403,408,500,502,503,504设定,可以用于default listen,backend,frontend,格式
errorfile < code > < file >
实例errorfile 400 /etc/haproxy/errorflles/400badreq.html
errorloc
功能和errorfile一样不过errorloc后面指定的是url不是文件地址
errorloc 400 http://X.X.X.X/SOME/FILE/400.html
reqadd#haproxy2.1之后不再使用,2.1之后用http-request add-header代替
为http请求报文添加头部用于frontend,backend,listen中
格式
reqadd < string > [{ if | unless } <cond>]
实例reqadd X-Proxy-By:\ HAProxy #第二段是添加的头部X-Proxy-By为什么:后面加个\因为他们键值对由空格隔开,空格用\转义,
http-request add-header
和reqadd一样不过此命令适用于2.1版本之后,
格式http-request add-header <name> <fmt> <condition> //name就是header的name,fmt就是header的变量,condition是条件判断
实例
http-request add-header X-Forward-For %[src] //自定义一个http头部X-Forward-For,其值为ip
rspadd #haproxy2.1之后不再使用,2.1之后用http-response add-header
为http回复报文添加头部,用于frontend,backend,listen中
格式
rspadd <string> [{if | unless} <code>]
http-response add-header
和rspadd一样不过此命令适用于2.1版本之后,
格式http-response add-header <name> <fmt> <condition> //name就是header的name,fmt就是header的变量,condition是条件判断
实例
http-response add-header X-Forward-For %[src] //自定义一个http头部X-Forward-For,其值为ip
http-request del-header
既然有添加头部也就有删除头部,因为有些返回的头部信息会暴露自己比如系统,比如服务所以我们要删除,reqadd也有对应的删除命令但是2.1之后不支持我们就没写了,所以我们直接介绍最新的http-request del-header
格式http-request del-header <name> [ -m <meth> ] [ { if | unless } <condition> ] #name是header的名字,-m是匹配方法支持精准匹配,前缀匹配,后缀匹配,condition是条件判断
例如
http-request del-header Server
http-response del-header
既然有添加头部也就有删除头部,因为有些返回的头部信息会暴露自己比如系统,比如服务所以我们要删除,reqadd也有对应的删除命令但是2.1之后不支持我们就没写了,所以我们直接介绍最新的http-request del-header
格式http-response del-header <name> [ -m <meth> ] [ { if | unless } <condition> ] #name是header的名字,-m是匹配方法支持精准匹配,前缀匹配,后缀匹配,condition是条件判断
例如
http-response del-header Server //铲除掉了server的首部,别人收到的response报文就不会包含server首部
timeout client
设定客户端一侧非活动时长单位毫秒,时间短,客户端处于非活动状态持续一定时间server端就会断开连接腾出更多的空间给后续的client,单位毫秒,格式 ,这个针对tcp模式
timeout client < ms >
timeout server
这个是设定haproxy的调度器连接至服务器的超时时间,时间越长越好,这个针对tcp模式
timeout http-request
针对client连接调度器,这个专门用于http协议,如果客户发送的http协议报文非常打需要几次才能发送过哎,可以设置这个
timeout client-fin
针对client一侧的半关闭状态的维持时间(client到调度器),什么是半关闭?在四次挥手的时候由client发起(谁发起谁断开),但是有一些情况比如client的连接时长超时,server自己主动关闭,但是可以容忍client继续连接他,这个时候的状态就是半关闭,所以client-fin就是设置这个时间的
timeout server-fin
针对server一侧半关闭状态的维持时间(调度器到server)
日志系统
访问控制
常用的leyword
use_backend
defaults_backend
acl
acl不用细讲直接看格式 ,它用于frontend,listen,backend
acl < aclname > < criterion > [ flag ] [ operator ] [ < value > ]…
< aclname > 区分大小写
< criterion >:检查那些内容四层
be_id:integer //针对backend id
dst:ip //针对目标ip进行匹配,value是ip
src:ip //针对源ip进行匹配
dst_conn:integer //针对目标主机套接字的连接数量
dst_port:integer //针对目标端口
src_port:integer //针对源端口
fe_id:integer //针对frontend id七层
path:strng //精确匹配一个路径比如path /etc/sysconfig/network-script
path_beg:string //模糊匹配字符开头,比如path_beg /etc 这个是匹配以/etc开头的字符
path_dir:string //模糊匹配一个子dir
path_end:string //按照以什么什么结尾模糊匹配path_end /network-script,匹配以/network-script结尾的路径
path_len:string //以长度匹配
path_reg:string //以正则表达式的方式进行匹配,< operator >:指定操作比如大于什么小于什么value
eq,ge,gt,le,lt
< value >:criterion比较的值它可以是
boolean:bool
integer:整数
ip address /network:ip地址端口等网络地址
string:支持前缀匹配,后缀匹配,精准匹配
regular expression:正则表达式匹配
hex block:16进制(提高性能)< flag >
-i:忽略大小写
-n:进制dns反向解析
-u:前置每个acl不能重名,默认acl可以重名,如果acl重名就是或||取交集,满足任意一个acl就行acl 逻辑关系
AND :&&
OR:||
!:非
多个acl默认是AND关系也就是说匹配的条件要都满足acl,如果加上了OR,才是或关系
实例listen stats acl allowstats src 172.X.X.X //定义一个acl,acl主要用于匹配 http-request deny deny_status 401 if ! allowstats //acl的操作条件 stats enable mode http
block //haproxy 2.1之后用http-request deny代替
我们之前定义了acl,这里到余下几个关键字都是操作acl的也就是acl操作,acl只是匹配真正的操作在如下几个,block专门用于block7层的协议,格式如下
block {if | unless} < condition > //condition一般都是acl,if acl代表匹配acl然后block
http-request {allow | deny}
用法和block差不多,就是它可以直接指定返回的错误码
http-request deny [deny_status < status >] {if | unless} < condition >
实例acl all src 0.0.0.0/0.0.0.0 acl allowstats src 172.x.x.x http-request deny if all http-request allow if allowstats //2个acl取交集
req.hdr
此匹配是匹配request的header,如果header的某一项包含什么什么信息我们都可以过滤出来,然后req.hdr == hdr 他有如下形式
hdr_beg([< name >[,< occ >]]) : prefix match
hdr_dir([< name >[,< occ >]]) : subdir match
hdr_dom([< name >[,< occ >]]) : domain match
hdr_end([< name >[,< occ >]]) : suffix match
hdr_len([< name >[,< occ >]]) : length match
hdr_reg([< name >[,< occ >]]) : regex match
hdr_sub([< name >[,< occ >]]) : substring match
示例
frontend XXX
acl bad_browser hdr_reg(User-Agent) .*curl. * //所有客户端包含curl的都过滤出来
http_request deny if bad_brodser //阻塞bad_browser这个acl
use_backend
use_backend也是用于acl中的,他和default_backend不同的是,default_backend是默认一个front使用一个backend,而use_backend是在某个acl下使用这个backend(搭配if),比如
frontend myweb bind *:80 ... ... ... acl static path_end .jpg .png .jpeg .gif .txt //匹配请求的路径是以这些静态资源结尾的请求,path是7层检测 use_backend staticsrvs if static //如果匹配到static这个acl就使用staticsrvs这个backend backend staticsrvs server staticsrv1 X.X.X.X:80 check server staticsrv2 X.X.X.X:8080 check balance roundrobin
tcp-request connection