Haproxy基础知识 -运维小结

[param*]：server后可加的参数weight ：权重，默认为1maxconn ：当前server的最大并发连接数backlog ：当server的连接数达到上限后的后援队列长度backup：设定当前server为备用服务器check：对当前server做健康状态检测，只用于四层检测

disabled：标记为不可用redir ：将发往此server的所有GET和HEAD类的请求重定向至指定的URLcookie ：为当前server指定cookie值，实现基于cookie的会话黏性。

基于cookie的session sticky的实现

4.3) 实现图形化配置页面stats enable 添加这条参数后会在web页面启用统计页；在frontend段添加stats enable ，重启haproxy。浏览器访问172.18.43.62/haproxy?stats即可。

listen admin    bind 192.168.43.62:6666    stats enable    stats uri /status    stats realm "haproxy info"    stats auth ha1:centos    stats hide-version    stats refresh 5s    stats admin if TRUE

listen ssh    bind :22022    balance leastconn    mode tcp    server sshsrv1 172.16.100.6:22 check    server sshsrv2 172.16.100.7:22 check

4.5) forwardfor配置语法 ：option forwardfor [ except ] [ header ] [ if-none ]在由haproxy发往后端主机的请求报文中添加“X-ForwardedFor”首部，其值为前端客户端的地址；用于向后端主发送真实的客户端IP    [ except ]：请求报请来自此处指定的网络时不予添加此首部，如haproxy自身所在网络    [ header ]：使用自定义的首部名称，而非“XForwarded-For”    [ if-none ] 如果没有首部才添加首部，如果有使用默认值默认defaults中有一条配置option forwardfor       except 127.0.0.0/8若想后端日志记录真实请求客户端IP，需更改后端两台服务器配置文件

五. ACL灵活转发详解acl：访问控制列表（ACL）的使用提供了一个灵活的解决方案来执行内容交换，并且通常基于从请求中提取的内容、响应或任何环境状态进行决策，是haproxy的重要特色。

5.1) 语法acl [flags] [operator] []...： ACL名称，可使用字母 数字 : . - _区分字符大小写： 比较的标准和条件        dst 目标IP        dst_port 目标PORT        src 源IP        src_port 源PORT        示例： acl invalid_src src 172.16.100.200        -i 不区分大小写        -m 使用指定的pattern匹配方法        -n 不做DNS解析        -u 强制每个ACL必须唯一ID，否则多个同名ACL或关系        --   强制flag结束. 当字符串和某个flag相似时使用[operator]    匹配整数值： eq、 ge、 gt、 le、 lt    匹配字符串：        - exact match (-m str) :字符串必须完全匹配模式        - substring match (-m sub) :在提取的字符串中查找如果包含， ACL将匹配        - prefix match (-m beg) :在提取的字符串首部中查找模式，如果其中任何一个被发现， ACL将匹配        - suffix match (-m end) :将模式与提取字符串的尾部进行比较，如果其中任何一个匹配，则ACL进行匹配        - subdir match (-m dir) :查看提取出来的用斜线分隔（“/”）的字符串， 如果其中任何一个匹配，则ACL进行匹配        - domain match (-m dom) :查找提取的用点（“.”）分隔字符串，如果其中任何一个匹配，则ACL进行匹配的类型：    - boolean    - integer or integer range    - IP address / network    - string (exact, substring, suffix, prefix, subdir,domain)    - regular expression    - hex block

5.2) 匹配条件进阶(1)base : string返回第一个主机头和请求的路径部分的连接，该请求从第一个斜杠开始，并在问号之前结束,对虚拟主机有用;://:@:/;?#    base : exact string match      #字符串匹配    base_beg : prefix match       #前缀匹配    base_dir : subdir match            #目录匹配    base_dom : domain match       #域名匹配    base_end : suffix match       #后缀匹配    base_len : length match      #长度    base_reg : regex match        #正则    base_sub : substring match       #字符串

(2)path : string提取请求的URL路径，该路径从第一个斜杠开始，并在问号之前结束（无主机部分）;://:@:/;?#    path : exact string match    path_beg : prefix match    path_dir : subdir match    path_dom : domain match    path_end : suffix match    path_len : length match    path_reg : regex match    path_sub : substring match

例：acl adminpath path_beg  -i  /admin acl imagefile  path_end  .jpg  .png   .bmp

(3)url : string提取请求中的URL。 一个典型的应用是具有预取能力的缓存，以及需要从数据库聚合多个信息并将它们保存在缓存中的网页门户入口    url : exact string match    url_beg : prefix match    url_dir : subdir match    url_dom : domain match    url_end : suffix match    url_len : length match    url_reg : regex match    url_sub : substring match

(4)req.hdr([[,]]) : string提取在一个HTTP请求报文的首部    hdr([[,]]) : exact string match    hdr_beg([[,]]) : prefix match    hdr_dir([[,]]) : subdir match    hdr_dom([[,]]) : domain match    hdr_end([[,]]) : suffix match    hdr_len([[,]]) : length match    hdr_reg([[,]]) : regex match    hdr_sub([[,]]) : substring match

(5)status : integer返回在响应报文中的状态码

5.3) acl作为条件时的逻辑关系    - 与：隐式（默认）使用    - 或：使用“or” 或 “||”表示    - 否定：使用“!“ 表示

同一个组名可定义多次示例：     if invalid_src invalid_port       #与关系    if invalid_src || invalid_port    #或    if ! invalid_src                        #非

5.4) 预定义ACL（部分）

5.5) 配置block拒绝访问语法：block { if | unless } 阻止7层请求if/unless一个条件匹配例1

例2(阻止curl访问)

acl bad_curl hdr_sub(User-Agent) -i curlblock if bad_curl

5.6) 指定backend组语法：use_backend [{if | unless} ]当if/unless一个基于ACL的条件匹配时切换指定backend（可实现动静分离）例1

acl imagefile path_end .jpg .png .bmpacl appfile path_end .phpuse_backend websrvs1 if imagefileuse_backend websrvs2 if appfile

例2

例3

acl webhost hdr(host) web.kevin.comacl apphost hdr(host) app.kevin.comuse_backend websrvs if webhostuse_backend appsrvs if apphost

5.8) tcp4层连接控制语法：tcp-request connection {accept|reject} [{if | unless} ]根据第4层条件对传入连接执行操作例子

listen sshbind :22022balance leastconnacl invalid_src src 172.16.200.2tcp-request connection reject if invalid_srcmode tcpserver sshsrv1 172.16.100.6:22 checkserver sshsrv2 172.16.100.7:22 check backup

[root@localhost ~]# cd /etc/pki/tls/certs/[root@localhost ~]# make /etc/haproxy/haproxy.pem

测试

向后端传递用户请求

六. 基于ACL的动静分离示例

frontend web *:80        acl url_static path_beg -i /static /images /javascript /stylesheets        acl url_static path_end -i .jpg .gif .png .css .js .html .txt .htm        use_backend staticsrvs if url_static        default_backend appsrvsbackend staticsrvs        balance roundrobin        server stcsrv1 172.16.100.6:80 checkbackend appsrvs        balance roundrobin        server app1 172.16.100.7:80 check        server app1 172.16.100.7:8080 checklisten stats       bind :9091       stats enable       stats auth admin:admin       stats admin if TRUE

分享一个小案例                                                                    如下的一个haproxy代理需求:

2.4) 默认跳转如果客户端访问的不是beijing.kevin.com与172.16.51.171，这两个地址的话，要把请求全部分发到172.16.51.178:8080上。

proxy.cfg配置内容如下:

补充下ACL规则的一些说明

ACL（Access Control List）访问控制列表，HAProxy中的ACL的匹配条件和控制条件有许多种，功能很强大，可以通过源地址、源端口、目标地址、目标端口、请求的资源类型、请求的主机等。

haproxy的ACL用于实现基于请求报文的首部、响应报文的内容或其它的环境状态信息来做出转发决策，这大大增强了其配置弹性。其配置法则通常分为两 步，首先去定义ACL，即定义一个测试条件，而后在条件得到满足时执行某特定的动作，如阻止请求或转发至某特定的后端。定义ACL的语法格式：acl [flags] [operator] []

aclname：自定义acl的名称，必填项，只能是大小写、数字、'-'、'_'、'.'、'：' , 也就是说这个是定义ACL名称，区分字符大小写，且其只能包含大小写字母、数字、-(连接线)、_(下划线)、.(点号)和:(冒号)；haproxy中，acl可以重名，这可以把多个测试条件定义为一个共同的acl；criterion：表示检查那些数据或内容，例如USERAGENT这个首部的值. 测试标准，即对什么信息发起测试；测试方式可以由[flags]指定的标志进行调整；而有些测试标准也可以需要为其在之前指定一个操作符[operator]；　　　 四个最为常用的criterion为：　　　　　src：ip 源IP　　　　　src_port：integer 源端口　　　　　dst：ip 目标IP　　　　　dst_port：integer 目标端口flags：定义控制条件，例如是否区分字符大小写等，flags的可选参数如下：　　　 　-i   忽略字符大小写　　　 　-m   启用特定的匹配方式，一般不用　　　 　-n   禁止DNS反向解析　　　 　-u   不允许aclname重复，默认是可以重名的，当两个acl的名称相同时，运算为或机制。            --    标志符的强制结束标记，在模式中的字符串像标记符时使用；operator：判断匹配条件，与相比较的条件　　　　若匹配整数值：eq,ge,gt,le,lt　　　　若匹配字符串：value： 访问控制的具体内容或值。这是acl测试条件支持的值。value的类型如下：　　　　boolean：布尔值　　　　integer or integer range：整数或整数范围. 如1024:65535表示从1024至65535；仅支持使用正整数(如果出现类似小数的标识，其为通常为版本测试)，且支持使用的操作符有5个，分别为eq、ge、gt、le和lt；　　　　IP address/network：网络地址　　　　string(exact, substring, suffix, prefix, subdir, domain)：字符串. 支持使用“-i”以忽略字符大小写，支持使用“\”进行转义；如果在模式首部出现了-i，可以在其之前使用“--”标志位；  　　　　regular expression：正则表达式　　　　hex block

同一个acl中可以指定多个测试条件，这些测试条件需要由逻辑操作符指定其关系。条件间的组合测试关系有三种：“与”(默认即为与操作)、“或”(使用“||”操作符)以及“非”(使用“!”操作符);

Haproxy 会话保持 (三种方式)

Haproxy保持客户端session会话同步的三种方式梳理如下:

============第一种方式: 源地址hash（用户IP识别）==========haroxy 将用户IP经过hash计算后 指定到固定的真实服务器上（类似于nginx 的IP hash 指令）。缺陷: 当后端一台服务器挂了以后会造成部分session丢失。

配置示例:

===========第二种方式: 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添加的内容。

配置示例:

特别注意:   rewrite | insert | prefix   这三个参数相互排斥，只能选一!rewrite: 表示cookie由服务器生成并且haproxy会在其值中注入该服务器的标识符;此关键字不能在HTTP隧道模式下工作。

insert: 表示如果客户端没有cookie信息且有权限访问服务器时，持久性cookie必须通过haproxy穿插在服务器的响应报文中。当服务器收到相同名称的cookie并且没有“preserve（保存）”选项时，将会移除之前已存的cookie信息。因此，insert可视作"rewrite"的升级版。cookie信息仅仅作为会话cookie且不会存到客户端的磁盘上。默认除非加了“indirect(间接)”选项，否则服务器端会看到客户端端发送的cookie信息。由于缓存的影响，最好加上“nocache”或“postonly”选项。

prefix: 表示不依赖专用的cookie做持久性，而是依赖现成的。用在某些特殊的场景，如客户端不支持一个以上的cookie和应用程序需求它。每当服务器建立一个名为的cookie时，它将以服务器的标识符和分隔符为前缀。来自于客户端的请求报文中的前缀将会被删除以便服务器端能识别出它所发出的cookie，由于请求和响应报文都被修改过，所以此模式不能工作在隧道模式中。且不能和“indirect”共用，否则服务器端更新的cookie将不会被发到客户端. indirect: 指定此选项时，将不会向客户端发送服务器已经处理过请求的且可用的cookie信息。如果服务器设置这样一个cookie本身，它将被删除，除非“保存”选项也设置。在“插入”模式下，将从发送给服务器的请求中删除cookie，使持久机制从应用程序的角度完全透明。

nocache: 当客户端和haproxy间存在缓存时，使用此选项和insert搭配最好，以便确保如果一个cookie需要被插入时，可被缓存的响应会被标记成不可缓存。这很重要，举个例子：如果所有的持久cookie被添加到一个可缓存的主页上，之后所有的客户将从外部高速缓存读取页面并将共享相同的持久性cookie，会造成服务器阻塞。

在LB服务器上配置好HAProxy后，LB服务器将接受用户的所有请求。如果一个用户请求不包含任何cookie，那这个请求将被HAProxy转发到一台可用的WEB服务器。可能是webA,webB，webC或webD。然后HAProxy将把处理这个请求的WEB服务器的cookie值插入到请求响应中。如SERVERID=A。当这个客户端再次访问并在HTTP请求头中带有SERVERID=A,HAProxy将会把它的请求直接转发给webA处理。在请求到达webA之前，cookie将被移除，webA将不会看到这个cookie。如果webA不可用，对应的请求将被转发到其他可用的WEB服务器，相应的cookie值也将被重新设置。

==============第三种方式: 基于session识别 ============haproxy 将后端服务器产生的session和后端服务器标识存在haproxy中的一张表里。客户端请求时先查询这张表。配置参数：appsession JSESSIONID len 64 timeout 5h request-learn

配置示例:

2) 由于一些原因，一些客户端不能识别多个cookie，并且后端应用已经设置了cookie，如果HAProxy再对响应插入cookie后，这些客户端可能不能识别cookie。这种情况下，可以使用cookie的prefix模式。

5) 在有些情况下，一些用户会将他们的浏览器的cookie功能关闭。这时候可能没法访问WEB服务器的内容。这种情况下，可以使用HAProxy的 source 负载均衡算法替代 roundroubin算法。source 算法可以确保来自同一个IP的所有请求都到达同一台WEB服务器，但是前提是，可用的服务器的数量保持不变。

6) 不要在一个小型网络和代理服务器后面使用source 算法，因为请求分发会不太公平，但是在大型内部网络或互联网上使用source算法，转发效率很好。对于那些具有动态IP地址的客户端，只要它们能够接收cookie，那么请求转发就不会受到影响，因为HAProxy对cookie的处理具有较高优先级。

===========================================================================================以上总结的指令和参数都是为了设置或定义ACL匹配条件的，即ACL仅仅只是将匹配条件进行分类归纳而不进行处理。若要将定义好的ACL规则做处理，需下面参数来设置：

1) 当符合指定的条件时使用特定的backend，表示设置的backend名，if和unless为判断条件，为比较的对象，可以是ACL规则，要注意的是在if和unless后面可以接两个ACL，默认表示两个ACL同时满足时才use_backend执行。格式如下

use_backend [{if | unless} ] #Switch to a specific backend if/unless an ACL-based condition is matched.

2) 阻塞一个七层请求满足/不满足某一ACL匹配条件。格式如下

block { if | unless } #Block a layer 7 request if/unless a condition is matched

例如

acl invalid_src src 192.18.29.101 #acl匹配条件为源地址为192.18.29.101，acl名为invalid_srcblock if invalid_src　　　　　　　　 #阻断满足名为invalid_src的acl匹配条件errorfile 403 /etc/fstab 　　　　　　 #并定义错误页

4) 配置四层的请求访问控制

tcp-request connection {accept|reject} [{if | unless} ]

例如:

listen sshbind :22022balance leastconnacl invalid_src src 172.16.200.2 　　　　　　　　#定义acl匹配规则tcp-request connection reject if invalid_src #在四层拒绝满足名为invalid_src的acl匹配规则mode tcpserver sshsrv1 172.16.100.6:22 checkserver sshsrv2 172.16.100.7:22 check

=======ACL示例======要注意到的是acl关键字可用在frontend、listen、backend中，不能用在default中。

例1：设置HAProxy状态页，只允许指定IP访问，设置如下

listen stats #定义名称 bind *:9099 #监听在9099端口 acl sta src 192.168.29.1 #匹配名为sta且源IP地址为192.168.29.1的ACL规则 block if ! sta #阻断不匹配sta规则的所有条件，!为非 stats enable #启用stats页 stats uri /myhaproxy?admin #自定义stats页面uri stats realm "Hello World" stats auth admin:admin #设置状态页登录账号和密码

提示错误401，只需输入账号密码即可访问，方法为

说明IP为29.104的主机可以访问，并无限制。添加限制后

再用IP为29.104的主机访问效果如下

此时错误为403，而29.1的主机是可以访问的（图太大了就省略了），说明ACL控制生效了。

例3: 七层规则匹配七层ACL规则匹配中，常用的参数是path，它用来做URL规则匹配，path包括以下参数:path :   精确匹配path_beg :   匹配字符串开头的所有内容path_dir :   子路径匹配path_dom :  域名匹配path_end :   匹配字符串结尾的所有内容path_len :   字符串长度匹配path_reg :   正则表达式匹配path_sub :  域名子串匹配

下面来举一个使用path的具体例子，选两台主机，安装Nginx并用Nginx虚拟为4台主机，两台用来处理图片请求，两台用来处理文本请求，利用HAProxy负载均衡的ACL控制机制实现，结构图如下：

1) 在192.168.29.102上添加监听8080端口的虚拟主机（安装的是Nginx），修改Nginx配置，在主配置中添加如下信息

server { listen 80 default_server; listen [::]:8080 default_server; server_name _; root /usr/share/nginx/html/test; #路径要修改，尽量不使用默认，尽量模拟为两台不同物理机的效果 # Load configuration files for the default server block. include /etc/nginx/default.d/*.conf; location / { } error_page 404 /404.html; location = /40x.html { } error_page 500 502 503 504 /50x.html; location = /50x.html { } }

2) 在80端口的主机root目录下创建文件static.txt，内容为static 1；在8080端口主机root目录下创建文件static.txt，内容为static 2。重启Nginx服务，并确保能正常访问，如下图

3) 用同样的方法在192.168.29.103上创建分别监听在80和8080端口的虚拟主机，并在根目录下创建图片文件，确保能正常访问,如下图：

4) 在主机192.168.29.101上配置HAProxy

frontend myweb bind *:80 acl image path_end .png #匹配以.png结尾的path规则 acl txt path_end .txt #匹配以.txt结尾的path规则 use_backend imagesv if image #将规则image负载均衡到服务器组imagesv use_backend txtsv if txt　　#将规则txt负载均衡至服务器组txtsv default_backend app #默认组，无匹配时负载均衡至此backend imagesv balance roundrobin server image1 192.168.29.103:80 check server image2 192.168.29.103:8080 checkbackend txtsv balance roundrobin server txt1 192.168.29.102:80 check server txt2 192.168.29.102:8080 checkbackend app balance leastconn cookie server insert nocache server app1 192.168.29.102:80 check cookie svr1 server app2 192.168.29.103:80 check cookie svr2

配置完成后重启HAProxy，分别访问192.168.29.101/image.png和192.168.29.101/static.txt，并刷新，会发现内容会不停变化，如下图

这说明ACL规则培植成功，HAProxy会根据请求的结尾来判断负载均衡规则。简单总结:  上面举了3个很简单的HAProxy ACL访问控制的例子，虽然例子中的配置很粗糙，但也可以初步领略到HAProxy有着比较智能的负载均衡功能，在后面的博客中我会更深入的介绍HAProxy的细节配置与调优

================Haproxy ACL规则小例==============1) 按请求的主机头(名)负载[root@localhost ~]# cat haproxy.cfg

2) 其它ACL规则

use_backend 参数or      用于匹配多个acl 名称 default_backend     没有满足条件的时候使用默认的后端服务器

========HAProxy 七层层模型下强大的ACL规则配置示例========

use_backend test-proxy-srv-a if host_ause_backend test-proxy-srv-b if host_buse_backend test-proxy-srv-c if url_policydefault_backend test-proxy-srv-default

当然acl还有更多的用法，如下:acl url_static path_end .gif .png .jpg .css .jsacl host_www hdr_beg(host) -i  wwwacl host_static hdr_beg(host) -i img. video. download. ftp.

use_backend static if host_static || host_www url_staticuse_backend www if host_wwwdefault_backend server_cache

第一个acl，通过path_end参数定义请求的url以.gif,.png,.jpg,.css,.js结尾时返回TRUE第二个acl,通过hdr_beg(host)参数定义如果客户端以www开头的域名发送请求时返回TRUE第三个acl,也是通过hdr_beg(host)参数定义以img.,video.,download.,ftp.开头域名发送请求返回TRUE第四行backend，定义了当请求需同时满足host_static与url_static时，或者满足host_www与url_static时请求将发往名为static 的backend第五行backend,定义了当请求满足host_www规则时，请求发往名为www的backend第六行backend，定义将用户请求默认调度到名为server-cache的backend

以上就是Haproxy的ACL常用控制用法，基本上可以满足日常负载需求。

========================设置haproxy负载均衡的最大并发连接数=======================

从三个方面来进行设置a) 查看内核[root@haproxy-test ~]# sysctl -a | grep filefs.file-nr = 1024 0 386459fs.file-max = 386459b) 查看应用层面的需求[root@haproxy-test ~]# vim /usr/local/haproxy/conf/haproxy.cfgglobal #全局参数设置 maxconn 65535 #设置最大连接数c) 更改系统层面[root@haproxy-test ~]# vim /etc/security/limits.conf #最后一行增加* - nofile 65535

===========================下面分析一个haproxy的负载均衡配置=============================

==========================整体总结下Haproxy的参数说明============================

一. Haproxy 配置说明haproxy的配置段有"global"，"defaults","listen","frontend"和"backend"等:global: 配置中的参数为进程级别的参数，且通常与其运行的操作系统有关defaults： 用于为所有其他配置段提供默认参数，这配置默认配置参数可由下一个"defaults"所重新设定forntend： 用于定义一系列监听的套接字，这些套接字可以接受客户端请求并与子建立连接backend: 用于定义一系列"后端"服务器，代理将会将对应客户端的请求转发至这些服务器listen: 用于定义通过关联"前段"和"后端"一个完整的代理，通常只对TCP流量有用

所有代理的名称只能使用大写字母、小写字母、数字、-（中线）、_（下划线）、.(点号)和：（冒号）。此外，ACL名称会区分大小写.

时间格式一些包含了值得参数表示时间，如超时时长。这些值一般都以毫秒为单位，但也可以使用其他的时间单位做后缀，如us（微妙，1/10000000秒），ms（毫秒，1/1000秒），s（秒），m（分钟），h（小时），d（天）

二. global 全局配置chroot: 修改haproxy的工作目录至指定的目录，并在放弃权限之前执行chroot（）操作，可以提升haproxy的安全级别，不过需要注意的是确保指定的目录为空目录且任何用户均不能有写权限;daemon: 让haproxy以守护进程的方式工作于后台，其等同于"-D"选项的功能，当然，也可以在命令行中以"-db"选项将其禁用;gid: 以指定的GID运行haproxy，建议使用专用于运行haproxy的GID，以避免因权限带来的风险;group: 同gid，不过这里为指定的组名;uid: 已指定的UID身份运行haproxy进程;user: 同uid，但这里使用的为用户名;log: 定义全局的syslog服务器，最多可以定义两个;nbproc: 指定启动的haproxy进程个数，只能用于守护进程模式的haproxy；默认为止启动一个进程，鉴于调试困难等多方面的原因，一般只在但进程仅能打开少数文件描述符的场中才使用多进程模式;pidfile: pid文件的存放位置;ulimit-n:设定每个进程所能够打开的最大文件描述符，默认情况下其会自动进行计算，因此不建议修改此选项;node: 定义当前节点的名称，用于HA场景中多haproxy进程共享同一个IP地址时;description: 当前实例的描述信息;maxconn: 设定每个haproxy进程所接受的最大并发连接数，其等同于命令行选项"-n"，"ulimit-n"自动计算的结果正式参照从参数设定的;maxpipes: haproxy使用pipe完成基于内核的tcp报文重组，此选项用于设定每进程所允许使用的最大pipe个数，每个pipe会打开两个文件描述符，因此，"ulimit -n"自动计算的结果会根据需要调大此值，默认为maxcoon/4;noepoll: 在linux系统上禁用epoll机制;nokqueue: 在BSE系统上禁用kqueue机制;nopoll: 禁用poll机制;nosepoll: 在linux系统上禁用启发式epoll机制;nosplice: 禁止在linux套接字上使用tcp重组，这会导致更多的recv/send调用，不过，在linux2.6.25-28系列的内核上，tcp重组功能有bug存在;spread-checks<0..50,in percent>: 在haprorxy后端有着众多服务器的场景中，在紧缺是时间间隔后统一对中服务器进行健康状况检查可能会带来意外问题，此选项用于将检查的时间间隔长度上增加或减少一定的随机时长，为当前检查检测时间的%;tune.bufsize: 设定buffer的大小，同样的内存条件下，较小的值可以让haproxy有能力接受更多的并发连接，较大的值了可以让某些应用程序使用较大的cookie信息，默认为16384，其可以在编译时修改，不过强烈建议使用默认值;tune.chksize: 设定检查缓冲区的大小，单位为字节，更大的值有助于在较大的页面中完成基于字符串或模式的文本查找，但也会占用更多的系统资源，不建议修改;tune.maxaccept: 设定haproxy进程内核调度运行时一次性可以接受的连接的个数，较大的值可以带来较大的吞吐量，默认为单进程模式下为100，多进程模式下为8，设定为-1可以禁止此限制，一般不建议修改;tune.maxpollevents: 设定一次系统调用可以处理的事件最大数，默认值取决于OS,其至小于200时可介于带宽，但会略微增大网络延迟，但大于200时会降低延迟，但会稍稍增加网络带宽的占用;tune.maxrewrite: 设定在首部重写或追加而预留的缓存空间，建议使用1024左右的大小，在需要更大的空间时，haproxy会自动增加其值;tune.rcvbuf.client: 设定内核套接字中客户端接收缓存区的大小，单位为字节，强烈推荐使用默认值;tune.rcvbuf.server: 设定内核套接字中服务器接收缓存区的大小，单位为字节，强烈推荐使用默认值;tune.sndbuf.client: 设定内核套接字中客户端发送缓存区的大小，单位为字节，强烈推荐使用默认值;tune.sndbuf.server: 设定内核套接字中服务器端发送缓存区的大小，单位为字节，强烈推荐使用默认值;debug: 调试模式，输出启动信息到标准输出;quiet: 安装模式，启动时无输出;

三. defaults 默认配置defaults：用于为所有其他配置段提供默认参数，这配置默认配置参数可由下一个"defaults"所重新设定

1) balancebalance [] balance url_param [check_post []]定义负载均衡算法，可用于"defaults"、"listen"和"backend"中。用于在负载均衡场景中挑选一个server，其仅用于持久信息不可用的条件下或需要将一个连接重新派发至另一个服务器时。支持的算法有：

roundrobin：基于权重进行轮询，在服务器的处理时间保持均匀分布时 ，这是最平衡、最公平的算法。此算法是动态的，这表示某权重可以在运行时进行调整，不过，在设计上，每个后端服务器仅能最多支持4128个连接; 即客户端请求每次都转发到不同的节点服务器上;

static-rr：基于权重进行轮询，与roundrobin类似，但是为静态方法，在运行时调整期后端权重不会生效，不过，其在后端服务器连接数上没有限制;

leastconn：新的连接强求笨哦派发至具有最少连接数目的后端服务器，在有这较长会话的场景中推荐使用此算法，如LDAP、SQL等。其并不太适合用于较短会话的应用层协议，如HTTP，此算法是动态的，可以在运行时调整其权重;

source：将请求的源地址进行hash运算，并有后端的服务器的权重总数相处后派发至某匹配的服务器，这可以使得同一个客户端IP的请求始终被派发至某特定的服务器，不过，当服务器权重总数发生变化时，如某服务器宕机或者添加新服务器，许多的请求可能会被派发至与此前请求不同的服务器，常用于负载均衡无cooki功能的基于TCP的协议，默认为动态，不过可以使用hash-type修改此特性;

uri：对URI的左半部分（“问号”标记之前的部分）或整个URI进行hash运算，并由服务器的总权重相除后派发至某匹配的服务器；这可以使得对同一个URI的请求总是派发至某匹配的服务器，除法服务器的权重总数发生了变化，此算法常用于代理缓存或反病毒代理以提高缓存的命中率，需要注意的是，此算法仅应用于HTTP后端服务器场景，其默认为静态算法，不过可以使用hash-type修改此特性;

url_param：通过为URL指定的参数在每个HTTP GET请求中将会被索引，日过找到了指定的参数且其通过等于号“=”被赋予了一个值，那么此值将被执行hash运算并被服务器的总权重相处后派发至某匹配的服务器，此算法可以通过追踪请求中的用户标识进而确保同一个用户的ID请求被发送同一个特定的服务器，除非服务器的总权重发生了变化；如果某请求中没有出现指定的参数或其没有有效值，则使用轮询算法对其想用请求进行调度，此算法默认为静态，不过可以使用hash-type修改此特性;

har（）:对于每个HTTP请求，通过指定的HTTP首部将会被检索，如果对于那个的首部没有出现或其没有有效值，则使用轮询算法对响应请求进行调度，其有一个可选项“use_domain_only”可以指定检索类似host类的首部时仅计算域名部分以降低hash算法的运算量，此算法默认为静态，不过可以使用hash-type修改此特性;

2) bindbind [