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