專業的前端反向代理HAproxy簡及其配置文件詳解

時間 2020-08-09

原文原文鏈接

1、HAProxy簡介
HAProxy提供高可用性、負載均衡以及基於TCP和HTTP應用的代理，支持虛擬主機，它是免費、快速而且可靠的一種解決方案。HAProxy特別適用於那些負載特大的web站點，這些站點一般又須要會話保持或七層處理。HAProxy運行在時下的硬件上，徹底能夠支持數以萬計的併發鏈接。而且它的運行模式使得它能夠很簡單安全的整合進您當前的架構中，同時能夠保護你的web服務器不被暴露到網絡上。
HAProxy實現了一種事件驅動、單一進程模型，此模型支持很是大的併發鏈接數。多進程或多線程模型受內存限制、系統調度器限制以及無處不在的鎖限制，不多能處理數千併發鏈接。事件驅動模型由於在有更好的資源和時間管理的用戶端(User-Space) 實現全部這些任務，因此沒有這些問題。此模型的弊端是，在多核系統上，這些程序一般擴展性較差。這就是爲何他們必須進行優化以使每一個CPU時間片(Cycle)作更多的工做。
HAProxy是免費、極速且可靠的用於爲TCP和基於HTTP應用程序提供高可用、負載均衡和代理服務的解決方案，尤爲適用於高負載且須要持久鏈接或7層處理機制的web站點。php

2、HAproxy支持的平臺及OS：
x8六、x86_6四、Alpha、SPARC、MIPS及PARISC平臺上的Linux 2.4；
x8六、x86_6四、ARM (ixp425)及PPC64平臺上的Linux2.6；
UltraSPARC 2和3上的Sloaris 8/9；
Opteron和UltraSPARC平臺上的Solaris 10；
x86平臺上的FreeBSD 4.1-8；
i386, amd64, macppc, alpha, sparc64和VAX平臺上的OpenBSD 3.1-current；css

若要得到最高性能，須要在Linux 2.6或打了epoll補丁的Linux 2.4上運行haproxy 1.2.5以上的版本。haproxy 1.1l默認使用的polling系統爲select()，其處理的文件數達數千個時性能便會急劇降低。1.2和1.3版本默認的爲poll()，在有些操做系統上可會也會有性能方面的問題，但在Solaris上表現至關不錯。HAProxy 1.3在Linux 2.6及打了epoll補丁的Linux 2.4上默認使用epoll，在FreeBSD上使用kqueue，這兩種機制在任何負載上都能提供恆定的性能表現。
在較新版本的Linux 2.6(>=2.6.27.19)上，HAProxy還可以使用splice()系統調用在接口間無複製地轉發任何數據，這甚至能夠達到10Gbps的性能。html

基於以上事實，在x86或x86_64平臺上，要獲取最好性能的負載均衡器，建議按順序考慮如下方案。
Linux 2.6.32及以後版本上運行HAProxy 1.4；
打了epoll補丁的Linux 2.4上運行HAProxy 1.4；
FreeBSD上運行HAProxy 1.4；
Solaris 10上運行HAProxy 1.4；
前端

3、HAproxy的性能特色node

HAProxy藉助於OS上幾種常見的技術來實現性能的最大化。
一、單進程、事件驅動模型顯著下降了上下文切換的開銷及內存佔用。
二、O(1)事件檢查器(event checker)容許其在高併發鏈接中對任何鏈接的任何事件實現即時探測。
三、在任何可用的狀況下，單緩衝(single buffering)機制能以不復制任何數據的方式完成讀寫操做，這會節約大量的CPU時鐘週期及內存帶寬；
四、藉助於Linux 2.6 (>= 2.6.27.19)上的splice()系統調用，HAProxy能夠實現零複製轉發(Zero-copy forwarding)，在Linux 3.5及以上的OS中還能夠實現零複製啓動(zero-starting)；
五、 MRU內存分配器在固定大小的內存池中可實現即時內存分配，這可以顯著減小建立一個會話的時長；
六、樹型存儲：側重於使用做者多年前開發的彈性二叉樹，實現了以O(log(N))的低開銷來保持計時器命令、保持運行隊列命令及管理輪詢及最少鏈接隊列；
七、優化的HTTP首部分析：優化的首部分析功能避免了在HTTP首部分析過程當中重讀任何內存區域；
精心地下降了昂貴的系統調用，大部分工做都在用戶空間完成，如時間讀取、緩衝聚合及文件描述符的啓用和禁用等；web

全部的這些細微之處的優化實現了在中等規模負載之上依然有着至關低的CPU負載，甚至於在很是高的負載場景中，5%的用戶空間佔用率和95%的系統空間佔用率也是很是廣泛的現象，這意味着HAProxy進程消耗比系統空間消耗低20倍以上。所以，對OS進行性能調優是很是重要的。即便用戶空間的佔用率提升一倍，其CPU佔用率也僅爲10%，這也解釋了爲什麼7層處理對性能影響有限這一現象。由此，在高端系統上HAProxy的7層性能可輕易超過硬件負載均衡設備。正則表達式

能夠從三個因素來評估負載均衡器的性能：
一、會話率
二、會話併發能力
三、數據率redis

4、HAproxy的配置文件詳解算法

一、配置文件格式apache

HAproxy的配置文件主要分爲二大段：

——"global"配置段，用於設定全局配置參數；
——"proxy"相關配置段，主要包括「defaults」、「listen」、「frontend」和「backend」等配置端信息；

二、時間格式

一些包含了值的參數表示時間，如超時時長。這些值通常以毫秒爲單位，但也可使用其它的時間單位後綴。
us: 微秒(microseconds)，即1/1000000秒；
ms: 毫秒(milliseconds)，即1/1000秒；
s: 秒(seconds)；
m: 分鐘(minutes)；
h：小時(hours)；
d: 天(days)；

三、HAproxy的默認配置樣板

    global
        daemon
        maxconn 25600

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

    frontend http-in
        bind *:80
        default_backend servers

backend servers
server server1 127.0.0.1:8080 maxconn 32

配置了一個監聽在全部接口的80端口上HTTP proxy服務，它轉發全部的請求至後端監聽在127.0.0.1:8080上的"server"。

四、global段參數詳解

「global」配置中的參數爲進程級別的參數，且一般與其運行的OS相關，其生效範圍爲全局。

(1)、與進程管理及安全相關的參數
chroot <jail dir>：修改haproxy的工做目錄至指定的目錄並在放棄權限以前執行chroot()操做，能夠提高haproxy的安全級別，不過須要注意的是要確保指定的目錄爲空目錄且任何用戶均不能有寫權限；
daemon：讓haproxy以守護進程的方式工做於後臺，其等同於「-D」選項的功能，固然，也能夠在命令行中以「-db」選項將其禁用；
gid <number>：以指定的GID運行haproxy，建議使用專用於運行haproxy的GID，以避免因權限問題帶來風險；

group <group name>：同gid，不過指定是組名；
log <address> <facility> [max level [min level]]：定義全局的syslog服務器，最多能夠定義兩個；
log-send-hostname [<string>]：在syslog信息的首部添加當前主機名，能夠爲「string」指定的名稱，也能夠缺省使用當前主機名；
nbproc <number>：指定啓動的haproxy進程個數，只能用於守護進程模式的haproxy；默認只啓動一個進程，鑑於調試困難等多方面的緣由，通常只在單進程僅能打開少數文件描述符的場景中才使用多進程模式；
pidfile：haproxy的pid文件
uid：以指定的UID身份運行haproxy進程；
ulimit-n：設定每進程所可以打開的最大文件描述符數目，默認狀況下其會自動進行計算，所以不推薦修改此選項；
user：同uid，但使用的是用戶名；
stats：
node：定義當前節點的名稱，用於HA場景中多haproxy進程共享同一個IP地址時；
description：當前實例的描述信息；

(2)、性能調整相關的參數
maxconn <number>：設定每一個haproxy進程所接受的最大併發鏈接數，其等同於命令行選項「-n」；「ulimit -n」自動計算的結果正是參照此參數設定的；
maxpipes <number>：haproxy使用pipe完成基於內核的tcp報文重組，此選項則用於設定每進程所容許使用的最大pipe個數；每一個pipe會打開兩個文件描述符，所以，「ulimit -n」自動計算時會根據須要調大此值；默認爲maxconn/4，其一般會顯得過大；
noepoll：在Linux系統上禁用epoll機制；
nokqueue：在BSD系統上禁用kqueue機制；
nopoll：禁用poll機制；
nosepoll：在Linux禁用啓發式epoll機制；
nosplice：禁止在Linux套接字上使用內核tcp重組，這會致使更多的recv/send系統調用；不過，在Linux 2.6.25-28系列的內核上，tcp重組功能有bug存在；
spread-checks <0..50, in percent>：在haproxy後端有着衆多服務器的場景中，在精確的時間間隔後統一對衆服務器進行健康情況檢查可能會帶來意外問題；此選項用於將其檢查的時間間隔長度上增長或減少必定的隨機時長；
tune.bufsize <number>：設定buffer的大小，一樣的內存條件下，較小的值可讓haproxy有能力接受更多的併發鏈接，較大的值可讓某些應用程序使用較大的cookie信息；默認爲16384，其能夠在編譯時修改，不過強烈建議使用默認值；
tune.chksize <number>：設定檢查緩衝區的大小，單位爲字節；更大的值有助於在較大的頁面中完成基於字符串或模式的文本查找，但也會佔用更多的系統資源；不建議修改；
tune.maxaccept <number>：設定haproxy進程內核調度運行時一次性能夠接受的鏈接的個數，較大的值能夠帶來較大的吞吐率，默認在單進程模式下爲100，多進程模式下爲8，設定爲-1能夠禁止此限制；通常不建議修改；
tune.maxpollevents <number>：設定一次系統調用能夠處理的事件最大數，默認值取決於OS；其值小於200時可節約帶寬，但會略微增大網絡延遲，而大於200時會下降延遲，但會稍稍增長網絡帶寬的佔用量；
tune.maxrewrite <number>：設定爲首部重寫或追加而預留的緩衝空間，建議使用1024左右的大小；在須要使用更大的空間時，haproxy會自動增長其值；
tune.rcvbuf.client <number>：設定內核套接字中接收客戶端的緩衝大小，單位爲字節

tune.rcvbuf.server <number>：設定內核套接字中接收後端服務端的緩衝大小，單位爲字節；強烈推薦使用默認值；
tune.sndbuf.client <number>：設定內核套接字中發送給客戶端的緩衝大小，單位爲字節;

tune.sndbuf.server <number>：設定內核套接字中發送給後端服務器的緩衝大小，單位爲字節;

五、代理相關（proxy）配置段

「defaults」段用於爲全部其它配置段提供默認參數，這配置默認配置參數可由下一個「defaults」所從新設定。

「frontend」段用於定義一系列監聽的套接字，這些套接字可接受客戶端請求並與之創建鏈接。

「backend」段用於定義一系列「後端」服務器，代理將會將對應客戶端的請求轉發至這些服務器。這些後端服務器將會在"fronend"中被調用。

「listen」段經過關聯「前端(frontend)」和「後端(backend)」定義了一個完整的代理。這也就是說在即便沒有"frontend"段和"backend"段，也能夠實現一個完成代理的定義。所以。定義代理的方式有2種：一是經過定義"frontend"和"backend"來實現；而是經過定義"listen"段來實現。一般listen只對TCP流量有用。

注意：全部代理的名稱只能使用大寫字母、小寫字母、數字、-(中線)、_(下劃線)、.(點號)和:(冒號)組成。此外，ACL名稱會區分字母大小寫。

代理的相關參數有以下：

(1)、 balance

語法格式爲：

balance <algorithm> [ <arguments> ]

balance url_param <param> [check_post [<max_wait>]]

balance用來定義負載均衡算法，可用於「defaults」、「listen」和「backend」。<algorithm>用於在負載均衡場景中挑選一個server，其僅應用於持久信息不可用的條件下或須要將一個鏈接從新派發至另外一個服務器時。支持的算法有：

roundrobin：基於權重進行輪叫，在服務器的處理時間保持均勻分佈時，這是最平衡、最公平的算法。此算法是動態的，這表示其權重能夠在運行時進行調整，該方法支持慢啓動。不過，在設計上，每一個後端服務器僅能最多接受4128個鏈接；

static-rr：基於權重進行輪叫，與roundrobin相似，可是爲靜態方法，在運行時調整其服務器權重不會生效，除非重啓服務器，不支持慢啓動；不過，其在後端服務器鏈接數上沒有限制；

leastconn：新的鏈接請求被派發至具備最少鏈接數目的後端服務器；在有着較長時間會話的場景中推薦使用此算法，如LDAP、SQL等，其並不太適用於較短會話的應用層協議，如HTTP；此算法是動態的，能夠在運行時調整其權重，支持慢啓動；

source：將請求的源地址進行hash運算，並由後端服務器的權重總數相除後取模，再派發至某匹配的服務器；這可使得同一個客戶端IP的請求始終被派發至某特定的服務器；不過，當服務器權重總數發生變化時，如某服務器宕機或添加了新的服務器，許多客戶端的請求可能會被派發至與此前請求不一樣的服務器；經常使用於負載均衡無cookie功能但又要保持會話的場景中；其默認爲靜態，不過也可使用hash-type修改此特性；

uri：對URI的左半部分(「？」號以前的部分)或整個URI進行hash運算，並由服務器的總權重相除取模後再派發至某匹配的服務器；這可使得對同一個URI的請求老是被派發至某特定的服務器，除非服務器的權重總數發生了變化；此算法經常使用於後端服務器是緩存或反病毒代理服務器的場景，以提升緩存的命中率；須要注意的是，此算法僅應用於HTTP後端服務器場景；其默認爲靜態算法，不過也可使用hash-type修改此特性；該算法支持2個參數，len和depth。len表示取指定長度的uri作hash計算；depth表示取指定的目錄層次作hash計算。這兩個參數只須要指定一個便可。

url的格式以下：

scache://host[:port]/path[;parameters][?query][#fregment]。

好比：http://test.xsl.com/a/b/c/hh.php;hello=world?a1=4&a2=3;若是這裏使用len=8，表示取uri長度爲8作hash計算，這裏即取/a/b/c/hh作hash計算，而後在除以weight總和取模，從而來匹配將請求轉發至那臺服務器上。若是指定depth=3，則這裏是取/a/b/c這三級目錄結構作hash計算，併除以weight的總和取模，從而來匹配將請求轉發至那臺服務器上。

url_param：若是某個url中含有parameters，且該parameters被賦予了value，那麼此value將被執行hash運算並被服務器的總權重相除取模後派發至某匹配的服務器；此算法經常使用於後端服務器有用戶認證時，能夠經過追蹤請求中的用戶標識進而確保同一個用戶ID的請求將被送往同一個特定的服務器，除非服務器的總權重發生了變化；若是某請求中沒有出現指定的參數或其沒有有效值，則使用rr算法對相應請求進行調度；此算法默認爲靜態的，不過其也可使用hash-type修改此特性；

好比http://test.xsl.com/a/b/c/hh.php;hello=world?a1=4&a2=3這個url中的參數爲hello，其value爲world,使用url_param算法時，將會對world作hash計算，而後在除以weight總和並取模後，在匹配至相應的後端服務器。

hdr(<header_name>)：對於每一個HTTP請求，經過<header_name>指定的HTTP首部將會被檢索；若是相應的首部沒有出現或其沒有有效值，則使用rr算法對相應請求進行調度；其有一個可選選項「use_domain_only」，可在指定檢索相似Host類的首部時僅計算域名部分(好比經過www.magedu.com來講，僅計算magedu.com字符串的hash值)以下降hash算法的運算量；此算法默認爲靜態的，不過其也可使用hash-type修改此特性；
rdp-cookie
rdp-cookie(name)

(2)、bind

語法格式爲：

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

此指令僅能用於frontend和listen區段，用於定義一個或幾個監聽的套接字。

<address>：可選選項，其能夠爲主機名、IPv4地址、IPv6地址或*；省略此選項、將其指定爲*或0.0.0.0時，將監聽當前系統的全部IPv4地址；
<port_range>：能夠是一個特定的TCP端口，也但是一個端口範圍(如5005-5010)，代理服務器將經過指定的端口來接收客戶端請求；須要注意的是，每組監聽的套接字<address:port>在同一個實例上只能使用一次，並且小於1024的端口須要有特定權限的用戶才能使用，這可能須要經過uid參數來定義；
<interface>：指定物理接口的名稱，僅能在Linux系統上使用；其不能使用接口別名，而僅能使用物理接口名稱，並且只有管理有權限指定綁定的物理接口；

(3)、mode

語法格式：mode { tcp|http|health }

設定實例的運行模式或協議。當實現內容交換時，前端和後端必須工做於同一種模式(通常說來都是HTTP模式)，不然將沒法啓動實例。

tcp：實例運行於純TCP模式，在客戶端和服務器端之間將創建一個全雙工的鏈接，且不會對7層報文作任何類型的檢查；此爲默認模式，一般用於SSL、SSH、SMTP等應用；
http：實例運行於HTTP模式，客戶端請求在轉發至後端服務器以前將被深度分析，全部不與RFC格式兼容的請求都會被拒絕,支持7層過濾、處理與轉換等機制。

health：這種模式也被廢棄。

(4)、hash-type

語法格式：hash-type <method>

定義用於將hash碼映射至後端服務器的方法；其不能用於frontend區段；可用方法有map-based和consistent，在大多數場景下推薦使用默認的map-based方法。

map-based：hash表是一個包含了全部在線服務器的靜態數組。其hash值將會很是平滑，會將權重考慮在列，但其爲靜態方法，對在線服務器的權重進行調整將不會生效，這意味着其不支持慢速啓動。此外，挑選服務器是根據其在數組中的位置進行的，所以，當一臺服務器宕機或添加了一臺新的服務器時，大多數鏈接將會被從新派發至一個與此前不一樣的服務器上，對於緩存服務器的工做場景來講，此方法不甚適用。
consistent：hash表是一個由各服務器填充而成的樹狀結構；基於hash鍵在hash樹中查找相應的服務器時，最近的服務器將被選中。此方法是動態的，支持在運行時修改服務器權重，所以兼容慢速啓動的特性。添加一個新的服務器時，僅會對一小部分請求產生影響，所以，尤爲適用於後端服務器爲cache的場景。不過，此算法不甚平滑，派發至各服務器的請求未必能達到理想的均衡效果，所以，可能須要不時的調整服務器的權重以得到更好的均衡性。

(5)、log

語法格式爲：

log global
log <address> <facility> [<level> [<minlevel>]]

爲每一個實例啓用事件和流量日誌，所以可用於全部區段。每一個實例最多能夠指定兩個log參數，不過，若是使用了「log global」且"global"段已經定了兩個log參數時，多餘了log參數將被忽略。

log global：表示當前的日誌系統參數和"global"段中定義的同樣。每一個實例僅能定義一次「log global」語句，且其沒有任何額外參數；

<address>：定義日誌發往的位置，其格式之一能夠爲<IPv4_address:PORT>，其中的port爲UDP協議端口，默認爲514；格式之二爲Unix套接字文件路徑，但須要留心chroot應用及用戶的讀寫權限；
<facility>：能夠爲syslog系統的標準facility之一；
<level>：定義日誌級別，即輸出信息過濾器，默認爲全部信息；指定級別時，全部等於或高於此級別的日誌信息將會被髮送；

(6)、maxconn

語法格式爲：maxconn <conns>

設定一個前端的最大併發鏈接數，所以，其不能用於backend區段。對於大型站點來講，能夠儘量提升此值以便讓haproxy管理鏈接隊列，從而避免沒法應答用戶請求。固然，此最大值不能超出「global」段中的定義。此外，須要留心的是，haproxy會爲每一個鏈接維持兩個緩衝，每一個緩衝的大小爲8KB，再加上其它的數據，每一個鏈接將大約佔用17KB的RAM空間。這意味着通過適當優化後，有着1GB的可用RAM空間時將能維護40000-50000併發鏈接。

若是爲<conns>指定了一個過大值，極端場景下，其最終佔據的空間可能會超出當前主機的可用內存，這可能會帶來意想不到的結果；所以，將其設定了一個可接受值方爲明智決定。其默認爲2000。

(7)、default_backend

語法格式爲：default_backend <backend>

若是某請求沒有匹配任何"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

(8)、server

語法格式爲：server <name> <address>[:port] [param*]

server用來指定後端服務器的，服務器能夠由多個，server不能用於defaults和frontend區段。

<name>：爲此服務器指定的內部名稱，其將出如今日誌及警告信息中；若是設定了"http-send-server-name"，它還將被添加至發往此服務器的請求首部中；
<address>：此服務器的的IPv4地址，也支持使用可解析的主機名，只不過在啓動時須要解析主機名至相應的IPv4地址；
[:port]：指定將鏈接請求所發往的此服務器時的目標端口，其爲可選項；未設定時，將使用客戶端請求時的相同端口；
[param*]：爲此服務器設定的一系參數；其可用的參數很是多，具體請參考官方文檔中的說明，下面僅說明幾個經常使用的參數；
   backup：設定爲備用服務器，僅在負載均衡場景中的其它server均不可用於啓用此server；
   check：啓動對此server執行健康狀態檢查，其能夠藉助於額外的其它參數完成更精細的設定，如：
   inter <delay>：設定健康狀態檢查的時間間隔，單位爲毫秒，默認爲2000；也可使用fastinter和downinter來根據服務器端狀態優化此時間延遲；
   rise <count>：設定健康狀態檢查中，某離線的server從離線狀態轉換至正常狀態須要成功檢查的次數；
   fall <count>：確認server從正常狀態轉換爲不可用狀態須要檢查的次數；
cookie <value>：爲指定server設定cookie值，此處指定的值將在請求入站時被檢查，第一次爲此值挑選的server將在後續的請求中被選中，其目的在於實現session持久鏈接的功能；
maxconn <maxconn>：指定此服務器接受的最大併發鏈接數；若是發往此服務器的鏈接數目高於此處指定的值，其將被放置於請求隊列，以等待其它鏈接被釋放；
maxqueue <maxqueue>：設定請求隊列的最大長度；
observe <mode>：經過觀察服務器的通訊情況來斷定其健康狀態，默認爲禁用，其支持的類型有「layer4」和「layer7」，「layer7」僅能用於http代理場景；
redir <prefix>：啓用重定向功能，將發往此服務器的GET和HEAD請求均以302狀態碼響應；須要注意的是，在prefix後面不能使用/，且不能使用相對地址，以避免形成循環；例如：
server srv1 172.16.100.6:80 redir http://p_w_picpathserver.magedu.com check
weight <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.magedu.com
    server apache1 192.168.1.1:443 check port 80

server的配置模板以下：

server first 172.16.100.7:1080 cookie first check inter 1000
server second 172.16.100.8:1080 cookie second check inter 1000
其意思爲定義了2個後端服務器，其中cookie爲first的用戶請求被轉發中後端的172.16.100.7:8080處理，cookie爲second的用戶請求被轉發至後端的172.16.100.8:8080處理，且haproxy每隔1秒鐘檢查一下後端服務器的健康情況。

(9)、capture request header

語法格式爲：capture request header <name> len <length>

捕獲並記錄指定的請求首部最近一次出現時的第一個值，僅能用於「frontend」和「listen」區段。捕獲的首部值使用花括號{}括起來後添加進日誌中。若是須要捕獲多個首部值，它們將以指定的次序出如今日誌文件中，並以豎線「|」做爲分隔符。不存在的首部記錄爲空字符串，最常須要捕獲的首部包括在虛擬主機環境中使用的「Host」、上傳請求首部中的「Content-length」、快速區別真實用戶和網絡機器人的「User-agent」，以及代理環境中記錄真實請求來源的「X-Forward-For」。

<name>：要捕獲的首部的名稱，此名稱不區分字符大小寫，但建議與它們出如今首部中的格式相同，好比大寫首字母。須要注意的是，記錄在日誌中的是首部對應的值，而非首部名稱。
<length>：指定記錄首部值時所記錄的精確長度，超出的部分將會被忽略。

能夠捕獲的請求首部的個數沒有限制，但每一個捕獲最多隻能記錄64個字符。爲了保證同一個frontend中日誌格式的統一性，首部捕獲僅能在frontend中定義。

(10)、 capture response header

語法格式爲：capture response header <name> len <length>

捕獲並記錄響應首部，其格式和要點同請求首部。

(11)、stats enable

啓用統計報告功能，不能用於「frontend」區段。只要沒有另外的其它設定，它們就會使用以下的配置：

啓用統計報告功能，須要使用http模式，即須要添加"mode http"參數

- stats uri : /haproxy?stats

//經過訪問這個uri能夠顯示當前haproxy的狀態和鏈接統計信息
- 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

(12)、stats hide-version

stats hide-version：啓用統計報告並隱藏HAProxy版本報告，不能用於「frontend」區段。默認狀況下，統計頁面會顯示一些有用信息，包括HAProxy的版本號，然而，向全部人公開HAProxy的精確版本號是很是有風險的，由於它能幫助惡意用戶快速定位版本的缺陷和漏洞。儘管「stats hide-version」一條就可以啓用統計報告，但仍是建議設定其它全部的參數，以避免其依賴於默認設定而帶來非預期後果。

(13)、stats realm

語法格式：stats realm <realm>

啓用統計報告並顯示認證領域，不能用於「frontend」區段。haproxy在讀取realm時會將其視做一個單詞，所以，中間的任何空白字符都必須使用反斜線進行轉義。此參數僅在與「stats auth」配置使用時有意義。

<realm>：實現HTTP基本認證時顯示在瀏覽器中的領域名稱，用於提示用戶輸入一個用戶名和密碼

(14)、stats scope

語法格式：stats scope { <name> | "." }

啓用統計報告並限定報告的區段，不能用於「frontend」區段。當指定此語句時，統計報告將僅顯示其列舉出區段的報告信息，全部其它區段的信息將被隱藏。若是須要顯示多個區段的統計報告，此語句能夠定義屢次。須要注意的是，區段名稱檢測僅僅是以字符串比較的方式進行，它不會真檢測指定的區段是否真正存在。
<name>：能夠是一個「listen」、「frontend」或「backend」區段的名稱，而「.」則表示stats scope語句所定義的當前區段。

(15)、stats auth

語法格式爲：stats auth <user>:<passwd>

啓用基於用戶認證的統計報告功能，其不能用於「frontend」區段

<user>：受權進行訪問的用戶名；
<passwd>：此用戶的訪問密碼，明文格式；

此語句將基於默認設定啓用統計報告功能，並僅容許其定義的用戶訪問，其也能夠定義屢次以受權多個用戶賬號。能夠結合「stats realm」參數在提示用戶認證時給出一個領域說明信息。在使用非法用戶訪問統計功能時，其將會響應一個「401 Forbidden」頁面。其認證方式爲HTTP Basic認證，密碼傳輸會以明文方式進行，所以，配置文件中也使用明文方式存儲以說明其非保密信息故此不能相同於其它關鍵性賬號的密碼。

(16)、stats admin

語法格式：stats admin { if | unless } <cond>

在指定的條件知足時啓用統計報告頁面的管理級別功能，它容許經過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

(17)、option httplog

語法格式：option httplog [ clf ]

啓用記錄HTTP請求、會話狀態和計時器的功能。

clf：使用CLF格式來代替HAProxy默認的HTTP格式，一般在使用僅支持CLF格式的特定日誌分析器時才須要使用此格式

默認狀況下，日誌輸入格式很是簡陋，由於其僅包括源地址、目標地址和實例名稱，而「option httplog」參數將會使得日誌格式變得豐富許多，其一般包括但不限於HTTP請求、鏈接計時器、會話狀態、鏈接數、捕獲的首部及cookie、「frontend」、「backend」及服務器名稱，固然也包括源地址和端口號等。

(18)、option logasap

[no] option logasap：啓用或禁用提早將HTTP請求記入日誌，不能用於「backend」區段。

默認狀況下，HTTP請求是在請求結束後進行記錄以便能將其總體傳輸時長和字節數記入日誌，由此，傳較大的對象時，其記入日誌的時長可能會略有延遲。「option logasap」參數可以在服務器發送complete首部時即時記錄日誌，只不過，此時將不記錄總體傳輸時長和字節數。此情形下，捕獲「Content-Length」響應首部來記錄傳輸的字節數是一個較好選擇。下面是一個例子。
listen http_proxy 0.0.0.0:80
      mode http
      option httplog
      option logasap
      log 172.16.100.9 local2

(19)、option forwardfor

語法格式：option forwardfor [ except <network> ] [ header <name> ] [ if-none ]

容許在發往服務器的請求首部中插入「X-Forwarded-For」首部。

<network>：可選參數，當指定時，源地址爲匹配至此網絡中的請求都禁用此功能。

<name>：可選參數，可以使用一個自定義的首部，如「X-Client」來替代「X-Forwarded-For」。有些獨特的web服務器的確須要用於一個獨特的首部。

if-none：僅在此首部不存在時纔將其添加至請求報文問道中。

HAProxy工做於反向代理模式，其發往服務器的請求中的客戶端IP均爲HAProxy主機的地址而非真正客戶端的地址，這會使得服務器端的日誌信息記錄不了真正的請求來源，「X-Forwarded-For」首部則可用於解決此問題。HAProxy能夠向每一個發往服務器的請求上添加此首部，並以客戶端IP爲其value。若是後端的httpd服務器想要記錄客戶端的真實ip，而不是haproxy服務器的ip，能夠在httpd的配置文件中的LogFormat指令中，添加%{X-Client-IP}i字段。這樣當有請求達到時，httpd服務器的日誌文件中就會記錄的真是客戶端ip，就不會是haproxy的ip了。

下面是一個配置案例：

frontend www
mode http
option forwardfor except 127.0.0.1

(20)、option dontlognull

該參數表示不將空鏈接產生的污染數據記錄到日誌文件中。所謂空鏈接就是指鏈接已經創建上了，可是沒有任何傳輸任何數據。可是一般系統爲了證實這些鏈接時alive的，老是會發起一些探針，這些探針產生的數據咱們就將他稱爲污染數據。no option dontlognull表示禁用此功能，那麼這些污染數據將會記錄到日誌文件中。

(21)、option abortonclose

丟失因爲客戶端等待過長時間而關閉的鏈接但仍在haproxy隊列中的請求。

(22)、option http-server-close

在有keep-alive的鏈接中，若是保持鏈接在時間已超時或者請求已達到最大值時，客戶端仍然沒有斷開該鏈接的話，那麼server端將主動斷開此鏈接。已節省系統資源。並下降客戶端延遲。默認該功能啓用。

(23)、option redispatch

該參數主要用來實現session的重定向功能的。

在http mode中，若是啓用了基於cookie的session的綁定功能，那麼當後端的某臺服務器down掉時，該服務器上的session信息也會丟失，所以，此前由該臺服務器響應的請求將沒法訪問。option redispatch就能夠用來解決此問題，當後端的某臺服務器down掉時，則此前由該臺服務器處理的請求將由另一臺服務器進行響應處理，並把另一臺服務器的cookie返回給客戶端。以達到從新實現session保持功能。這樣，當客戶端下一次請求時，該請求將直接由另一臺服務器進行處理。固然，後端服務器down掉時，haproxy服務器會嘗試鏈接另外的服務器，所以，該功能要想啓用，還必須指定重連次數，即設定retires的值。該參數不能用於frontend段。

(24)、retries

當某個鏈接被拒絕或者超時後，從新嘗試鏈接的次數。若是設置了option redispatch的話，那麼最後一次重試會鏈接到另一臺服務器上去。以便返回不一樣服務器上的cookie信息，實現session重定向功能。

(25)、超時時長設置

timeout http request：設置請求的最大等待時間。當請求超時後，斷開客戶端鏈接。

timeout queue：當後端服務器達到最大鏈接時，新的鏈接將會放置到隊列中。爲了防止隊列中的鏈接無限制的等待下去。須要爲這些隊列中的鏈接設置一個超時時間。當超過該時間後，這些鏈接將會丟棄，並返回503錯誤。

timeout client：客戶端一次非活動鏈接的超時時長。非活動鏈接指的是鏈接已經創建，可是客戶端或服務器並未傳輸數據。

timeout server：服務器端非活動鏈接的超時時長。

timeout connect：haproxy鏈接後端服務器的超時時長。

timeout http-keep-alive：保持鏈接的超時時長。

timeout check：在實現健康情況檢查時，檢查後端服務器健康的超時時長。該值要小於timeout server。

(26)、errorfile

語法格式爲：errorfile <code> <file>

在用戶請求不存在的頁面時，返回一個頁面文件給客戶端而非由haproxy生成的錯誤代碼；可用於全部段中。

<code>：指定對HTTP的哪些狀態碼返回指定的頁面；這裏可用的狀態碼有200、400、40三、40八、500、50二、503和504；
<file>：指定用於響應的頁面文件；

配置案例以下：

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

(27)、errorloc 和 errorloc302

語法格式：

errorloc <code> <url>
errorloc302 <code> <url>

請求錯誤時，返回一個HTTP重定向至某URL的信息；可用於全部配置段中

<code>：指定對HTTP的哪些狀態碼返回指定的頁面；這裏可用的狀態碼有200、400、40三、40八、500、50二、503和504；
<url>：Location首部中指定的頁面位置的具體路徑，能夠是在當前服務器上的頁面的相對路徑，也可使用絕對路徑；須要注意的是，若是URI自身錯誤時產生某特定狀態碼信息的話，有可能會致使循環定向；

須要留意的是，這兩個關鍵字都會返回302狀態嗎，這將使得客戶端使用一樣的HTTP方法獲取指定的URL，對於非GET方法的場景(如POST)來講會產生問題，由於返回客戶的URL是不容許使用GET之外的其它方法的。若是的確有這種問題，可使用errorloc303來返回303狀態碼給客戶端。

(28)、errorloc303

語法格式：errorloc303 <code> <url>

請求錯誤時，返回一個HTTP重定向至某URL的信息給客戶端；可用於全部配置段中。

<code>：指定對HTTP的哪些狀態碼返回指定的頁面；這裏可用的狀態碼有400、40三、40八、500、50二、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
errorloc 403 /etc/haproxy/errorpages/sorry.htm
errorloc 503 /etc/haproxy/errorpages/sorry.htm

六、haproxy的acl

haproxy的acl提供了一種靈活的解決方案來實現內容交換。它能夠經過請求報文、響應報文及其餘環境狀態信息做出轉發決策。acl的一般用來阻塞請求、爲請求挑選後端服務器或者添加一些首部信息。acl的實現分爲2個步驟：首先去定義ACL，即定義一個測試條件，然後在條件獲得知足時執行某特定的動做，如阻止請求或轉發至某特定的後端。acl不能用於default段中。

定義ACL的語法格式以下。

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

(1)、aclname

<aclname>：ACL名稱，區分字符大小寫，且其只能包含大小寫字母、數字、-(鏈接線)、_(下劃線)、.(點號)和:(冒號)；在haproxy中，acl能夠重名，這能夠把多個測試條件定義爲一個共同的acl；這多個相同的acl彼此之間的關係爲"或"關係，也就是隻須要知足其中一個就算是匹配了。

(2)、criterion（標準、規範、準則的意思）

criterion表示測試標準或者測試條件，即對什麼樣的數據進行測試。這些數據一般指的是value。常見的criterion以下表所示：

criterion（測試標準）	匹配意義
src	匹配的是源ip地址或某個網絡。如： acl safe_ip src 127.0.0.1/8
src_port	匹配的是源端口。如： acl safe_port src_port 80
dst	匹配的目標ip或網絡
dst_port	匹配的是目標端口
path_beg <string>	用於測試請求的url中的path是否以指定的<string>結束的。以下實例用於測試請求是否以.gif、.png、.jpg、.css、.js結束的靜態內容。 acl url_static path_end .gif .png .jpg .css .js
path_end <string>	用於測試請求的url中的path是否以指定的<string>開始的。例如，以下實例用於測試請求的是否以/static、/p_w_picpaths、/img、/css開頭的靜態內容。 acl url_static path_beg /static /p_w_picpaths /img /css
path_end <string>		hdr_beg <string>	用於測試請求報文的指定首部的開頭部分是否符合<string>指定的模式。例如，下面的例子用於測試請求報文中的主機是以img、video、download或ftp開始的靜態內容主機。 acl host_static hdr_beg(host) -i img. video. download. ftp.
hdr_end <string>	用於測試請求報文的指定首部的結尾部分是否符合<string>指定的模式。例如，下面的例子用記測試請求報文中的主機是否屬於.xsl.com這個域內的主機. acl host_static hdr_end(host) -i .xsl.com
fe_sess_rate(frontend) <integer>	用於測試指定的frontend(或當前frontend)上的會話建立速率是否知足指定的條件；經常使用於爲frontend指定一個合理的會話建立速率的上限以防止服務被濫用。例以下面的例子限定入站郵件速率不能大於50封/秒，全部在此指定範圍以外的請求都將被延時50毫秒。 acl too_fast fe_sess_rate ge 50