负载均衡服务之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才可上线提供服务；