HAproxy配置文件詳解

1、簡介

HAProxy提供高可用性、負載均衡以及基於TCP和HTTP應用的代 理，支持虛擬主機，它是免費、快速而且可靠的一種解決方案。HAProxy特別適用於那些負載特大的web站點，這些站點一般又須要會話保持或七層處理。HAProxy運行在當前的硬件上，徹底能夠支持數以萬計的併發鏈接。而且它的運行模式使得它能夠很簡單安全的整合進您當前的架構中， 同時能夠保護你的web服務器不被暴露到網絡上。

   HAProxy實現了一種事件驅動, 單一進程模型，此模型支持很是大的併發鏈接數。多進程或多線程模型受內存限制 、系統調度器限制以及無處不在的鎖限制，不多能處理數千併發鏈接。事件驅動模型由於在有更好的資源和時間管理的用戶端(User-Space) 實現全部這些任務，因此沒有這些問題。此模型的弊端是，在多核系統上，這些程序一般擴展性較差。這就是爲何他們必須進行優化以 使每一個CPU時間片(Cycle)作更多的工做。

   HAProxy是免費、極速且可靠的用於爲TCP和基於HTTP應用程序提供高可用、負載均衡和代理服務的解決方案，尤爲適用於高負載且須要持久鏈接或7層處理機制的web站點。

   HAProxy目前主要有兩個版本：

   1.4——提供較好的彈性：衍生於1.2版本，並提供了額外的新特性，其中大多數是期待已久的。

       客戶端側的長鏈接(client-side keep-alive)

       TCP加速(TCP speedups)

       響應池(response buffering)

       RDP協議

       基於源的粘性(source-based stickiness)

       更好的統計數據接口(a much better stats interfaces)

       更詳細的健康狀態檢測機制(more verbose health checks)

       基於流量的健康評估機制(traffic-based health)

       支持HTTP認證

       服務器管理命令行接口(server management from the CLI)

       基於ACL的持久性(ACL-based persistence)

       日誌分析器

   1.3——內容交換和超強負載：衍生於1.2版本，並提供了額外的新特性。

      內容交換(content switching)：基於任何請求標準挑選服務器池；

       ACL：編寫內容交換規則；

       負載均衡算法(load-balancing algorithms)：更多的算法支持；

       內容探測(content inspection)：阻止非受權協議；

       透明代理(transparent proxy)：在Linux系統上容許使用客戶端IP直接連入服務器；

       內核TCP拼接(kernel TCP splicing)：無copy方式在客戶端和服務端之間轉發數據以實現數G級別的數據速率；

       分層設計(layered design)：分別實現套接字、TCP、HTTP處理以提供更好的健壯性、更快的處理機制及便捷的演進能力；

       快速、公平調度器(fast and fair scheduler)：爲某些任務指定優先級可實現理好的QoS；

       會話速率限制(session rate limiting)：適用於託管環境；

   支持的平臺及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；

   在較新版本的Linux 2.6(>=2.6.27.19)上，HAProxy還可以使用splice()系統調用在接口間無複製地轉發任何數據，這甚至能夠達到10Gbps的性能。

   官方文檔：http://cbonte.github.io/haproxy-dconv/configuration-1.4.html

2、性能

   HAproxy藉助於OS上的集中常見的技術來實現性能的最大化

       單進程、時間驅動模型顯著下降了上下文切換的開銷和內存佔用

       0（1）事件檢查器（event checker）容許在其高併發鏈接中隊任何鏈接的任何事件實現即時探測

       在任何可用的狀況下，單緩存（singer buerffing）機制能以不復制任何數據的方式完成讀寫操做，這會節約大量的CPU時鐘週期及內存帶寬

       藉助於Linux2.6（實際上是2.6.19以上）上的splice（）系統調用，HAproxy能夠實現0複製轉發（Zero-copy forwarding），在linux3.5及以上的OS中還能夠實現零複製啓動（Zero-starting）

       MRU內存分配器在固定大小的內存池中實現即時內存分配，這可以顯著減小一個會話的時間

       樹形存儲：側重於使用做者多年前開發的彈性二叉樹，實現了以0(log(N))的低開銷來保持計時器命令、保持運行隊列及管理輪詢及最少鏈接隊列

       優化的HTTP首部分析：優化的首部分析過程避免了在HTTP首部分析過程當中重讀任何內存區域，精心的下降了昂貴的系統調用，大部時間都在用戶空間完成，如時間讀取、緩存聚合及文件描述符的啓用和禁用等

   全部的這些細微之處的優化實現了在中等規模負載之上依然有着至關低的CPU負載，甚至在很是高的負載場景中，5%的用戶空間佔用率和95%的系統空間佔用率也是很是廣泛的現象，這意味着HAproxy集成消耗比系統消耗低了20倍以上，所以，對0S進行性能調優是很是重要的，即時用戶空間的佔用率提高了一倍，其CPU佔用率也僅爲10%，這也監視了爲什麼7層處理對性能影響有限這一現象，由此，在高端系統上HAproxy的7層性能可輕易超過硬件負載均衡器

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

3、配置HAproxy

   3.1 配置文件格式

      HAproxy的配置處理3類主要參數來源：

           最優先處理的命令行參數

           "global"配置段，用於設定全局配置參數

           prxoy相關配置端，如"defaults","listen","frontend"和"backend"等

   3.2 時間格式

       一些包含了值得參數表示時間，如超時時長。這些值通常都以毫秒爲單位，但也可使用其餘的時間單位作後綴，如us（微妙，1/10000000秒），ms（毫秒，1/1000秒），s（秒），m（分鐘），h（小時），d（天）

   3.3 全局配置

   「global」配置中的參數爲進程級別的參數，且一般與其運行的OS有關

     進程管理及安全相關的參數

         chroot: 修改haproxy的工做目錄至指定的目錄，並在放棄權限以前執行chroot（）操做，能夠提高haproxy的安全級別，不過須要注意的是確保指定的目錄爲空目錄且任何用戶均不能有寫權限

         daemon：讓haproxy以守護進程的方式工做於後臺，其等同於「-D」選項的功能，固然，也能夠在命令行中以「-db」選項將其禁用

         gid：以指定的GID運行haproxy，建議使用專用於運行haproxy的GID，以免因權限帶來的風險

         group：同gid，不過這裏爲指定的組名

         uid: 已指定的UID身份運行haproxy進程

         user：同uid，但這裏使用的爲用戶名

         log：定義全局的syslog服務器，最多能夠定義兩個

         log-send-hostname <string>：在syslog信息的同步添加當前主機名，能夠爲「string」指定的名稱，也能夠缺省使用當前主機名

         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

   3.4 代理

       代理相關的配置能夠以下配置端中

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

          forntend：用於定義一系列監聽的套接字，這些套接字能夠接受客戶端請求並與子創建鏈接

          backend: 用於定義一系列「後端」服務器，代理將會將對應客戶端的請求轉發至這些服務器

          listen: 用於定義經過關聯「前段」和「後端」一個完整的代理，一般只對TCP流量有用

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

4、配置文件中的關鍵字詳解

   4.1 balance

       balance <algorithm> [<arguments>]

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

       定義負載均衡算法，可用於"defaults"、"listen"和"backend"中。<algorithm>用於在負載均衡場景中挑選一個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：經過<argument>爲URL指定的參數在每一個HTTP GET請求中將會被索引，日過找到了指定的參數且其經過等於號「=」被賦予了一個值，那麼此值將被執行hash運算並被服務器的總權重相處後派發至某匹配的服務器，此算法能夠經過追蹤請求中的用戶標識進而確保同一個用戶的ID請求被髮送同一個特定的服務器，除非服務器的總權重發生了變化；若是某請求中沒有出現指定的參數或其沒有有效值，則使用輪詢算法對其想用請求進行調度，此算法默認爲靜態，不過可使用hash-type修改此特性

           har（<name>）:對於每一個HTTP請求，經過<name>指定的HTTP首部將會被檢索，若是對於那個的首部沒有出現或其沒有有效值，則使用輪詢算法對響應請求進行調度，其有一個可選項「use_domain_only」能夠指定檢索相似host類的首部時僅計算域名部分（好比經過www.wangfeng7399.com來講，僅計算wangfeng7399.com字符串的hash值）以下降hash算法的運算量，此算法默認爲靜態，不過可使用hash-type修改此特性

           rdp-cookie

           rdp-cookie（name）：

   4.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端口，也但是一個端口範圍（如6604-6610），代理服務器將經過制定的端口來接受客戶端請求，須要注意的是，每組監聽的套接字<address:prot>在同一個實例上只能使用一次，並且小於1024的端口須要有特定的權限的用戶才能使用，這可能須要經過uid參數來定義

       <interface>：指定物理接口的名稱，僅能在linux系統上使用，其不能使用接口別名，二進程使用物理端口名稱，並且只有管理有權限指定綁定的物理端口
   4.3 mode

       mode{ tcp|http|health }

       設定實例的運行模式或協議，當實現內容交換時，前段和後端必須工做與統一中模式（通常說來時tcp模式），不然將沒法啓動實例

       tcp: 實例運行於純tcp模式，在客戶端和服務器端之間將創建一個全雙工的鏈接，且不會對7層報文作任何類型的檢查，此爲默認模式，一般用於SSL、SSH、SMTP等應用

       http：實例運行於http模式，客戶端請求在轉發至後端服務器以前將被深度分析，全部不與RFC模式兼容的請求都會被拒絕

       health：實例運行於health模式，其對入站請求僅響應「OK」信息並關閉鏈接，且不會記錄任何日誌信息 ，此模式將用於相應外部組件的監控狀態檢測請求；目前來說，此模式已經廢棄，由於tcp或http模式中的monitor關鍵字可完成此類功能

   4.4 hash-type

       hash-type <method>

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

        map-based：hash表示一個包含了全部在線服務器的靜態數組。其hash值將會很是平滑，會將權重考慮在列，但其爲靜態方法，對在線服務器的權重進行調整將不會生效，這意味着不支持慢速啓動。此外，挑選服務器是根據其在屬組中的位置運行的，所以，當一臺服務器宕機或添加了一臺新的服務器時，大多數鏈接將會倍從新派發至一個與此前不一樣的服務器上，對於緩存服務器的工做場景來講，此方法不甚適應

       consistent：hash表一個由個服務器填充而成的樹狀結構；基於hash間在hash樹種查找相應的服務器時，最近的服務器將被選中，此方法是動態的，支持在運行時修改服務器的權重，所以兼容慢啓動的特性，添加一個新的服務器時，僅會對一部分請求產生影響，所以，尤爲適用於後端服務器爲cache的場景 。不過，此算法不甚平滑，派發至各服務器的請求未必能達到理想的均衡效果，所以，可能須要不時的調整上游服務器的權重以得到更好的均衡性

   4.5  log

       log global

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

       爲每一個實例啓用事件和流量日誌，所以可用於全部區段。每一個實例最多可硬定義兩個log參數，不過，若是使用了「log global」且「global」端定義了兩個log參數時，多餘的log參數將會倍忽略

       global：當前實例的日誌系統參數同「global」段中的定義時，將使用此格式，每一個實例僅能定義一個「log global」語句，且其沒有額外的參數

       <address>：定義日誌發往的位置，其格式之一能夠爲<ipv4_address:port>，其中prot爲udp協議，默認爲514，格式之二爲Unix套接字文件路徑，當須要留心chroot應用及用戶讀寫權限

       <facility>: 能夠爲syslog系統的標準facility之一

       <level>: 定義日誌級別，即輸出信息過濾器，默認爲全部信息，指定級別時，全部等於或高於此級別的日誌信息將會被髮送

   4.6 maxconn

       maxconn <conns>

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

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

  4.7 default_backend

       default_backend <backend>

       在沒有匹配的「use_backend」規則時爲實例指定使用的默認後端，所以，其不可應用於backend區段，在「frontend」和「backend」之間進行內容交換時，一般使用「use-backend」定義其匹配規則，而沒有被匹配到的請求將有此參數指定的後端接收

       <backend>:指定使用的後端名稱

   4.8 server

       server<name><address>[:port][param*]

       在後端聲明一個server，所以，不能用於defaults和frontend區段。

       <name>: 爲此服務器指定的內部名稱，其將會出如今日誌及警告信息中；若是設定了「http-send-server-name」,他還將會被添加至發往此服務器的請求首部中

       <adderss>：此服務器的IPv4地址，也支持使用可解析的主機名，只不過在啓動時須要解析主機名至響應的IPV4地址

       <:port>：指定將鏈接請求所發往此服務器時的目標端口，其爲可選項，爲設定是，將使用客戶端請求時的同一相同端口

       [param*]：爲此服務器設定的一系列參數：其能夠得參數很是多，具體請參考官方文檔（http://cbonte.github.io/haproxy-dconv/configuration-1.4.html#5）中的說明，下面僅說明幾個經常使用的參數

            服務器或默認服務器參數:

               backup：設定爲備用服務器，僅在負載均衡場景中的其餘server均不能夠啓用此server

               check：啓動對此server執行監控狀態檢查，其能夠藉助於額外的其餘參數完成更精細的設定，如：

                   inter<delay>: 設定監控狀態檢查的時間間隔，單位爲毫秒，默認爲2000，也可使用fastinter和downinter來根據服務器端專題優化此事件延遲

                   rise<count>：設定檢查狀態檢查中，某離線的server從離線狀態轉換至正常狀態須要成功檢查的次數

                   fall<count>：設定檢查狀態檢查中，某離線的server從正常狀態轉換至離線狀態須要成功檢查的次數

               cookie<value>：爲指定server設定cookie值，此處指定的值將會在請求入站時被檢查，第一次爲此值挑選的server將會倍後續的請求所選中，其目的在於實現持久鏈接的功能

               maxconn<maxconn>：指定此服務器接受的最大併發鏈接數，若是發往此服務器的鏈接數目高於此處指定的值，其將被放置於請求隊列，以等待其餘鏈接被釋放

               maxqueue<maxqueue>：經過觀察服務器的通訊情況來判斷其健康狀態，默認爲禁用，其支持的類型有「layer 4」和「layer 7」，「layer 7」僅能用於http代理場景

               redir<prefix>：啓用重定向功能，將發往此服務的GET和HEAD請求均以302狀態碼響應，須要注意的是，在prefix後面不能使用/，且不能使用相對地址，以免形成循環，例如

server srv1 192..168.1.202:80 redir http://p_w_picpathserver.wangfeng7399.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
    server apache1 192.168.1.1:443 check port 80

   4.9 capture request header

       capture request header <name> len <length>

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

        <name>: 要捕獲的首部的名稱，此名稱不區分大小寫，但建議與他們出如今首部中的格式相同，好比大寫首字母，須要注意的是，記錄在日誌的是首部的值，而非首部名稱

        <length>: 指定距離首部值時所記錄的精確長度，超出的部分將會倍忽略

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

   4.10 capture response header

       capture response header <name> len <length>

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

   4.11  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 srv1 192.168.1.201:80
    stats enable
    stats hide-version
    stats scope   .
    stats uri     /admin?stats
    stats realm   Haproxy\ Statistics
    stats auth    admin1:AdMiN123
    stats auth    admin2:AdMiN321

   4.12 stats hide-version

       stats hide-version

       啓用統計報告並所以HAProxy版本報告，不能用於「frontend」區域，默認狀況下，統計頁面會顯示一些有用信息，包括HAProxy的版本號，而後，向全部人公開HAproxy的準確版本號是很是有危險的，由於他可以版主惡意用戶快速定位版本的缺陷和漏洞，儘管「stats hide-version」一條就可以啓用統計報告，但仍是建議設定其餘全部的參數，以免其依賴默認設定而帶來非預期後果請參照「stats enable」一節的說明

   4.13 stats realm

        stats realm <realm>

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

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

       儘管「stats realm」一條就可以啓用統計報告，但仍是建議設定其餘全部的參數，以免其依賴默認設定而帶來非預期，後果請參照「stats enable」一節的說明

   4.14 stats scope

       stats scope {<name>|"."}

       啓用統計報告並限定報告的區段，不能用於「frontend」區域，當指定此語句時，統計報告將僅顯示其列舉出區段的報告信息，全部其餘區段的信息將被隱藏，若是須要顯示多個區段的統計報告，此語句能夠定義屢次，須要注意的是，區段名稱進程僅僅是以字符串比較的方式進行，他不會真檢查指定的區段是否真正存在

       <name>：能夠是一個「listen」、「frontend」或「backend」區段的名稱，而「.」則表示stats scope語句所定義的當前區段

        儘管「stats scope」一條就可以啓用統計報告，但仍是建議設定其餘全部的參數，以免其依賴默認設定而帶來非預期後果，請參照「stats enable」一節的說明

   4.15 stats auth

       stats auth <user>:<password>

       啓用帶認證的統計報告功能並受權一個用戶帳號，不能用於「frontend」區域

       <user>：受權進行訪問的用戶名

       <password>：此用戶的訪問密碼，明文格式

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

       儘管「stats auth」一條就可以啓用統計報告，但仍是建議設定其餘全部的參數，以免其依賴默認設定而帶來非預期後果，請參照「stats enable」一節的說明

   4.16 stats admin

       atsts admin {if|unless}<cond>

       在指定的條件知足時啓用統計報告頁面的管理級別功能，他容許經過web接口啓用或禁用服務器，不過，基於安全的角度考慮，統計報告頁面應該儘量爲只讀的，此外，若是啓用了HAproxy的多進程模式，啓用此管理級別將會可能致使異常行爲

        目前來講，POST請求方法被限制於僅能使用緩衝區減去保留以外的空間，所以，服務器列表不能過長，不然，此請求將沒法正常工做，所以，建議一次僅調整少數幾個服務器，例如

Example :
# statistics admin level only for localhost
backend stats_localhost
    stats enable
    stats admin if LOCALHOST
限制了技能在本機打開報告頁面時啓用管理級別功能
Example :
# statistics admin level always enabled because of the authentication
backend stats_auth
    stats enable
    stats auth  admin:AdMiN123
    stats admin if TRUE
定義了僅容許經過認證的用戶使用管理級別功能

   4.17 option httplog

       option httplog [clf]

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

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

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

   4.18 option logasap  

        no option logasap

        啓用或禁用提早將HTTP請求記入日誌，不能用於「frontend」區段。

        默認狀況下，HTTP請求是在請求結束時進行記錄以便可以將其總體輸入時長和字節數記入日誌，由此，傳較大的對象時，其記入日誌的市場可能會略有延遲，「option logasap」參數可以在服務器發送complete首部時及時記錄日誌，只不過，此時將不記錄總體傳輸時長和字節數。此情形下，捕獲「Content-Length」響應報文來記錄的字節數是以一個較好的選擇

   4.19 option forwardfor

        option forwardfor[ except <network> ][ header <name> ][ if-none ]  

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

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

        <name>：可選參數，可以使用一個自定義的首部，如「X-Cluster-Client-IP」來代替「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  # stunnel already adds the header
# Those servers want the IP Address in X-Client
backend www
    mode http
    option forwardfor header X-Client

   4.20 errorfile

       errorfile <code> <file>

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

       <code>: 指定對HTTP的那些狀態碼發回指定的頁面，這裏可用的狀態碼有200、400、40三、40八、500、50二、503和504

       <file>：指定用於響應的頁面文件

       例如：

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

   4.21 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方法獲取指定的URL，對於非GET方法的場景（如POST）來講會產生問題，由於返回客戶端的URL是不容許使用GET意外的其餘方法的，若是的確有這種問題，可使用errorloc303來返回303狀態碼給客戶端

   4.22 errorloc303

       errorloc303 <code> <url>

       <code>: 指定對HTTP的那些狀態碼發回指定的頁面，這裏可用的狀態碼有400、40三、40八、500、50二、503和504

       <url>：Location首部中指定的頁面位置的具體路徑，能夠是在當前服務器上的頁面的相對路徑，也可使用絕對路徑，須要注意的是，若是URI之神錯誤時禪師某特定狀態碼信息的話，有可能會致使循環定向

5、ACL  

   haproxy的ACL用於實現基於請求報文的首部、響應報文的內容或其餘的環境狀態信息來作出轉發決策，這大大加強了其配置彈性，其配置法則一般非爲兩步，首先定義ACL，及定義一個測試條件，然後在條件獲得知足時執行某特定的動做，如阻止請求或轉發至某特定的後端，官方文檔（http://cbonte.github.io/haproxy-dconv/configuration-1.4.html#7）定義ACL的語法格式以下：

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

   <aclname>：ACL名稱，區分字符大小寫，其只能包含大小寫字符、數字、-（鏈接線）、_(下劃線)、.(點號)和：冒號，haproxy中，acl能夠重名，還能夠把多個測試條件定義爲一個共同的acl

   <criterion>: 測試標準，即對什麼信息發起測試，測試方式能夠有[flags]指定的標誌進行調整，而有些測試標準也能夠須要在其爲<value>以前指定一個操做符[operator]

   [flags]：目前haproxy的acl支持的標誌位有3個

       -i：不區分<value>中模式字符的大小寫

       -f：從指定的文件中加載模式

       --：標識符的強制結束標記，在模式中的字符串像標記符時使用

    <value>：acl測試條件支持的值有如下四類

       整數或證書範圍：如1024：65535表示從1024到65535，僅支持使用正整數（若是出現相似小數的標識，其一般爲測試版本），其支持使用的操做符有5個，分別爲eq（等於）、ge（大於等於）、gt(大於)、le(小於等於）和lt(小於)

       字符串：支持使用「-i」以忽略字符大小寫，支持使用「\」進行轉義，若是在模式首部出現了-i，能夠在以前使用「--」標識位

       正則表達式：其機制類同於字符串匹配

       IP地址及網絡地址

    同一個acl中能夠指定多個測試條件，這些測試條件須要由邏輯操做符指定其關係，條件間的組合測試關係有三種：「與」（默認即爲與操做）、「或」（使用「||」操做符和「or」）和「非」（使用「！」操做符）

   經常使用的測試標準

       5.1 be_sess_rate (integer)

           be_sess_rate(backend) (integer)

           用於測試指定的backend上會話建立的速率（即每秒建立的會話數）是否知足指定的條件，經常使用於在指定的backend上的會話速率太高時將用戶請求轉發至另外的backend，或用於阻止***行爲。例如：

backend dynamic
    mode http
    acl being_scanned be_sess_rate gt 100
    redirect location /denied.html if being_scanned

      5.2 fe_sess_rate <integer>

         fe_sess_rate(backend) (integer)

           用於測試指定的frontend（或當前fortend）上的建立速率是否知足指定的條件，經常使用於爲frontend指定一個合理的會話建立速率的上限以防止服務器被濫用，例如

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
定律限定入站郵件速率不能大於50封/秒，全部在指定範圍以外的請求都被延時50毫秒

       5.3 hdr <string>

           hdr(header) <string>

           用於測定請求報文中的全部首部或指定首部是否知足指定的條件，指定首部時，其名稱不區分大小寫，且在括號「（）」中不能有任何多餘的空白字符，測試服務器端的響應報文時可使用shdr（）。例如。下面的例子用於測試首部Connection的值是否爲close

hdr(Connection) -i close

       5.4 method <string>

           測試HTTP請求報文中使用的方法

       5.5 path_beg <string>

           用於測試請求的URI是否以<string>指定的模式開頭。

acl url_static       path_beg       -i /static /p_w_picpaths /javascript /stylesheets
測試URL是個以/static /p_w_picpaths /javascript /stylesheets開頭

       5.6 path_end <string>

           用於測試請求的URL是否以<string>指定的模式結尾

acl url_static       path_end       -i .jpg .gif .png .css .js
                                                                    
測試URI是否以.jpg .gif .png .css .js結尾

       5.7 hdr_beg <string>

           用於測試請求報文的指定首部的開頭部分是否符合<string>指定的模式

acl host_static hdr_beg(host) -i img. video. download. ftp.
用於測試請求報文首部中的主機是否已img. video. download. ftp.開頭

      5.8 hdr_beg <string>

           用於測試請求報文的指定首部結尾是否符合<string>指定的模式

       更多的參數請參照：http://cbonte.github.io/haproxy-dconv/configuration-1.4.html

       因爲本人水平有限，可能會有錯誤，請各位大神匹配指正