說明:javascript
1.haproxy的配置段有"global","defaults","listen","frontend"和"backend"等
「global」配置中的參數爲進程級別的參數,且一般與其運行的操做系統有關
defaults:用於爲全部其餘配置段提供默認參數,這配置默認配置參數可由下一個"defaults"所從新設定
forntend:用於定義一系列監聽的套接字,這些套接字能夠接受客戶端請求並與子創建鏈接
backend: 用於定義一系列「後端」服務器,代理將會將對應客戶端的請求轉發至這些服務器
listen: 用於定義經過關聯「前段」和「後端」一個完整的代理,一般只對TCP流量有用
全部代理的名稱只能使用大寫字母、小寫字母、數字、-(中線)、_(下劃線)、.(點號)和:(冒號)。此外,ACL名稱會區分大小寫
2.時間格式一些包含了值得參數表示時間,如超時時長。這些值通常都以毫秒爲單位,但也可使用其餘的時間單位作後綴,如us(微妙,1/10000000秒),ms(毫秒,1/1000秒),s(秒),m(分鐘),h(小時),d(天)
3.配置參數詳細說明請參考http://cbonte.github.io/haproxy-dconv/configuration-1.4.html
一:global 全局配置
「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"所從新設定
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類的首部時僅計算域名部分以下降hash算法的運算量,此算法默認爲靜態,不過可使用hash-type修改此特性
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系統上使用,其不能使用接口別名,二進程使用物理端口名稱,並且只有管理有權限指定綁定的物理端口
mode
mode{ tcp|http|health }
設定實例的運行模式或協議,當實現內容交換時,前段和後端必須工做與統一中模式(通常說來時tcp模式),不然將沒法啓動實例
tcp: 實例運行於純tcp模式,在客戶端和服務器端之間將創建一個全雙工的鏈接,且不會對7層報文作任何類型的檢查,此爲默認模式,一般用於SSL、SSH、SMTP等應用
http:實例運行於http模式,客戶端請求在轉發至後端服務器以前將被深度分析,全部不與RFC模式兼容的請求都會被拒絕
health:實例運行於health模式,其對入站請求僅響應「OK」信息並關閉鏈接,且不會記錄任何日誌信息 ,此模式將用於相應外部組件的監控狀態檢測請求;目前來說,此模式已經廢棄,由於tcp或http模式中的monitor關鍵字可完成此類功能
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>: 定義日誌級別,即輸出信息過濾器,默認爲全部信息,指定級別時,全部等於或高於此級別的日誌信息將會被髮送
maxconn
maxconn <conns>
設定一個前段的最大併發鏈接數,所以,其不能用於backend區段,對於大型站點來講,能夠儘量提升此值以便讓haproxy管理鏈接隊列,從而便面沒法應答用戶請求。固然,此最大值不能超過「global」段中的定義。此外,須要留心的是,haproxy會爲每一個鏈接維持兩個緩衝,每一個緩存的大小爲8KB,在加上其餘的數據,每一個鏈接將大約佔用17KB的RAM空間,這意味着通過適當優化後 ,有着1GB的可用RAM空間時將維護40000-50000併發鏈接
若是爲<conns>指定了一個過大值,極端場景中,其最終所佔據的空間可能會超過當前主機的可用內存,這可能會帶來意想不到的結果,所以,將其設定一個可接受值放爲明智絕對,其默認爲2000
default_backend
default_backend <backend>
在沒有匹配的「use_backend」規則時爲實例指定使用的默認後端,所以,其不可應用於backend區段,在「frontend」和「backend」之間進行內容交換時,一般使用「use-backend」定義其匹配規則,而沒有被匹配到的請求將有此參數指定的後端接收
<backend>:指定使用的後端名稱
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://imageserver.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.1rnHost: www
server apache1 192.168.1.1:443 check port 80
capture request header
capture request header <name> len <length>
捕獲並記錄指定的請求首部最近一次出現時的第一個值,僅能用於「frontend」和「listen」區段,捕獲的首部值使用花括號{}括起來後添加進日誌中,若是須要捕獲多個首部值,他們將以指定的次序出如今日誌文件中,並以豎線「|」做爲分隔符,不存在的首部記錄爲空字符串,最長鬚要捕獲的首部包括在虛擬主機環境中使用的「host」、上傳請求首部中的「Content-length」、快速區別現實用戶和網絡機器人「User-agent」,已經代理環境中距離請求來源的「X-Forword-For」
<name>: 要捕獲的首部的名稱,此名稱不區分大小寫,但建議與他們出如今首部中的格式相同,好比大寫首字母,須要注意的是,記錄在日誌的是首部的值,而非首部名稱
<length>: 指定距離首部值時所記錄的精確長度,超出的部分將會倍忽略
能夠捕獲的請求首部的個數沒有限制,但每一個捕獲最多能記錄64個字符,爲了保證同一個frontend中日誌格式的統一性,首部捕獲僅能在frontend中定義
capture response header
capture response header <name> len <length>
捕獲並記錄響應首部。其格式和要點同捕獲的請求首部響應
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
stats hide-version
啓用統計報告並隱藏HAProxy版本報告,不能用於「frontend」區域,默認狀況下,統計頁面會顯示一些有用信息,包括HAProxy的版本號,而後,向全部人公開HAproxy的準確版本號是很是有危險的,由於他可以版主惡意用戶快速定位版本的缺陷和漏洞,儘管「stats hide-version」一條就可以啓用統計報告,但仍是建議設定其餘全部的參數,以免其依賴默認設定而帶來非預期後果請參照「stats enable」一節的說明
stats realm
stats realm <realm>
啓用統計報告並高精認證領域,不能用於「frontend」區域,haproxy在讀取realm是會講是作一個單詞,所以,中間的空白字符都必須使用反斜線進行轉移。此參數僅在與「stats auth」配置使用時有意義
<realm>:實現HTTP基本認證時顯示在瀏覽器中的領域名稱,用於提示用戶輸入一個用戶名和密碼
儘管「stats realm」一條就可以啓用統計報告,但仍是建議設定其餘全部的參數,以免其依賴默認設定而帶來非預期,後果請參照「stats enable」一節的說明
stats scope
stats scope {<name>|"."}
啓用統計報告並限定報告的區段,不能用於「frontend」區域,當指定此語句時,統計報告將僅顯示其列舉出區段的報告信息,全部其餘區段的信息將被隱藏,若是須要顯示多個區段的統計報告,此語句能夠定義屢次,須要注意的是,區段名稱進程僅僅是以字符串比較的方式進行,他不會真檢查指定的區段是否真正存在
<name>:能夠是一個「listen」、「frontend」或「backend」區段的名稱,而「.」則表示stats scope語句所定義的當前區段
儘管「stats scope」一條就可以啓用統計報告,但仍是建議設定其餘全部的參數,以免其依賴默認設定而帶來非預期後果,請參照「stats enable」一節的說明
stats auth
stats auth <user>:<password>
啓用帶認證的統計報告功能並受權一個用戶帳號,不能用於「frontend」區域
<user>:受權進行訪問的用戶名
<password>:此用戶的訪問密碼,明文格式
此語句將給予默認設定啓用統計功能報告,並僅容許其定義的用戶訪問,其也能夠定義屢次以手段多個用戶帳號,能夠結合「stats realm」參數在提示用戶認證是給出一個領域說明信息,在使用非法用戶訪問統計功能時,其將會響應一個「401 Forbidden」頁面,其認證方式爲HTTP Basic認證,密碼傳輸會以明文方式進行,所以,配置文件中也使用存儲明文方式存儲以說明其非保密信息故此不能想用與其餘關鍵性帳號的密碼。
儘管「stats auth」一條就可以啓用統計報告,但仍是建議設定其餘全部的參數,以免其依賴默認設定而帶來非預期後果,請參照「stats enable」一節的說明
stats admin
atsts admin {if|unless}<cond>
在指定的條件知足時啓用統計報告頁面的管理級別功能,他容許經過web接口啓用或禁用服務器,不過,基於安全的角度考慮,統計報告頁面應該儘量爲只讀的,此外,若是啓用了HAproxy的多進程模式,啓用此管理級別將會可能致使異常行爲
目前來講,POST請求方法被限制於僅能使用緩衝區減去保留以外的空間,所以,服務器列表不能過長,不然,此請求將沒法正常工做,所以,建議一次僅調整少數幾個服務器,
option httplog
option httplog [clf]
啓用記錄HTTP請求、會話狀態和計時器的功能
clf:使用CLF格式來代替HAproxy默認的HTTP格式,一般在使用僅支持CLF格式的特定日誌分析器時才須要使用此格式
默認狀況下,日誌輸入格式很是簡陋。由於其僅包括源地址、目標地址和實例名稱、而「option httplog」參數將會使得日誌變得豐富許多,其一般包括但不侷限於HTTP請求、鏈接計時器、會話狀態、鏈接數、捕獲的首部及cookie、「frontend」、「backend」及服務器名稱。固然也包括源地址和端口號等。
option logasap
no option logasap
啓用或禁用提早將HTTP請求記入日誌,不能用於「frontend」區段。
默認狀況下,HTTP請求是在請求結束時進行記錄以便可以將其總體輸入時長和字節數記入日誌,由此,傳較大的對象時,其記入日誌的市場可能會略有延遲,「option logasap」參數可以在服務器發送complete首部時及時記錄日誌,只不過,此時將不記錄總體傳輸時長和字節數。此情形下,捕獲「Content-Length」響應報文來記錄的字節數是以一個較好的選擇
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,例如
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
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狀態碼給客戶端
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>指定的模式開頭。 1 acl url_static path_beg -i /static /images /javascript /stylesheets 測試URL是個以/static /images /javascript /stylesheets開頭 5.6 path_end <string> 用於測試請求的URL是否以<string>指定的模式結尾 1 acl url_static path_end -i .jpg .gif .png .css .js 測試URI是否以.jpg .gif .png .css .js結尾 5.7 hdr_beg <string> 用於測試請求報文的指定首部的開頭部分是否符合<string>指定的模式 1 acl host_static hdr_beg(host) -i img. video. download. ftp. 用於測試請求報文首部中的主機是否已img. video. download. ftp.開頭 5.8 hdr_beg <string> 用於測試請求報文的指定首部結尾是否符合<string>指定的模式css