最详细！教你学习haproxy七层代理

一、工作原理

（1）包括

1. 监听端口：HAProxy 会在指定的端口上监听客户端的请求。 例如，它可以监听常见的 HTTP 和 HTTPS 端口，等待客户端连接。
2. 请求接收：当客户端发起请求时，HAProxy 接收到请求。 它会解析请求的内容，包括请求的方法（如 GET、POST 等）、目标 URL 等。
3. 负载均衡决策：根据预先配置的负载均衡策略，决定将请求转发到后端的哪个服务器。 常见的负载均衡算法有轮询、加权轮询、最少连接等。 比如，轮询算法会依次将请求均匀地分配到后端的服务器；加权轮询则会根据服务器的权重来分配请求。
4. 健康检查：HAProxy 会持续监测后端服务器的健康状态。 通过发送特定的请求或者检测服务器的响应来判断服务器是否正常工作。 如果发现某台服务器不可用，它会自动将请求转发到其他正常的服务器上。
5. 请求转发：确定目标服务器后，将客户端的请求转发给该服务器。
6. 响应处理：后端服务器处理请求并返回响应给 HAProxy。
7. 响应返回：HAProxy 再将后端服务器的响应返回给客户端。

（2）负载均衡

1、为什么使用负载均衡？

• Web服务器的动态水平扩展-->对用户无感知
• 增加业务并发访问及处理能力-->解决单服务器瓶颈问题
• 节约公网IP地址-->降低IT支出成本
• 隐藏内部服务器IP-->提高内部服务器安全性
• 配置简单-->固定格式的配置文件
• 功能丰富-->支持四层和七层，支持动态下线主机
• 性能较强-->并发数万甚至数十万

2、四层负载均衡

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

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

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

支持四层的软件

1. lvs：重量级四层负载均衡器。
2. Nginx：轻量级四层负载均衡器，可缓存。（nginx四层是通过upstream模块）
3. Haproxy：模拟四层转发。

3、七层负载均衡

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

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

支持7层代理的软件：

1. Nginx:基于http协议(nginx七层是通过proxy_pass)
2. Haproxy:七层代理，会话保持、标记、路径转移等

4、区别

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

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

1. 分层位置:四层负载均衡在传输层及以下，七层负载均衡在应用层及以下。
2. 性能 :四层负载均衡架构无需解析报文消息内容，在网络吞吐量与处理能力上较高:七层可支持解析应用 层报文消息内容，识别URL、Cookie、HTTP header等信息。
3. 原理 :四层负载均衡是基于ip+port;七层是基于虚拟的URL或主机IP等。
4. 功能类比:四层负载均衡类似于路由器;七层类似于代理服务器。 5.安全性:四层负载均衡无法识别DDoS攻击;七层可防御SYN Cookie/Flood攻击。

二、定义

• HAProxy是法国开发者威利塔罗(Willy Tarreau) 在2000年使用C语言开发的一个开源软件，是一款具备高并发(万级以上)、高性能的TCP和HTTP负载均衡器 支持基于cookie的持久性，自动故障切换，支持正则表达式及web状态统计
• HAProxy 七层代理是指在 OSI 模型的第七层（应用层）进行代理操作。 在七层代理中，HAProxy 不仅能够根据 IP 地址和端口进行流量分发，还能够理解应用层协议（如 HTTP、HTTPS 等）的内容。 这意味着它可以基于诸如请求的 URL、HTTP 方法、HTTP 头部信息等更详细的应用层数据来做出决策和进行流量的分配。

三、基本配置

1、global---全局配置段

• 进程及安全配置相关的参数
• 性能调整相关参数
• Debug参数

  global
         log 127.0.0.1 local3        
         log 127.0.0.1   local1 notice        
         #log loghost    local0 info
         ulimit-n 82000              
         maxconn 20480              
         chroot /usr/local/haproxy   
         uid 99                      
         gid 99                     
         daemon                      
         nbproc 1                   
         pidfile /usr/local/haproxy/run/haproxy.pid  
         #debug                      
         #quiet

解释一下：

• log：全局的日志配置，local0是日志输出设置，info表示日志级别。
• maxconn：设定每个haproxy进程可接受的最大并发连接数。
• chroot：修改haproxy的工作目录至指定的目录并在放弃权限之前执行chroot()操作。
• daemon：让 haproxy 以后台模式运行，不占用终端的输入输出。
• nbproc：设置运行的进程数量。
• pidfile：用于记录运行中的 haproxy 进程的 ID，方便其他程序或脚本对其进行管理和监控。
• ulimit-n：设定每进程所能够打开的最大文件描述符数目，默认情况下其会自动进行计算，因此不推荐修改此选项。

2、proxies---代理配置段

参数说明：

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

（1）defaults

 defaults
         log    global         
         mode    http          
         maxconn 50000         
         option  httplog       
         option  httpclose     
         option  dontlognull  
         option  forwardfor    
         retries 3                    
         stats refresh 30       
         option abortonclose    
         balance roundrobin    
         #balance source      
         #contimeout 5000        
         #clitimeout 50000       
         #srvtimeout 50000       
         timeout http-request    10s  
         timeout queue           1m  
         timeout connect         10s  
         timeout client          1m   
         timeout server          1m 
         timeout http-keep-alive 10s  
         timeout check           10s 

解释一下：

• defaults：表示以下的配置是默认的全局配置。
• log global：引入名为“global”定义的日志格式，用于记录相关的日志信息。
• mode http：指定所处理的类别为 7 层代理的 HTTP 模式。
• maxconn 50000：设置最大的连接数量为 50000 个。
• option httplog：表示日志的类别为 HTTP 日志格式，用于记录 HTTP 相关的日志。
• option httpclose：每次 HTTP 请求完毕后，主动关闭 HTTP 通道，释放资源。
• option dontlognull：不记录健康检查的日志信息，避免产生不必要的日志记录。
• option forwardfor：如果后端服务器需要获取客户端的真实 IP 地址，通过这个参数可以从 HTTP 头中获取。
• retries 3：如果连接失败，最多尝试重新连接 3 次，超过 3 次则认为服务器不可用。
• stats refresh 30：设置统计页面的刷新时间间隔为 30 秒。
• option abortonclose：当服务器负载很高时，自动结束当前队列中处理时间较长的连接，以释放资源。 
• balance roundrobin：设置默认的负载均衡方式为轮询方式，即依次将请求分配到不同的服务器。 timeout http-request 10s：默认的 HTTP 请求超时时间为 10 秒，如果在 10 秒内未完成请求，则视为超时。 
• timeout queue 1m：默认的队列超时时间为 1 分钟。
• timeout connect 10s：默认的连接超时时间为 10 秒。
• timeout client 1m：默认的客户端超时时间为 1 分钟。
• timeout server 1m：默认的服务器超时时间为 1 分钟。
• timeout http-keep-alive 10s：默认的 HTTP 持久连接超时时间为 10 秒。
• timeout check 10s：设置超时检查的超时时间为 10 秒。 

（2）frontend

frontend http_80_in
     bind 0.0.0.0:80    
     mode http          
     log global         
     option httplog     
     option httpclose    
     option forwardfor  
     default_backend wwwpool   

解释一下：

• frontend http_80_in：定义一个名为http_80_in的frontend。
• bind 0.0.0.0:80：表示将 HAProxy 服务绑定到所有可用的网络接口（0.0.0.0）的 80 端口上。这样，客户端可以通过任何网络接口连接到这个端口来发送请求。
• mode http：指定了工作模式为 HTTP 的 7 层模式。在这种模式下，HAProxy 可以理解和处理 HTTP 协议的相关信息，例如请求头、响应头。 
• log global：应用全局的日志设置，意味着使用在全局配置中定义的日志规则来记录与这个前端相关的操作和事件。
• option httplog：启用了 HTTP 相关的日志记录，以便更详细地记录 HTTP 请求和响应的信息。 option httpclose：每次处理完请求后主动关闭 HTTP 通道。这是因为 HAProxy 不支持 HTTP 的 keep-alive 模式，为了避免资源占用和潜在的问题，选择在请求完成后关闭连接。
• option forwardfor：如果后端服务器需要获取客户端的真实 IP 地址，配置此参数可以从 HTTP 头中提取客户端的真实 IP 信息。
• default_backend wwwpool：设置了默认情况下，接收到的请求将被转发到名为 `wwwpool` 的后端服务池进行处理。 例如，如果有多个客户端向 80 端口发送 HTTP 请求，HAProxy 会根据上述配置来处理这些请求。如果后端服务器需要知道是哪个客户端发起的请求，通过 `option forwardfor` 就能获取到真实的客户端 IP 地址。而所有没有特别指定后端的请求，都会被默认转发到 `wwwpool` 这个后端服务池去处理。  

（3）backend

backend wwwpool     
  mode http          
  option  redispatch
  option  abortonclose
  balance source      
  cookie  SERVERID   
  option  httpchk GET /test.html  
  server web1 10.1.1.2:80 cookie 2 weight 3 check inter 2000 rise 2 fall 3 maxconn 8

解释一下：

• backend wwwpool：定义了一个“wwwpool”的服务器组。
• mode http：指定使用 HTTP 的 7 层模式进行负载均衡。这意味着不仅会考虑 IP 和端口，还会分析 HTTP 请求的内容（如 URL、请求头）来做出负载均衡决策。
• option redispatch：重分发选项，通常用于在某些情况下重新分配请求到其他服务器。
• option abortonclose：当连接关闭时采取特定的动作，可能与处理异常关闭的连接相关。 *
• balance source：表示使用源哈希算法进行负载均衡。这意味着根据客户端的源 IP 地址来决定将请求分配到哪个后端服务器，相同源 IP 的请求通常会被发送到同一台服务器。
• cookie SERVERID：允许在 cookie 中插入“SERVERID”。这有助于跟踪和识别与特定服务器的会话关联。
• option httpchk GET /test.htm：心跳检测，通过发送 GET 请求到“/test.html”路径来检查后端服务器的健康状况。
• server web1 10.1.1.2:80 cookie 2 weight 3 check inter 2000 rise 2 fall 3 maxconn 8：
• -- “server web1”定义了服务器的名称为“web1”。
• -- “10.1.1.2:80”是服务器的 IP 地址和端口。
• -- “cookie 2”可能表示与该服务器相关的特定 cookie 设置。
• -- “weight 3”为服务器设置权重为 3，权重越大，分配到的请求相对越多。
• -- “check inter 2000”表示检查的间隔为 2000 毫秒。
• -- “rise 2”表示服务器被认为正常的连续成功检查次数为 2 次。
• -- “fall 3”表示服务器被认为故障的连续失败检查次数为 3 次。
• -- “maxconn 8”表示该服务器的最大并发连接数为 8。

（4）listen

 listen  admin_status           
         bind 0.0.0.0:8888               
         mode http                      
         log 127.0.0.1 local3 err      
         stats refresh 5s