Haproxy 常用acl规则与会话保持

theoforce

　　一、常用的acl规则
　　haproxy的ACL用于实现基于请求报文的首部、响应报文的内容或其它的环境状态信息来做出转发决策，这大大增强了其配置弹性。其配置法则通常分为两步，首先去定义ACL，即定义一个测试条件，而后在条件得到满足时执行某特定的动作，如阻止请求或转发至某特定的后端。定义ACL的语法格式如下。
  acl   [flags] [operator]  ...
  ：ACL名称，区分字符大小写，且其只能包含大小写字母、数字、-(连接线)、_(下划线)、.(点号)和:(冒号)；haproxy中，acl可以重名，这可以把多个测试条件定义为一个共同的acl；
  ：测试标准，即对什么信息发起测试；测试方式可以由[flags]指定的标志进行调整；而有些测试标准也可以需要为其在之前指定一个操作符[operator]；
  [flags]：目前haproxy的acl支持的标志位有3个：
    -i：不区分中模式字符的大小写；
    -f：从指定的文件中加载模式；
    --：标志符的强制结束标记，在模式中的字符串像标记符时使用；
  ：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)

     用于测试指定的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)
     用于测试指定的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)
     用于测试请求报文中的所有首部或指定首部是否满足指定的条件；指定首部时，其名称不区分大小写，且在括号“()”中不能有任何多余的空白字符。测试服务器端的响应报文时可以使用shdr()。例如下面的例子用于测试首部Connection的值是否为close。
    hdr(Connection) -i close
4. method
    测试HTTP请求报文中使用的方法。
5. path_beg
     用于测试请求的URL是否以指定的模式开头。下面的例子用于测试URL是否以/static、/iilannis、/javascript或/stylesheets头。
    acl url_static       path_beg     -i   /static /iilannis /javascript /stylesheets
                                           #url 目录                                                
　　6. path_end
     用于测试请求的URL是否以指定的模式结尾。例如，下面的例子用户测试URL是否以jpg、gif、png、css或js结尾。
    acl url_static       path_end       -i    .jpg .gif .png .css .js
                                                 #url 结尾文件                                                                                 
　　7. hdr_beg
     用于测试请求报文的指定首部的开头部分是否符合指定的模式。例如，下面的例子用记测试请求是否为提供静态内容的主机img、video、download或ftp。
    acl host_static hdr_beg(host) -i img. video. download. ftp.
8. hdr_end
     用于测试请求报文的指定首部的结尾部分是否符合指定的模式。例如，下面的例子用记测试请求是否为9. hdr_reg

　　正则匹配

　　     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  len  timeout
　　配置指令例举 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