HAProxy详解

1. HAProxy概述

1.1 HAProxy简介

• HAProxy提供负载均衡以及基于TCP和HTTP应用的代理
• HAProxy只是http协议的方向代理，不提供缓存功能，但额外支持对tcp层对基于tcp通信的应用做LB
  • http协议的反向代理
  • tcp层的LB
• HAProxy的特性：
  • HAProxy实现了一种事件驱动、单一进程模型，此模型支持非常大的并发连接数
  • HAProxy中保存了数据的数据结构为弹性二叉树结构
• 代理服务器的调度算法：
  • 取模法
  • 一致性哈希算法
• LB负载均衡器：
  • TCP：
    • lvs，haproxy，nginx
  • application layer：
    • http：haproxy，nginx，ats，apache
    • mysql：mysql-proxy

1.2 HAProxy性能上的优势

• 单进程、事件驱动模型显著降低了上下文切换的开销及内存占用
• O(1)事件检查器（event check）允许其在高并发连接中对任何连接的任何时间实现即时探测
• 在任何可用的情况下，单缓冲（single buffering）机制能以不复制任何数据的方式完成读写操作，这会节约大量的CPU时钟周期及内存带宽
• 借助于Linux 2.6 (>= 2.6.27.19)上的splice()系统调用，HAProxy可以实现零复制转发(Zero-copy forwarding)
• 在Linux 3.5及以上的OS中还可以实现零复制启动(zero-starting)
• 内存分配器在固定大小的内存池中可以实现即时内存分配，这能够显著减少创建一个会话的时长
• 树型存储：侧重于使用弹性二叉树，实现了以O(log(N))的低开销来保持计数器命令、保持运行队列命令及管理轮询及最少连接队列
• 优化的HTTP首部分析：优化的首部分析功能避免了在HTTP首部分析过程中重读任何内存区域
• 精心地降低了昂贵的系统调用，大部分工作都在用户空间完成，如时间读取、缓冲聚合及文件描述符的启用和禁用等

1.3 负载均衡器的性能评估

1. 会话率：会话建立的速率
2. 会话并发能力：整体服务器的会话并发能力
3. 数据率：在所有会话上数据传输速率

1.4 正向代理与反向代理

• 正向代理中，proxy和client同属一个LAN，对server透明
• 反向代理中，proxy和server同属一个LAN，对client透明

 1.5 代理和缓存的作用

• 代理的作用：
  • web缓存（加速）、反向代理、内存路由（根据流量及内容类型等将请求转发至特定服务器）、转码器
  • 有些CDN会在代理服务器上添加Via首部
• 缓存的作用：
  • 减少冗余内容传输
  • 节省带宽、缓解网络瓶颈
  • 降低了对原始服务器的请求压力
  • 降低了传输延迟

2. HAProxy配置文件详解

2.1 配置文件格式

2.1.1 配置文件

• 配置文件：/etc/haproxy/haproxy.cfg
• 主程序：/usr/sbin/haproxy
• HAProxy的配置处理3类来主要参数来源：
  • 最优先处理的命令行参数，
  • global配置段，用于设定全局配置参数
  • proxy相关配置段，如“defaults”、“listen”、“frontend”和“backend”

2.1.2 简单的配置格式：

frontend        # 前端，指明它要监听在某个地址的某个端口上，能够接受客户端的请求的
    use_backend       # 指明所调用的后端组
    default_backend   # 指明的默认的后端组

backend         # 后端，定义后端服务器组
    balance           # 指定调度算法
    server            # 指定主机
    server

listen：        # 指明监听的地址和端口
    server            # 然后直接指明地址
        
default         # 默认的

2.1.3 简单的配置示例

• 配置一个监听在所有接口的80端口上HTTP Proxy服务，它转发所有的请求至后端监听在127.0.0.1:8000上的"server"

global
daemon
maxconn 25600

defaults
    mode http
    timeout connect 5000ms
    timeout client 50000ms
    timeout server 50000ms

frontend http-in 
    bind *:80                 # 监听在80端口上
    default_backend servers   # 默认转发到后端的servers组内

backend servers               # 定义后端的servers组
    server server1 127.0.0.1:8080 maxconn 32  

2.2 global配置内容详解

2.2.1 简单的global配置

# 这里日志只是转交给本地的local2设备，要在rsyslog中添加上local2的设备条目，记录到指定的文件中
log         127.0.0.1   local2   

chroot      /var/lib/haproxy         # 切换根目录，haproxy是被切换到这个目录下以安全模式运行的
pidfile     /var/run/haproxy.pid     # pid文件的保存位置
maxconn     4000                     # 最大连接数，这里比较保守，可以按需调整
user        haproxy                  # 进程启动时以haproxy用户的身份运行
group       haproxy       
daemon                               # 启动为守护进程

# turn on stats unix socket
stats socket /var/lib/haproxy/stats  # 本地访问统计数据时可以基于共享内存的方式进程通信

 注意：

• 记录日志时，要开启rsyslog服务，开启514/tcp和514/udp端口
  • 然后要加上对应设备的条目，以记录日志到指定的文件中：
  • local2.*       /var/log/haproxy.log

2.2.2 global配置进阶

进程管理及安全相关的参数：

• chroot <dir>
  • 修改haproxy的工作目录至指定的目录
  • 在放弃权限之前执行chroot()操作，可以提升haproxy的安全级别
  • 要确保指定的目录为空目录且任何用户均不能有写权限
• daemon：
  • 让haproxy以守护进程的方式工作于后台
• log <address> <facility> [max level [min level]]
  • 定义全局的syslog服务器，最多可以定义两个
• nbproc：
  • 指定启动的haproxy进程的个数，只能用于守护进程模式的haproxy
  • 默认只启动一个进程，鉴于调试困难等多方面的原因，一般只在单进程仅能打开少数文件描述符的场景中才使用多进程模式
• ulimit-n：
  • 设定每进程所能够打开的最大文件描述符数目，默认情况下其会自动进行计算，因此不推荐修改此选项

性能调整相关的参数：

• maxconn <number>
  • 设定每个haproxy进程所接受的最大并发连接数，其等同于命令行选项 “-n”
  • “ulimit -n” 自动计算的结果正是参照此参数设定的
• spread-checks <0..50, in percent>
  • 在haproxy后端有着众多服务器的场景中，在精确的时间间隔后统一对众服务器进行健康状况检查可能会带来意外问题
  • 此选项用于将其检查的时间间隔长度上增加或减小一定的随机时长
  • 0到50是百分比，可以选择向前百分之五十或者向后百分之五十

2.3 代理配置详解

代理相关的配置可以如下配置段中

• defaults <name>
  • “defaults”段用于为所有其它配置段提供默认参数，这配置默认配置参数可由下一个“defaults”所重新设定
• frontend <name>
  • “frontend”段用于定义一系列监听的套接字，这些套接字可接受客户端请求并与之建立连接
• backend <name>
  • “backend”段用于定义一系列“后端”服务器，代理将会将对应客户端的请求转发至这些服务器
• listen <name>
  • “listen”段通过关联“前端”和“后端”定义了一个完整的代理，通常只对TCP流量有用
  • Fronted和backend的组合体，比如haproxy实例状态监控部分配置
  • 组合的方式直接定义frontend及相关的backend

代理名称的使用规则：

• 所有代理的名称只能使用大写字母、小写字母、数字、-(中线)、_(下划线)、.(点号)和:(冒号)
• ACL名称会区分字母大小写

3. HAProxy配置文件中的关键字详解

3.1 balance

3.1.1 用法

• balance <algorithm> [ <arguments> ]
• balance url_param <param> [check_post [<max_wait>]]

3.1.2 作用

• 定义负载均衡算法，可用于“defaults”、“listen”和“backend”
• <algorithm>用于在负载均衡场景中挑选一个server
  • 其仅应用于持久信息不可用的条件下或需要将一个连接重新派发至另一个服务器时
• 指明调度算法：
  • 动态：权重可动态调整
  • 静态：调整权重不会实时生效

3.1.3 支持的算法

roundrobin：动态

• 基于权重进行轮询，动态算法，权重可以在运行时进行调整
• 每个后端主机最多支持4128个连接

static-rr：静态

• 基于权重进行轮询，静态算法，在运行时调整其服务器权重不会生效
• 每个后端主机支持的数量无上限

leastconn：动态

• 新的连接请求被被派发至具有最少连接数目的后端服务器
• 较长时间会话的场景中推荐此算法，如LDAP，SQL等
• 其不适用于较短会话的应用层协议，如HTTP

source：

• 将请求的源地址进行hash运算，并由后端服务器的权重总数相除后发至某匹配的服务器
  • 这可以使得同一个客户端IP的请求始终被发派至特定的服务器
  • 但当服务器权重总数发生变化时，如果某服务器宕机，许多客户端的请求可能会被派发至与此前请求不同的服务器
• 常用于负载均衡无cookie功能的基于TCP的协议
• 其默认为静态，不过也可以使用hash-type修改此特性，hash-type如果是map-based则就是静态的，consistent则为动态
• 使用示例：

  • balance  source
    server  web1  172.16.100.68:80  check   weight  1
    server  web2  172.16.100.69:80  check   weight  3

uri：

• 对URI的左半部分或整个URI进行hash运算，并由服务器的总权重相除后派发至某匹配的服务器
  • 这可以使得对同一个URI的请求总是被派发至特定的服务器，除非服务器的权重总数发生了变化
• 此算法常用于代理缓存或反病毒代理以提高缓存的命中率
• 此算法仅应用于HTTP后端服务器场景
• 其默认为静态算法，不过也可以使用hash-type修改此特性
• 使用示例：

  • balance   uri
    hash-type  consistent

url_param：

• 通过argument为Url指定的参数在每个HTTP GET请求中将会被检索
  • 如果找到了指定的参数且被赋予了一个值，那么此值将被执行hash运算并被服务器的总权重相除后派发至匹配的服务器
  • 在url中添加一个参数，然后把url中的url_param指定的那个参数的值做hash运算，并处除以总权重
• 此算法可以通过追踪请求中的用户标识进而确保同一个用户ID的请求将被送往同一个特定的服务器，除非服务器的总权重发生了变化
• 如果某请求中没有出现指定的参数或其没有有效值，则使用轮叫算法对相应请求进行调度
• 此算法默认为静态的，不过可以使用hash-type修改此特性

bdr(<name>)：

• 对于每个HTTP请求，通过<name>指定的HTTP首部将会被检索（根据请求报文中指定的http首部的值来进行调度，把指定的header的值做hash计算）
• 如果相应的首部没有出现或其没有有效值，则使用轮叫算法对相应的请求进行调度
• 此算法默认为静态的，不过其也可以用hash-type修改此特性
• 使用示例：

  • balance  hdr(User-Agent)
    hash-type  consistent

3.2 hash-type

3.2.1 用法

• hash-type  <method>

3.2.2 作用

• 定义用于将hash码映射至后端服务器的方法
• 其不能用于frontend区段
• 可用的方法有map-based和consistent，在大多数场景下推荐使用默认的map-based方法

3.2.3 可用的方法

map-based：（其实就是取模算法）

• hash表是一个包含了所有在线服务器的静态数组。
• 其hash值将会非常平滑，会将权重考虑在内，但其为静态方法
  • 对在线服务器的权重进行调整将不会生效，这意味着其不支持慢速启动
• 挑选服务器是根据其在数组中的位置进行的，
• 因此，当一台服务器宕机或添加了一台新的服务器时，大多数连接将会被重新派发至一个与此前不同的服务器上，
  • 对于缓存服务器的工作场景来说，此方法不甚适用

consistent：（其实就是一致性哈希算法）

• hash表是一个由各服务器填充而成的树状结构
• 基于hash键在hash树中查找相应的服务器时，最近的服务器将被选中。
• 此方法是动态的，支持在运行时修改服务器权重，因此兼容慢速启动的特性
• 添加一个新的服务器时，仅会对一小部分请求产生影响，因此，尤其适用于后端服务器为cache的场景
• 不过，此算法不甚平滑，派发至各服务器的请求未必能达到理想的均衡效果，
  • 因此，可能需要不时的调整服务器的权重以获得更好的均衡性

3.3 bind

3.3.1 用法

• bind [<address>]:<port_range> [, ...]
• bind [<address>]:<port_range> [, ...] interface <interface>

3.3.2 作用

• 此指令仅能用于frontend和listen区段，用于定义一个或几个监听的套接字
• 可以监听多个地址
  • bind  *:80
  • bind  *:8080

3.3.3 使用

<address>

• 可选选项，其可以为主机名、IPv4地址、IPv6地址或*
• 省略此选项，将其指定为*或0.0.0.0时，将监听当前系统的所有IPv4地址

<port_range>

• 可以是一个特定的TCP端口，也可以是一个端口范围（如5005-5010），代理服务器将通过指定的端口来接收客户端请求
• 需要注意的是，每组监听的套接字<address:port>在同一个实例上只能使用一次，
  • 而且小于1024的端口需要有特定权限的用户才能使用，这可能需要通过uid参数来定义

<interface>

• 指定物理接口的名称，仅能在Linux系统上使用
• 其不能使用接口别名，而仅能使用物理接口名称，而且只有管理有权限指定绑定的物理接口

3.4 mode

• 用法：
  • mode  { tcp | http | health }
• 作用：
  • 设定实例的运行模式或协议
  • 当实现内容交换时，前端和后端必须工作于同一种模式（一般来说都是HTTP模式），否则将无法启动实例
• 模式：
  • tcp：
    • 实例运行于纯TCP模式，在客户端和服务器端之间将建立一个全双工的连接，且不会对7层报文做任何类型的检查
    • 此为默认模式，通常用于SSL、SSH、SMTP等应用
  • http：
    • 实例运行于HTTP模式，客户端请求在转发至后端服务器之前将被深度分析，所以不与RFC格式兼容的请求都会被拒绝
  • health：
    • 实例工作于health模式，其对入站请求仅响应“OK”信息并关闭连接，且不会记录任何日志信息
    • 此模式将用于响应外部组件的健康状态检查请求
    • 目前业讲，此模式已经废弃，因为tcp或http模式中的monitor关键字可完成类似功能

3.5 log

• 用法：
  • log global
  • log <address> <facility> [<level> [<minlevel>]]
• 作用：
• 为每个实例启用事件和流量日志，因此可用于所有区段
• 每个实例最多可以指定两个log参数，区段中可以使用“log global”来指定将log发往全局的log
• 参数：
  • global：
    • 当前实例的日志系统参数同"global"段中的定义时，将使用此格式
    • 每个实例仅能定义一次“log global”语句，且其没有任何额外参数；
  • <address>：
    • 定义日志发往的位置，其格式之一可以为<IPv4_address:PORT>，其中的port为UDP协议端口，默认为514
    • 格式之二为Unix套接字文件路径，但需要留心chroot应用及用户的读写权限
  • <facility>：
    • 可以为syslog系统的标准facility之一
  • <level>：
    • 定义日志级别，即输出信息过滤器，默认为所有信息
    • 指定级别时，所有等于或高于此级别的日志信息将会被发送

3.6 maxconn

• 用法：
  • maxconn <conns>
• 作用：
  • 设定一个前端的最大并发连接数，因此，其不能用于backend区段
  • 可以尽可能提高此值以便让haproxy管理连接队列，从而避免无法应答用户请求，此最大值不能超出“global”段中的定义
  • 此外，haproxy会为每个连接维持两个缓冲，每个缓冲的大小为8KB，再加上其它的数据，每个连接将大约占用17KB的RAM空间
    • 这意味着经过适当优化后，有着1GB的可用RAM空间时将能维护40000-50000并发连接（理论上）
• 注意：
  • 如果为<conns>指定了一个过大值，极端场景下，其最终占据的空间可能会超出当前主机的可用内存，这可能会带来意想不到的结果
  • 因此，将其设定了一个可接受值方为明智决定，其默认为2000。

3.7 default_backend

• 用法：
  • default_backend <backend>
• 作用：
  • 为frontend指明使用的默认后端
  • 在没有匹配的"use_backend"规则时为实例指定使用的默认后端，因此，其不可应用于backend区段
  • 在"frontend"和"backend"之间进行内容交换时，通常使用"use-backend"定义其匹配规则
  • 而没有被规则匹配到的请求将由此参数指定的后端接收
• 参数：
  • <backend>：指定使用的后端的名称
• 使用案例：
  • use_backend dynamic if url_dyn
  • use_backend static if url_css url_img extension_img
  • default_backend dynamic

3.8 server

用法：server  <name>  <address>[:port]  [param*]

作用：为后端声明一个server，因此，不能用于defaults和frontend区段

参数：

• <name>：
  • 为此服务器指定的内部名称，其将出现在日志及警告信息中
  • 如果设定了"http-send-server-name"，它还将被添加至发往此服务器的请求首部中
• <address>：
  • 此服务器的的IPv4地址
• [:port]：
  • 指定将连接请求所发往的此服务器时的目标端口，其为可选项
  • 未设定时，将使用客户端请求时的同一端口

[param*]：为此服务器设定的一系列参数

• backup
  • 设定为备用服务器
  • 仅在负载均衡场景中的其它server均不可用时启用此server
• check
  • 启动对此server执行健康状态检查，
  • 其可以借助于额外的其它参数完成更精细的设定：
    • inter <delay>：每隔多长时间检测一次，健康状态检查的时间间隔，单位为毫秒，默认为2000
    • rise <count>：设定健康状态检查中，某离线的server从离线状态转换至正常状态需要成功检查的次数
    • fall <count>：某次检测从up变成down时，要检测几次才确认，确认server从正常状态转换为不可用状态需要检查的次数，默认为3次
• cookie <value>
  • 为指定的server设定cookie值，此处指定的值将在请求入站时被检查，第一次为此值挑选的server将在后续的请求中被选中
  • 其目的在于实现持久连接的功能
• maxconn  <maxconn>
  • 指定此服务器接受的最大并发连接数
  • 如果发往此服务器的连接数目高于此处指定的值，其将被放置于请求队列，以等待其它连接被释放
• maxqueue  <maxqueue>
  • 设定请求队列的最大长度
  • 请求满了之后，后面排队队列的最大长度
• observe  <mode>
  • 通过观察服务器的通信状况来判定其健康状态，根据后端服务器的响应状态和流量来判断，默认为禁用
  • 其支持的类型有“layer4”和“layer7”，“layer7”仅能用于http代理场景
• redir  <prefix>
  • 启用重定向功能（URL重写），将发往此服务器的GET和HEAD请求均以302状态码响应
  • 注意：在prefix后面不能使用/，且不能使用相对地址，以免造成循环
  • 示例：server srv1 172.16.100.6:80 redir http://imageserver.hgzerowzh.com check
• weight  <weight>
  • 权重，默认为1，最大值为256，0表示不参与负载均衡
  • 示例：
    • balance roundrobin
    • server web1 172.16.100.68:80 check weight 1
    • server web2 172.16.100.69:80 check weight 3

指明对Real Server做健康状态检查时的检查方式：

• 不能用于frontend段
• 检查方法：
  • option httpchk
  • option httpchk <uri>
  • option httpchk <method> <uri>
  • option httpchk <method> <uri> <version>
• 使用示例：

  • backend https_relay
        mode tcp
        option httpchk OPTIONS  *  HTTP/1.1
    Host:  www.hgzerowzh.com 
            # 这里指明了要检查的请求首部内容，注意这里的空格要转义  
        server apache1 192.168.1.1:443 check port 80
            # 这里的check就根据上面定义的option的httpchk来进行检查的
            # check后面的port 80表示，对后端主机进行健康状态检测是对后端主机的80端口做检测
            # check后面还可以指明后端主机的另一个网卡的地址，以方便日志记录

3.9 使用示例

server first  172.16.100.7:1080 cookie first  check inter 1000

server second 172.16.100.8:1080 cookie second check inter 1000

4. HAProxy的一些高级功能

4.1 基于浏览器cookie实现session sticky

4.1.1 cookie的指定格式

cookie的指定格式：

• cookie <name> [ rewrite | insert | prefix ]

指明在哪些情况下不用cookie：

• [ indirect ][ nocache ][ postonly ][ preserve ][ httponly ][ secure ]
• 一般使用nocache和indirect就可以了

cookie的写入方式：

• rewrite：直接将原来的cookie覆盖重写
• insert：插入到原来的cookie中（一般insert比较常用）
• prefix：附加在原来的cookie前面

4.1.2 基于cookie的会话绑定示例

backend websrvs
        balance    roundrobin
        cookie  SERVERID  insert  nocache  indirect
        # 这里指明每个用户请求都插入一个cookie，这个cookie的名字明确指明就叫SERVERID
        # 基于insert的方式插入
        server  web1  172.16.100.68:80  check  weight  1  cookie  httpd_1
        server  web2  172.16.100.69:80  check  weight  3  cookie  httpd_2
        # 这里在每一个server的后面指明这里的专用cookie标识符（如httpd_1和httpd_2）

 

注意：

• 每个server要有自己唯一的cookie标识
• 在backend中定义为用户请求调度完成后操纵其cookie

4.2 启用HAProxy的状态信息查看功能

4.2.1 开启stats功能：stats enable

• 启用基于程序编译时默认设置的统计报告，不能用于“frontend”区段
• 统计页面会显示一些有用的信息，包括HAProxy的版本号，因此需要隐藏版本号

4.2.2 配置语法

stats uri   : /haproxy?stats        # 指明stats页面默认的请求url
stats realm : HAProxy Statistics   # 指明认证时的显示提示信息，空格需要转义
stats auth  : no authentication     # 定义认证信息
stats scope : no restriction        # 指明作用域，一般使用点 . 即可
stats admin { if | unless } <cond>  # 指明条件满足或不满足时启动管理功能

4.2.3 配置示例

backend public_www
        server websrv1 172.16.100.11:80
        stats enable              # 开启stats功能
        stats hide-version        # 隐藏版本号
        stats scope   .           # 指明作用域，这里的点.表示当前，就是作用域stats自身
    # 显示指定区段的报告信息，所有其他区段的信息将被隐藏，如果需要显示多个区段的统计报告，可以定义多次
    # 可以指定一个listen、frontend或backend区段的名称，点 . 则表示stats scope语句所定义的当前区段
        stats uri     /haproxyadmin?stats   # 访问url路径
        stats realm   Haproxy Statistics   # 指明认证时的提示信息，空格需要转义
        stats auth    statsadmin:password   # 指明认证时的账号和密码
        stats auth    statsmaster:password  # 可以有多个账号和密码认证信息

4.2.4 启用管理功能

backend stats_localhost
    stats enable
    stats admin if LOCALHOST           # 定义只有本机能启用管理功能

backend stats_auth
    stats enable
    stats auth  haproxyadmin:password  # 定义认证的用户名和密码
    stats admin if TRUE                # 指明当上面的验证成功时才启用管理功能
# 注意：管理功能启用时，注意不要和scope定义的作用域冲突，最好将作用域功能关闭

4.2.5 实际使用示例

listen  statistics
        bind  *:9090
        stats  enable
        stats  hide-version
        # stats  scope  .
        stats  uri  /haproxyadmin?stats
        stats  realm  HAProxyStatistics
        stats  auth  haadmin:hgzero
        stats  admin  if  TRUE

• 当mode为http时，如果要记录丰富的日志信息，则要加上option httplog
  • 默认在default中已经开启

4.3 捕获HTTP报文首部的额外其他信息（记录到日志中）

4.3.1 捕获请求首部信息：capture request header

语法：

• capture request header <name> len <length>

作用：

• 捕获并记录指定的请求首部最近一次出现时的第一个值，仅能用于“frontend”和“listen”区段
• 捕获的首部值使用花括号{}括起来后添加进日志中
• 如果需要捕获多个首部值，它们将以指定的次序出现在日志文件中，并以竖线“|”作为分隔符
• 不存在的首部记录为空字符串，最常需要捕获的首部包括：
  • 在虚拟主机环境中使用的“Host”
  • 上传请求首部中的“Content-length”
  • 快速区别真实用户和网络机器人的“User-agent”
  • 以及代理环境中记录真实请求来源的“X-Forward-For”

参数：

• <name>：
  • 要捕获的首部的名称，此名称不区分字符大小写，但建议与它们出现在首部中的格式相同，比如大写首字母
  • 需要注意的是，记录在日志中的是首部对应的值，而非首部名称
• <length>：
  • 指定记录首部值时所记录的精确长度，超出的部分将会被忽略

注意：

• 可以捕获的请求首部的个数没有限制，但每个捕获最多只能记录64个字符
• 为了保证同一个frontend中日志格式的统一性，首部捕获仅能在frontend中定义

4.3.2 捕获响应首部信息：capture response header

• 语法：
  • capture response header <name> len <length>
• 使用：
  • 捕获并记录响应首部，其格式和要点同请求首部

4.4 定义访问控制功能

• http_request（还有tcp_request）
• 语法：
  • http-request { allow | deny | auth [ realm <realm> ] } [ { if | unless } <condition> ]

配置示例：

acl nagios src 192.168.129.3     # 定义一个acl名叫nagios，此acl是用来检查源地址的
acl local_net src 192.168.0.0/16 # 定义一个acl名叫local_net，是用来定义源地址网段的
acl auth_ok http_auth(L1)        # 定义一个acl名叫auth_ok，
                                 # 如果使用请求报文中的认证首部http_auth的值认证是ok的则ok
http-request allow if nagios     # 如果匹配的名为nagios的acl满足通过，则允许访问
http-request allow if local_net auth_ok 
                                   # 如果匹配的名为local_net和auth_ok的acl满足通过，则允许访问
http-request deny                # 如果上面的条目都没有匹配到，则拒绝访问，默认机制

4.5 添加请求或响应报文首部

• 定义在frontend中

4.5.1 reqadd

• 语法：
  • reqadd <string> [ {if | unless} <cond> ]
• 作用：
  • HAProxy在转发客户端的请求到后端RealServer时，添加一个请求首部
  • 注意：空格一定要进行转义
• 示例：

  • acl  is-ssl  dsp_port  81       # 定义一个叫is-ssl的acl，规则是目标端口为81
    reqadd  X-Proto: SSL if is-ssl # 如果is-ssl的acl规则符合，则添加一个请求首部：X-Prote: SSL
    # 注意：空格一定要转义

4.5.2 rspadd

• 作用：HAProxy在返回报文给客户端时，添加一个响应首部
• 使用：和reqadd一样

4.6 一系列的超时时长定义

• timeout http-request
  • 等待接受客户端发送过来的整个请求报文的超时时长
  • 因为如果发送请求的时候，客户端挂掉了，服务器会一直等待
• timeout queue
  • 队列超时时长
• timeout connect
  • 建立连接的超时时长
• timeout client
  • 客户端超时时长，客户端不活动超过这个时间就断开
• timeout server
  • 当后端的RealServer不活动超过这个时长就断开
• timeout http-keep-alive
  • 在面向客户端的保持连接功能的超时时长
• timeout check
  • 检查的超时时长，只针对已经建立好的连接

5. option选项&自定义错误页面

5.1 option选项启用的一些功能

5.1.1 option httplog

• 作用：当mode为http时，记录丰富的日志信息，如记录http请求、会话状态、计时器等信息

5.1.2 option logasap

• 关闭此功能：no option logasap
• 作用：
  • 启用或禁用提前将HTTP请求记入日志，不能用于"backend"区段
• 说明：
  • 默认情况下，HTTP请求是在请求结束时进行记录以便能将其整体传输时长和字节数记入日志，因此，传较大的对象时，其记入日志的时长可能会略有延迟
  • option logasap参数能够在服务器发送complete首部时即时记录日志，只是此时将不记录整体传输时长和字节数
  • 此情形下，捕获“Content-Length”响应首部来记录传输的字节数是一个较好选择

5.1.3 option forwardfor

• 语法：
  • option forwardfor [ except <network> ] [ header <name> ] [ if-none ]
• 作用：
  • 允许在发往服务器的http请求首部中插入“X-Forwarded-For”首部
• 参数：
  • [ except <network> ]：
    • 可选参数，当指定时，源地址为匹配至此网络中的请求都禁用此功能
  • [ header <name> ]：
    • 可选参数，可使用一个自定义的首部，如“X-Client”来替代“X-Forwarded-For”
    • 有些独特的web服务器的确需要用于一个独特的首部
  • if-none：
    • 仅在此首部不存在时才将其添加至请求报文问道中
• 注意：
  • HAProxy工作于反向代理模式，其发往服务器的请求中的客户端IP均为HAProxy主机的地址，而非真正客户端的地址
  • 这会使得服务器端的日志信息记录不了真正的请求来源，“X-Forwarded-For”首部则可用于解决此问题
  • HAProxy可以向每个发往服务器的请求上添加此首部，并以客户端IP为其value
  • 然后在后端的RealServer上记录X-Forwarded-For传递而来的客户端真实IP
  • 需要注意的是，HAProxy工作于隧道模式，其仅检查每一个连接的第一个请求，因此，仅第一个请求报文被附加此首部
  • 如果想为每一个请求都附加此首部，要确保同时使用了“option httpclose”、“option forceclose”和“option http-server-close”几个option
• 示例：

  • frontend www
        mode http
        option forwardfor except 127.0.0.1

5.1.4 option http-server-close

• 关闭此功能：no option http-server-close
• 作用：在保持连接时，服务器主动断开连接（默认是谁发起连接谁先断开连接）

5.1.5 option http-pretend-keepalive

• 关闭此功能：no option http-pretend-keepalive
• 此功能应对的问题：
  • 当声明了 "option http-server-close" 或 "option forceclose"，haproxy会在给server的request头中添加 "Connection: close"
  • 然而有些服务器看到这个头，会返回未知长度的response，并自动避免chunked encoding，其实这是不对的
  • 它会阻止haproxy保持客户端长连接，还会使客户端或缓存接收了未完成的响应，却认为响应结束了
• 解决：
  • 设置 "option http-pretend-keepalive"，haproxy会在服务器端保持长连接，服务端则不会出现前面的问题
  • 当haproxy获取了完整的response，才会以类似forceclose的方式关闭服务端，
  • 这样客户端得到一个普通的响应，连接也在服务端被正常关闭
• 注意：
  • 这个选项可以与 "option httpclose"结合，使服务端keepalive，客户端close，但并不建议这样做

5.1.6 option httpclose

• 关闭此功能：no option httpclose
• 作用：在保持连接时，服务器主动断开连接

5.1.7 option redispatch

• 关闭此功能：no option redispatch
• 作用：
  • 当HAProxy服务器启动了源地址绑定功能时，若后端RealServer宕掉了一台，此时是否将先前绑定了的请求转移到其他主机上
  • 若关闭此功能，则请求会等待宕掉的主机恢复

5.2 自定义错误页面

5.2.1 errorfile

• 语法：errorfile <code> <file>
• 作用：
  • 在用户请求不存在的页面时，返回一个页面文件给客户端，而非返回由haproxy生成的错误代码
  • 可用于所有段中
• 参数：
  • <code>：
    • 指定对HTTP的哪些状态码返回指定的页面
    • 这里可用的状态码有200、400、403、408、500、502、503和504
    • 注意：这里的状态码不包含404，因为404存在与否是由后端RealServer来判断的
  • <file>：
    • 指定用于响应的页面文件
• 使用示例：

  • errorfile 400 /etc/haproxy/errorpages/400badreq.http
    errorfile 403 /etc/haproxy/errorpages/403forbid.http
    errorfile 503 /etc/haproxy/errorpages/503sorry.http

5.2.2 errorloc 和 errorloc302

• 语法：
  • errorloc <code> <url>
  • errorloc302 <code> <url>
• 作用：
  • 请求错误时，返回一个HTTP重定向至某URL的信息
  • 可用于所有配置段中
• 参数：
  • <code>：
    • 指定对HTTP的哪些状态码返回指定的页面
    • 这里可用的状态码有200、400、403、408、500、502、503和504
  • <url>：
    • Location首部中指定的页面位置的具体路径，可以是在当前服务器上的页面的相对路径，也可以使用绝对路径
    • 需要注意的是，如果URI自身错误时产生某特定状态码信息的话，有可能会导致循环定向
• 注意：
  • 这两个关键字都会返回302状态吗，这将使得客户端使用同样的HTTP方法获取指定的URL，
    • 对于非GET方法的场景(如POST)来说会产生问题，因为返回客户的URL是不允许使用GET以外的其它方法的
    • 如果的确有这种问题，可以使用errorloc303来返回303状态码给客户端

5.2.3 errorloc303

• 语法：errorloc303 <code> <url>
• 作用：
  • 请求错误时，返回一个HTTP重定向至某URL的信息给客户端
  • 可用于所有配置段中
• 参数：
  • <code>：
    • 指定对HTTP的哪些状态码返回指定的页面
    • 这里可用的状态码有400、403、408、500、502、503和504
  • <url>：
    • Location首部中指定的页面位置的具体路径，可以是在当前服务器上的页面的相对路径，也可以使用绝对路径
    • 需要注意的是，如果URI自身错误时产生某特定状态码信息的话，有可能会导致循环定向
• 使用示例：

  • backend webserver
            server 172.16.100.6 172.16.100.6:80 check maxconn 3000 cookie srv01
            server 172.16.100.7 172.16.100.7:80 check maxconn 3000 cookie srv02
            errorfile 403 /etc/haproxy/errorpages/sorry.htm
            errorfile 503 /etc/haproxy/errorpages/sorry.htm

6. ACL&redirect重定向

6.1 ACL功能详解

6.1.1 ACL的作用

• HAProxy的ACL用于实现基于请求报文的首部、响应报文的内容或其他的环境状态信息来做出转发决策
• 配置法则通常分为两步：
  • 首先去定义ACL，即定义一个测试条件
  • 然后在条件得到满足时执行某个特定的动作，如阻止请求或转发至某特定的后端

6.1.2 ACL的语法及参数

ACL语法：

• acl  <aclname>  <criterion>   [flags]  [operator]  <value>  ...

ACL参数：

• <aclname>：
  • ACL名称，区分字符大小写
  • haproxy中，acl可以重名，这可以把多个测试条件定义为一个共同的acl
  • 若两个acl同名，则表示满足其中的一个即可
• <criterion>：
  • 测试标准，即对什么信息发起测试
  • 测试方式可以由[flags]指定的标志进行调整
• [flags]：目前acl支持的标志位有3个
  • -i：不区分<value>中模式字符的大小写
  • -f：从指定的文件中加载模式
  • 而有些测试标准也可以需要为其在<value>之前指定一个操作符[operator]
• <value>：acl测试条件支持的值有以下四类：
  • 整数或整数范围，支持使用的操作符有5个，分别为eq、ge、gt、le和lt
  • 字符串
  • 正则表达式
  • IP地址及网络地址
• 同一个acl中可以指定多个测试条件，这些测试条件需要由逻辑操作符指定其关系，条件间的组合测试关系有三种：
  • “与”(默认即为与操作)
  • “或”(使用“||”操作符)
  • “非”(使用“!”操作符)

6.1.3 常用的ACL测试标准（criteria）

1) be_sess_rate <integer>

• 语法：be_sess_rate(backend) <integer>
• 作用：
  • 用于测试指定的backend上会话创建的速率(即每秒创建的会话数)是否满足指定的条件
  • 常用于在指定backend上的会话速率过高时将用户请求转发至另外的backend，或用于阻止攻击行为
• 使用示例：

  • backend dynamic
            mode http
        # backend上的会话创建速率是否大于50个每秒
            acl being_scanned be_sess_rate gt 50 
        # 若会话速率大于满足acl定义，则将url重写至指定指定路径
            redirect location /error_pages/denied.html if being_scanned

2) fe_sess_rate <integer>

• 语法：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          # 定义frontend的会话速率是否大于50个每秒
            tcp-request inspect-delay 50ms           # 会话速率若大于50，都将被延时50毫秒
            tcp-request content accept if ! too_fast # 只要会话速率小于50，都accept
            tcp-request content accept if WAIT_END   # 等待50毫秒之后，才accept

3) hdr <string>

• 语法：hdr(header) <string>
• 作用：
  • 用于测试请求报文中的所有首部或指定首部是否满足指定的条件
  • 指定首部时，其名称不区分大小写，且在括号 "()" 中不能有任何多余的空白字符
• 使用示例：

  • # 用于测试首部Connection的值是否为close
    # 这里的-i表示后面的close不区分大小写 
    hdr(Connection) -i close  

4) method <string>

• 作用：
  • 测试HTTP请求报文中使用的方法
  • 可以是GET、POST或者OPTION等等

5) path_beg <string> 和 path_end <string>

• 作用：
  • path_beg <string>
    • 用于测试请求的URL是否以<string>指定的模式开头
    • 其实就是判断请求的URI的路径开头是否为指定的内容
  • path_end <string>
    • 用于测试请求的URL是否以<string>指定的模式结尾
    • 其实就是判断请求的URI的路径结尾是否为指定内容
•  使用示例：

  • # 测试URL是否以/static、/images、/javascript、/stylesheets开头
    acl url_static   path_beg  -i /static  /images  /javascript  /stylesheets
    # 上面的-i表示后面的内容不区分大小写，各个内容直接是或的关系
    
    # 测试URL是否以jpg、gif、png、css或js结尾
    acl  url_static   path_end  -i  .jpg  .gif  .png  .css  .js

6) hdr_beg <string> 和 hdr_end <string>

• 作用：
  • hdr_beg用于测试请求报文的指定首部的开头部分是否符合<string>指定的模式
  • hdr_end用于测试请求报文的指定首部的结尾部分是否符合<string>指定的模式
• 使用示例：

  • # 测试请求是否为提供静态内容的主机img、video、download或ftp。
    acl  host_static  hdr_beg(host) -i  img.  video. download. ftp.

7) url_beg 和 url_end

• 作用：
  • url_beg匹配整个url的开头是否符合条件
  • url_end匹配真个url的结尾是否符合条件
• 使用示例：

  • # 匹配url为http://www.hgzerowzh.com
    acl  is_hgzero.com  url_beg  http://www.hgzerowzh.com
    use_backend  bobo.com  if  is_hgzero.com

8) path_reg 和 url_reg

• 作用：
  • path_reg用于检测URI的路径是否为这里指定的正则所匹配
  • url_reg用于检测整个URL是否为这里指定的正则所匹配

6.2 redirect重定向

6.2.1 位置重定向

• 语法：
  • redirect location <loc> [code <code>] <option> [{if | unless} <condition>]
• 作用：
  • 使用位置重定向，可以将用户重定向到所提供的精确的位置，可以是第三方URL连接，也可以是本地web服务的另一个访问路径
  • 其实就是直接将整个url全部重写了

参数：

• <loc>：
  • 一个日志格式变量（或简单的字符串redirect语句）描述了新位置
• [code <code>]：（可选）
  • HTTP重定向的状态代码来执行
  • 允许的状态码：
    • 301：永久移动，转发
    • 302：临时移动，不应该由客户端进行缓存，这是默认值，如果没有code配置
    • 303：像302，但是浏览器必须使用GET获取新位置
    • 307：像302，但是浏览器必须重新使用相同的方法之一，从原来的请求
    • 308：像301
• <option>：（可选）
  • set-cookie NAME[=value] :
    • 一个Set-Cookie头部被添加到重定向
    • 该cookie被命名为名称，可以有一个可选的值
  • clear-cookie NAME[=]
    • 一个特殊的Set-Cookie头被添加到重定向
    • 该Cookie名为名称和最大年龄的cookie参数设置为0，目的是为了指示浏览器删除cookie
  • 注意：在浏览器中，这是两个不同的cookie：NAME和NAME=
• {if | unless}：
  • 用于条件判断
• <condition>：（可选）
  • 用于匹配acl，一般为acl的名称

6.2.2 前缀重定向

• 语法：
  • redirect prefix <loc> [code <code>] <option> [{if | unless} <condition>]
• 作用：
  • 使用前缀重定向，将用户重定向到由concateneting建立了一个网址<pfx>和完整的原始URI路径
  • 其实就是只修改url的前缀部分，而不修改uri部分
• 参数：和位置重定向一样

6.2.3 协议（计划）重定向（比如将http重定向到https）

• 语法：
  • redirect scheme <sch> [code <code>] <option> [{if | unless} <condition>]
• 作用：
  • 使用位置重定向，可以将用户重定向到所提供的新的http协议url链接
  • 一般用于非安全链接跳转到安全链接，比如http跳转到https上
• 参数：和位置重定向一样

6.2.4 综合使用示例

### 先定义一系列的acl：
acl clear    dst_port  80                     # clear，请求的目的端口为80
acl secure     dst_port  8080                 # secure，请求的目的端口为8080
acl login_page url_beg   /login               # login_page，请求的url是以login开头
acl logout     url_beg  /logout               # logout，请求的url是以logout开头
acl uid_given   url_reg   /login?userid=[^&]+ # uid_given，请求的url为后面指定的正则
acl cookie_set  hdr_sub(cookie) SEEN=1        # 请求的cookie中的子串中的SEEN=1，就是cookie中的SEEN=1

### 定义前缀重定向：
redirect prefix   https://hgzerowzh.com set-cookie SEEN=1 if !cookie_set
        # 表示用户请求时，若cookie_set的acl不满足条件，那么将其重定向到指定的url，且将其cookie中的SEEN设置为1
        # 这里是只修改前缀
redirect prefix   https://hgzerowzh.com  if login_page !secure
        # 表示请求时，login_page的acl符合，且secure的acl不满足条件，将其重定向到指定的url，这里是只重写URL前缀
redirect prefix   http://hgzerowzh.com  drop-query if login_page !uid_given

### 定义位置重定向：
redirect location http://hgzerowzh.com/  if !login_page secure
        # 表示如果login_page的acl不满足，但是secure的acl满足时，将其重定向到指定的位置，这里是url完全重写
redirect location / clear-cookie USERID=  if logout
        # 表示如果logout的acl满足条件，那么将整个url全部重写，且清除cookie信息，并且将URERID设置为空

7. HAProxy动静分离

global
    log         127.0.0.1 local2
    chroot      /var/lib/haproxy
    pidfile     /var/run/haproxy.pid
    maxconn     4000
    user        haproxy
    group       haproxy
    daemon
    # turn on stats unix socket
    stats socket /var/lib/haproxy/stats

defaults
    mode                    http
    log                     global
    option                  httplog
    option                  dontlognull
    option http-server-close
    option forwardfor       except 127.0.0.0/8
    option                  redispatch
    retries                 3
    timeout http-request    10s
    timeout queue           1m
    timeout connect         10s
    timeout client          1m
    timeout server          1m
    timeout http-keep-alive 10s
    timeout check           10s
    maxconn                 30000

listen stats
    mode http
    bind 0.0.0.0:1080
    stats enable
    stats hide-version
    stats uri     /haproxyadmin?stats
    stats realm   Haproxy Statistics
    stats auth    admin:admin
    stats admin if TRUE

frontend http-in
    bind *:80
    mode http
    log global
    option httpclose
    option logasap
    option dontlognull
    capture request  header Host len 20
    capture request  header Referer len 60

    # 这里定义了两个判断静态的acl
    acl url_static   path_beg  -i /static /images /javascript /stylesheets
    acl url_static   path_end  -i .jpg .jpeg .gif .png .css .js

    # 这里定义了若任意满足url_static其中的一个acl，就调用static_servers静态服务器组
    use_backend static_servers   if   url_static
    # 这里定义了默认使用的是动态服务器组
    default_backend dynamic_servers

# 定义后端静态服务器组
backend static_servers
    balance roundrobin
    server imgsrv1 172.16.200.7:80 check maxconn 6000
    server imgsrv2 172.16.200.8:80 check maxconn 6000

# 定义后端动态服务器组
backend dynamic_servers
    cookie srv insert nocache
    balance roundrobin
    server websrv1 172.16.200.7:80 check maxconn 1000 cookie websrv1
    server websrv2 172.16.200.8:80 check maxconn 1000 cookie websrv2
    server websrv3 172.16.200.9:80 check maxconn 1000 cookie websrv3