HAProxy提供高可用性、負載均衡以及基於TCP和HTTP應用的代理，支持虛擬主機，它是免費、快速並且可靠地一套解決方案。HAProxy特別適用於那些負載特大的web站點，這些站點通常又需要會話保持或七層處理。HAProxy運行在時下的硬件上，完全可以支持數以萬計的併發連接。並且它的運行模式使得它可以很簡單的安全的整合進您當前的架構中，同時可以保護你的web服務器不被暴露到網絡上。
HAProxy實現了一種事件驅動、單一進程模型，此模型支持非常大的併發連接數。多進程或多線程模型受內存限制、系統調度器限制以及無處不在的鎖限制，很少能處理數千併發連接。事件驅動模型因爲在有更好的資源和時間管理的用戶端（user-space）實現所有這些任務，所有沒有這些問題。此模型的弊端是，在多核系統上，這些程序通常擴展性較差。這就是爲什麼他們必須進行優化以使每個cpu時間片（cycle）做更多的工作。
LB Cluster工作協議層分類：
1) 傳輸層（四層）
Lvs，nginx，haproxy（mode tcp）
2) 應用層（七層）
http：nginx（http模塊），haproxy（mode http），httpd，…
Note：haproxy和nginx一樣，是工作在用戶空間的應用程序，負載均衡能力同樣受限於套接字的數量限制；Lvs是工作在內核空間的，只是作爲了一個報文轉發的角色，不受限於端口的數量，所以有人說lvs優化可以承載四百萬個併發。
HAProxy安裝及參數配置：
配置文件：/etc/haproxy/haproxy.cfg
程序：/usr/sbin/haproxy
Unit file：
Centos6：/etc/rc.d/init.d/haproxy
Centos7：haproxy.service
配置可分爲兩段：
Global
配置參數：log，maxconn，…
Proxies（代理）
Defaults,frontend,backend,listen
示例：
frontend main *:80
default_backend websrvs
backend websrvs
balance roundrobin
server web1 172.16.100.68 check
server web2 172.16.100.69 check
演示1：配置haproxy負載均衡web服務；
1. 試驗環境
代理服務器（haproxy）：192.168.19.203
upserver1：192.168.19.143
upserver2：192.168.19.134
2. 編輯haproxy配置文件/etc/haproxy/haproxy.cfg，使其反向代理後端web服務器，
3. 啓動haproxy服務，查看端口是否開啓；
4. 爲後端兩臺upserver提供網頁測試頁面；
Upserver1：
Upserver2：
5. 測試代理服務器訪問；
HAProxy具體參數配置（全局配置GLOBAL）：
進程管理及安全相關的參數
1. chroot <jail dir>
修改haproxy的工作目錄至指定的目錄並在放棄權限之前執行chroot（）操作，可以提升haproxy的安全級別，不顧需要注意的是要確保指定的目錄爲空目錄且任何用戶均不能有寫權限；
2. daemon
讓haproxy以守護進程方式工作於後臺，其等同於“-D”選項的功能，當然，也可以在命令行中以“-db”選項將其禁用；
3. gid <number>
以指定的GID運行haproxy，建議使用專用於運行haproxy的GID，以免因權限問題帶來風險；
4. group
同gid，不過指定的組名；
5. uid
以指定的UID身份運行haproxy進程；
6. user
同uid，但使用的是用戶名；
7. nbproc <number>
指定啓動的haproxy進程的個數，只能用於守護進程模式的haproxy；默認只啓動一個進程，鑑於調試困難等多方面的原因，一般只在單進程僅能打開少數文件描述符的場景中才使用多進程模式；
8. pidfile
pid文件；
9. ulimit-n
設定每進程所能夠打開的最大文件描述符數目，默認情況下其會自動進行計算，因此不推薦修改此選項；
10. description
當前實例的描述信息
11. node
定義當前節點的名稱，用於HA場景中多haproxy進程共享同一個IP地址時；
12. log <address> <facility> [max level [min level]]
定義全局的syslog服務器，最多可以定義兩個；
13. log-send-hostname [<string>]：在syslog信息的首部添加當前主機名，可以爲“string”指定的名稱，也可以缺省使用當前的主機名；
演示：啓用haproxy的記錄日誌功能：
1) 編輯haproxy的配置文件，啓用記錄日誌功能；
2) 編輯/etc/rsyslog.conf配置文件，記錄一個記錄遠程日誌的tcp或udp服務；
3) 重啓rsyslog服務，並查看端口是否開啓；
4) 瀏覽器訪問測試，查看日誌；
性能調整相關的參數：
1. maxconn <number>
設定每個haproxy進程所接受的最大併發連接數，其等同於命令行選項“-n”；“ulimit -n”自動計算的結果正是參照此參數設定的；
2. maxpipes <number>
haproxy使用pipe完成基於內核的tcp報文重組，此選項則用於設定每進程所允許使用的最大pipe個數；每個pipe會打開兩個文件描述符，因此，“ulimit -n”自動計算時會根據需要調大此值；默認爲maxconn/4，其通常會顯得過大。
3. noepoll
在linux系統上禁用epoll機制；
4. nokqueue
在BSD系統上禁用epoll機制
5. nopoll
禁用poll機制；
6. nosepoll
在linux禁用啓發式epoll機制；
7. nosplice
禁止在linux套接字上使用內核tcp重組，這會導致更多的recv/send系統調用；不過，在Linux 2.6.25-28系列的內核上，tcp重組功能有bug存在；
8. spread-checks <0..50,in percent>
在haproxy後端有着衆多服務器的場景中，在精確的時間間隔後統一對衆服務器進行健康狀況檢查可能會帶來意外問題；此選項用於將其檢查的時間間隔長度上增加或減小到一定的隨機時長；
9. tune.bufsize <number>
設定buffer的大小，同樣的內存條件下，較小的值可以讓haproxy有能力接受更多的併發連接，較大的值可以讓某些應用程序使用較大的cookie信息；默認爲16384，其可以在編譯時修改，不過強烈建議使用默認值；
10. tune.chksize <number>
設定檢查緩衝區的大小，單位爲字節；更大的值有助於在較大的頁面中完成基於字符串或模式的文本查找，但也會佔用更多的系統資源；不建議修改；
11. tune.maxaccept <number>
設定haproxy進程內核調度運行時一次性可以接受的連接的個數，較大的值可以帶來較大的吞吐率，默認在單進程模式下爲100，多進程模式下爲8，設定爲-1可以禁止此限制；一般不建議修改；
12. tune.maxpollevents <number>
設定一次系統調用可以處理的事件最大數，默認值取決於OS；其值小於200時可節約帶寬，但會略微增大網絡延遲，而大於200時會降低延遲，但會稍稍增加網絡帶寬的佔用量；
13. tune.maxrewrite <number>
設定爲首部重寫或追加而預留的緩衝空間，建議使用1024左右的大小；在需要使用更大的空間時，haproxy會自動增加其值；
14. tune.rcvbuf.server <number>
設定內核套接字中服務端或客戶端接收緩衝的大小，單位爲字節；強烈推薦使用默認值；
Debugging、userlists、peers參數
1. Debugging 調試相關的參數；
debug ：儘量詳細的輸出信息；
quiet：儘量不輸出信息
2. Userlists：定義用戶、組及用戶列表
userlist <listname>
group <groupname> [users <user>,<user>,(...)]
user <username> [password|insecure-password <password>] [groups <group>,<group>,(...)]
3. Peers：定義haproxy同步集羣
peer
peers
HAProxy參數配置（代理配置段）：
代理相關的配置可以如下配置段中。
- defaults <name>
- frontend <name>
- backend <name>
- listen <name>
“defaults”段用於爲所有其它配置段提供默認參數，這配置默認配置參數可由下一個“defaults”所重新設定。
“frontend”段用於定義一系列監聽的套接字，這些套接字可接受客戶端請求並與之建立連接。
“backend”段用於定義一系列“後端”服務器，代理將會將對應客戶端的請求轉發至這些服務器。
“listen”段通過關聯“前端”和“後端”定義了一個完整的代理，通常只對TCP流量有用。
所有代理的名稱只能使用大寫字母、小寫字母、數字、-(中線)、_(下劃線)、.(點號)和:(冒號)。此外，ACL名稱會區分字母大小寫。
1. balance：指明調度算法
balance <algorithm> [ <arguments> ]
balance url_param <param> [check_post [<max_wait>]]
動態：權重可動態調整
靜態：調整權重不會實時生效
roundrobin：輪詢，動態算法，每個後端主機最多支持4128個連接；
static-rr：輪詢，靜態算法，每個後端主機支持的數量無上限
leastconn：最少連接算法，根據後端主機的負載數量進行調度；僅適用長連接的會話；動態；
source：源地址哈希算法，將來自同一個ip地址的請求發往同一個real server
將請求的源地址進行hash運算，並由後端服務器的權重總數相除後派發至某匹配的服務器；這可以使得同一個客戶端IP的請求始終被派發至某特定的服務器；不過，當服務器權重總數發生變化時，如某服務器宕機或添加了新的服務器，許多客戶端的請求可能會被派發至與此前請求不同的服務器；常用於負載均衡無cookie功能的基於TCP的協議；其默認爲靜態，不過也可以使用hash-type修改此特性；
hash-type：
map-based：取模法，靜態；
consistent：一致性哈希算法；動態；
uri：對URI的左半部分(“問題”標記之前的部分)或整個URI進行hash運算，並由服務器的總權重相除後派發至某匹配的服務器；這可以使得對同一個URI的請求總是被派發至某特定的服務器，除非服務器的權重總數發生了變化；此算法常用於代理緩存或反病毒代理以提高緩存的命中率；需要注意的是，此算法僅應用於HTTP後端服務器場景；其默認爲靜態算法，不過也可以使用hash-type修改此特性；
hash-type
map-based:
consistent:
url_param: 根據url中的指定的參數的值進行調度；把值做hash計算，併除以總權重；
hash-type
map-based:
consistent:
hdr(<name>) ：根據請求報文中指定的header(如use_agent, referer, hostname)進行調度；把指定的header的值做hash計算；
hash-type
map-based:
consistent:
rdp-cookie
rdp-cookie（<name>）
2. bind：設定監聽的地址和端口，適用於frontend，listen段
bind [<address>]:<port_range> [, ...]
bind [<address>]:<port_range> [, ...] interface <interface>
<address>：可選選項，其可以爲主機名、IPv4地址、IPv6地址或*；省略此選項、將其指定爲*或0.0.0.0時，將監聽當前系統的所有IPv4地址；
<port_range>：可以是一個特定的TCP端口，也可是一個端口範圍(如5005-5010)，代理服務器將通過指定的端口來接收客戶端請求；需要注意的是，每組監聽的套接字<address:port>在同一個實例上只能使用一次，而且小於1024的端口需要有特定權限的用戶才能使用，這可能需要通過uid參數來定義；
<interface>：指定物理接口的名稱，僅能在Linux系統上使用；其不能使用接口別名，而僅能使用物理接口名稱，而且只有管理有權限指定綁定的物理接口；
示例：
1) 編輯配置文件，適用bind監聽多個地址；
2) 重啓haproxy，查看端口；
3. mode {tcp|http|health}：設定haproxy工作模式
設定實例的運行模式或協議。當實現內容交換時，前端和後端必須工作於同一種模式(一般說來都是HTTP模式)，否則將無法啓動實例。
tcp：實例運行於純TCP模式，在客戶端和服務器端之間將建立一個全雙工的連接，且不會對7層報文做任何類型的檢查；此爲默認模式，通常用於SSL、SSH、SMTP等應用；
http：實例運行於HTTP模式，客戶端請求在轉發至後端服務器之前將被深度分析，所有不與RFC格式兼容的請求都會被拒絕；
health：實例工作於health模式，其對入站請求僅響應“OK”信息並關閉連接，且不會記錄任何日誌信息；此模式將用於響應外部組件的健康狀態檢查請求；目前業講，此模式已經廢棄，因爲tcp或http模式中的monitor關鍵字可完成類似功能；
4. log
log global
log <address> <facility> [<level> [<minlevel>]]
爲每個實例啓用事件和流量日誌，因此可用於所有區段。每個實例最多可以指定兩個log參數，不過，如果使用了“log global”且"global"段已經定了兩個log參數時，多餘了log參數將被忽略。
global：當前實例的日誌系統參數同"global"段中的定義時，將使用此格式；每個實例僅能定義一次“log global”語句，且其沒有任何額外參數；
<address>：定義日誌發往的位置，其格式之一可以爲<IPv4_address:PORT>，其中的port爲UDP協議端口，默認爲514；格式之二爲Unix套接字文件路徑，但需要留心chroot應用及用戶的讀寫權限；
<facility>：可以爲syslog系統的標準facility之一；
<level>：定義日誌級別，即輸出信息過濾器，默認爲所有信息；指定級別時，所有等於或高於此級別的日誌信息將會被髮送；
5. maxconn
maxconn <conns>
設定一個前端的最大併發連接數，因此，其不能用於backend區段。對於大型站點來說，可以儘可能提高此值以便讓haproxy管理連接隊列，從而避免無法應答用戶請求。當然，此最大值不能超出“global”段中的定義。此外，需要留心的是，haproxy會爲每個連接維持兩個緩衝，每個緩衝的大小爲8KB，再加上其它的數據，每個連接將大約佔用17KB的RAM空間。這意味着經過適當優化後，有着1GB的可用RAM空間時將能維護40000-50000併發連接。
如果爲<conns>指定了一個過大值，極端場景下，其最終佔據的空間可能會超出當前主機的可用內存，這可能會帶來意想不到的結果；因此，將其設定了一個可接受值方爲明智決定。其默認爲2000。
6. default_backend：爲frontend指明使用的默認後端；
default_backend <backend>
use_backend：條件式後端調用
示例：
use_backend dynamic if url_dyn
use_backend static if url_css url_img extension_img
default_backend dynamic
7. server
server <name> <addr>[:port] [param*]
backup：設定當前server爲backup server
check：健康狀態檢測
inter <delay>：檢測時間間隔，單位爲ms，默認爲2000；
fall：up --> down，soft state，soft state，hard state；
rise：down --> up，
cookie <value>：
maxconn：此服務接受的併發連接的最大數量；
maxqueue：請求隊列的最大長度；
observe：根據流量判斷後端server的健康狀態；
weight：指定權重，默認爲1，最大爲256；0表示不被調度；
redir <prefix>：重定向，所有發往此服務器的請求均已302響應；
8. 後端http服務時的健康狀態的檢測方法：
option httpchk
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
9. 基於瀏覽器cookie實現session sticky
backend webserver
balance roundrobin
cookie SERVERID insert nocache indirect
server web1 192.168.19.143:80 check weight 1 cookie webserver1
server web2 192.168.19.134:80 check weight 3 cookie webserver2
要點：
1) 每個server有自己唯一的cookie標識；
2) 在backend中定義爲用戶請求調度完成後操縱器cookie
演示：
1) 編輯配置文件；
2) 重啓服務後瀏覽器測試；
10. 啓用stats
listen statistics
bind *:9090
stats enable
stats hide-version 隱藏版本信息；
#stats scope . no restriction
stats uri /haproxyadmin?stats //自定義stats頁面的uri，默認爲/haproxy?stats
stats realm "HAPorxy\ Statistics" //啓用統計信息並設置身份認證域；
stats auth admin:mageedu //定義認證使用的賬號和密碼；
stats admin if TRUE //條件滿足啓用stats內建的管理功能接口；不建議啓用，有安全隱患；
stats refresh <delay> //自動刷新相關頁面的時間間隔；
演示：定義統計頁，並配置相關統計頁參數
1) 編輯配置文件，開啓統計頁；
重啓haproxy服務，並用瀏覽器訪問測試；
2) 編輯/etc/haproxy/haproxy.cfg配置文件，自定義統計頁的uri；
重啓服務並測試，輸入原來的uri將找不到頁面；
輸入自定義的uri：
3) 爲統計頁面添加賬號和密碼；
重啓服務後測試，輸入賬號密碼才能進入統計頁面；
4) 隱藏stats統計頁面的版本號，定義3s自動刷新一次頁面，啓動stats管理功能接口；
重啓服務並測試；
11. 向日志中記錄額外信息：
capture request header
capture request header <name> len <length>
捕獲並記錄指定的請求首部最近一次出現時的第一個值，僅能用於“frontend”和“listen”區段。捕獲的首部值使用花括號{}括起來後添加進日誌中。如果需要捕獲多個首部值，它們將以指定的次序出現在日誌文件中，並以豎線“|”作爲分隔符。不存在的首部記錄爲空字符串，最常需要捕獲的首部包括在虛擬主機環境中使用的“Host”、上傳請求首部中的“Content-length”、快速區別真實用戶和網絡機器人的“User-agent”，以及代理環境中記錄真實請求來源的“X-Forward-For”。
<name>：要捕獲的首部的名稱，此名稱不區分字符大小寫，但建議與它們出現在首部中的格式相同，比如大寫首字母。需要注意的是，記錄在日誌中的是首部對應的值，而非首部名稱。
<length>：指定記錄首部值時所記錄的精確長度，超出的部分將會被忽略。
可以捕獲的請求首部的個數沒有限制，但每個捕獲最多隻能記錄64個字符。爲了保證同一個frontend中日誌格式的統一性，首部捕獲僅能在frontend中定義。
演示：向日志添加額外信息；
1) 編輯配置文件；
2) 修改後端服務器httpd的配置文件，修改日誌格式；
3) 在代理服務器上重啓服務，並用瀏覽器測試訪問，查看後端服務器的日誌；
capture response header
capture response header <name> len <length>
捕獲並記錄響應首部，其格式和要點同請求首部。
12. 當mode爲httpd時，記錄豐富的日誌信息；
option httplog
13. 錯誤頁面重定向：
errorfile <code> <file>
在用戶請求不存在的頁面時，返回一個頁面文件給客戶端而非由haproxy生成的錯誤代碼；可用於所有段中。
<code>：指定對HTTP的哪些狀態碼返回指定的頁面；這裏可用的狀態碼有200、400、403、408、500、502、503和504；
<file>：指定用於響應的頁面文件；
errorfile：使用haproxy主機本地文件進行響應；
errorloc，errorloc302：使用指定的url進行響應，響應狀態碼爲302；不適用於GET以外的其它請求方法；
errorloc 303：返回303狀態碼；
14. 添加請求或響應報文首部；（適用範圍：frontend，backend，listen）
reqadd <string> [{if | unless} <cond>]：在請求報文添加一個首部信息；
rspadd <string> [{if | unless} <cond>]：在響應報文添加一個首部信息；
reqdel <search> [{if | unless} <cond>]：刪除請求報文首部
reqidel <search> [{if | unless} <cond>]：刪除請求報文首部（忽略大小寫）
rspdel <search> [{if | unless} <cond>]：刪除響應報文首部；
rspdel <search> [{if | unless} <cond>]：刪除響應報文首部（忽略大小寫）；
15. 訪問控制ACL
haproxy的ACL用於實現基於請求報文的首部、響應報文的內容或其它的環境狀態信息來做出轉發決策，這大大增強了其配置彈性。其配置法則通常分爲兩步，首先去定義ACL，即定義一個測試條件，而後在條件得到滿足時執行某特定的動作，如阻止請求或轉發至某特定的後端。定義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中可以指定多個測試條件，這些測試條件需要由邏輯操作符指定其關係。條件間的組合測試關係有三種：“與”(默認即爲與操作)、“或”(使用“||”操作符)以及“非”(使用“!”操作符)。
[operator]：
數值匹配：eq，ge，gt，le，lt
字符串匹配：
- exact match (-m str) : 字符串精確匹配
- substring match (-m sub) : 子串匹配
- prefix match (-m beg) : 前綴匹配
- suffix match (-m end) : 後綴匹配
- subdir match (-m dir) : 子目錄匹配
- domain match (-m dom) : 域匹配
條件邏輯連接：
AND
OR
block { if | unless } <condition>：條件匹配阻斷一個7層請求
常用的測試標準：
1) src,dst,src_port,dst_port
示例：
acl invalid_src src 0.0.0.0/7 224.0.0.0/3
acl invalid_src src_port 0:1023
acl local_dst hdr(host) -i localhost
block if invalid_src || local_dst
2) be_sess_rate <integer>
be_sess_rate(backend) <integer>
用於測試指定的backend上會話創建的速率(即每秒創建的會話數)是否滿足指定的條件；常用於在指定backend上的會話速率過高時將用戶請求轉發至另外的backend，或用於阻止***行爲。例如：
backend dynamic
mode http
acl being_scanned be_sess_rate gt 50
redirect location /error_pages/denied.html if being_scanned
3) 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
tcp-request inspect-delay 50ms
tcp-request content accept if ! too_fast
tcp-request content accept if WAIT_END
4) hdr <string>
hdr(header) <string>
用於測試請求報文中的所有首部或指定首部是否滿足指定的條件；指定首部時，其名稱不區分大小寫，且在括號“()”中不能有任何多餘的空白字符。測試服務器端的響應報文時可以使用shdr()。例如下面的例子用於測試首部Connection的值是否爲close。
hdr(Connection) -i close
5) method <string>
method <string>
測試HTTP請求報文中使用的方法。
6) path_beg <string>
用於測試請求的URL是否以<string>指定的模式開頭。下面的例子用於測試URL是否以/static、/images、/javascript或/stylesheets頭。
acl url_static path_beg -i /static /images /javascript /stylesheets
7) path_end <string>
用於測試請求的URL是否以<string>指定的模式結尾。例如，下面的例子用戶測試URL是否以jpg、gif、png、css或js結尾。
acl url_static path_end -i .jpg .gif .png .css .js
8) hdr_beg <string>
用於測試請求報文的指定首部的開頭部分是否符合<string>指定的模式。例如，下面的例子用記測試請求是否爲提供靜態內容的主機img、video、download或ftp。
acl host_static hdr_beg(host) -i img. video. download. ftp.
9) hdr_end <string>
用於測試請求報文的指定首部的結尾部分是否符合<string>指定的模式。
動靜分離示例：
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 url_static path_beg -i /static /images /javascript /stylesheets
acl url_static path_end -i .jpg .jpeg .gif .png .css .js
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