公主少爷都爱看的haproxy七层代理详细介绍及常见实验详解

对比维度	四层负载均衡	七层负载均衡
工作层次	基于 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算法当服务器数量发生变化时并不会所有的缓存都失效，大部分任可以正常访问，依然可以分担整个系统大部分压力，不至于在同一时间都将压力转到后端服务器。

五、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 webcluster
    bind *:80
    mode http
    balance roundrobin
    server web1 172.25.254.10:80 
    server web2 172.25.254.20:80 
##########

frontend main
    bind *: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 webcluster
    bind *:80
    mode http
    balance roundrobin
    server web1 172.25.254.10:80 check inter 2 fall 3 rise 5 weight 2
    server web2 172.25.254.20:80 check inter 2 fall 3 rise 5 weight 1
    server web_sorry 172.25.254.100:8080 backup

##########

frontend main
    bind *: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端口的请求重向定443
 bind *:80
 redirect 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 webserver
   bind *:80
   redirect scheme https if !{ ssl_fc }
   mode http
   use_backend webcluster
frontend webserver-https
   bind *:443 ssl crt /etc/haproxy/timinglee.org.pem
   mode http
   use_backend webcluster
backend webcluster
   mode http
   balance roundrobin
   server web1 172.25.254.10:80 check inter 3s fall 3 rise 5
   server 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通常用于‌路由器和‌三层交换机，通过定义一系列包含“允许”或“拒绝”的规则语句，对进出接口的数据包进行控制，从而提升网络设备的安全性。‌

14.2ACL的工作原理

ACL的工作原理是通过在设备上定义一张包含多种访问规则的列表，然后将此表调用在设备的某个接口上，让设备对收到的流量基于表中规则执行动作——允许或拒绝。ACL规则自上而下按照顺序匹配，一旦匹配到流量，则不再查看下一条规则。‌

14.3ACL的主要用途

CL的主要用途包括保障网络安全、可靠和稳定。通过ACL可以控制用户对网络的访问，防止未经授权的访问，提升网络的安全性。此外，ACL还可以用于数据报文过滤和分类，帮助其他应用（如‌QoS、‌策略路由等）对不同类别的数据报文进行区别处理。‌

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

基本配置和实验详解见以下链接：

http://t.csdnimg.cn/5xMCIhttp://t.csdnimg.cn/5xMCI

qiao不出代码来

关注

13
点赞
踩
11

收藏

觉得还不错? 一键收藏
0
评论
公主少爷都爱看的haproxy七层代理详细介绍及常见实验详解

‌haproxy是一个开源的高性能反向代理和负载均衡器，主要用于‌TCP和‌HTTP流量管理。是法国开发者威利塔罗(Willy Tarreau) 在2000年使用C语言开发的一个开源软件是一款具备高并发(万级以上)、高性能的TCP和HTTP负载均衡器支持基于cookie的持久性，自动故障切换，支持正则表达式及web状态统计。haproxy实验环境与之前相同。^M什么动物生气最安静大猩猩！！‌ACL（‌。
复制链接

扫一扫