haproxy 常用acl规则与会话保持
一、常用的acl规则
haproxy的ACL用于实现基于请求报文的首部、响应报文的内容或其它的环境状态信息来做出转发决策，这大大增强了其配置弹性。其配置法则通常分为两 步，首先去定义ACL，即定义一个测试条件，而后在条件得到满足时执行某特定的动作，如阻止请求或转发至某特定的后端。定义ACL的语法格式如下。
acl <aclname> <criterion> [flags] [operator] <value> ...
<aclname>：ACL名称，区分字符大小写，且其只能包含大小写字母、数字、-(连接线)、_(下划线)、.(点号)和:(冒号)；haproxy中，acl可以重名，这可以把多个测试条件定义为一个共同的acl；
<criterion>：测试标准，即对什么信息发起测试；测试方式可以由[flags]指定的标志进行调整；而有些测试标准也可以需要为其在<value>之前指定一个操作符[operator]；
[flags]：目前haproxy的acl支持的标志位有3个：
-i：不区分<value>中模式字符的大小写；
-f：从指定的文件中加载模式；
--：标志符的强制结束标记，在模式中的字符串像标记符时使用；
<value>：acl测试条件支持的值有以下四类：
整数或整数范围：如1024:65535表示从1024至65535；仅支持使用正整数(如果出现类似小数的标识，其为通常为版本测试)，且支持使用的操作符有5个，分别为eq、ge、gt、le和lt；
字符串：支持使用“-i”以忽略字符大小写，支持使用“\”进行转义；如果在模式首部出现了-i，可以在其之前使用“--”标志位；
regular expressions：正则表达式：其机制类同字符串匹配；
IP addresses and networks：IP地址及网络地址；
同一个acl中可以指定多个测试条件，这些测试条件需要由逻辑操作符指定其关系。条件间的组合测试关系有三种：“与”(默认即为与操作)、“或”(使用“||”操作符)以及“非”(使用“!”操作符)。
常用的测试标准(criteria)：
1. be_sess_rate(backend) <integer>
用于测试指定的backend上会话创建的速率(即每秒创建的会话数)是否满足指定的条件；常用于在指定backend上的会话速率过高时将用户请求转发至另外的backend，或用于阻止攻击行为。例如：
backend dynamic
mode http
acl being_scanned be_sess_rate gt 50
redirect location /error_pages/denied.html if being_scanned
2. fe_sess_rate(frontend) <integer>
用于测试指定的frontend(或当前frontend)上的会话创建速率是否满足指定的条件；常用于为frontend指定一个合理的会话创建速率的
上限以防止服务被滥用。例如下面的例子限定入站邮件速率不能大于50封/秒，所有在此指定范围之外的请求都将被延时50毫秒。
frontend mail
bind :25
mode tcp
maxconn 500
acl too_fast fe_sess_rate ge 50
tcp-request inspect-delay 50ms
tcp-request content accept if ! too_fast
tcp-request content accept if WAIT_END
3. hdr(header) <string>
用于测试请求报文中的所有首部或指定首部是否满足指定的条件；指定首部时，其名称不区分大小写，且在括号“()”中不能有任何多余的空白字符。测试服务器
端的响应报文时可以使用shdr()。例如下面的例子用于测试首部Connection的值是否为close。
hdr(Connection) -i close
4. method <string>
测试HTTP请求报文中使用的方法。
5. path_beg <string>
用于测试请求的URL是否以<string>指定的模式开头。下面的例子用于测试URL是否以/static、/iilannis、/javascript或/stylesheets头。
acl url_static path_beg -i /static /iilannis /javascript /stylesheets
#url 目录
6. path_end <string>
用于测试请求的URL是否以<string>指定的模式结尾。例如，下面的例子用户测试URL是否以jpg、gif、png、css或js结尾。
acl url_static path_end -i .jpg .gif .png .css .js
#url 结尾文件
7. hdr_beg <string>
用于测试请求报文的指定首部的开头部分是否符合<string>指定的模式。例如，下面的例子用记测试请求是否为提供静态内容的主机img、video、download或ftp。
acl host_static hdr_beg(host) -i img. video. download. ftp.
8. hdr_end <string>
用于测试请求报文的指定首部的结尾部分是否符合<string>指定的模式。例如，下面的例子用记测试请求是否为
9. hdr_reg <string>
正则匹配
acl bbs hdr_reg(host) -i ^(bbs.test.com|shequ.test.com|forum)
use_backend bbs_pool if bbs or bbs_path #注意 "or"
二、会话保持
haproxy负载均衡保持客户端和服务器Session的三种方式:
2.1 用户源IP 识别
haroxy 将用户IP经过hash计算后 指定到固定的真实服务器上（类似于nginx 的IP hash 指令）
配置指令 balance source
backend www
mode http
balance source
server web1 192.168.0.150:80 check inter 1500 rise 3 fall 3
server web2 192.168.0.151:80 check inter 1500 rise 3 fall 3
2.2 cookie 识别
haproxy 将WEB服务端发送给客户端的cookie中插入(或添加加前缀)haproxy定义的后端的服务器COOKIE ID。
配置指令例举 cookie SESSION_COOKIE insert indirect nocache
用firebug可以观察到用户的请求头的cookie里 有类似" Cookie jsessionid=0bc588656ca05ecf7588c65f9be214f5;
SESSION_COOKIE=app1"
SESSION_COOKIE=app1就是haproxy添加的内容。
backend COOKIE_srv
mode http
cookie SESSION_COOKIE insert indirect nocache
server web1 192.168.0.150:80 cookie 1 check inter 1500 rise 3 fall 3
server web2 192.168.0.151:80 cookie 2 check inter 1500 rise 3 fall 3
2.3 session 识别
haproxy 将后端服务器产生的session和后端服务器标识存在haproxy中的一张表里。客户端请求时先查询这张表。
配置指令：appsession <cookie> len <length> timeout <holdtime>
配置指令例举 appsession JSESSIONID len 64 timeout 5h request-learn
配置举例
backend APPSESSION_srv
mode http
appsession JSESSIONID len 64 timeout 5h request-learn
server web1 192.168.0.150:80 cookie 1 check inter 1500 rise 3 fall 3
server web2 192.168.0.151:80 cookie 2 check inter 1500 rise 3 fall 3
