目錄

?編輯什么是負載均衡

為什么用負載均衡

四層和七層的區(qū)別

實驗環(huán)境

實驗步驟

webserver上安裝nginx

啟動nginx

安裝haproxy

編輯配置文件

多進程

多線程

SORRY SERVER

訪問重定向

maxconne最大可承受連接

socat?工具

常用示例

ha?p?r?ox?y?的?算?法

靜?態(tài)?算?法

static-rr:基于權(quán)重的輪詢調(diào)度

示例

first算法

示例

動態(tài)算法

roundrobin

示例

leastconn

示例

其他算法

source

示例

map-base取模法

示例

一致性hash

示例

uri

uri取模法配置示例

?uri一致性hash?配置示例

訪問測試

url_param

url_param取模法配置示例

url_param一致性hash?配置示例

測試訪問

hdr

hdr取模法配置示例

一致性hash?配置示例

測試訪問

算法總結(jié)

高?級?功?能?及?配?置

基于cookie的會話保持

配置選項

配置示例

訪問測試

?狀態(tài)頁

訪問測試

?編輯

IP透傳

layer 4與layer?7

四層負載

七層代理

四?層IP?透?傳

七層IP透?傳

示例

ACL

ACL-criterion?匹配規(guī)范

改本地解析

hdr——dom

hdr_beg

hdr_end

base: string

base_sub

base_reg

path

domin基于域名

匹配瀏覽器類型

基于文件后綴名實現(xiàn)動靜分離

?編輯

匹配訪問路徑實現(xiàn)動靜分離

自定義HAProxy??錯誤界面

重定向錯誤界面

HAProxy??https實現(xiàn)

---

什么是負載均衡

負載均衡：Load??????Balance,簡?稱LB, 是一種服務或基于硬件設備等實現(xiàn)的高可用反向代理技術(shù)，負載均?衡將特定的業(yè)務(web?服務、網(wǎng)絡流量等)分擔給指定的一個或多個后端特定的服務器或設備，從而提高了?公司業(yè)務的并發(fā)處理能力、保證了業(yè)務的高可用性、方便了業(yè)務后期的水平動態(tài)擴展

為什么用負載均衡

● ?Web服務器的動態(tài)水平擴展-->對用戶無感知

●增加業(yè)務并發(fā)訪問及處理能力-->解決單服務器瓶頸問題

●節(jié)約公網(wǎng)IP地址-->降低IT支出成本

●隱藏內(nèi)部服務器IP-->提高內(nèi)部服務器安全性

●配置簡單-->固定格式的配置文件

●功能豐富-->支持四層和七層，支持動態(tài)下線主機

●性能較強-->并發(fā)數(shù)萬甚至數(shù)十萬

四層負載均衡

1.通過ip+port決定負載均衡的去向。

2.對流量請求進行NAT 處理，轉(zhuǎn)發(fā)至后臺服務器。

3.記錄tcp、udp流量分別是由哪臺服務器處理，后續(xù)該請求連接的流量都通過該服務器處理。?4.支持四層的軟件

4.支持四層的軟件

● Ivs:重量級四層負載均衡器。

·Nginx:?輕量級四層負載均衡器，可緩存。(nginx?四層是通過upstream模塊)?

·Haproxy: ?模擬四層轉(zhuǎn)發(fā)。

1.通過虛擬ur| 或主機ip 進行流量識別，根據(jù)應用層信息進行解析，決定是否需要進行負載均衡。

2.代理后臺服務器與客戶端建立連接，如nginx可代理前后端，與前端客戶端tcp連接，與后端服務器建?立tcp連接，

3.支持7層代理的軟件：

·Nginx: ??基于http?協(xié)議(nginx 七層是通過proxy_pass)???

?·Haproxy: ??七層代理，會話保持、標記、路徑轉(zhuǎn)移等。

四層和七層的區(qū)別

所謂的四到七層負載均衡，就是在對后臺的服務器進行負載均衡時，依據(jù)四層的信息或七層的信息來決?定怎么樣轉(zhuǎn)發(fā)流量

四層的負載均衡，就是通過發(fā)布三層的IP地址(VIP),?然后加四層的端口號，來決定哪些流量需要做負?載均衡，對需要處理的流量進行NAT?處理，轉(zhuǎn)發(fā)至后臺服務器，并記錄下這個TCP?或者UDP 的流量是由??哪臺服務器處理的，后續(xù)這個連接的所有流量都同樣轉(zhuǎn)發(fā)到同一臺服務器處理

七層的負載均衡，就是在四層的基礎上(沒有四層是絕對不可能有七層的),再考慮應用層的特征，比?如同一個Web服務器的負載均衡，除了根據(jù)VIP加80端口辨別是否需要處理的流量，還可根據(jù)七層的

URL、瀏覽器類別、語言來決定是否要進行負載均衡。

1.分層位置：四層負載均衡在傳輸層及以下，七層負載均衡在應用層及以下

2.性能：四層負載均衡架構(gòu)無需解析報文消息內(nèi)容，在網(wǎng)絡吞吐量與處理能力上較高：七層可支持解析應?用層報文消息內(nèi)容，識別URL、Cookie、HTTP?header等信息。、

3.原理：四層負載均衡是基于ip+port;七層是基于虛擬的URL 或主機IP等。?4.功能類比：四層負載均衡類似于路由器；七層類似于代理服務器。

5.安全性：四層負載均衡無法識別DDoS攻擊；七層可防御SYN Cookie/Flood攻擊

實驗環(huán)境

功能	IP
客戶端	172.25.250.100/24
haproxy	172.25.250.100/24, eth1:192.168.0.10
RS1	eth0:172.25.250.10/24
RS2	eth0:172.25.250.20/24

實驗步驟

webserver上安裝nginx

dnf install nginx -y

寫入網(wǎng)頁文件

啟動nginx

安裝haproxy

注意區(qū)分在haproxy主機上安裝

dnf install haproxy -y

編輯配置文件

global?配?置參數(shù)說明

參數(shù)	類?型	作用
chroot	全?局	鎖定運行目錄
deamon	全?局	以守護進程運行
user,group,uid,gid	全?局	運行haproxy的用戶身份
stats?socket	全?局	套接字文件
nbproc N	全局	開啟的haproxy worker進程數(shù)，默認進程數(shù)是一個
nbthread?1(和nbproc?互斥)	全?局	指定每個haproxy進程開啟的線程數(shù)，默認為每個進程一個?線程
cpu-map?10	全?局	綁定haproxy worker進程至指定CPU,將第1個work進程綁?定至0號CPU
cpu-map?21	全?局	綁定haproxy worker進程至指定CPU,將第2個work進程綁?定至1號CPU
maxconn N	全?局	每個haproxy進程的最大并發(fā)連接數(shù)
maxsslconn N	全?局	每個haproxy進程ssl最大連接數(shù)，用于haproxy配置了證書的?場景下
maxConnrate N	全局	每個進程每秒創(chuàng)建的最大連接數(shù)量
spread-checks N	全局	后端server狀態(tài)check隨機提前或延遲百分比時間，建議2-?5(20%-50%)之間，默認值0
pidfile	全?局	指定pid文件路徑
log?127.0.0.1?local2?info	全局	定義全局的syslog服務器；日志服務器需要開啟UDP協(xié)議， 最多可以定義兩個

重啟服務

測試

如果重啟服務后訪問不了后端服務器，檢測haproxy監(jiān)聽的端口是否是80

如果是5000.記得把一下刪除

多進程

查看多進程信息

多線程

用的很少，僅做了解

SORRY SERVER

修改配置文件并重啟服務

記得要關(guān)閉一臺webserve的nginx服務

測試

訪問重定向

maxconne最大可承受連接

超過負載后就會把請求導向另外一個realserver

多開幾個端口進行訪問

socat?工具

對服務器動態(tài)權(quán)重和其它狀態(tài)可以利用socat工具進行調(diào)整，Socat?是 Linux?下的一個多功能的網(wǎng)絡工具，名字來由是Socket??CAT,相當于netCAT?的增強版.Socat?的主要特點就是在兩個數(shù)據(jù)流之間建立雙向?通道，且支持眾多協(xié)議和鏈接方式。如IP、TCP、UDP、IPv6、Socket???文件等

范例：利用工具socat??對服務器動態(tài)權(quán)重調(diào)整

下載工具

常用示例

要根據(jù)配置文件中的來寫socat

針對多進程的處理方法

ha?p?r?ox?y?的?算?法

HAProxy通過固定參數(shù)?balance 指明對后端服務器的調(diào)度算法?balance參數(shù)可以配置在listen?或backend選項中。

HAProxy 的調(diào)度算法分為靜態(tài)和動態(tài)調(diào)度算法

有些算法可以根據(jù)參數(shù)在靜態(tài)和動態(tài)算法中相互轉(zhuǎn)換。

靜?態(tài)?算?法

靜態(tài)算法：按照事先定義好的規(guī)則輪詢公平調(diào)度，不關(guān)心后端服務器的當前負載、連接數(shù)和響應速度?等，且無法實時修改權(quán)重(只能為0和1,不支持其它值),只能靠重啟HAProxy?生效。

static-rr:基于權(quán)重的輪詢調(diào)度

• ?不支持運行時利用socat?進行權(quán)重的動態(tài)調(diào)整(只支持0和1,不支持其它值)

• 不支持端服務器慢啟動

• 其后端主機數(shù)量沒有限制，相當于LVS?中的?wrr

慢啟動是指在服務器剛剛啟動上不會把他所應該承擔的訪問壓力全部給它，而是先給一部分，當沒?問題后在給一部分

示例

重啟服務

client上測試

不支持運行時利用socat?進行權(quán)重的動態(tài)調(diào)整(只支持0和1,不支持其它值)

first算法

●根據(jù)服務器在列表中的位置，自上而下進行調(diào)度

●其只會當?shù)谝慌_服務器的連接數(shù)達到上限，新請求才會分配給下一臺服務?·?其會忽略服務器的權(quán)重設置

●?不支持用socat?進行動態(tài)修改權(quán)重，可以設置0和1,可以設置其它值但無效

示例

調(diào)整maxconnect為1是為了方便演示效果

在多臺主機中執(zhí)行循環(huán)

達不到效果就多開幾個端口

while true; do curl 172.25.250.100; sleep 0.1; done

一堆10中會出現(xiàn)一個20，這是超過最大連接數(shù)后會調(diào)度到20上

測試完后改回maxconnect

動態(tài)算法

●基于后端服務器狀態(tài)進行調(diào)度適當調(diào)整，

●新請求將優(yōu)先調(diào)度至當前負載較低的服務器

●權(quán)重可以在haproxy?運行時動態(tài)調(diào)整無需重啟

roundrobin

1.基于權(quán)重的輪詢動態(tài)調(diào)度算法，

2.支持權(quán)重的運行時調(diào)整，不同于Ivs中?的rr輪訓模式，

3.HAProxy?中的roundrobin??支持慢啟動(新加的服務器會逐漸增加轉(zhuǎn)發(fā)數(shù)),

4.其每個后端backend?中最多支持4095個real??server,

5.支持對real server權(quán)重動態(tài)調(diào)整，

6.roundrobin?為默認調(diào)度算法，此算法使用廣泛?

支持慢啟動

示例

leastconn

• leastconn加權(quán)的最少連接的動態(tài)，將新的連接請求分配給當前連接數(shù)最少的服務器，以此來達到負載均衡的目的。

• ?支持權(quán)重的運行時調(diào)整和慢啟動，即：根據(jù)當前連接最少的后端服務器而非權(quán)重進行優(yōu)先調(diào)度(新客?戶端連接)

• ?比較適合長連接的場景使用，比如：MySQL?等場景。

示例

其他算法

其它算法即可作為靜態(tài)算法，又可以通過選項成為動態(tài)算法

source

源地址hash, ?基于用戶源地址hash并將請求轉(zhuǎn)發(fā)到后端服務器，后續(xù)同一個源地址請求將被轉(zhuǎn)發(fā)至同一?個后端web?服務器。此方式當后端服務器數(shù)據(jù)量發(fā)生變化時，會導致很多用戶的請求轉(zhuǎn)發(fā)至新的后端服??務器，默認為靜態(tài)方式，但是可以通過hash-type支持的選項更改這個算法一般是在不插入Cookie的TCP?模式下使用，也可給拒絕會話cookie的客戶提供最好的會話粘性，適用于session會話保持但不支持

cookie和緩存的場景源地址有兩種轉(zhuǎn)發(fā)客戶端請求到后端服務器的服務器選取計算方式，分別是取模法?和一致性hash

示例

測試

如果訪問客戶端時一個家庭，那么所有的家庭的訪問流量都會被定向到一臺服務器，這時source算?法的缺陷

map-base取模法

取模法用的較少，所以后續(xù)僅作示例，常用hash一致性算法

map-based:?取模法，對source地址進行hash計算，再基于服務器總權(quán)重的取模，最終結(jié)果決定將此?請求轉(zhuǎn)發(fā)至對應的后端服務器。

此方法是靜態(tài)的，即不支持在線調(diào)整權(quán)重，不支持慢啟動，可實現(xiàn)對后端服務器均衡調(diào)度

缺點是當服務器的總權(quán)重發(fā)生變化時，即有服務器上線或下線，都會因總權(quán)重發(fā)生變化而導致調(diào)度結(jié)果?整體改變，hash-type ??指定的默認值為此算法

所謂取模運算，就是計算兩個數(shù)相除之后的余數(shù)，10%7=3,7%4=3

map-based?算法：基于權(quán)重取模，hash(source_ip)%所有后端服務器相加的總權(quán)重

比如當源hash值時1111,1112,1113,三臺服務器a?b?c的權(quán)重均為1,

即abc的調(diào)度標簽分別會被設定為012(1111%3=1,1112%3=2,1113%3=0)?假設a?為0,1113主機會被調(diào)度到a上，

如果a下線后，權(quán)重數(shù)量發(fā)生變化

1111%2=1,1112%2=0,1113%2=1

1112和1113被調(diào)度到的主機都發(fā)生變化，這樣會導致會話丟失

示例

一致性hash

一致性哈希，當服務器的總權(quán)重發(fā)生變化時，對調(diào)度結(jié)果影響是局部的，不會引起大的變動hash(o)

mod???n

該hash 算法是動態(tài)的，支持使用socat?等工具進行在線權(quán)重調(diào)整，支持慢啟動?

1、后端服務器哈希環(huán)點keyA=hash?(后端服務器虛擬ip)%(2^32)

2、客戶機哈希環(huán)點keyl=hash(client_ip)%(2^32) ?????????????得到的值在[0---4294967295]之間，

3、將keyA 和keyl 都放在hash?環(huán)上，將用戶請求調(diào)度到離key1?最近的keyA 對應的后端服務器

hash?環(huán)偏斜問題

增加虛擬服務器IP?數(shù)量，比如：一個后端服務器根據(jù)權(quán)重為1生成1000個虛擬IP,??再?hash?。而后端服務器權(quán)?重為2則生成2000的虛擬IP, ??再bash, ??最終在hash??環(huán)上生成3000個節(jié)點，從而解決hash??環(huán)偏斜問題

hash對象

Hash?對象到后端服務器的映射關(guān)系：

一?致性hash?示意圖

示例

source 變成hash一致性

uri

基于對用戶請求的URI的左半部分或整個uri做hash, 再 將hash?結(jié)果對總權(quán)重進行取模后

根據(jù)最終結(jié)果將請求轉(zhuǎn)發(fā)到后端指定服務器?

適用于后端是緩存服務器場景

默認是靜態(tài)算法，也可以通過hash-type?指定map-based?和consistent,?來定義使用取模法還是一致性?hash

注意：此算法基于應用層，所以只支持mode????http,不?支?持mode??tcp，也就是只支持七層不支持四層

<scheme>://<user>:<password>@<host>:<port>/<path>;<params>?<query>#<frag> 左半部分：/<path>;<params>
整個uri:/<path>;<params>?<query>#<frag>

uri取模法配置示例

?uri一致性hash?配置示例

訪問測試

訪問不同的uri,?確認可以將用戶同樣的請求轉(zhuǎn)發(fā)至相同的服務器

如圖所示訪問不同的uri,?確認可以將用戶同樣的請求轉(zhuǎn)發(fā)至相同的服務器

url_param

url_param?對用戶請求的url中的?params??部分中的一個參數(shù)key對應的value值作hash?計算，并由服務器?總權(quán)重相除以后派發(fā)至某挑出的服務器，后端搜索同一個數(shù)據(jù)會被調(diào)度到同一個服務器，多用與電商

通常用于追蹤用戶，以確保來自同一個用戶的請求始終發(fā)往同一個real?server

如果無沒key, 將按roundrobin?算法?

#假設：
url=http://www.timinglee.com/foo/bar/index.php?key=value#則：
host="www.timinglee.com"   url_param="key=value"

url_param取模法配置示例

url_param一致性hash?配置示例

測試訪問

如圖

hdr

針對用戶每個http?頭部(header)?請求中的指定信息做hash,?此處由name?指定的http?首部將會被取出并做hash計算，

然后由服務器總權(quán)重取模以后派發(fā)至某挑出的服務器，如果無有效值，則會使用默認的輪詢調(diào)度。
?

hdr取模法配置示例

一致性hash?配置示例

測試訪問

算法總結(jié)

#靜態(tài)
static-rr--------->tcp/http#動態(tài)
roundrobin-------->tcp/http leastconn--------->tcp/http
random------------>tcp/http#以下靜態(tài)和動態(tài)取決于hash_type   是否consistent
source------------>tcp/http
Uri--------------->http
url_param--------->http
hdr--------------->httpfirst	#使用較少
static-rr	#做了session  共享的web集群
roundrobin random	
leastconn	#數(shù)據(jù)庫
source	#基于客戶端公網(wǎng)IP 的會話保持	
Uri--------------->http   	#緩存服務器，CDN服務商，藍汛、百度、阿里云、騰訊 
url_param--------->http     #可以實現(xiàn)session 保持
hdr                         #基于客戶端請求報文頭部做下一步處理

高?級?功?能?及?配?置

基于cookie的會話保持

cookie??value:為當前server?指定cookie?值，實現(xiàn)基于cookie?的會話黏性，相對于基于source???地址，hash?調(diào)度算法對客戶端的粒度更精準，但同時也加大了haproxy?負載，目前此模式使用較少，已經(jīng)被?session共享服務器代替

注意：不支持 tcp????mode,使?用http???mode

配置選項

cookie   name   [rewrite   | insert  |   prefix   ][ indirect   ][ nocache   ][postonly   ][ preserve   ][httponly     ][secure     ][domain    ]*[maxidle   <idle>][maxlife         ]name:  #cookie     的 key 名稱，用于實現(xiàn)持久連接 
insert:    #插入新的cookie, 默認不插入cookie
indirect: #如果客戶端已經(jīng)有cookie,    則不會再發(fā)送cookie   信息
nocache:  #當client    和hapoxy  之間有緩存服務器(如：CDN) 時，不允許中間緩存器緩存cookie, #因為這會導致很多經(jīng)過同一個CDN的請求都發(fā)送到同一臺后端服務器

cookie ? name ? [rewrite ? | insert ?| ? prefix ? ][ indirect ? ][ nocache ? ][postonly ? ][ preserve ? ][httponly ? ? ][secure ? ? ][domain ? ?]*[maxidle ? <idle>][maxlife ? ? ? ? ]

配置示例

訪問測試

可以看到cookie是我們設置的值

?狀態(tài)頁

訪問測試

IP透傳

web?服務器中需要記錄客戶端的真實IP地址，用于做訪問統(tǒng)計、安全防護、行為分析、區(qū)域排行等場?景。不做透傳是無法看到誰發(fā)送的請求，RS只能看到haproxy的ip

layer 4與layer?7

四 層?：IP+PORT 轉(zhuǎn)發(fā)

七層：協(xié)議+內(nèi)容交換

四層負載

在四層負載設備中，把client發(fā)送的報文目標地址(原來是負載均衡設備的IP地址),根據(jù)均衡設備設置的?選擇web?服務器的規(guī)則選擇對應的web?服務器IP?地址，這樣client?就可以直接跟此服務器建立TCP?連接并?發(fā)送數(shù)據(jù)，而四層負載自身不參與建立連接，而和LVS不 同 ，haproxy??是偽四層負載均衡，因為haproxy ??需要分別和前端客戶端及后端服務器建立連接

七層代理

七層負載均衡服務器起了一個反向代理服務器的作用，服務器建立一次TCP?連接要三次握手，而client要?訪?問Web???Server要先與七層負載設備進行三次握手后建立TCP連接，把要訪問的報文信息發(fā)送給七層負?載均衡；然后七層負載均衡再根據(jù)設置的均衡規(guī)則選擇特定的 Web?????Server,然后通過三次握手與此臺

Web??Server建?立TCP?連接，然后Web??Server把需要的數(shù)據(jù)發(fā)送給七層負載均衡設備，負載均衡設備再把?數(shù)據(jù)發(fā)送給client;所以，七層負載均衡設備起到了代理服務器的作用，七層代理需要和Client和后端服?務器分別建立連接

四?層IP?透?傳

haproxy上

server1

重啟服務

訪問一下172.25.250.100然后查看日志

七層IP透?傳

在?由haproxy?發(fā)往后端主機的請求報文中添加“"X-Forwarded-For"?首部，其值為前端客戶端的地址；用于?向后端主發(fā)送真實的客戶端IP

示例

ACL

訪問控制列表ACL,Access?Control?Lists)?是一種基于包過濾的訪問控制技術(shù)

它可以根據(jù)設定的條件對經(jīng)過服務器傳輸?shù)臄?shù)據(jù)包進行過濾(條件匹配)即對接收到的報文進行匹配和過?濾，基于請求報文頭部中的源地址、源端口、目標地址、目標端口、請求方法、?URL、 文件后綴等信息?內(nèi)容進行匹配并執(zhí)行進一步操作，比如允許其通過或丟棄。

ACL-criterion?匹配規(guī)范

hdr ???string,提取在一個HTTP?請求報文的首部 hdr([<name>[,<0cc>]]): ???????????????????完全匹配字符串，header ???的指定信息，<0CC>?表示在多值中使用的值的出 現(xiàn)次數(shù) hdr_beg([<name>[,<0Cc>]]): ???????前?綴?匹?配?，header?中指定匹配內(nèi)容的begin hdr_end([<name>[,<0Cc>]]): ????????????????后綴匹配，header ?中指定匹配內(nèi)容end hdr_dom([<name>[,<0Cc>]]): ????????域?匹?配?，header?中的domain ????name(host) hdr_dir([<name>[,<0Cc>]]):????????路徑匹配，header?的uri?路徑 hdr_len([<name>[,<0cc>]]): ?????????????????長度匹配，header ?的長度匹配 hdr_reg([<name>[,<0Cc>]]): ????????????????????正則表達式匹配，自定義表達式(regex) ???模糊匹配 hdr_sub([<name>[,<0cc>]]): ??????????????????子串匹配，header ??中的uri ??模糊匹配 模糊匹配c?洪湖報文中a/b/c 也會匹配 #示例： hdr(<string>)??????????用于測試請求頭部首部指定內(nèi)容 hdr_dom(host) ??請求的host?名稱，如?www.timinglee.org hdr_beg(host) ??請求的host?開頭，如www.img.video.?????????????download. ????????ftp. hdr_end(host) ??請求的host?結(jié)尾，如?.com????.net????.cn #示例： acl ??????bad_agent ??????hdr_sub(User-Agent)-i ??????curl ?????wget block?????if?????bad_agent #有些功能是類似的，比如以下幾個都是匹配用戶請求報文中host 的開頭是不是www acl???????short_form???????hdr_beg(host) ????????????????WwW. acl alternate1 hdr_beg(host)-m?beg www.?acl ????alternate2 ?????hdr_dom(host)-m?????beg ????www. acl ???????alternate3????????hdr(host) ??????????-m??beg ?www. base:string #返回第一個主機頭和請求的路徑部分的連接，該請求從主機名開始，并在問號之前結(jié)束，對虛擬主機有用?<scheme>://<user>:<password>@#<host>:<port>/<path>;<params>#?<query>#<frag> base????????????:exact?string?match base_beg?:prefix?match base_dir:subdir??match base_dom:domain ?????????match base_end?:suffix?match base_len:length ?match base_reg??????:regex??????match base_sub???????:substring???????match path:string #提取請求的URL?路徑，該路徑從第一個斜杠開始，并在問號之前結(jié)束(無主機部分)

改本地解析

C:\Windows\System32\drivers\etc、

hdr——dom

hdr_beg

hdr_beg請求的host開頭，如www. img. bbs.

重啟服務

改解析

測試

匹配上了就是web1

沒有匹配上就是20

hdr_end

重啟服務

測試結(jié)果

base: string

#返回第一個主機頭和請求的路徑部分的連接，該請求從第一個斜杠開始，并在問號之前結(jié)束,對虛擬主機有用

base_sub

sub就是網(wǎng)址整個一段中包含lee就算

不管是域名還是路徑

base_reg

正則表達式匹配

這里是匹配以lee結(jié)尾的正則

測試

path

#提取請求的URL路徑，該路徑從第一個斜杠開始，并在問號之前結(jié)束（無主機部分）

<scheme>:``//<user>:<password>@<host>:<port>#/<path>;<params>#?<query>#<frag>

domin基于域名

指定的域名導向webcluster

否則導向default-host

基于源ip或子網(wǎng)段

指定來源都拒絕

匹配瀏覽器類型

拒絕curl和?wget的訪問?

基于文件后綴名實現(xiàn)動靜分離

匹配訪問路徑實現(xiàn)動靜分離

自定義HAProxy??錯誤界面

停止10web和20nginx的服務

編寫文件

指定創(chuàng)建的文件

重啟hapraxy

然后去網(wǎng)頁訪問

重定向錯誤界面

重啟

在網(wǎng)頁測試訪問

HAProxy??https實現(xiàn)

haproxy??可以實現(xiàn)https?的證書安全，從用戶到haproxy??為https, ?從haproxy???到后端服務器用http?通?信?但基于性能考慮，生產(chǎn)中證書都是在后端服務器比如nginx?上實現(xiàn)

重啟服務

測試