Haproxy commonly used ACL rules are held in session

I. Common ACL rules

The ACL of the

       Haproxy is used to make forwarding decisions based on the header of the request packet, the content of the response message, or other environmental state information, which greatly enhances its configuration flexibility. The configuration rule is usually divided into two steps, defining an ACL first, defining a test condition, and then executing a specific action when the condition is met, such as blocking the request or forwarding it to a specific backend. The syntax format for defining ACLs is as follows.

  ACLS <aclname> <criterion> [flags] [operator] <value> ...

  <aclname>:acl names, which are case-sensitive and can only contain uppercase and lowercase letters, numbers,-(connectors), _ (underscores),. ( DOT) and: (colon); in Haproxy, the ACL can have the same name, which can define multiple test conditions as a common ACL;
  <CRITERION>: test criteria, that is, what information is tested, and how it can be tested by [flags] The specified flags are adjusted, and some test criteria may need to be assigned an operator [operator] before <value>;
  [flags]: There are currently 3 flag bits supported by Haproxy ACLs:
    -I: The case of the pattern character in <value> is not distinguished;
   -F: Loads the schema from the specified file;
   -- : The force end tag of a marker, used in a string-like marker in a pattern;
  <VALUE>:ACL test conditions support the following four classes:
    integer or integer range: 1024 : 65535 indicates from 1024 to 65535; only positive integers are supported (if there is a decimal-like identity, which is typically version tested), and the supported operators are 5, EQ, GE, GT, le, and lt;
    String: Supports the use of "-I" to ignore the case of characters, support the use of "\" to escape, if I is present in the pattern header, you can use the "--" flag bit;   

Regular Expressions: Regular expression: its mechanism is similar to string matching;

IP addresses and NETWORKS:IP address and network address;
Multiple test conditions can be specified in the same ACL, which require a logical operator to specify its relationship. There are three types of combination test relationships between conditions: "with" (the default is the operation), "or" (using the | | operator) and "non" (use "!" operator).

Common Criteria for testing (criteria):
1. Be_sess_rate (Backend) <integer>

Used to test whether the rate of session creation on the specified backend (that is, the number of sessions created per second) satisfies the specified condition, and is commonly used to forward user requests to additional backend when the session rate on the specified backend is too high, or to block attack behavior. For example:

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>

Used to test whether the session creation rate on the specified frontend (or current frontend) satisfies the specified condition, and is often used to specify a reasonable limit on the session creation rate for frontend to prevent misuse of the service. For example, the following example restricts the inbound message rate to be greater than 50/second, and all requests outside this specified range will be delayed by 50 milliseconds.

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>

Used to test whether all headers or headers in the request message satisfy the specified condition, when the header is specified, its name is not case-sensitive, and there cannot be any extra white space characters in the parentheses "()". SHDR () can be used when testing server-side response messages. For example, the following example is used to test whether the value of the header connection is close.

HDR (Connection)-I close

4. Method <string>

Test the method used in the HTTP request message.

5. Path_beg <string>

Whether the URL used to test the request begins with a pattern specified by <string>. The following example is used to test whether the URL is in/static,/iilannis,/javascript, or/stylesheets headers.

ACL url_static path_beg-i/static/iilannis/javascript/stylesheets

6. Path_end <string>

Whether the URL used to test the request ends in a pattern specified by <string>. For example, the following example user tests whether the URL ends with JPG, GIF, PNG, CSS, or JS.

ACL url_static path_end-i. jpg. gif. png. css. js

                                                 #url End File

7. Hdr_beg <string>

Used to test whether the beginning of the specified header of the request message conforms to the <string> specified pattern. For example, the following example uses a test request for host IMG, video, download, or FTP that provides static content.

ACL host_static Hdr_beg (host)-I img. Video. Download. Ftp.

8. Hdr_end <string>

Used to test whether the end of the specified header of the request message conforms to the <string> specified pattern. For example, the following example uses the test request as

9. Hdr_reg <string>

Regular match

ACL BBS Hdr_reg (host)-I ^ (bbs.test.com|shequ.test.com|forum)

Second, session hold

Haproxy load balancing three ways to keep the client and server session:

2.1 User Source IP identification

Haroxy the User IP is hashed and assigned to the fixed real server (similar to the Nginx IP hash command)

Configuration directive Balance Source

Backend www

Mode http

Balance Source

Server Web1 192.168.0.150:80 check Inter rise 3 Fall 3

Server WEB2 192.168.0.151:80 check Inter rise 3 Fall 3

2.2 Cookie Recognition

Haproxy inserts (or adds prefixes) the server cookie ID of the backend defined by the Haproxy in the cookie that is sent to the client by the Web service side.

Configuration Instructions Example Cookie Session_cookie Insert indirect nocache

There is a similar "cookie Jsessionid=0bc588656ca05ecf7588c65f9be214f5" in the cookie of the user's request header that can be observed with firebug;

Session_cookie=app1 "

SESSION_COOKIE=APP1 is the content that Haproxy adds.

Backend Cookie_srv

Mode http

Cookie Session_cookie Insert Indirect nocache

Server Web1 192.168.0.150:80 Cookie 1 Check Inter rise 3 Fall 3

Server Web2 192.168.0.151:80 Cookie 2 Check Inter rise 3 Fall 3

2.3 Session Recognition

Haproxy the session and back-end server identities generated by the backend server are present in a table in Haproxy. This table is queried first when the client requests it.

Configuration directives: appsession <cookie> len <length> timeout

Configuration Instructions Example appsession Jsessionid len 5h request-learn

Configuration examples

Backend Appsession_srv

Mode http

Appsession Jsessionid Len 5h request-learn

Server Web1 192.168.0.150:80 Cookie 1 Check Inter rise 3 Fall 3

Server Web2 192.168.0.151:80 Cookie 2 Check Inter rise 3 Fall 3

Haproxy commonly used ACL rules are held in session