負載均衡服務之HAProxy基礎配置（四）

　　前文咱們聊了haproxy的狀態頁配置，狀態頁中顯示各參數的含義，以及基於cookie作會話保持的配置，回顧請參考http://www.javashuo.com/article/p-xovornbp-t.html；今天咱們來聊一聊haproxy的修改報文首部配置、壓縮功能、自定義策略對後端主機作健康狀態檢查；

　　首先咱們來看看haproxy的修改報文首部的配置；

　　做爲代理服務器，在完成一次http事務的過程當中，報文的流向是這樣的；首先用戶端的請求會到達haproxy，haproxy收到用戶的請求，對其進行拆包分析，而後根據用戶請求報文的某些首部的特徵，而後模擬用戶的請求去請求對應後端server，此時haproxy就扮演着客戶端角色去請求後端服務器；後端服務器收到haproxy的請求，而後響應資源內容給haproxy，haproxy收到後端服務器的響應，而後再次拆包，分析，而後封裝響應報文響應客戶端；在這樣的一個過程當中，對於客戶端的請求報文是否可以到達後端服務器或者後端服務器的響應報文是否可以到達客戶端這個須要haproxy說了算；簡單說haproxy能夠控制用戶的那些報文首部讓後端服務器看到，那些不能看到，又或者說haproxy能夠在請求報文中添加一些特定的首部發送給後端服務器，這就比如兩我的傳話，對於後面的人，中間傳話的人能夠添油加醋，固然也能夠一字不差的把原話傳給後面的人；對於後端服務器的響應也是同樣的道理，haproxy可讓客戶端看到某些首部，也可讓客戶端看不到某些首部；

　　示例：添加請求首部via： haproxy

　　測試：重啓haproxy後，在後端server上配置日誌格式顯示via的值，而後經過請求haproxy的80看看是否可以把對應的首部的值打印記錄下

　　重啓httpd

　　提示：本人的實驗環境是把後端server運行成容器的，因此重啓容器裏的應用對於httpd來講咱們須要用-k選項指定restart參數重啓httpd;

　　用瀏覽器訪問haproxy對外提供服務端IP和端口，看看當haproxy把請求調度到web1上對應日誌是否記錄via變量的值爲咱們定義的haproxy這個值

　　提示：能夠看到web1的日誌是能夠正常把請求首部via的值記錄下，說明via： haproxy首部成功傳向後端server；

　　示例：刪除請求報文中的User-Agent首部

　　提示：刪除操做一般是基於一匹配模式來作的，意思就是被該模式匹配到的首部都會刪除，除此還能夠基於模式不區分字符大小寫匹配報文；

　　修改web1的日誌格式，讓其記錄User-Agent首部

　　測試：重啓web1後，用瀏覽器訪問，而後在看web1的日誌，看看對應user-agent首部是否沒有值了

　　提示：能夠看到web1的日誌中對應user-agent首部的位置留空了，說明在請求首部中沒有user-agent；

　　示例：添加響應報文x-via: haproxy

　　提示：紅框中的配置表示在響應報文添加一首部，名稱爲x-via 值爲haproxy-1.5.18

　　測試：重啓haproxy用瀏覽器訪問，看看對應響應報文是否有x-via首部？

　　提示：能夠看到咱們添加在響應報文中的x-via 首部在響應報文中存在；

　　示例：刪除響應報文中server首部

　　提示：rspidel表示刪除不區分字符大小寫匹配到的響應首部，rspdel是區分字符大小寫的；

　　測試：重啓haproxy看看響應首部server是否還存在？

　　提示：重啓haproxy後，再次訪問，在其響應首部中就沒有server首部了；

　　啓用壓縮功能

 　　haproxy啓用壓縮功能同nginx的原理相似，在nginx裏咱們須要明確配置啓動壓縮功能，支持那些壓縮算法，最小壓縮大小以及壓縮級別等等；在haproxy中要啓用壓縮功能咱們只須要指定壓縮算法，以及壓縮資源類型便可；

　　示例：指定壓縮算法是gzip，壓縮資源類型爲文本類型資源text/html text/plain

　　提示：壓縮資源類型格式同MIME類型格式同樣；

　　測試：重啓haproxy，用瀏覽器訪問看看響應首部是否有Content-Encoding: gzip首部？

　　提示：從上面的測試結果看，在響應報文中可以看到Content-Encoding: gzip首部，這意味着壓縮功能已經啓用；除了gzip壓縮算法之外還有經常使用的壓縮算法還有deflate；

　　對後端服務器作http協議的健康狀態檢測

　　在上一篇博客中咱們經過狀態頁能夠查看後端server是否健康，這是haproxy的默認健康狀態檢測機制；默認健康狀態檢測是經過對後端server作tcp鏈接探測從而來判斷後端server是否健康；若是對應後端server的IP地址或端口不通時，haproxy就認爲該server不健康；其實這樣判斷不是不能夠只是判斷的力度不夠精準；爲了可以更加精準的檢測後端server的健康狀態，咱們能夠配置讓其健康狀態檢測在應用層上作；好比對後端server上的某個url發起訪問，若是可以正常響應，咱們就認爲後端server是健康的；

　　示例：基於http協議對後端server作健康狀態檢測；

　　提示：option httpchk 這個指令能夠配置defaults配置段中，能夠配置在backend配置段中和listen配置段中，不可用配置在frontend配置段中；以上配置表示使用http協議對後端server作健康狀態檢測，經過GET方法對/index.html發起訪問，若是能正常響應則後端server健康，反之亦然；

　　測試：重啓haproxy，把web1的主頁移動到別的地方去，看看狀態也上是否可以及時發現該server不健康了？

　　提示：能夠看到對應server的主頁不存在時，狀態頁上可以及時發發現後端server不健康了；

　　測試：把主頁還原，看看haproxy是否可以及時的發現後端server已經恢復正常了？

　　提示：能夠看到當後端server恢復正常時，在狀態也上對應主機會從down狀態慢慢轉向up狀態，知道幾回檢查都經過後，才徹底把down狀態的server轉換爲active up；這意味着必需要經過幾回檢查經過後該server纔可上線提供服務；