一、什么是HAproxy

HAProxy是一个免费、开源的高性能TCP/HTTP负载均衡器和代理服务器软件，主要用于实现以下功能

一、负载均衡

1. 多种负载均衡算法支持：

   • 轮询（Round Robin）：它依次将请求均匀分配到后端的各个服务器。例如有服务器A、B、C，第一个请求会被分配到服务器A，第二个请求分配到服务器B，第三个请求分配到服务器C，然后再按照这个顺序循环。这样可以确保每个服务器都有机会处理请求，平均分担负载。
   • 加权轮询（Weighted Round Robin）：根据服务器的性能差异为每台服务器分配不同的权重。性能好的服务器权重高，会被分配更多请求。比如服务器A性能较强，权重设为3；服务器B性能中等，权重设为2；服务器C性能较弱，权重设为1。那么在一轮分配中，服务器A会分配到3个请求，服务器B会分配到2个请求，服务器C会分配到1个请求，然后再按照这个比例循环分配。这样可以更合理地利用服务器资源，让高性能服务器处理更多任务。
   • 最少连接（Least Connections）：该算法将新的请求分配给当前连接数最少的服务器。HAProxy会实时监测每台后端服务器的连接数，当有新的请求到来时，选择连接数最少的服务器进行分配。例如在某一时刻，服务器A当前连接数为10，服务器B当前连接数为8，服务器C当前连接数为12，当有一个新请求时，HAProxy会将请求分配给服务器B。这种算法适用于服务器处理请求的时间差异较大的情况，能够更有效地平衡服务器负载，避免某些服务器因连接过多而响应缓慢，同时充分利用连接数较少的服务器资源。

2. 七层负载均衡（基于应用层）：

   • HAProxy能够分析应用层协议（如HTTP）的内容，根据不同的请求特征进行更精细的负载均衡。例如，它可以根据请求的URL路径将不同类型的请求分发到不同的后端服务器组。比如，对于网站的静态资源（如图片、CSS文件、JavaScript文件等）请求，可以将其分配到专门优化过处理静态资源的服务器组；而对于动态网页（如.php、.jsp等后缀的网页请求），可以分配到处理动态内容的服务器组。这样可以根据不同的应用需求进行更高效的资源分配，提高整个系统的性能和响应速度。
   • 还可以根据HTTP请求头中的信息进行负载均衡。比如，根据用户的地理位置信息（通常在请求头中包含），将来自不同地区的用户请求分配到距离他们较近的数据中心的服务器上，减少网络延迟，提高用户体验。或者根据用户的浏览器类型、设备类型等信息进行针对性的负载均衡，为不同类型的客户端提供最佳的服务。

二、代理服务

 

1. 正向代理：

   • 在企业网络中，HAProxy可以作为正向代理服务器，为内部客户端访问外部网络提供代理服务。它可以缓存经常访问的外部网页内容，当内部客户端再次请求相同内容时，直接从缓存中返回，提高访问速度，减少网络带宽占用。同时，它可以对内部客户端的访问进行过滤和控制，例如限制访问某些不安全或不适当的网站，提高企业网络的安全性和合规性。
   • 对于一些移动应用开发者，他们可以使用HAProxy作为正向代理来模拟不同的网络环境和测试应用在各种网络条件下的性能。通过配置HAProxy，可以模拟低速网络、高延迟网络等情况，以便在应用发布前发现和解决潜在的网络相关问题。

2. 反向代理：

   • 当用户访问一个网站时，他们实际上是与HAProxy进行通信，HAProxy再将请求转发到后端的真实Web服务器。对于用户来说，他们只看到HAProxy的IP地址，不知道后端具体有哪些服务器在处理请求。这样可以隐藏后端服务器的真实IP地址和架构，提高服务器的安全性，防止直接针对后端服务器的攻击。同时，HAProxy可以对后端服务器进行负载均衡，如前面所述的各种负载均衡算法，确保每个服务器都能合理分担用户请求，提高网站的整体性能和可靠性。
   • HAProxy还可以对后端服务器返回的响应进行优化和处理。例如，对响应数据进行压缩，减少网络传输的数据量，提高响应速度；或者对响应内容进行修改，如添加统一的版权信息、错误处理页面等，提高网站的一致性和用户体验。

三、高可用性和可靠性

1. 健康检查：

   • HAProxy会定期对后端服务器进行健康检查，以确保它们能够正常处理请求。它可以通过多种方式进行检查，如发送简单的TCP连接请求或HTTP请求来验证服务器的可用性。如果发现某台服务器出现故障，如无法建立连接、响应超时或返回错误状态码等，HAProxy会自动将其从负载均衡池中移除，不再向其发送新的请求，直到该服务器恢复正常。这样可以避免将用户请求发送到故障服务器，保证用户能够始终得到正常的服务响应。
   • 例如在一个电商网站的服务器集群中，HAProxy每隔5秒对后端的Web服务器进行一次健康检查。如果某台服务器在连续三次检查中都没有正常响应，HAProxy就会将其标记为故障服务器，并停止向其分配请求。当该服务器恢复正常并通过后续的健康检查时，HAProxy会再次将其加入到负载均衡池中，重新开始接收请求。

2. 故障切换：

   • 在配置了多个HAProxy实例的高可用架构中，如果主HAProxy实例出现故障，备用实例会自动接管服务，实现无缝的故障切换。例如，通过使用Keepalived等工具，可以实现HAProxy的高可用。当主HAProxy所在的服务器出现硬件故障、软件崩溃或网络问题时，Keepalived会检测到故障，并迅速将虚拟IP地址切换到备用HAProxy实例所在的服务器上，用户的请求会自动被导向备用HAProxy，从而保证负载均衡服务的不间断运行。
   • 在后端服务器层面，如果一台服务器出现故障，HAProxy不仅会将其从负载均衡池中移除，还会在该服务器恢复正常后自动尝试重新将其加入到池中，实现故障服务器的自动恢复和重新纳入负载均衡体系，确保整个系统在面对服务器故障时具有良好的弹性和恢复能力

 四、四层负载均衡和七层负载均衡的区别

一、工作层次

1. 四层负载均衡：

   • 工作在OSI模型的第四层，即传输层。它主要通过分析IP地址和端口号来决定如何分发网络流量。
   • 例如，当一个客户端向服务器发起TCP连接请求时，四层负载均衡器会根据预先配置的策略，如轮询、加权轮询等，将请求转发到不同的后端服务器。它只关心数据包中的源IP地址、目标IP地址、源端口号和目标端口号这些信息，而不关心数据包的具体内容。
   • 以一个简单的Web应用场景为例，假设有多个Web服务器提供相同的服务，客户端通过浏览器访问网站，四层负载均衡器接收到请求后，只根据TCP连接的相关信息将请求分发到不同的Web服务器，而不考虑请求是要获取具体哪个网页等更上层的信息。

2. 七层负载均衡：

   • 工作在OSI模型的第七层，即应用层。它能够深入分析应用层协议（如HTTP、HTTPS、FTP等）的内容，理解用户的具体请求。
   • 例如，在HTTP协议中，七层负载均衡器可以根据请求的URL、HTTP方法（GET、POST等）、HTTP头部信息等进行更加精细的负载均衡。如果一个电商网站使用七层负载均衡，它可以根据用户请求的不同URL，将请求商品列表页面的请求分发到一组专门优化处理商品列表的服务器，将请求购物车页面的请求分发到另一组针对购物车操作优化的服务器。
   • 七层负载均衡器还可以根据用户的会话信息进行负载均衡。比如，对于需要保持用户会话一致性的应用，它可以将属于同一个用户的连续请求都转发到同一台后端服务器，以确保用户会话状态的正确维护。

二、负载均衡策略

1. 四层负载均衡策略：

   • 主要基于网络层和传输层的信息制定策略。常见的策略有：
     • 轮询（Round Robin）：依次将客户端的连接请求均匀地分配到后端的不同服务器。例如，有三台服务器A、B、C，第一个连接请求分配给服务器A，第二个分配给服务器B，第三个分配给服务器C，然后第四个又重新分配给服务器A，如此循环。
     • 加权轮询（Weighted Round Robin）：根据服务器的性能差异为每台服务器分配不同的权重。性能好的服务器权重高，会分配到更多的连接请求。例如，服务器A权重为3，服务器B权重为2，服务器C权重为1，那么在一轮分配中，服务器A会分配到3个连接请求，服务器B会分配到2个连接请求，服务器C会分配到1个连接请求，然后再按照这个比例循环分配。
     • 最少连接（Least Connections）：将新的连接请求分配给当前连接数最少的服务器。负载均衡器会实时监测每台服务器的连接数，当有新的连接请求到来时，选择连接数最少的服务器进行分配。例如，服务器A当前连接数为10，服务器B当前连接数为8，服务器C当前连接数为12，当有一个新连接请求时，负载均衡器会将请求分配给服务器B。

2. 七层负载均衡策略：

   • 由于可以分析应用层协议的内容，其策略更加丰富和灵活。除了类似四层的一些基本策略外，还有：
     • 基于URL的负载均衡：根据请求的URL路径将不同类型的请求分发到不同的后端服务器组。比如，对于网站的静态资源（如图片、CSS文件、JavaScript文件等）请求，可以将其分配到专门优化过处理静态资源的服务器组；而对于动态网页（如.php、.jsp等后缀的网页请求），可以分配到处理动态内容的服务器组。
     • 基于HTTP方法的负载均衡：对于不同的HTTP方法（如GET、POST、PUT、DELETE等）进行不同的负载均衡处理。例如，对于频繁的GET请求（如获取网页内容）可以分配到一组性能较好的缓存服务器，而对于相对较少但可能涉及数据更新的POST请求（如提交表单数据）可以分配到专门的数据库更新服务器组。
     • 基于HTTP头部信息的负载均衡：根据HTTP请求头部中的信息进行负载均衡。比如，根据用户的地理位置信息（通常在请求头中包含），将来自不同地区的用户请求分配到距离他们较近的数据中心的服务器上，减少网络延迟，提高用户体验。或者根据用户的浏览器类型、设备类型等信息进行针对性的负载均衡，为不同类型的客户端提供最佳的服务。

三、对应用的影响

1. 四层负载均衡对应用的透明性：

   • 四层负载均衡对应用是相对透明的。它不需要对应用程序本身进行修改，只需要将应用服务器的IP地址和端口配置到负载均衡器上，负载均衡器就可以根据策略将请求分发到不同的服务器。
   • 例如，对于一个已经部署好的Web应用，无论它是使用Java开发的Tomcat服务器，还是使用Python开发的Flask服务器，只要将这些服务器的IP地址和端口告知四层负载均衡器，负载均衡器就可以正常工作，应用程序无需做任何关于负载均衡的代码修改。
   • 这种透明性使得四层负载均衡在一些对应用程序改动有限制或希望快速部署负载均衡的场景下非常方便，不会因为引入负载均衡而对应用程序的开发和维护带来过多的复杂性。

2. 七层负载均衡对应用的定制性：

   • 七层负载均衡可以根据应用层的具体信息进行更精细的控制和优化，因此它可以更好地适应应用的需求，但同时也可能需要对应用程序进行一定的配合和调整。
   • 例如，为了实现基于用户会话的负载均衡（即将同一个用户的请求始终分发到同一台服务器），应用程序可能需要在HTTP请求中添加一些特定的标识信息，以便七层负载均衡器能够识别和跟踪用户会话。或者在某些复杂的负载均衡策略下，应用程序可能需要按照负载均衡器的要求返回特定的状态码或响应头信息，以便负载均衡器进行更准确的决策。
   • 虽然这种对应用程序的调整增加了一些复杂性，但它也为应用提供了更多的优化和定制空间。比如通过七层负载均衡可以更好地实现应用的高可用性、优化资源分配以及针对不同用户群体提供个性化的服务等。

四、性能和资源消耗

1. 四层负载均衡的性能优势和资源消耗情况：

   • 四层负载均衡通常具有较高的性能，因为它的工作在相对较低的层次，只需要分析和处理较少的网络数据包信息，对数据包的处理相对简单和快速。
   • 它的资源消耗相对较低，因为不需要像七层负载均衡那样深入解析应用层协议的内容。这使得四层负载均衡器能够处理大量的并发连接请求，适用于对性能要求较高、网络流量较大的场景。例如，在一些大型的在线游戏服务器集群中，四层负载均衡器可以快速地将玩家的连接请求分发到不同的游戏服务器，保证游戏的低延迟和高并发处理能力。
   • 然而，四层负载均衡的简单性也导致了它在某些功能上的局限性，无法像七层负载均衡那样提供丰富的负载均衡策略和对应用的精细控制。

2. 七层负载均衡的性能和资源消耗特点：

   • 七层负载均衡由于需要深入分析应用层协议的内容，对数据包的处理更加复杂，因此相对四层负载均衡来说性能会稍低一些，并且资源消耗也会相对较高。
   • 当处理大量并发请求时，七层负载均衡器可能需要更多的计算资源和内存来解析和处理应用层协议。例如，在一个繁忙的电商网站中，七层负载均衡器在分析大量的HTTP请求的URL、头部信息等内容时，可能会占用较多的CPU和内存资源。
   • 但是，七层负载均衡的这种性能和资源消耗是为了换取更丰富的功能和对应用的更精细控制。在一些对应用层功能和策略要求较高的场景下，如前面提到的根据用户请求内容进行智能分发、优化用户体验等，七层负载均衡的这些特性是非常有价值的。

五、HAproyx实验环境的部署

企业版网站：HAProxy Technologies | World's Fastest Load Balancer

社区版网站：HAProxy - 可靠、高性能。TCP/HTTP 负载均衡器

github: HAProxy · GitHub

四台虚拟机

测试：172.25.254.128

haproxy：172.25.254.129

webserver1:172.25.254.160

webserver2:172.25.254.161

两台webserver安装nginx

写入发布文件并测试

[root@localhost ~]# echo webserver1 - 172.25.254.160> /usr/share/nginx/html/index.html

[root@localhost ~]# echo webserver2 - 172.25.254.161 >/usr/share/nginx/html/index.html

安装软件

六、HAproxy基本配置信息

HAProxy的配置文件haproxy.cfg由两大部分组成，分别是:
global:全局配置段
进程及安全配置相关的参数
性能调整相关参数
Debug参数

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

前端和后端分开写

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

[root@localhost ~]# systemctl enable haproxy.service --now
检测

后端检测

[root@localhost ~]# systemctl stop nginx.service 

前端和后端合并

检测

七、HAproxy的全局配置及日志分离

一、daemon

1. 参数说明：

   • 这个参数用于设置HAProxy是否以守护进程（Daemon）模式运行。
   • 在守护进程模式下，HAProxy会在后台运行，不会与终端关联。这意味着即使启动HAProxy的终端关闭，HAProxy也会继续运行，不会受到影响。

2. 示例配置：

   • daemon：
   • 当设置为true时，HAProxy将以守护进程模式运行。默认情况下，它是false，即不以守护进程模式运行。

二、maxconn

1. 参数说明：

   • 用于定义HAProxy能够处理的最大并发连接数。
   • 它限制了同时连接到HAProxy的客户端数量，包括所有的前端（frontend）监听端口的连接总和。

2. 示例配置：

   • maxconn 65535：
   • 这里将最大并发连接数设置为65535。这个值需要根据服务器的硬件资源（如内存、CPU等）以及预期的负载情况来合理调整。如果设置得过高，可能会导致服务器资源耗尽；如果设置得过低，可能会限制系统的处理能力，导致客户端连接被拒绝。

三、pidfile

1. 参数说明：

   • 指定HAProxy进程的PID（进程ID）文件的路径。
   • PID文件用于记录HAProxy运行时的进程ID，方便其他程序或脚本对HAProxy进程进行管理和监控。

2. 示例配置：

   • pidfile /var/run/haproxy.pid：
   • 这里指定了PID文件的路径为/var/run/haproxy.pid。当HAProxy启动时，它会将自己的进程ID写入这个文件，当需要停止、重启或查询HAProxy进程状态时，可以通过读取这个文件获取进程ID。

四、user和group

1. 参数说明：

   • user用于指定运行HAProxy进程的用户。
   • group用于指定运行HAProxy进程的用户组。
   • 这两个参数主要用于安全和权限管理。通过将HAProxy运行在一个特定的用户和用户组下，可以限制HAProxy对系统资源的访问权限，提高系统的安全性。

2. 示例配置：

   • user haproxy：
   • group haproxy：
   • 这里将HAProxy进程的运行用户和用户组都设置为haproxy（假设系统中存在这个用户和用户组）。如果不进行这样的设置，HAProxy可能会以默认的较高权限用户运行，可能会带来安全风险。

五、log

1. 参数说明：

   • 用于配置HAProxy的日志相关设置。
   • 它可以指定日志的输出位置、日志级别等。

2. 示例配置：

   • log 127.0.0.1 local0 info：
   • 这里指定将日志发送到IP地址为127.0.0.1（本地）的local0日志设备，日志级别为info。日志级别可以根据需要调整，常见的日志级别还有debug（调试，最详细）、warning（警告）、error（错误）等。不同的日志级别会记录不同详细程度的信息，info级别通常会记录一些重要的运行状态和事件信息。

六、stats socket

1. 参数说明：

   • 用于设置HAProxy的统计信息套接字（socket）路径。
   • 通过这个套接字，可以获取HAProxy的实时运行状态和统计信息，如当前的连接数、吞吐量、后端服务器的健康状态等。

2. 示例配置：

   • stats socket /var/lib/haproxy/stats：
   • 这里指定了统计信息套接字的路径为/var/lib/haproxy/stats。可以通过相应的工具或脚本连接到这个套接字来获取HAProxy的统计信息，以便进行监控和分析。

七、nbproc

1. 参数说明：

   • 用于指定HAProxy启动的进程数量。
   • 在一些高负载的场景下，通过启动多个HAProxy进程可以提高系统的处理能力和性能。每个进程可以独立地处理连接请求。

2. 示例配置：

   • nbproc 2：
   • 这里设置启动2个HAProxy进程。可以根据服务器的硬件资源（如CPU核心数等）和负载情况来调整这个值。但需要注意的是，启动多个进程也会消耗更多的系统资源，所以需要合理平衡。

多进程

多线程（多进程和多线程不能同时出现）

日志定义

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

[root@localhost ~]# vim /etc/rsyslog.conf 

开启UDP协议

[root@localhost ~]# systemctl restart rsyslog.service 

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

八、HAproxy-proxies中的常用配置参数

 

参数	类型	作用
defaults[]	proxies	默认配置项，针对以下的frontend、backend和listen生效，可以多个name也可以没有name
frontend	proxies	前端servername，类似于nginx的一个虚拟主机server和LVS服务集群
listen	proxies	#将frontend和backend合并在一起配置，相对于frontend和backend配置更简洁，生产常用

 proxies配置-defaults

参数	功能
option abortonclose	当服务器负载很高时，目自动结束掉当前队列处理比较久的连接，针对业务情况选择开启
option redispatch	当server ld对应的服务器挂掉后，强制定向到其他健康的服务器，重新派发
option http-keep-alive	开启与客户端的会话保持
option forwardfor	透传客户端真实IP至后端web服务器(在apache配置文件中加入:%{X-Forwarded-For}i 后在webserer中看日志即可看到地址透传信息)
mode http | tcp	设置默认工作类型,使用TCP服务器性能更好，减少压力
timeout http-keep-alive 120s	session 会话保持超时时间，此时间段内会转发到相同的后端服务器
timeout connect 120s	客户端请求从haproxy到后端server最长连接等待时间(TCP连接之前)默认单位ms
timeout server 600s	客户端请求从haproxy到后端服务端的请求处理超时时长(TCP连接之后)，默认单位ms，如果超时，会出现502错误，此值建议设置较大些，访止502错误
timeout client 600s	设置haproxy与客户端的最长非活动时间，默认单位ms，建议和timeout server相同
timeout check 5s	对后端服务器的默认检测超时时间
default-server inter 1000 weight 3	指定后端服务器的默认设置

proxies配置-frontend

frontend配置参数：

proxies配置backend

定义一组后端服务器，backend服务器将被frontend进行调用。

注意: backend 的名称必须唯一,并且必须在listen或frontend中事先定义才可以使用,否则服务无法

启动

mode http|tcp #指定负载协议类型,和对应的frontend必须一致

option #配置选项

server #定义后端real server,必须指定IP和端口

 

注意：option后面加 httpchk，smtpchk,mysql-check,pgsql-check，ssl-hello-chk方法，可用于实现更多应用层检测功能。

 

server配置

#针对一个server配置

check #对指定real进行健康状态检查，如果不加此设置，默认不开启检查,只有check后面没

有其它配置也可以启用检查功能

#默认对相应的后端服务器IP和端口,利用TCP连接进行周期性健康性检查,注意必须指定

端口才能实现健康性检查

addr <IP>      #可指定的健康状态监测IP，可以是专门的数据网段，减少业务网络的流量

port <num>   #指定的健康状态监测端口

inter <num>  #健康状态检查间隔时间，默认2000 ms

fall <num>     #后端服务器从线上转为线下的检查的连续失效次数，默认为3

rise <num>    #后端服务器从下线恢复上线的检查的连续有效次数，默认为2

weight <weight>   #默认为1，最大值为256，0(状态为蓝色)表示不参与负载均衡，但仍接受持久连接

backup     #将后端服务器标记为备份状态,只在所有非备份主机down机时提供服务，类似Sorry

Server

disabled   #将后端服务器标记为不可用状态，即维护状态，除了持久模式

                #将不再接受连接,状态为深黄色,优雅下线,不再接受新用户的请求

redirect prefix http://www.baidu.com/ #将请求临时(302)重定向至其它URL，只适用于http模

式

maxconn <maxconn>     #当前后端server的最大并发连接数

 

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

 

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

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

[root@localhost ~]# systemctl restart nginx.service

下线维护

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

测试

上线

将请求临时(302)重定向至其它URL

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

maxconn <maxconn>     #当前后端server的最大并发连接数

九、HAproxy热处理

十、HAproxy算法

静态算法

 

uri

随便down掉一台服务器

[root@localhost ~]# systemctl stop nginx.service

 十二、HAproxy基于cookie的会话保持

当客户端首次访问后端服务器时，后端服务器会在响应中设置一个特定的 cookie。HAProxy 会识别这个 cookie，并在后续的请求中，根据这个 cookie 的值将客户端的请求始终转发到同一台后端服务器上。这样就保证了属于同一个会话的请求都能被发送到同一台服务器处理，从而保持会话的一致性。

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的请求都发送到同一台后端服务器

十三、HAproxy的ip透传

HAProxy 的 IP 透传（也称为 IP 地址传递或源 IP 保持）是一种重要的功能，它主要用于在负载均衡场景下确保后端服务器能够获取到客户端的真实 IP 地址。以下是关于 HAProxy IP 透传的详细内容：

一、为什么需要 IP 透传

在一些应用场景中，后端服务器需要知道客户端的真实 IP 地址，例如：

1. 访问日志记录：准确记录客户端的 IP 以便进行分析和安全监控等。
2. 基于 IP 的访问控制：某些应用可能根据客户端 IP 来限制或允许访问。
3. 地理位置定位：根据 IP 确定客户端的地理位置，提供个性化的服务。

二、HAProxy 实现 IP 透传的原理

HAProxy 通常通过在 HTTP 头或 TCP 选项中传递客户端的 IP 地址信息到后端服务器来实现 IP 透传。具体有以下几种常见方式：

1. X-Forwarded-For 方式：

   • HAProxy 在将客户端请求转发到后端服务器时，会在 HTTP 请求头中添加 X-Forwarded-For 字段。
   • 这个字段的值包含了客户端的 IP 地址，以及可能存在的经过的代理服务器的 IP 地址列表（按照顺序）。例如，如果客户端的 IP 是 192.168.1.100，经过了一个代理服务器 10.0.0.1，那么 X-Forwarded-For 的值可能是“192.168.1.100, 10.0.0.1”。
   • 后端服务器可以通过读取这个 HTTP 头字段来获取客户端的真实 IP 地址。

2. PROXY Protocol 方式（适用于 TCP 负载均衡）：

   • PROXY Protocol 是一种专门用于在代理服务器和后端服务器之间传递连接信息（包括源 IP 和源端口、目标 IP 和目标端口）的协议。
   • HAProxy 支持发送和接收 PROXY Protocol 信息。当 HAProxy 作为负载均衡器时，它可以在与后端服务器建立连接时，先发送 PROXY Protocol 头，将客户端的连接信息传递给后端服务器。
   • 后端服务器需要支持 PROXY Protocol 才能正确解析和处理这个信息，获取到客户端的真实 IP 地址和端口。

七层IP透传

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

Apache默认没有设定

这里因为之前做过设定，所以直接出效果了

但是要在http的配置文件里加入%{X-Forwarded-For}i

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

四层IP透传

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

十四、HAproxy访问控制列表

 HAProxy 的访问控制列表（ACL，Access Control List）是一种强大的机制，用于根据不同的条件来控制对后端服务器的访问

1. 基于 IP 地址的访问控制：可以限制或允许特定 IP 地址或 IP 地址范围的客户端访问。例如，只允许公司内部 IP 段的用户访问某些关键服务，而阻止外部未授权 IP 的访问。
2. 基于 HTTP 请求特征的访问控制：根据 HTTP 方法（如 GET、POST 等）、请求的 URL 路径、HTTP 头部等条件来控制访问。比如，只允许特定的 HTTP 方法访问某个 API 端点，或者限制对某些敏感路径的访问。
3. 流量管理和路由：结合 HAProxy 的其他功能，如负载均衡策略，可以根据 ACL 的结果将请求路由到不同的后端服务器群组。例如，将来自不同地区的用户请求路由到相应地区的服务器上。

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

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

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

 

十五、HAproxy利用acl做动静分离等访问控制

基于域名访问

基于IP访问

拒绝访问

匹配浏览器类型

基于文件后缀名

十六、自定义错误页面内容

[root@localhost ~]# systemctl stop httpd.service 

[root@localhost ~]# systemctl stop nginx.service 

 

十七、HAproxy https