当前位置：首页 > news >正文

网络专业有哪些沈阳seo排名优化推广

news 2025/7/22 8:13:27

网络专业有哪些,沈阳seo排名优化推广,淘宝运营培训机构,做网站所需要的技术目录一、负载均衡 1.1什么是负载均衡 1.2为什么要实验负载均衡 1.3四层负载均衡 1.4七层负载均衡 1.5四层负载均衡和七层负载均衡的对比二、什么是haproxy 2.1定义 2. 2功能和特点 2.3应用场景 2.4haproxy的分类三、安装及基本配置的信息 3.1软件的安装 3.2ha…

一、负载均衡

1.1什么是负载均衡

1.2为什么要实验负载均衡

1.3四层负载均衡

1.4七层负载均衡

1.5四层负载均衡和七层负载均衡的对比

二、什么是haproxy

2.1定义

2. 2功能和特点

2.3应用场景

2.4haproxy的分类

三、安装及基本配置的信息

3.1软件的安装

3.2haproxy基本配置的信息

四、haproxy算法介绍

4.1.haproxy的算法

4.2 haproxy的静态算法

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

4.2.2 first

4.3 haproxy的动态算法

4.3.1 roundrobin

4.3.2 leastconn

4.4其他算法

4.3.1 一致性哈希算法：

五、haproxy的基本部署实验

5.1实验环境：

5.2实验要求：

5.3实验步骤：

1.环境配置

2.后端服务器下载httpd模块，写页面信息

3.haproxy代理机下载软件包，写配置文件

4.客户机测试

六、haproxy的代理参数实验

5.1实验环境：

5.2实验要求：

5.3实验步骤：

1.代理机下载htppd模块，将监听端口改为8080，写页面内容

2.编写代理机配置文件

3.客户机测试

4.如果想要指定下线的服务器，加以下参数

5.页面重定向，加以下参数

七、haproxy的热处理实验（也就是使用socat 工具）

7.1实验环境：

7.2实验步骤：

1.haproxy主机配置文件配置提权

2.使用命令热处理，并在客户机查看效果

八、haproxy的算法实验

8.1实验环境：

8.2实验步骤：

1.haproxy主机写配置文件

2.浏览器测试，用不同的两台浏览器

九、haproxy四层IP透析实验

9.1实验环境：

9.2实验步骤：

1.查看日志

2.nginx服务器修改配置文件（webserver2）

3.haproxy主机写配置文件

4.查看日志，看看能不能看见访问的真实源地址

十、haproxy七层IP透析实验

10.1实验环境：

10.2实验步骤：

1.nginx服务器修改配置文件（webserver2）

2.apacge服务器修改配置文件

3.haproxy主机写配置文件

4.查看日志

十一、自定义错误页面实验

11.1实验环境：

11.2实验步骤：

1.查看haproxy默认使用的错误错误页

2.自定义错误页面

3.haproxy主机写配置文件

4.服务器关闭服务后访问查看页面

十二、haproxy四层负载示例实验（这里用数据库演示）

12.1实验环境：

12.2实验步骤：

1.下载mariadb数据

2.RS主机编写配置文件

3.RS主机创建用户允许远程连接

4.haproxy主机写配置文件

5.测试负载

十三、HAProxy https 实现实验

12.1实验环境：

12.2实验步骤：

1.haproxy主机配置

2.证书制作

3.haproxy主机写配置文件

4.客户端访问测试

十四、ACL

14.1什么是ACL

14.2ACL的工作原理

14.3ACL的主要用途

14.4ACL的基本配置和实验详解

一、负载均衡

1.1什么是负载均衡

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

1.2为什么要实验负载均衡

1. 提高系统性能和响应速度

可以将工作负载均匀分配到多个服务器上，避免单个服务器过载，从而减少响应时间，提高用户体验。
例如，电商网站在促销活动期间流量激增，负载均衡能确保服务器快速处理订单请求，避免出现卡顿或崩溃。

2. 增强系统可靠性和可用性

当某台服务器出现故障时，负载均衡器可以自动将流量导向其他正常运行的服务器，确保服务不中断。
比如，在线教育平台如果一台服务器宕机，负载均衡能立即将学生的访问请求分配到其他服务器，不影响课程的正常进行。

3. 便于扩展系统规模

可以轻松添加新的服务器到负载均衡池中，以应对不断增长的业务需求，无需对现有架构进行大规模改动。
假设一个社交媒体应用的用户量持续增加，通过负载均衡添加服务器就能轻松应对，而无需重新设计整个系统。

4. 优化资源利用

充分利用服务器资源，避免部分服务器闲置而其他服务器过载的情况，提高服务器的整体利用率。
以游戏服务器为例，负载均衡能根据玩家数量和游戏区域，合理分配服务器资源，确保资源利用最大化。

5. 实现成本效益

通过合理分配负载，可以使用相对较少但性能适中的服务器来满足业务需求，降低硬件采购和维护成本。
对于中小企业的网站，使用负载均衡能以更经济的方式提供稳定的服务。

1.3四层负载均衡

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

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

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

4.支持四层的软件：

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

1.4七层负载均衡

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

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

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

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

1.5四层负载均衡和七层负载均衡的对比

对比维度	四层负载均衡	七层负载均衡
工作层次	基于 IP + 端口	基于应用层协议（如 HTTP）
协议支持	TCP、UDP 等	HTTP、HTTPS、FTP 等
处理内容	仅处理数据包的源地址、目标地址和端口信息	能够解析应用层协议的具体内容
配置复杂度	相对简单	较为复杂
性能	较高	相对较低
灵活性	较低	较高
对服务器的要求	无特殊要求	服务器需要支持相应的应用层协议
应用场景	对性能要求高、协议简单的场景，如游戏服务器	对内容处理要求高、复杂的应用场景，如 Web 应用

二、什么是haproxy

2.1定义

‌haproxy是一个开源的高性能反向代理和负载均衡器，主要用于‌TCP和‌HTTP流量管理。是法国开发者威利塔罗(Willy Tarreau) 在2000年使用C语言开发的一个开源软件是一款具备高并发(万级以上)、高性能的TCP和HTTP负载均衡器支持基于cookie的持久性，自动故障切换，支持正则表达式及web状态统计。

2. 2功能和特点

haproxy能够处理大量的并发连接，支持TCP和HTTP协议，具有高可用性和负载均衡功能。它特别适用于需要处理大量流量的网站，能够保护web服务器不被直接暴露在网络中，同时提供基于cookie的会话保持、健康检查、动态和静态负载均衡策略等功能。‌

2.3应用场景

haproxy被广泛应用于各种需要高性能网络流量管理的场景，包括网站、应用服务等。由于其高性能和可靠性，haproxy已经成为许多高流量网站的负载均衡解决方案。‌

2.4haproxy的分类

haproxy分为社区版和企业版
社区版网站：http://www.haproxy.org
企业版网站：https://www.haproxy.com

企业版本和社区版功能对比:

版本	企业版	社区版
安全性	提供更高级别的安全防护，如数据加密、访问控制等。	安全级别相对较低，可能缺少一些企业级的安全特性。
技术支持	拥有专业的技术支持团队，提供及时响应和解决方案。	主要依靠社区用户的互助和有限的官方文档支持。
定制化	可根据企业需求进行深度定制和集成。	定制化程度相对有限。
性能优化	针对大规模使用进行了优化，能支持更多用户和更高并发。	性能可能在高负载下表现不如企业版。
功能完整性	包含更多高级功能，如企业级报表、高级分析工具等。	功能相对基础，满足一般用户的基本需求。

三、安装及基本配置的信息

3.1软件的安装

软件包下载地址：https://github.com/haproxy/wiki/wiki/Packages
安装软件包： yum install haproxy -y

3.2haproxy基本配置的信息

官方文档：http://cbonte.github.io/haproxy-dconv/

HAProxy 的配置文件haproxy.cfg由两大部分组成，分别是：

global：全局配置段

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

proxies：代理配置段

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

global部分参数介绍：

参数	描述	用法示例
`daemon`	以守护进程的方式运行 HAProxy 。	`daemon true` 表示以守护进程运行。
`maxconn`	设置 HAProxy 可以接受的最大并发连接数。	`maxconn 5000` 表示最大并发连接数为 5000 。
`pidfile`	指定 HAProxy 进程的 PID 文件路径。	`pidfile /var/run/haproxy.pid` 指明 PID 文件的存放位置。
`user`	运行 HAProxy 进程的用户。	`user haproxy` 指定用户为 `haproxy` 。
`group`	运行 HAProxy 进程的用户组。	`group haproxy` 指定用户组为 `haproxy` 。
`log`	定义日志相关的设置，包括设备、级别等。	`log 127.0.0.1 local0 info` 表示将日志发送到 `127.0.0.1` ，使用 `local0` 设备，级别为 `info` 。

proxies部分参数介绍：

参数	描述	用法示例
`name`	代理的名称，用于在配置中标识该代理。	`frontend http_front`
`mode`	代理的模式，如 `http`、`tcp` 等。	`mode http`
`balance`	负载均衡算法，如 `roundrobin`（轮询）、`leastconn`（最少连接）等。	`balance roundrobin`
`default_backend`	定义默认的后端服务器组。	`default_backend http_back`

四、haproxy算法介绍

4.1.`haproxy`的算法

HAProxy通过固定的参数balance指明对后端服务器的调度算法；
balance参数可以配置在listen或backend选项中;
HAProxy的调度算法分为静态和动态；
有些算法可以根据参数在静态和动态算法中相互转换。

4.2 `haproxy`的静态算法

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

4.2.1 `static-rr`：基于权重的轮询调度

HAProxy的static-rr（round-robin）调度算法是一种简单的轮询算法，它按照后端服务器在配置中的顺序依次分配连接请求。这种算法不关心后端服务器的当前负载或健康状态，适用于简单的负载均衡场景。

不支持运行时利用socat进行权重的动态调整

不支持服务器的慢启动

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

服务器的慢启动：

是指在服务器刚刚启动的时候，不会把它应该承担的所有访问压力给它，而是先给一部分，当没有问题后再给其他的。

4.2.2 `first`

first：根据服务器在列表中的位置，自上而下进行调度，但是其只会当第一台服务器的连接数达到上限，新请求才会分配给下一台服务，因此会忽略服务器的权重设置。

不支持运行时利用socat进行权重的动态调整

4.3 `haproxy`的动态算法

动态算法：

基于后端服务器状态进行调度适当调整

新请求将优先调度当前负载较低的服务器

支持运行时利用socat进行权重的动态调整，无需重启

4.3.1 `roundrobin`

roundrobin：基于权重的轮询动态调度算法，支持权重的运行时调整，不完全等于lvs中的rr轮询模式，HAProxy中的roundrobin支持慢启动(新加的服务器会逐渐增加转发数)，其每个后端backend中最多支持4095个realserver，roundrobin为默认调度算法，且支持对real server权重动态调整。

4.3.2 `leastconn`

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

4.4其他算法

4.3.1 一致性哈希算法：

传统的哈希算法：

分布式缓存，比如有三台服务器s0 s1 s2 当我们缓存或访问时应该均匀的在每台服务器上，而不是只缓存或访问一台服务器。实现的方式就是哈希算法，原理如下：
比如有一张图片要缓存到服务器上，那么将它缓存的键进行哈希取值，然后对值进行取模，除数是服务器的数量（如果有权重要进行加权求和），然后会得到一个余数。比如图片上三台服务器，那么取模得到的余数就是0 1 2，正好和服务器的编号相对应，这样我们就可以将对应的号缓存到对应的服务器上去。例如：图片哈希取值为6，对3取模后为0，就缓存到s0服务器上。因为同一个图片哈希取值是不变的，因此当需要再次访问图片时，只需经过哈希值计算和取模计算，就可以找到上次实在那台服务器上缓存的，只需要到这台服务器上去访问就可以了。

弊端：
当服务器的数量或者权重发生变化时，那么对原来的缓存值进行取模运算时，除数就会不同，那么余数也会不同。比如上面6对3取模是0，但是如果加一台服务器，那么6对4取模就是2，这样就会到2号服务器去找图片，这样显然是不对的，是读取不到图片的。这样就导致了缓存失效，这时访问数据就会去找后端服务器，如果太多缓存失效，那么就会造成缓存雪崩，这样大量的访问压力就会到后端服务器，缓存集群就会失效，很可能导致后端服务器崩溃。
为了解决这个问题，避免大量的缓存失效，就有了一致性hash算法。

一致性哈希算法：

一致性哈希算法的原理如下：
有一个哈希环（2^32），如图有A B C 三个服务器，将其编号的哈希值对2^32取模，得到的结果必然是在0~2^32之间，那么它一定可以在这个哈希环上对应一个点，于是就将缓存服务器都映射到这些点上。同理对需要缓存或访问的数据进行同样的操作，也可以在哈希环上得到一个点，那么沿顺时针方向，其遇到的第一个缓存服务器就将数据缓存到上面。如图示a.jpg缓存在B上，b.jpg缓存在C上。访问也是一样，计算取模的余数，然后去对应点的服务器拿数据。
当服务器数量或权重发生变化时，比如在c.jpg和A服务器之间加上一个D服务器，那么c.jpg的缓存服务器就从A服务器变成了D服务器。但是其他大部分还是正常缓存和访问的，并不是全部失效。

总结：
一致性hash算法当服务器数量发生变化时并不会所有的缓存都失效，大部分任可以正常访问，依然可以分担整个系统大部分压力，不至于在同一时间都将压力转到后端服务器。

更多算法详解见以下链接：

https://blog.51cto.com/u_13236892/6726645https://blog.51cto.com/u_13236892/6726645

五、haproxy的基本部署实验

5.1实验环境：

四台机子：红帽9
webserver1：172.25.254.10/24; webserver2: 172.25.254.20/24; haproxy代理机：172.25.254.100/200；客户机IP地址172.25.254.50/24。
防火墙关闭，selinux关闭

5.2实验要求：

客户机通过curl访问haproxy代理机能够访问到后端真实服务器的页面。

5.3实验步骤：

1.环境配置

和前面LVS博客中配置环境的方法一致：

http://t.csdnimg.cn/7GBYlhttp://t.csdnimg.cn/7GBYl

2.后端服务器下载`httpd`模块，写页面信息

[root@webserver1 ~]# cat /var/www/html/index.html 
webserver1 172.25.254.10#webserver2配置相同#重启服务
systemctl restart httpd

3.`haproxy`代理机下载软件包，写配置文件

[root@haproxy ~]# rpm -qa | grep hapro
haproxy-2.4.17-6.el9.x86_64[root@haproxy ~]# cat /etc/haproxy/haproxy.cfg
......省略
#---------------------------------------------------------------------
# main frontend which proxys to the backends
#---------------------------------------------------------------------#配置从这里开始##########
listen webclusterbind *:80mode httpbalance roundrobinserver web1 172.25.254.10:80 server web2 172.25.254.20:80 
##########frontend mainbind *:5000
......省略#重启服务
[root@haproxy ~]# systemctl restart haproxy.service

4.客户机测试

[root@client ~]# curl 172.25.254.100
webserver1 172.25.254.10
[root@client ~]# curl 172.25.254.100
webserver2 172.25.254.20
[root@client ~]# curl 172.25.254.100
webserver1 172.25.254.10
[root@client ~]# curl 172.25.254.100
webserver2 172.25.254.20

六、`haproxy`的代理参数实验

5.1实验环境：

在上一个基础上继续。

5.2实验要求：

webserver1权重为2
当后端服务器崩溃之后，访问的页面是代理机的8080端口

5.3实验步骤：

1.代理机下载`htppd`模块，将监听端口改为8080，写页面内容

#httpd配置文件改监听端口
[root@haproxy ~]# vim /etc/httpd/conf/httpd.conf 
......[root@haproxy ~]# systemctl enable --now httpd
Created symlink /etc/systemd/system/multi-user.target.wants/httpd.service → /usr/lib/systemd/system/httpd.service.

2.编写代理机配置文件

[root@haproxy ~]# cat /etc/haproxy/haproxy.cfg
......省略
#---------------------------------------------------------------------
# main frontend which proxys to the backends
#---------------------------------------------------------------------#配置从这里开始##########
listen webclusterbind *:80mode httpbalance roundrobinserver web1 172.25.254.10:80 check inter 2 fall 3 rise 5 weight 2server web2 172.25.254.20:80 check inter 2 fall 3 rise 5 weight 1server web_sorry 172.25.254.100:8080 backup##########frontend mainbind *:5000
......省略#重启服务
[root@haproxy ~]# systemctl restart haproxy.service

3.客户机测试

#后端服务器好的时候
[root@client ~]# curl 172.25.254.100
webserver1 172.25.254.10
[root@client ~]# curl 172.25.254.100
webserver1 172.25.254.10
[root@client ~]# curl 172.25.254.100
webserver2 172.25.254.20
[root@client ~]# curl 172.25.254.100
webserver1 172.25.254.10
[root@client ~]# curl 172.25.254.100
webserver1 172.25.254.10
[root@client ~]# curl 172.25.254.100
webserver2 172.25.254.20#后端服务器崩了的时候
[root@client ~]# curl 172.25.254.100
sorry is time to go home!
[root@client ~]# curl 172.25.254.100
sorry is time to go home!
[root@client ~]# curl 172.25.254.100
sorry is time to go home!

4.如果想要指定下线的服务器，加以下参数

这种通常用在做服务器升级的时候，先不让用户访问在做升级的服务器。

5.页面重定向，加以下参数

七、`haproxy`的热处理实验（也就是使用socat 工具）

7.1实验环境：

在上一个实验环境基础下。

7.2实验步骤：

1.`haproxy`主机配置文件配置提权

2.使用命令热处理，并在客户机查看效果

查看权重：

#查看权重
[root@haproxy ~]# echo get weight webcluster/web1 | socat stdio /var/lib/haproxy/stats 
2 (initial 2)[root@haproxy ~]# echo get weight webcluster/web2 | socat stdio /var/lib/haproxy/stats 
1 (initial 1)

热处理设置webserver1权重改为1：

#热处理设置webserver1权重改为1
[root@haproxy ~]# echo set weight webcluster/web1 1 | socat stdio /var/lib/haproxy/stats

#客户机测试查看
[root@client ~]# for i in {1..10}; do curl 172.25.254.100; done
webserver2 172.25.254.20
webserver1 172.25.254.10
webserver2 172.25.254.20
webserver1 172.25.254.10
webserver2 172.25.254.20
webserver1 172.25.254.10
webserver2 172.25.254.20
webserver1 172.25.254.10
webserver2 172.25.254.20
webserver1 172.25.254.10

热处理查看信息：

#热处理查看信息
[root@haproxy ~]# echo 'show  servers state' | socat stdio /var/lib/haproxy/stats 
1
# be_id be_name srv_id srv_name srv_addr srv_op_state srv_admin_state srv_uweight srv_iweight srv_time_since_last_change srv_check_status srv_check_result srv_check_health srv_check_state srv_agent_state bk_f_forced_id srv_f_forced_id srv_fqdn srv_port srvrecord srv_use_ssl srv_check_port srv_check_addr srv_agent_addr srv_agent_port
2 webcluster 1 web1 172.25.254.10 2 0 1 2 157 6 3 7 6 0 0 0 - 80 - 0 0 - - 0
2 webcluster 2 web2 172.25.254.20 2 0 1 1 158 6 3 7 6 0 0 0 - 80 - 0 0 - - 0
2 webcluster 3 web_sorry 172.25.254.100 2 0 1 1 7703 1 0 2 0 0 0 0 - 8080 - 0 0 - - 0
4 static 1 static 127.0.0.1 0 0 1 1 7702 8 2 0 6 0 0 0 - 4331 - 0 0 - - 0
5 app 1 app1 127.0.0.1 0 0 1 1 7702 8 2 0 6 0 0 0 - 5001 - 0 0 - - 0
5 app 2 app2 127.0.0.1 0 0 1 1 7702 8 2 0 6 0 0 0 - 5002 - 0 0 - - 0
5 app 3 app3 127.0.0.1 0 0 1 1 7702 8 2 0 6 0 0 0 - 5003 - 0 0 - - 0
5 app 4 app4 127.0.0.1 0 0 1 1 7701 8 2 0 6 0 0 0 - 5004 - 0 0 - - 0

热处理下线某台服务器：

#热处理下线某台服务器
[root@haproxy ~]# echo "disable server webcluster/web1" | socat stdio /var/lib/haproxy/stats

#客户机测试查看
[root@client ~]# for i in {1..10}; do curl 172.25.254.100; done
webserver2 172.25.254.20
webserver2 172.25.254.20
webserver2 172.25.254.20
webserver2 172.25.254.20
webserver2 172.25.254.20
webserver2 172.25.254.20
webserver2 172.25.254.20
webserver2 172.25.254.20
webserver2 172.25.254.20
webserver2 172.25.254.20

热处理开启某台服务器：

#热处理开启某台服务器
[root@haproxy ~]# echo "enable server webcluster/web1" | socat stdio /var/lib/haproxy/stats

#客户端测试查看
[root@client ~]# for i in {1..10}; do curl 172.25.254.100; done
webserver2 172.25.254.20
webserver1 172.25.254.10
webserver2 172.25.254.20
webserver1 172.25.254.10
webserver2 172.25.254.20
webserver1 172.25.254.10
webserver2 172.25.254.20
webserver1 172.25.254.10
webserver2 172.25.254.20
webserver1 172.25.254.10

八、`haproxy`的算法实验

8.1实验环境：

实验环境与之前相同。

8.2实验步骤：

1.`haproxy`主机写配置文件

这里用roundrobin算法举例，配合cookie做缓存标记。

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

2.浏览器测试，用不同的两台浏览器

这里页面内容写错了，应该是webserver2，这只是方便我们观察实验结果，但是IP地址是对的，所有问题不大

另一个浏览器：

其他算法详情可以查看以下链接：

https://blog.51cto.com/u_13236892/6726645https://blog.51cto.com/u_13236892/6726645

九、`haproxy`四层`IP`透析实验

9.1实验环境：

实验环境与之前相同，唯一的区别是将webserver2的apache服务改成了nginx。

9.2实验步骤：

1.查看日志

在访问haproxy后查看nginx日志，在此日志中是无法看到真实访问源地址的

[root@webserver2 ~]# tail -n 3 /var/log/nginx/access.log 
172.25.254.100 - - [10/Aug/2024:10:35:22 +0800] "GET / HTTP/1.1"200 25 "-" "curl/7.76.1" "-"
172.25.254.100 - - [10/Aug/2024:10:35:42 +0800] "GET / HTTP/1.1"200 25 "-" "curl/7.76.1" "-"
172.25.254.100 - - [10/Aug/2024:10:35:44 +0800] "GET / HTTP/1.1"200 25 "-" "curl/7.76.1" "-"

2.`nginx`服务器修改配置文件（`webserver2`）

加入$proxy_protocol_addr参数。

启用 proxy_protocol项

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

3.`haproxy`主机写配置文件

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

配置如下：

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

4.查看日志，看看能不能看见访问的真实源地址

[root@webserver2 ~]# tail -n 3 /var/log/nginx/access.log 
172.25.254.100 - - [10/Aug/2024:10:38:22 +0800] "GET / HTTP/1.1"  "172.25.254.50"200 25 "-" "curl/7.76.1" "-"
172.25.254.100 - - [10/Aug/2024:10:38:42 +0800] "GET / HTTP/1.1"  "172.25.254.50"200 25 "-" "curl/7.76.1" "-"
172.25.254.100 - - [10/Aug/2024:10:38:44 +0800] "GET / HTTP/1.1"  "172.25.254.50"200 25 "-" "curl/7.76.1" "-"

十、`haproxy`七层`IP`透析实验

10.1实验环境：

实验环境与之前相同。

10.2实验步骤：

1.`nginx`服务器修改配置文件（`webserver2`）

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

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

2.`apacge`服务器修改配置文件

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

[root@webserver1 ~]# systemctl restart httpd

3.`haproxy`主机写配置文件

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

4.查看日志

webserver1

[root@webserver1 ~]# tail -n 3 /etc/httpd/logs/access_log 
172.25.254.100 - - [10/Aug/2024:11:01:00 +0800] "GET / HTTP/1.1" 200 25 "-" "curl/7.76.1"
172.25.254.100 - - [10/Aug/2024:11:01:01 +0800] "GET / HTTP/1.1" 200 25 "-" "curl/7.76.1"
172.25.254.100 - - [10/Aug/2024:11:01:02 +0800] "GET / HTTP/1.1" 200 25 "-" "curl/7.76.1"

webserver2

[root@webserver2 ~]# tail -n 3 /var/log/nginx/access.log 
172.25.254.100 - - [10/Aug/2024:11:01:00 +0800] "GET / HTTP/1.1"  "172.25.254.50"200 25 "-" "curl/7.76.1" "-"
172.25.254.100 - - [10/Aug/2024:11:01:02 +0800] "GET / HTTP/1.1"  "172.25.254.50"200 25 "-" "curl/7.76.1" "-"
172.25.254.100 - - [10/Aug/2024:11:01:03 +0800] "GET / HTTP/1.1"  "172.25.254.50"200 25 "-" "curl/7.76.1" "-"

十一、自定义错误页面实验

11.1实验环境：

实验环境与之前相同。

11.2实验步骤：

1.查看`haproxy`默认使用的错误错误页

[root@haproxy ~]# rpm -ql haproxy | grep -E http$
/usr/share/haproxy/400.http
/usr/share/haproxy/403.http
/usr/share/haproxy/408.http
/usr/share/haproxy/500.http
/usr/share/haproxy/502.http
/usr/share/haproxy/503.http
/usr/share/haproxy/504.http

2.自定义错误页面

[root@haproxy ~]# mkdir /haproxy/errorpages/ -p
[root@haproxy ~]# cp /usr/share/haproxy/503.http /haproxy/errorpages/503page.http
[root@haproxy ~]# vim /haproxy/errorpages/503page.http
HTTP/1.0 503 Service Unavailable^M
Cache-Control: no-cache^M
Connection: close^M
Content-Type: text/html;charset=UTF-8^M
^M
<html><body><h1>什么动物生气最安静</h1>大猩猩！！</body></html>

3.`haproxy`主机写配置文件

4.服务器关闭服务后访问查看页面

十二、`haproxy`四层负载示例实验（这里用数据库演示）

12.1实验环境：

实验环境与之前相同。

12.2实验步骤：

1.下载`mariadb`数据

#这里下载是为了使用mysql工具
[root@haproxy ~]# yum install mariadb-server -y#webserver1 和 webserver2也要下载

2.`RS`主机编写配置文件

[root@webserver1 ~]# vim /etc/my.cnf.d/mariadb-server.cnf#webserver1编号是1；webserver2上操作一样，编号是2，这样做的原因是为了方便观察实验结果

webserver1：

webserver2：

3.`RS`主机创建用户允许远程连接

webserver1：

webserver2：

4.`haproxy`主机写配置文件

5.测试负载

haproxy主机上：

webserver2：

webserver1：

十三、HAProxy https 实现实验

12.1实验环境：

实验环境与之前相同。

12.2实验步骤：

1.haproxy主机配置

#配置HAProxy支持https协议，支持ssl会话；bind *:443 ssl crt /PATH/TO/SOME_PEM_FILE 
#指令 crt 后证书文件为PEM格式，需要同时包含证书和所有私钥cat demo.key demo.crt > demo.pem 
#把80端口的请求重向定443bind *:80redirect scheme https if !{ ssl_fc }

2.证书制作

[root@haproxy ~]# mkdir /etc/haproxy/certs/
[root@haproxy ~]# openssl req -newkey rsa:2048 \ 
-nodes -sha256 –keyout /etc/haproxy/certs/timinglee.org.key \ 
-x509 -days 365 -out /etc/haproxy/certs/timinglee.org.crt

3.haproxy主机写配置文件

[root@haproxy ~]# vim /etc/haproxy/haproxy.cfg
frontend webserverbind *:80redirect scheme https if !{ ssl_fc }mode httpuse_backend webcluster
frontend webserver-httpsbind *:443 ssl crt /etc/haproxy/timinglee.org.pemmode httpuse_backend webcluster
backend webclustermode httpbalance roundrobinserver web1 172.25.254.10:80 check inter 3s fall 3 rise 5server web2 172.25.254.20:80 check inter 3s fall 3 rise 5

4.客户端访问测试

[root@client ~]# curl -IkL http://172.25.254.100
HTTP/1.1 302 Found
content-length: 0 
location: https://www.timinglee.org/
cache-control: no-cache
HTTP/1.1 200 OK
date: Sat, 04 Apr 2020 02:31:31 GMT
server: Apache/2.4.6 (CentOS) PHP/5.4.16
last-modified: Thu, 02 Apr 2020 01:44:13 GMT
etag: "a-5a244f01f8adc"
accept-ranges: bytes
content-length: 10
content-type: text/html; charset=UTF-8
[root@client ~]# curl -Ik https://www.timinglee.org
HTTP/1.1 200 OK
date: Sat, 04 Apr 2020 02:31:50 GMT
server: Apache/2.4.6 (CentOS) PHP/5.4.16
last-modified: Thu, 02 Apr 2020 01:44:28 GMT
etag: "a-5a244f0fd5175"
accept-ranges: bytes
content-length: 10
content-type: text/html; charset=UTF-8

十四、ACL

14.1什么是ACL

‌ACL（‌Access Control List，访问控制列表）是一种基于包过滤的访问控制技术，它可以根据设定的条件对接口上的数据包进行过滤，允许其通过或丢弃。 ACL通常用于‌路由器和‌三层交换机，通过定义一系列包含“允许”或“拒绝”的规则语句，对进出接口的数据包进行控制，从而提升网络设备的安全性。‌