天天看点
返回

HAProxy.mdHAProxy

HAProxy

代理http

1、正向代理

2、反向代理

代理作用：web缓存（加速）、反向代理、内容路由（根据流量及内容类型等将请求转发至特定服务器）、转码器；

在代理服务器上添加Via首部；

缓存的作用：

1、减少冗余内容传输：

2、节省带宽、缓解网络瓶颈；

3、降低了对原始服务器的请求压力：

4、降低了传输延迟：

HAProxy：只是http协议的反向代理，不提供缓存功能：但额外支持对tcp层对基于tcp通信的应用做LB：

yum install haproxy -y
rpm -ql haproxy
/etc/haproxy/haproxy.cfg
/usr/sbin/haproxy
......

haproxy 配置中分成五部分内容，分别如下：

1、global：参数是进程级的，通常是和操作系统相关。这些参数一般只设置一次，如果配置无误，就不需要再次进行修改；

2、defaults：配置默认参数，这些参数可以被用到 frontend，backend，Listen 组件；

3、frontend：接收请求的前端虚拟节点，Frontend 可以更加规则直接指定具体使用后端的 backend；

4、backend：后端服务集群的配置，是真实服务器，一个 Backend 对应一个或者多个实体服务器；

5、Listen Fronted 和 backend 的组合体。

HAProxy 配置文件详解

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

  • chroot ：修改haproxy的工作目录至指定的目录并在放弃权限之前执行chroot（）操作，可以提升haproxy的安全级别，不过需要注意的是要确保指定的目录为空目录且任何用户均不能有写权限；

    -daemon:i让haproxy以守护进程的方式工作于后台，其等同于“-D”选项的功能，当然，也可以在命令行中以“-db”选项将其禁用；gid：以指定的GID运行haproxy，建议使用专用于运行haproxy的GID，以免因权限问题带来风险：

  • group：同gid，不过指定的组名：
  • log [max level[min level]]：定义全局的syslog服务器，最多可以定义两个：
  • log-send-hostname[]：在syslog信息的首部添加当前主机名，可以为“string”指定的名称，也可以缺省使用当前主机名；
  • nbproc ：指定启动的haproxy进程的个数，只能用于守护进程模式的haproxy；默认只启动一个进程，鉴于调试困难等多方面的原因，一般只在单进程仅能打开少数文件描述符的场景中才使用多进程模式：
  • pidfile：
  • uid：以指定的UI0身份运行haproxy进程：
  • ulimit-n：设定每进程所能够打开的最大文件描述符数目，默认情况下其会自动进行计算，因此不推荐修改此选项；user：同uid，但使用的是用户名：
  • stats：
  • node：定义当前节点的名称，用于HA场景中多haproxy进程共享同一个IP地址时；
  • description：当前实例的描述信息：

性能调整相关的参数

  • maxconn：设定每个haproxy进程所接受的最大并发连接数，其等同于命令行选项“-n”；“ulimit-

    n”自动计算的结果正是参照此参数设定的：

  • maxpipes；haproxy使用pipe完成基于内核的tcp报文重组，此选项则用于设定每进程所允许使用的最大pipe个数；每个pipe会打开两个文件描述符，因此，“ulimit-n”自动计算时会根据需要调大此值：默认为maxconn/4，其通常会显得过大：
  • noepoll：在Linux系统上禁用epoll机制；
  • nokqueue：在BSD系统上禁用kqueue机制：
  • nopoll：禁用pol1机制：
  • nosepoll：在Linux禁用启发式epoll机制：

  • nosplice：禁止在Linux套接字上使用内核tcp重组，这会导致更多的recv/send系统调用：不过，在Linux 2.6.25-

    28系列的内核上，tcp重组功能有bug存在：

  • spread-checks <0..50，in percent>：在haproxy后端有着众多服务器的场景中，在精确的时间间隔后统一对众服务器进行健康状况检查可能会带来意外问题；此选项用于将其检查的时间间隔长度上增加或减小一定的随机时长；
  • tune.bufsize ：设定buffer的大小，同样的内存条件下，较小的值可以让haproxy有能力接受更多的并发连接，较大的值可以让某些应用程序使用较大的cookie信息；默认为16384，其可以在编译时修改，不过强烈建议使用默认值：
  • tune.chksize：设定检查缓冲区的大小，单位为字节：更大的值有助于在较大的页面中完成基于字符串或模式的文本查找，但也会占用更多的系统资源；不建议修改：
  • tune.maxaccept ：设定haproxy进程内核调度运行时一次性可以接受的连接的个数，较大的值可以带来较大的吞吐率，默认在单进程模式下为10e，多进程模式下为8，设定为-1可以禁止此限制：一般不建议修改：
  • tune.maxpollevents ：设定一次系统调用可以处理的事件最大数，默认值取决于05；其值小于2e0时可节约带宽，但会略微增大网络延迟，而大于2e0时会降低延迟，但会稍稍增加网络带宽的占用量：

  • tune.maxrewrite

    ：设定为首部重写或追加而预留的缓冲空间，建议使用1024左右的大小：在需要使用更大的空间时，haproxy会自动增加其值：

  • tune.rcvbuf.client ：
  • tune.rcvbuf.server <number）：设定内核套接字中服务端或客户端接收缓冲的大小，单位为字节；强烈推荐使用默认值；
  • tune.sndbuf.client：
  • tune.sndbuf.server：

Debug相关的参数

  • debug
  • quiet

配置文件中的关键字参考

1、balance []

balance url_param [check_post[<max_wait>]]

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

  • roundrobin：基于权重进行轮叫，在服务器的处理时间保持均匀分布时，这是最平衡、最公平的算法。此算法是动态的，这表示其权重可以在运行时进行调整，不过，在设计上，每个后端服务器仅能最多接受4128个连接：
  • static-rr：基于权重进行轮叫，与roundrobin类似，但是为静态方法，在运行时调整其服务器权重不会生效；不过，其在后端服务器连接数上没有限制：
  • leastconn：新的连接请求被派发至具有最少连接数目的后端服务器；在有着较长时间会话的场景中推荐使用此算法，如LDAP、S0L等，其并不太适用于较短会话的应用层协议，如Hmp：此算法是动态的，可以在运行时调整其权重：
  • source：将请求的源地址进行hash运算，并由后端服务器的权重总数相除后派发至某匹配的服务器：这可以使得同一个客户端IP的请求始终被派发至某特定的服务器；不过，当服务器权重总数发生变化时，如某服务器岩机或添加了新的服务器，许多客户端的请求可能会被派发至与此前请求不同的服务器；常用于负载均衡无cookie功能的基于TCP的协议；其默认为静态，不过也可以使用hash-type修改此特性；uri：对URI的左半部分（“问题”标记之前的部分）或整个URI进行hash运算，并由服务器的总权重相除后派发至某匹配的服务器：这可以使得对同一个URI的请求总是被派发至某特定的服务器，除非服务器的权重总数发生了变化：此算法常用于代理缓存或反病毒代理以提高缓存的命中率：需要注意的是，此算法仅应用于HTTP后端服务器场景；其默认为静态算法，不过也可以使用hash-type修改此特性：
  • url param：通过为URL指定的参数在每个HTTP GET请求中将会被检索；如果找到了指定的参数且其通过等于号“=”被赋予了一个值，那么此值将被执行hash运算并被服务器的总权重相除后派发至某匹配的服务器：此算法可以通过追踪请求中的用户标识进而确保同一个用户ID的请求将被送往同一个特定的服务器，除非服务器的总权重发生了变化；如果某请求中没有出现指定的参数或其没有有效值，则使用轮叫算法对相应请求进行调度：此算法默认为静态的，不过其也可以使用hash-type修改此特性：

  • hdr（）：对于每个HTTP请求，通过指定的HTTP首部将会被检索：如果相应的首部没有出现或其没有有效值，则使用轮叫算法对相应请求进行调度；其有一个可选选项“use_domain_only”，可在指定检索类似Host类的首部时仅计算域名部分（比如通过wmww.magedu.

    com来说，仅计算magedu字符串的hash值）以降低hash算法的运算量：此算法默认为静态的，不过其也可以使用hash-type修改此特性：

  • rdp-cookie
  • rdp-cookie（name）：

2、bind bind [

]：<port_range> [，…]

bind [ ]： [，..] interface

此指令仅能用于frontend和listen区段，用于定义一个或几个监听的套接字。

<address> ：可选选项，其可以为主机名、IPv4地址、IPv6地址或*；省略此选项、将其指定为*或e.e.e.

0时，将监听当前系统的所有IPv4地址：

<port_range>：可以是一个特定的TCP端口，也可是一个端口范围（如5005-5010）

，代理服务器将通过指定的端口来接收客户端请求；需要注意的是，每组监听的套接字- - address:port

在同一个实例上只能使用一次，而且小于1024的端口需要有特定权限的用户才能使用，这可能需要通过uid参数来定义；

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

3、bind

bind [

]：<port_range>[，……]

bind [ ]：<port_range>[，..interface

此指令仅能用于frontend和listen区段，用于定一个或几个监听的套接字。

：可选选项，其可以为主机名、IPv4地址、IPv6地址或*：省略此选项、将其指定为*或e.e.e. 0时，将监听当前系统的所有IPv4地址： ：可以是一个特定的TCP端口，也可是一个端口范围（如5005-5010） ，代理服务器将通过指定的端口来接收客户端请求：需要注意的是，每组监听的套接字 在同一个实例上只能使用一次，而且小于1024的端口需要有特定权限的用户才能使用，这可能需要通过uid参数来定义； ：指定物理接口的名称，仅能在Linux系统上使用；其不能使用接口别名，而仅能使用物理接口名称，而且只有管理有权限指定绑定的物理接口：

4、mode

mode { tcp|http|health}

设定实例的运行模式或协议。当实现内容交换时，前端和后端必须工作于同一种模式（一般说来都是HTTP模式），否则将无法启动实例。

tcp：实例运行于纯TCP模式，在客户端和服务器端之间将建立一个全双工的连接，且不会对7层报文做任何类型的检查；此为默认模式，通常用于SSL、SSH、SMTP等应用；http：实例运行于HTTP模式，客户端请求在转发至后端服务器之前将被深度分析，所有不与RFC格式兼容的请求都会被拒绝；health：实例工作于health模式，其对入站请求仅响应“OK”信息并关闭连接，且不会记录任何日志信息；此模式将用于响应外部组件的健康状态检查请求；目前业讲，此模式已经废弃，因为tcp或http模式中的monitor关键字可完成类似功能：

4、hash-type

hash-type

定义用于将hash码映射至后端服务器的方法；其不能用于frontend区段；可用方法有map-

based和consistent，在大多数场景下推荐使用默认的map-based方法。

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

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

5、log

log global

Log

[ []]

为每个实例启用事件和流量日志，因此可用于所有区段。每个实例最多可以指定两个log参数，不过，如果使用了log global”且"global“段已经定了两个log参数时，多余了log参数将被忽略。

global：当前实例的日志系统参数同“global”段中的定义时，将使用此格式：每个实例仅能定义一次1。g global”语句，且其没有任何额外参数：

：定义日志发往的位置，其格式之一可以为 ，其中的port为UDP协议端口，默认为514：格式之二为Unix套接字文件路径，但需要留心chroot应用及用户的读写权限； ：可以为syslog系统的标准facility之一； ：定义日志级别，即输出信息过滤器，默认为所有信息；指定级别时，所有等于或高于此级别的日志信息将会被发送；

6、maxconn

maxconn

设定一个前端的最大并发连接数，因此，其不能用于backend区段。对于大型站点来说，可以尽可能提高此值以便让haproxy管理连接队列，从而避免无法应答用户请求。当然，此最大值不能超出“global”段中的定义。此外，需要留心的是，haproxy会为每个连接维持两个缓冲，每个缓冲的大小为8KB，再加上其它的数据，每个连接将大约占用17KB的RAM空间。这意味着经过适当优化后，有着1GB的可用RAM空间时将能维护40000-50000并发连接。

如果为指定了一个过大值，极端场景下，其最终占据的空间可能会超出当前主机的可用内存，这可能会带来意想不到的结果；因此，将其设定了一个可接受值方为明智决定。其默认为2000。

7、default_backend

default backend

在没有匹配的“usebackend"规则时为实例指定使用的默认后端，因此，其不可应用于backend区段。在“frontend“和“backend“之间进行内容交换时，通常使用“use-backend"定义其匹配规则；而没有被规则匹配到的请求将由此参数指定的后端接收。

：指定使用的后端的名称：

使用案例：

use backend dynamic if url_dyn use_backend static if url_css url_img extension_img default backend dynamic

9、server

server

[:port ][param*]

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

：为此服务器指定的内部名称，其将出现在日志及警告信息中；如果设定了“http-send-server-

name"，它还将被添加至发往此服务器的请求首部中：

：此服务器的的IPv4地址，也支持使用可解析的主机名，只不过在启动时需要解析主机名至相应的IPv4地址： [：port]：指定将连接请求所发往的此服务器时的目标端口，其为可选项；未设定时，将使用客户端请求时的同一相端口； [param*]：为此服务器设定的一系参数；其可用的参数非常多，具体请参考官方文档中的说明，下面仅说明几个常用的参数；服务器或默认服务器参数： backup：设定为备用服务器，仅在负载均衡场景中的其它server均不可用于启用此server； check：启动对此server执行健康状态检查，其可以借助于额外的其它参数完成更精细的设定，如： inter ：设定健康状态检查的时间间隔，单位为毫秒，默认为2000；也可以使用fastinter和downinter来根据服务器端状态优化此时间延迟： rise ：设定健康状态检查中，某高线的server从离线状态转换至正常状态需要成功检查的次数； fall ：确认server从正常状态转换为不可用状态需要检查的次数； cookie ：为指定server设定cookie值，此处指定的值将在请求入站时被检查，第一次为此值挑选的server将在后续的请求中被选中，其目的在于实现持久连接的功能： maxconn ：指定此服务器接受的最大并发连接数；如果发往此服务器的连接数目高于此处指定的值，其将被放置于请求队列，以等待其它连接被释放： maxqueue ：设定请求队列的最大长度； observe ：通过观察服务器的通信状况来判定其健康状态，默认为禁用，其支持的类型有“layer4”和“layer7”，“layer7”仅能用于http代理场景： redir ：启用重定向功能，将发往此服务器的GET和HEAD请求均以302状态码响应；需要注意的是，在prefix后面不能使用/，且不能使用相对地址，以免造成循环；例如： server srv1 192.168.200.254:80 redir http://imageserver.test.com check 注意URL后面不是加/；http://www.test.com/ weight ：权重，默认为1，最大值为256，0表示不参与负载均衡；

检查方法：

检查方法：
option httpchk 
option httpchk <uri>
option httpchk <method><uri>
option httpchk<method><uri><version>：不能用于frontend段，例如：

backend https_relay 
mode tcp 
option httpchk OPTIONS*HTTP/1.1\r\nHost:\www.test.com 
server apache1 .: check port 

使用案例：
server first .: cookie first check inter 
server second .: cookie second check inter

10、stats enable

启用基于程序编译时默认设置的统计报告，不能用于“frontend”区段。只要没有另外的其它设定，它们就会使用如下的配置：

-stats uri:/haproxy?stats

-stats realm:"HAProxy Statistics"

-stats auth:no authentication

-stats scope:no restriction

尽管“stats enable”一条就能够启用统计报告，但还是建议设定其它所有的参数，以免其依赖于默认设定而带来非期后果。下面是一个配置案例。

backend public_www
server websrv1 172.16.100.11:80
stats enable 
stats hide-version 
stats scope 
stats uri /haproxyadmin?stats 
stats realm Haproxy\ Statistics 
stats auth statsadmin:password 
stats auth statsmaster:password

11、stats hide-version

stats hide-version启用统计报告并隐藏HAProxy版本报告，不能用于“frontend”区段。默认情况下，统计页面会显示一些有用信息，包括HAProxy的版本号，然而，向所有人公开HAProxy的精确版本号是非常有风险的，因为它能帮助恶意用户快速定位版本的缺陷和漏洞。尽管"stats hide-

version”一条就能够启用统计报告，但还是建议设定其它所有的参数，以免其依赖于默认设定而带来非期后果。具体请参照“stats enable”一节的说明。

12、stats admin

stats admin{if |unless}

在指定的条件满足时启用统计报告页面的管理级别功能，它允许通过web接口启用或禁用服务器，不过，基于安全的角度考虑，统计报告页面应该尽可能为只读的。此外，如果启用了HAProxy的多进程模式，启用此管理级别将有可能导致异常行为。

目前来说，POST请求方法被限制于仅能使用缓冲区减去保留部分之外的空间，因此，服务器列表不能过长，否则，此请求将无法正常工作。

因此，建议一次仅调整少数几个服务器。下面是两个案例，第一个限制了仅能在本机打开报告页面时启用管理级别功能，第二个定义了仅允许通过认证的用户使用管理级别功能。

backend stats_localhost 
stats enable 
stats admin if LOCALHOST 

backend stats_auth 
stats enable 
stats auth haproxyadmin:password 
stats admin if TRUE

13、capture request header

capture request headerlen

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

agent”，以及代理环境中记录真实请求来源的“X-Forward-For”。

：要捕获的首部的名称，此名称不区分字符大小写，但建议与它们出现在首部中的格式相同，比如大写首字母。需要注意的是，记录在日志中的是首部对应的值，而非首部名称。

<1length>：指定记录首部值时所记录的精确长度，超出的部分将会被忽略。

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

14、capture response header

capture response header len

捕获并记录响应首部，其格式和要点同请求首部。

15、option httplog

option httplog [ clf ]

启用记录HTTP请求、会话状态和计时器的功能。

clf：使用CLF格式来代替HAProxy默认的HTTP格式，通常在使用仅支持CLF格式的特定日志分析器时才需要使用此格式。

默认情况下，日志输入格式非常简陋，因为其仅包括源地址、目标地址和实例名称，而“option httplog”参数将会使得日志格式变得丰富许多，其通常包括但不限于HTTP请求、连接计时器、会话状态、连接数、捕获的首部及cookie、“frontend”、“backend”及服务器名称，当然也包括源地址和端口号等。

16、option logasap

no option logasap

option logasap

no option logasap

启用或禁用提前将HTTP请求记入日志，不能用于“backend”区段。

默认情况下，HTP请求是在请求结束时进行记录以便能将其整体传输时长和字节数记入日志，由此，传较大的对象时，其记入日志的时长可能会略有延迟。option

1ogasap”参数能够在服务器发送complete首部时即时记录日志，只不过，此时将不记录整体传输时长和字节数。此情形下，捕获“Content-

Length”响应首部来记录传输的字节数是一个较好选择。下面是一个例子。

listen http_proxy 0.0.0.0:80
    mode http 
    option httplog
    option logasap
    1og 172.16.100.9 loca12

17、option forwardfor

option forwardfo \ [except ] header ][if-none]

允许在发往服务器的请求首部中插入“X-Forwarded-For”首部。

：可选参数，当指定时，源地址为匹配至此网络中的请求都禁用此功能。

：可选参数，可使用一个自定义的首部，如“x-client”来替代“X-Forwarded-

For”。有些独特的web服务器的确需要用于一个独特的首部。

if-none：仅在此首部不存在时才将其添加至请求报文问道中。

HAProxy工作于反向代理模式，其发往服务器的请求中的客户端IP均为HAProxy主机的地址而非真正客户端的地址，这会使得服务器端的日志信息记录不了真正的请求来源，“X-Forwarded-

For”首部则可用于解决此问题。HAProxy可以向每个发往服务器的请求上添加此首部，并以客户端IP为其value.

需要注意的是，HAProxy工作于隧道模式，其仅检查每一个连接的第一个请求，因此，仅第一个请求报文被附加此首部。如果想为每一个请求都附加此首部，请确保同时使用了“option httpclose”、“option forceclose”和“option http-server-close”几个option.

下面是一个例子。

frontend www 
    mode http 
    option forwardfor except 127.0.0.1

18、errorfile

errorfile

在用户请求不存在的页面时，返回一个页面文件给客户端而非由haproxy生成的错误代码；可用于所有段中。

：指定对HTTP的哪些状态码返回指定的页面：这里可用的状态码有200、400、403、408、500、502、503和5e4； ：指定用于响应的页面文件；

例如：

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

19、errorloc和errorlog302

errorloc

errorloc302

请求错误时，返回一个HTTP重定向至某URL的信息；可用于所有配置段中。

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

20、errorlog303

errorloc303

请求错误时，返回一个HTTP重定向至某URL的信息给客户端；可用于所有配置段中。

：指定对HTTP的哪些状态码返回指定的页面；这里可用的状态码有400、403、408、500、502、503和504； ：Location首部中指定的页面位置的具体路径，可以是在当前服务器上的页面的相对路径，也可以使用绝对路径：需要注意的是，如果URI自身错误时产生某特定状态码信息的话，有可能会导致循环定向：

例如

ACL

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

常用的测试标准（criteria）

1、be_sess_rate be_sess_rate（backend） 用于测试指定的backend上会话创建的速率（即每秒创建的会话数）是否满足指定的条件：常用于在指定backend上的会话速率过高时将用户请求转发至另外的backend，践用于阻止攻击行为。例如：

2、fe_sess_rate（frontend）

fe_sess_rate（frontend）

用于测试指定的frontend（或当前frontend）上的会话创建速率是否满足指定的条件：常用于为frontend指定一个合理的会话创建速率的上限以防止服务被滥用。例如下面的例子限定入站邮件速率不能大于50封/秒，所有在此指定范围之外的请求都将被延时50毫秒。

3、hdr

hdr（header）

用于测试请求报文中的所有首部或指定首部是否满足指定的条件：指定首部时，其名称不区分大小写，且在括号“（） ”中不能有任何多余的空白字符。测试服务器端的响应报文时可以使用shdr（）。例如下面的例子用于测试首部Connection的值是否为close。 hdr（Connection）-i close

4 、method method 测试HTTP请求报文中使用的方法。

5、path_beg 用于测试请求的URL是否以指定的模式开头。下面的例子用于测试URL是否以/static、/images、/javascript或/stylesheets头。 acl url_static path_beg -i /static /images /javascript /stylesheets

6、path_end 用于测试请求的URL是否以指定的模式结尾。例如，下面的例子用户测试URL是否以jpg、gif、png、css或js结尾。 ac1 url_static path_end-i .jpg .gif .png .css .js

7、hdr_beg 用于测试请求报文的指定首部的开头部分是否符合 指定的模式。例如，下面的例子用记测试请求是否为提供静态内容的主机img、video、download或ftp。 acl host_static hdr_beg（host）-i img. video. download. ftp.

8、hdr_end <string> 用于测试请求报文的指定首部的结尾部分是否符合指定的模式。例如，下面的例子用记测试请求是否为 url_beg: url_end:

path_reg url_reg

动静分离示例

ACL 定义，及调用

参考：http://cbonte.github.io/haproxy-dconv/configuration-1.4.html#4-redirect

开放策略：拒绝所有，只开放已知 拒绝策略：允许所有，只拒绝某些

我们自定定义一个 acl 如果访问的是 / bbs 开头的地址，那么将其跳转到 / forum

示例

haproxy 192.168.200.102

web1 192.168.200.107

web2 192.168.200.106

1、基于cookie实现会话绑定：

haproxy

web1 web2

client

2、基于uri实现调度；

haproxy

client

3、基于hdr实现调度：

harpoxy

client

3、实现基于 cookie 的会话绑定

4、启用 HAproxy 统计接口

haproxy

client

a、修改状态页监听端口

b、修改状态页 url

c、添加安全认证

4、动静分离 ​

5、用keepalived高可用haproxy

harpxoy keepalived

转载于:https://www.cnblogs.com/fina/p/10101680.html

后端 前端 epoll
上一篇: 字符串String、StringBuffer、StringBuilder类的区分
下一篇: 初识Django-介绍Django

继续阅读