haproxy七层代理

1、负载均衡

Load Balance ，简称 LB ，是一种服务或基于硬件设备等实现的高可用反向代理技术，负载均 衡将特定的业务(web 服务、网络流量等 ) 分担给指定的一个或多个后端特定的服务器或设备，从而提高了 公司业务的并发处理能力、保证了业务的高可用性、方便了业务后期的水平动态扩展

（1）四层负载均衡

a.通过 ip+port 决定负载均衡的去向。

b.对流量请求进行 NAT 处理，转发至后台服务器。

c. 记录 tcp 、 udp 流量分别是由哪台服务器处理，后续该请求连接的流量都通过该服务器处理。

d. 支持四层的软件

lvs ：重量级四层负载均衡器。

Nginx ：轻量级四层负载均衡器，可缓存。（ nginx 四层是通过 upstream 模块）

Haproxy ：模拟四层转发。

（2）七层负载均衡

a.通过虚拟 ur| 或主机 ip 进行流量识别，根据应用层信息进行解析，决定是否需要进行负载均衡。

b. 代理后台服务器与客户端建立连接，如 nginx 可代理前后端，与前端客户端 tcp 连接，与后端服务器建立 tcp连接 ,

c. 支持 7 层代理的软件：

Nginx: 基于 http 协议 (nginx 七层是通过 proxy_pass)

Haproxy: 七层代理，会话保持、标记、路径转移等

（3）四层七层区别

四层的负载均衡，就是通过发布三层的 IP 地址（ VIP ），然后加四层的端口号，来决定哪些流量需要做负 载均衡，对需要处理的流量进行NAT 处理，转发至后台服务器，并记录下这个 TCP 或者 UDP 的流量是由哪 台服务器处理的，后续这个连接的所有流量都同样转发到同一台服务器处理

七层的负载均衡，就是在四层的基础上（没有四层是绝对不可能有七层的），再考虑应用层的特征，比 如同一个Web 服务器的负载均衡，除了根据 VIP 加 80 端口辨别是否需要处理的流量，还可根据七层的 URL、浏览器类别、语言来决定是否要进行负载均衡。

a.分层位置 : 四层负载均衡在传输层及以下，七层负载均衡在应用层及以下

b. 性能 : 四层负载均衡架构无需解析报文消息内容，在网络吞吐量与处理能力上较高 : 七层可支持解析应用 层报文消息内容，识别URL 、 Cookie 、 HTTP header 等信息。、

c. 原理 : 四层负载均衡是基于 ip+port; 七层是基于虚拟的 URL 或主机 IP 等。

d. 功能类比 : 四层负载均衡类似于路由器 ; 七层类似于代理服务器。

e. 安全性 : 四层负载均衡无法识别 DDoS 攻击 ; 七层可防御 SYN Cookie/Flood 攻击

2、haproxy的安装和服务信息

A、haproxy实验环境部署

安装下载haproxy服务

[root@haproxy ~]# dnf install haproxy -y

server1&server2下载安装nginx服务

[root@server1 ~]# dnf install nginx -y
[root@server2 ~]# dnf install nginx -y

haproxy主机测试

（1）、haproxy的基本配置信息

a.global：全局配置段 进程及安全配置相关的参数 性能调整相关参数 、Debug

b.proxies：代理配置段 defaults：为frontend, backend, listen提供默认配置 ,frontend：前端，相当于nginx中的server {} ,backend：后端，相当于nginx中的upstream {} ,listen：同时拥有前端和后端配置,配置简单,生产推荐使用。

B、haproxy的基本部署方法以及负载均衡的实现

修改配置文件

[root@haproxy ~]# vim /etc/haproxy/haproxy.cfg

#重启服务
[root@haproxy ~]# systemctl restart haproxy.service 

测试：curl 172.25.254.100

C、haproxy的全局配置参数以及日志分离

设定多线程

[root@haproxy ~]# vim /etc/haproxy/haproxy.cfg

查看进程数

多线程

自定义日志

打开UDP协议

D、haproxy中的常用配置参数

[root@haproxy ~]# systemctl restart haproxy.service

[root@haproxy ~]# dnf install httpd -y
[root@haproxy ~]# vim /etc/httpd/conf/httpd.conf

backup ---sorryserver的端口\

3、算法

（1）、静态算法

静态算法：按照事先定义好的规则轮询公平调度，不关心后端服务器的当前负载、连接数和响应速度 等，且无法实时修改权重( 只能为 0 和 1, 不支持其它值 ) ，只能靠重启 HAProxy 生效。

a. static-rr ：基于权重的轮询调度

不支持运行时利用 socat 进行权重的动态调整 ( 只支持 0 和 1, 不支持其它值 ) 不支持端服务器慢启动

其后端主机数量没有限制，相当于 LVS 中的 wrr

b. first

根据服务器在列表中的位置，自上而下进行调度

其只会当第一台服务器的连接数达到上限，新请求才会分配给下一台服务 其会忽略服务器的权重设置 不支持用socat 进行动态修改权重 , 可以设置 0 和 1, 可以设置其它值但无效

（2）、动态算法

动态算法 ：基于后端服务器状态进行调度适当调整， 新请求将优先调度至当前负载较低的服务器

权重可以在 haproxy 运行时动态调整无需重启

a. roundrobin

1. 基于权重的轮询动态调度算法，

2. 支持权重的运行时调整，不同于 lvs 中的 rr 轮训模式，

3. HAProxy 中的 roundrobin 支持慢启动 ( 新加的服务器会逐渐增加转发数 ) ，

4. 其每个后端 backend 中最多支持 4095 个 real server ，

5. 支持对 real server 权重动态调整，

6. roundrobin 为默认调度算法 , 此算法使用广泛

b. leastconn

leastconn 加权的最少连接的动态

支持权重的运行时调整和慢启动，即 : 根据当前连接最少的后端服务器而非权重进行优先调度 ( 新客户 端连接) 比较适合长连接的场景使用，比如：MySQL 等场景。

c. source

源地址 hash ，基于用户源地址 hash 并将请求转发到后端服务器，后续同一个源地址请求将被转至同一 个后端web 服务器。此方式当后端服务器数据量发生变化时，会导致很多用户的请求转发至新的后端服 务器，默认为静态方式，但是可以通过hash-type 支持的选项更改这个算法一般是在不插入 Cookie 的 TCP 模式下使用，也可给拒绝会话cookie 的客户提供最好的会话粘性，适用于 session 会话保持但不支持 cookie和缓存的场景源地址有两种转发客户端请求到后端服务器的服务器选取计算方式，分别是取模法和一致性hash

d. map-based ：取模法，对 source 地址进行 hash 计算，再基于服务器总权重的取模，最终结果决定将此请 求转发至对应的后端服务器。 此方法是静态的，即不支持在线调整权重，不支持慢启动，可实现对后端服务器均衡调度 缺点是当服务器的总权重发生变化时，即有服务器上线或下线，都会因总权重发生变化而导致调度结果 整体改变

e.一致性hash，当服务器的总权重发生变化时，对调度结果影响是局部的，不会引起大的变动hash（o)mod n 该hash算法是动态的，支持使用 socat等工具进行在线权重调整，支持慢启动

f.uri 基于对用户请求的URI的左半部分或整个uri做hash，再将hash结果对总权重进行取模后 根据最终结果将请求转发到后端指定服务器适用于后端是缓存服务器场景 默认是静态算法，也可以通过hash-type指定map-based和consistent，来定义使用取模法还是一致性 hash

g、url_param对用户请求的url中的 params 部分中的一个参数key对应的value值作hash计算，并由服务器 总权重相除以后派发至某挑出的服务器,后端搜索同一个数据会被调度到同一个服务器，多用与电商 通常用于追踪用户，以确保来自同一个用户的请求始终发往同一个real server 如果无没key，将按roundrobin算法

h、hdr 针对用户每个http头部(header)请求中的指定信息做hash，此处由 name 指定的http首部将会被取出并做hash计算， 然后由服务器总权重取模以后派发至某挑出的服务器，如果无有效值，则会使用默认的轮询调度。

下线指定realserver

网页重定向

访问172.25.254.100界面重定向到百度

E、haproxy的热更新方法

# turn on stats unix socket
stats socket/var/lib/haproxy/stats mode 600 level admin
# utilize system-wide crypto-policiesssl-default-bind-cipherS PROFILE=SYSTEMssl-default-server-cipherS PROFILE=SYSTEM


[root@haproxy ~l# dnf install socat -y

[root@haproxy ~]# echo "help" | socat stdio /var/lib/haproxy/stats 

uri 一致性 hash 配置

url_param一致性hash配置hdr一致性hash配置

F、haproxy的状态页面监控

4、基于cookie的会话保持

cookie value ：为当前 server 指定 cookie 值，实现基于 cookie 的会话黏性，相对于基于 source 地址 hash 调度算法对客户端的粒度更精准，但同时也加大了haproxy 负载，目前此模式使用较少， 已经被 session 共享服务器代替

（1）配置选项

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

name ： #cookie 的 key 名称，用于实现持久连接

insert ： # 插入新的 cookie, 默认不插入 cookie

indirect ： # 如果客户端已经有 cookie, 则不会再发送 cookie 信息

nocache ： # 当 client 和 hapoxy 之间有缓存服务器（如： CDN ）时，不允许中间缓存器缓 cookie ，

# 因为这会导致很多经过同一个 CDN 的请求都发送到同一台后端服务器

G、基于cookie的会话保持

修改配置文件并重启haproxy服务测试

修改配置文件并重启haproxy服务

测试

（2）IP透传

H、IP透传

a、七层IP透传

如果把这行注释掉测试访问webserver1查看日志去掉注释再次测试server1停止nginx服务安装httpd服务测试查看日志

[root@server1 ~]# vim /etc/httpd/conf/httpd.conf

添加

b、四层IP透传

nginx服务下的ip透传

[root@server2 ~]# cat /var/log/nginx/access.log

[root@server2 ~]# vim /etc/nginx/nginx.conf

IP未透传

修改nginx.conf配置文件

[root@server2 ~]# cat /var/log/nginx/access.log

apache服务下的ip透传

5、ACL

是一种基于包过滤的访问控制技术

它可以根据设定的条件对经过服务器传输的数据包进行过滤 ( 条件匹配 ) 即对接收到的报文进行匹配和过滤，基于请求报文头部中的源地址、源端口、目标地址、目标端口、请求方法、URL 、文件后缀等信息内容进行匹配并执行进一步操作，比如允许其通过或丢弃。

（1）、ACL配置选项

# 用 acl 来定义或声明一个 acl

acl <aclname> <criterion> [flags] [operator] [<value>]

acl 名称 匹配规范 匹配模式 具体操作符 操作对象类型

（2）、ACL-Name 名称

acl test path_end -m sub /a

#ACL 名称，可以使用大字母 A-Z 、小写字母 a-z 、数字 0-9 、冒号：、点 . 、中横线和下划线，并且严格区分大 小写，比如:my_acl 和 My_Acl 就是两个完全不同的 acl5.8.1.2 ACL-criterion

（3）、ACL-flags 匹配模式

-i 不区分大小写

-m 使用指定的正则表达式匹配方法

-n 不做 DNS 解析

-u 禁止 acl 重名，否则多个同名 ACL 匹配或关系

（4）ACL-operator 具体操作符

- domain match (-m dom) : 查找提取的用点（ “." ）分隔字符串，如果其中任何一个匹配，则 ACL进行 匹配

整数比较： eq 、 ge 、 gt 、 le 、 lt

字符比较：

- exact match (-m str) : 字符串必须完全匹配模式

- substring match (-m sub) : 在提取的字符串中查找模式，如果其中任何一个被发现， ACL 将匹配

- prefix match (-m beg) : 在提取的字符串首部中查找模式，如果其中任何一个被发现， ACL 将匹配

- suffix match (-m end) : 将模式与提取字符串的尾部进行比较，如果其中任何一个匹配，则 ACL 进行 匹配

- subdir match (-m dir) : 查看提取出来的用斜线分隔（ “/" ）的字符串，如其中任一个匹配，则 ACL

进行匹配

I、ACL的常用参数

数据报文

J、ACL的应用实例

a、域名匹配

b、基于网段

frontend webcluster
    bind *:80
    mode http
    acl test  src  172.25.254.1 172.25.254.20 192.168.0.0/24
    use_backend webcluster-host if test
    default_backend default-host

backend wwebcluster-host
    mode http
    server webl 172.25.254.10:80 check inter 2 fall 2 rise 5

backend default-host
    mode http
    server web2 172.25.254.20:80 check inter 2 fall 2 rise 5


测试结果
[root@server1]# curl 172.25.254.100
default web server node10
[root@rs1 ~]# curl 192.168.0.101
RS1 192.168.0.101

[root@node1 ~]# curl 172.25.254.100
<html><body><h1>403 Forbidden</h1>
Request forbidden by administrative rules.
</body></html>

c、基于文件后缀名实现动静分离

frontend testacl
bind :80
mode http

acl url_static path_end -i .jpg .png .css .js .html
acl url_php path_end -i .php

use_backend static_host if url_static
use_backend php_host if url_php

default_backend default_webserver
backend static_host
mode http
server web1 172.25.254.10:80 check weight 1 inter 2 fall 3 rise 5
backend php_host
mode http
server web2 172.25.254.20:80 check weight 1 inter 2 fall 3 rise 5
backend default_webserver
mode http
server web1 172.25.254.10:80 check weight 1 inter 2 fall 3 rise 5

[root@server1 ~]# echo css 172.25.254.10 > /usr/share/nginx/html/index.css
[root@server2 ~]# echo php 172.25.254.20 > /var/www/html/index.php
[root@node1 ~]# curl 172.25.254.100/index.php
php 172.25.254.20
[root@node1 ~]# curl 172.25.254.100/index.css
css 172.25.254.10

K、自定义HAProxy 错误界面

[root@server1 ~]# systemctl stop httpd
[root@server2 ~]# systemctl stop nginx

浏览器访问172.25.254.100

错误页面重定向

L、Haproxy四层负载

[root@server1 ~]# dnf install mariadb-server -y

[root@server1 ~]# vim /etc/my.cnf.d/mariadb-server.cnf 
[root@server2 ~]# dnf install mariadb-server -y

[root@haproxy ~]# mysql -ull -p -h 172.25.254.100

M、haproxy的https加密访问

全站加密

子配置文件