【Haproxy】七层代理

HAProxy 七层代理知识点与实验原理总结

负载均衡基础概念

负载均衡通过反向代理技术将业务请求分发到多个后端服务器，提升并发处理能力、保证高可用性、便于水平扩展。核心价值包括实现Web服务器动态扩展、突破单服务器瓶颈、节约公网IP、隐藏内部服务器IP。

负载均衡类型

• 硬件负载均衡：性能强、成本高，适合大型企业场景（如F5、Netscaler）
• 四层负载均衡：基于IP+端口转发，修改报文头部，处理TCP/UDP协议（如LVS、Nginx upstream模块）
• 七层负载均衡：基于应用层信息（URL、浏览器类型等）转发（如Nginx proxy_pass、HAProxy）

四层与七层区别

• 分层位置：四层在传输层及以下，七层在应用层及以下
• 转发依据：四层基于IP+端口，七层基于URL、Cookie等
• 性能：四层无需解析报文内容，性能更高
• 安全性：七层可防御SYN Flood等应用层攻击

HAProxy特性

• 支持高并发（万级以上）和高性能
• 功能包括负载均衡、会话保持、健康检查、正则匹配
• 版本分为社区版（基础功能）和企业版（高级支持）

负载均衡算法

• 静态算法：static-rr（权重轮询）、first（顺序调度）
• 动态算法：roundrobin（默认）、leastconn（最少连接）
• 混合算法：source（IP哈希）、uri（URL哈希）、hdr（HTTP头部匹配）

会话保持与健康检查

• 通过cookie参数实现基于Cookie的会话保持
• option httpchk实现应用层健康检查（HTTP状态码等）

状态页配置

listen statsmode httpbind 0.0.0.0:8888stats enablestats uri /statusstats auth admin:password

通过浏览器访问http://IP:8888/status查看实时状态

IP透传技术

• 七层透传：option forwardfor添加X-Forwarded-For头
• 四层透传：send-proxy结合后端proxy_protocol协议

访问控制列表（ACL）

acl static_files path_end .jpg .png
acl php_files path_end .php
use_backend static_servers if static_files
use_backend php_servers if php_files

自定义错误页面

errorfile 503 /etc/haproxy/errors/503.http
errorloc 503 https://example.com/error

实验核心原理

1. 前端监听端口接收请求
2. 通过ACL规则或算法匹配后端服务器组
3. 后端服务器处理请求并返回响应
4. 状态监控模块实时收集运行指标

Haproxy负载均衡的基本原理

Haproxy通过分发客户端请求到后端多个服务器，实现流量均衡和高可用。核心机制包括监听前端请求、匹配规则、选择后端服务器及健康检查。

实验工作流程

1. 前端（Frontend）监听
   Haproxy配置前端监听特定端口（如80或443），接收客户端请求。前端定义访问控制、SSL证书等参数。

   frontend web_frontbind *:80default_backend web_backend
   

2. 后端（Backend）服务器池
   后端定义一组服务器及负载均衡算法（如轮询、最少连接）。Haproxy根据算法选择目标服务器。

   backend web_backendbalance roundrobinserver server1 192.168.1.10:80 checkserver server2 192.168.1.11:80 check
   

3. 健康检查
   定期检测后端服务器状态，自动剔除故障节点，确保流量仅分发到健康服务器。

负载均衡算法

• roundrobin：轮询，依次分发请求。
• leastconn：优先选择当前连接数最少的服务器。
• source：根据客户端IP哈希选择服务器，适合会话保持。
• uri：根据请求URI哈希分配，相同URI总发到同一服务器。

会话保持

通过cookie或stick-table实现会话粘滞，确保用户请求始终指向同一后端服务器。

backend web_backendbalance roundrobincookie SERVERID insert nocacheserver server1 192.168.1.10:80 cookie s1 checkserver server2 192.168.1.11:80 cookie s2 check

动态配置与ACL规则

使用ACL（访问控制列表）实现高级路由，例如按路径、域名或Header分流。

frontend web_frontbind *:80acl path_blog path_beg /bloguse_backend blog_backend if path_blogdefault_backend web_backend

1. 实验准备工作

在开始HAProxy实验前，需确保以下准备工作已完成：(了解即可，具体配置在后面)

• 环境准备：下载haproxy服务，关闭防火墙和SElinux
• 配置文件：熟悉HAProxy的配置文件结构，通常位于/etc/haproxy/haproxy.cfg，包含全局设置、前端（frontend）、后端（backend）等模块。
• 测试环境: 确保网络互通。使用虚拟机模拟多节点环境。
• 监控工具：配置日志和监控（如Prometheus + Grafana），便于观察性能指标（连接数、延迟、错误率等）。
• 安全设置：若涉及生产环境，需配置TLS证书、ACL（访问控制列表）等安全策略。

1.1 环境准备

 三个虚拟机:   RS1,RS2,haproxy

   都是NAT模式/或者都是仅主机  ip在同一个网段即可    

haproxy：

dnf install haproxy -y
systemctl disable --now firewalld

RS1,RS2：

dnf install nginx
systemctl disable --now firewalld
echo RS1 - 192.168.1.10 > /usr/share/nginx/html/index.html
#echo RS2 - 192.168.1.20 > /usr/share/nginx/html/index.html
systemctl enable --now nginx

1.2 访问测试

到此环境搭建完成

1.3 线程与CPU核心绑定

原因

HAProxy默认以单线程模式运行，但现代版本支持多线程（通过nbthread参数配置）。线程绑定的核心目的和优势包括：

• 性能优化：将线程绑定到特定CPU核心（通过cpu-map配置），减少上下文切换开销，提升缓存命中率，尤其在高并发场景下显著降低延迟。
• 资源隔离：避免线程在不同核心间迁移导致的性能波动，确保关键流量处理的稳定性。
• NUMA架构适配：在多处理器NUMA系统中，绑定线程到本地内存节点可减少跨节点访问延迟。

通过配置nbproc和cpu-map实现进程与CPU核心的绑定。例如：

globalnbthread 4  # 启用4个工作线程cpu-map 1 0  # 线程1绑定到CPU核心0cpu-map 2 1  # 线程2绑定到CPU核心1cpu-map 3 2  # 线程3绑定到CPU核心2cpu-map 4 3  # 线程4绑定到CPU核心3

绑定后减少线程跨核心切换的开销，提升处理效率，适用于高并发场景。

这是默认情况下的样子

#添加多线程

1.vim /etc/haproxy/haproxy.cfg

2.修改完重启文件件 systemctl restart haproxy

进程会在下面多n个

重启文件

2.通过文件配置具体内容

注意：每次修改完文件后都要重启服务systemctl restart haproxy

2.1前端（Frontend）监听

Haproxy配置前端监听特定端口（如80或443），接收客户端请求。前端定义访问控制、SSL证书等参数

ps：前后端大致配置位置就在这张图里，下面内容是方便理解 ，如何运用的

2.2后端（Backend）服务器池

后端定义一组服务器及负载均衡算法（如轮询、最少连接）。Haproxy根据算法选择目标服务器。

• check：启用健康检查

• inter 2000：健康检查间隔（默认2000ms）
• fall 3：连续失效3次标记为下线
• weight 1：权重值（0表示不参与负载）
• backup：标记为备份服务器

backend web_backendbalance roundrobin#算法server server1 192.168.1.10:80 checkserver server2 192.168.1.20:80 check

示例：

2.3 故障访问IP（备份） 

erver backup 172.25.254.100:8080 check backup

这个是前面两服务器故障时访问的

故障时访问100的http的服务的8080端口（对配置100主机的httpd服务为8080端口）

重启文件

负载均衡算法的具体配置

静态负载均衡算法

采用“慢更新”策略：先给一点点访问压力，当没问题后在给一部分

服务器加入时逐步增加负载，但权重固定不可动态调整。

• 适用场景：服务器性能差异小且负载稳定。
• 缺点：灵活性低，无法适应突发流量或服务器性能变化。

动态负载均衡算法

roundrobin（轮询）

根据权重比例分配请求，结合实时LVS负载计算最优目标服务器，谁的值小就给谁

• 支持动态权重调整（无需重启）。
• 适用场景：服务器性能差异大或负载波动频繁。

文件配置：

先将这部分全部注释掉

然后添加 roundrobin（轮询）配置

重启文件systemctl restart haproxy

测试访问是否是轮询、

leastconn（最小连接数）

优先分配请求给当前连接数最少的服务器，权重高的服务器在连接数相近时优先。

• 支持动态权重调整。
• 适用场景：长连接服务（如数据库）。

文件配置：记得把之前的注释掉，否则会冲突

重启服务

访问测试

结果类似 

第二种修改权重的方法：

其他特殊算法

#在特定情况下，既可以是静态，也可以通过配置变为动态

source（源地址哈希）

根据客户端IP哈希固定分配请求到同一服务器。

• 优点：会话保持。
• 缺点：服务器故障时影响所有关联客户端。

重启，访问

发现链接只打在一台主机上

map-base（取模）

总结：对主机标识取模分配请求，服务器故障需全局重新计算。

主机有数字，该数字除以服务器的个数然后取余，余数跟对应的服务器建立链接，挂了一台服务器算法就得重新计算链接

如果有一台主机（服务器）挂科了，所有主机都要重新建立VIP

• 适用场景：服务器数量固定且故障率低。

这个可以和其他算法共存

一致性哈希

通过哈希环分配请求，服务器故障仅影响相邻节点。

• 虚拟节点解决数据倾斜问题。
• 适用场景：服务器频繁扩缩容。

具体理解：

        客户的环点落到哈希环上，如果客户去访问红色服务器，采取就近原则

如果其中一个服务器挂了，客户机就会访问其他就近的服务器，尽量让权重变化的影响最小 

URI哈希

基于请求URI哈希分配，相同URI指向同一服务器。

• 仅支持HTTP模式（mode http）。
• 适用场景：静态资源缓存优化。

 此时可以通过VIP轮询访问两个服务器对应的index2

index1页面

url_param（URL参数哈希）

根据指定URL参数（如user_id）哈希分配请求。

• 适用场景：需按业务参数保持会话一致性。

重启服务

访问出现的都是同一个

hdr(User-Agent)（用户代理哈希）

根据请求头中的User-Agent分配请求。

• 适用场景：针对不同客户端类型差异化处理。

现在我们访问的都是同一个页面

指定浏览器，就可以保证访问该浏览器时出现固定的页面

Cookie会话保持

通过cookie或stick-table实现会话粘滞，确保用户请求始终指向同一后端服务器。

• 适用场景：登录态等强会话依赖服务。

backend web_backendbalance roundrobincookie SERVERID insert nocacheserver server1 192.168.1.10:80 cookie s1 checkserver server2 192.168.1.11:80 cookie s2 check

动态权重调整

# 动态修改服务器权重（需启用stats socket）
echo "set server backend/server1 weight 50" | sudo socat stdio /var/run/haproxy.sock

动态配置与ACL规则

使用ACL（访问控制列表）实现高级路由，例如按路径、域名或Header分流。

frontend web_frontbind *:80acl path_blog path_beg /bloguse_backend blog_backend if path_blogdefault_backend web_backend

以上算法可根据实际业务需求组合使用，例如：

• 电商场景：source + Cookie保证会话一致性。
• CDN加速：URI哈希提升缓存命中率。