文章目录

• HAProxy简介
• • 四层调度
  • 七层调度
• HAProxy安装
• HAproxy基本配置
• • HAproxy配置段
  • • global
    • proxies
  • 日志系统
  • 访问控制
  • • 常用的leyword

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.g

root@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 > eg

option 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
eg

frontend 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进行hash

session 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