一、反向代理基础
实验目的：通过 Nginx 反向代理，将客户端请求按类型（静态页面 / 动态 PHP 页面）转发到不同的后端服务器（RS1 处理静态资源，RS2 处理动态请求），实现 “客户端只与代理服务器交互，无需知道后端实际服务器” 的架构，提升服务安全性、可扩展性和资源处理效率。
反向代理的核心价值
反向代理是指 代理服务器接收客户端所有请求，再根据规则转发到后端不同服务器，客户端仅感知代理服务器的存在，对后端服务器的 IP、架构等信息完全透明。其核心作用：
隐藏后端架构：保护后端服务器不直接暴露在公网，降低被攻击风险；
请求分流：将静态资源（HTML、图片等）和动态请求（PHP、JSP 等）分配到不同服务器处理，发挥各自优势（如静态服务器可优化缓存，动态服务器专注计算）；
扩展性强：后续可轻松添加更多后端服务器（如增加 RS3 处理图片），只需修改代理配置，无需改动客户端。
实验架构与准备
代理服务器：Nginx 所在主机（192.168.67.100），接收客户端请求并转发；
RS1（后端静态服务器）：192.168.67.10，处理静态页面（HTML 等）；
RS2（后端动态服务器）：192.168.67.20，处理动态请求（PHP 等）；
本地解析：客户端（如 Windows）需在
hosts文件中添加www.haha.org到代理服务器 IP（192.168.67.100）的映射，确保通过域名访问时指向代理服务器。
RS1 配置静态页面
echo rs1 - 192.168.67.10 > /usr/share/nginx/html/index.html
systemctl restart nginxRS2 配置 php 动态页面
yum install php -y
mkdir /usr/share/nginx/html/php/
vim /usr/share/nginx/html/php/index.php
###########
<?php
phpinfo();
?>
###########
systemctl restart nginxnginx 代理服务器配置代理
vim /usr/local/nginx/conf.d/haha.conf
##########
server {
listen 80;
server_name www.haha.org;
location / { # 规则 1：普通路径请求（如 /）转发到 RS1（静态服务器）
proxy_pass http://192.168.67.10; # 转发请求到 RS1 的 IP
}
location ~ \.(php|jsp|js)$ { # 规则 2：.php/.jsp/.js 后缀的动态请求转发到 RS2（动态服务器）
proxy_pass http://192.168.67.20; # 转发请求到 RS2 的 IP
}
}
##########
systemctl restart nginx测试：
测试静态请求转发：
客户端访问 www.haha.org，代理服务器匹配 location /，转发到 RS1，页面显示 “rs1 - 192.168.67.10”，验证静态请求正确转发。
测试动态请求转发：
客户端访问 www.haha.org/php/index.php，代理服务器匹配 ~ .(php)$，转发到 RS2，页面显示 PHP 环境信息（phpinfo() 输出），验证动态请求正确转发。
为什么这样配置？核心逻辑
资源分流，提升效率：静态资源（HTML）无需计算，由 RS1 专注处理；动态资源（PHP）需要解析执行，由 RS2 处理，避免单服务器同时处理两类请求导致的性能瓶颈。
隐藏后端，增强安全：客户端仅知道代理服务器（192.168.67.100），无法直接访问 RS1/RS2，减少后端服务器被直接攻击的风险。
灵活扩展，便于维护：若后续静态资源增多，可添加 RS3 作为新静态服务器，只需修改 location / 的 proxy_pass 为负载均衡组（如 http://static_servers）；动态服务同理，扩展性极强。
适用场景
反向代理广泛用于：
大型网站的请求分流（静态资源 CDN 转发、动态请求到应用服务器）；
负载均衡（多台后端服务器分担请求压力）；
安全隔离（代理服务器作为入口，过滤恶意请求后再转发到后端）。
二、反向代理 - 负载均衡
实验目的：通过 Nginx 负载均衡功能，将客户端请求按规则分配到多个后端服务器（RS），实现 “请求分流” 以分担单服务器压力；同时配置健康检查和备用服务器（sorry server），确保后端服务器故障时自动切换，提升服务可用性（避免单点故障导致服务中断）。
负载均衡的核心价值
在高并发场景下，单台后端服务器（RS）可能因请求量过大导致响应缓慢或宕机。负载均衡通过 “多服务器协同工作” 解决这一问题：
请求分流：将客户端请求均匀分配到多台后端服务器，避免单服务器过载；
高可用：通过健康检查自动剔除故障服务器，请求仅转发到正常服务器；
容灾备份：当所有主服务器故障时，自动切换到备用服务器（sorry server），避免返回错误页面，提升用户体验。
实验架构与准备
代理服务器：Nginx 所在主机（假设 IP 为代理服务器 IP），负责负载均衡调度；
后端主服务器（RS）：
RS1：192.168.67.10，提供静态页面服务；
RS2：192.168.67.20，提供静态页面服务；
备用服务器（sorry server）：代理服务器本地的 Apache 服务（端口 8888），当所有主服务器故障时提供兜底响应。
RS 主机配置默认访问页面。
echo rs1 - 192.168.67.10 > /usr/share/nginx/html/index.html
systemctl restart nginx修改 nginx 子配置文件
vim /usr/local/nginx/conf.d/haha.conf
##########
upstream webserver {
server 192.168.67.10:80 weight=1 fail_timeout=15s max_fails=3; # RS1：权重 1，失败 3 次后标记为不可用，15 秒后重试检测
server 192.168.67.20:80 weight=1 fail_timeout=15s max_fails=3;
server 192.168.67.100:8888 backup; # 备用服务器：仅当所有主服务器故障时启用，端口 8888
}
server {
listen 80;
server_name www.haha.org;
location / {
proxy_pass http://webserver; # 所有请求转发到定义的 webserver 服务器组
}
}
##########
systemctl restart nginx配置 nginx 代理服务器的 sorry server 功能。运用 apache 服务器，修改端口作为 sorry server。
yum install httpd
vim /etc/httpd/conf/httpd.conf
########
Listen 8888 # 修改端口
########
echo sorry > /var/www/html/index.html
systemctl start httpd
systemctl enable --now httpd
netstat -antlupe | grep http
测试负载均衡效果
正常轮询：客户端多次访问 www.haha.org，页面会交替显示 “rs1 - 192.168.67.10” 和 “rs2 - 192.168.67.20”，验证请求被均匀分配到两台主服务器。
故障自动剔除：手动停止 RS1 的 Nginx 服务（systemctl stop nginx），再次访问时，请求仅转发到 RS2（页面稳定显示 RS2 内容），验证故障服务器被自动剔除。
备用服务器激活：同时停止 RS1 和 RS2 的服务，访问时页面显示 “sorry”，验证备用服务器生效，提供兜底响应。
为什么这样配置？核心设计逻辑
请求分流，降负载：通过 weight 配置实现请求均匀分配（或按权重分配），避免单服务器因高并发过载，提升整体响应速度。
健康检查，保可用：max_fails 和 fail_timeout 确保故障服务器被及时剔除，请求不浪费在无效节点上，减少用户等待。
多级备份，防极端：backup 备用服务器解决 “全故障” 场景，将 “服务中断” 转化为 “降级可用”，最大限度减少用户流失。
灵活扩展，易维护：新增后端服务器时，只需在 upstream 中添加 server 配置，无需修改客户端或代理入口，扩展性极强。
适用场景
负载均衡广泛用于：
高并发网站（如电商平台、资讯门户），通过多服务器分担流量；
核心业务系统，通过冗余服务器避免单点故障；
混合架构服务（如部分服务器处理静态资源，部分处理动态请求）。
三、四层代理 - 负载均衡
实验目的：通过 Nginx 的 stream 模块实现四层（传输层）负载均衡，针对非 HTTP 协议的服务（如 DNS、MySQL）进行请求分流，将客户端连接按规则分配到多台后端服务器，同时通过健康检查确保服务可用性，适用于数据库、DNS 等底层服务的负载均衡场景。
核心原理：四层代理与 stream 模块
四层代理工作在 TCP/UDP 传输层，仅根据 “源端口、目标端口、IP 地址” 转发数据，不解析应用层协议（如 HTTP 头部、DNS 报文内容），因此适用于所有基于 TCP/UDP 的服务（如 DNS、MySQL、SSH 等）。
Nginx 通过 stream 模块实现四层代理，功能类似硬件负载均衡器的 “四层转发”，核心优势：
通用性：支持所有 TCP/UDP 服务，不受应用层协议限制；
高性能：转发逻辑简单（仅处理传输层数据），性能接近硬件级；
高可用：结合健康检查（max_fails、fail_timeout）自动剔除故障节点。
3.1.DNS 负载
实验背景
DNS 服务是网络基础服务，负责将域名解析为 IP 地址，通常使用 UDP 53 端口（普通查询）和 TCP 53 端口（区域传输等）。通过四层代理实现 DNS 负载均衡，可分担单台 DNS 服务器的查询压力，同时避免单点故障。
RS 安装 bind 软件，配置 DNS 服务。
yum install bind -y # 安装 BIND（DNS 服务软件）
vim /etc/named.conf
############
options {
...
listen-on port 53 { any; }; # 确保 DNS 服务可被远程客户端访问（不仅限于本地）
allow-query { any; }; # 允许所有 IP 地址查询该 DNS 服务器，适合作为公共解析服务
dnssec-validation no; # 关闭 DNS 记录的数字签名验证（测试场景简化，生产环境需开启）
...
}
############禁用 DNSSEC 验证后，系统在处理 DNS 解析结果时，不会对记录的数字签名进行验证，直接接受并使用解析结果（无论其是否被篡改、是否来自真实域名所有者）。
dnssec-validation no; 是为了 “可用性” 牺牲 “安全性” 的配置，让系统 “不较真” DNS 记录的真实性，直接使用解析结果。
vim /etc/named.rfc1912.zones
###########
zone "haha.org" IN { # 添加以下内容
type master; # 作为主 DNS 服务器
file "haha.org.zone"; # 解析记录文件路径
allow-update { none; }; # 禁止动态更新（安全加固）
};
###########
cd /var/named/
cp -p named.localhost haha.org.zone
vim haha.org.zone
###########
$TTL 1D
@ IN SOA dns.haha.org. root.haha.org. (
0 ; serial
1D ; refresh
1H ; retry
1W ; expire
3H ) ; minimum
NS dns.haha.org.
dns A 192.168.67.10 # 为了查看效果 20 主机写本机 IP
###########
systemctl start named
systemctl enable --now namednginx 代理服务器配置。
# 主配置文件添加
vim /usr/local/nginx/conf/nginx.conf
##########
...
include "/usr/local/nginx/tcp.d/*.conf"; # 引入四层代理配置文件（不可放在 http 或 server 块内）
...
##########mkdir /usr/local/nginx/tcp.d/
vim /usr/local/nginx/tcp.d/xixi.conf
#########
stream {
upstream dns {
server 192.168.67.10:53 max_fails=3 fail_timeout=5; # RS1 的 DNS 服务（53 端口），3 次失败后标记不可用，5 秒后重试
server 192.168.67.20:53 max_fails=3 fail_timeout=5;
}
server {
listen 53 udp; # 监听代理服务器的 UDP 53 端口
proxy_pass dns; # 转发到 dns 服务器组
}
server {
listen 53; # 默认 TCP 协议，监听 53 端口
proxy_pass dns;
}
}
#########
systemctl restart nginx
netstat -antlupe | grep nginx
预期结果：多次查询会交替返回 RS1（192.168.67.10）和 RS2（192.168.67.20）的 IP，验证请求被轮询分配到两台后端 DNS 服务器。
dig @192.168.67.100 dns.haha.org
3.2.Mysql 负载
实验背景
MySQL（或 MariaDB）是常用的关系型数据库，使用 TCP 3306 端口通信。通过四层代理实现 MySQL 负载均衡，可将客户端连接分配到多台数据库服务器，分担读写压力（需配合数据库主从复制等策略确保数据一致性）。
后端 RS 下载 mariadb，配置 server_id，授权用户。
# 安装 mariadb
yum install mariadb-server -y
vim /etc/my.cnf.d/mariadb-server.cnf
[mysqld]
...
server-id=10 # RS1 设为 10，RS2 设为 20（唯一标识，便于区分实例）
...
systemctl enable --now mariadb
mysql -e "grant all on *.* to zyz@'%' identified by 'zyz'" # 进入MySQL
# 添加可远程登录的用户
# 测试：远程登录 mysql
mysql -uzyz -pzyz -h192.168.13.10
mysql -uzyz -pzyz -h192.168.13.20nginx 主机配置
vim /usr/local/nginx/tcp.d/xixi.conf
########
stream {
upstream mariadb {
server 192.168.67.10:3306 max_fails=3 fail_timeout=4; # RS1 的 MySQL 服务（3306 端口），3 次失败后标记不可用，4 秒后重试
server 192.168.67.20:3306 max_fails=3 fail_timeout=4;
}
server {
listen 3306; # 监听代理服务器的 3306 端口
proxy_pass mariadb; # 转发到 mariadb 服务器组
}
}
########
netstat -antlupe | grep nginx
测试：
预期结果：多次连接会交替返回 server_id=10（RS1）和 server_id=20（RS2），验证请求被轮询分配到两台后端数据库服务器。
四层代理的核心价值与配置解析
关键参数作用
stream 块：Nginx 处理四层代理的核心模块，与 http 块平级，专门用于配置 TCP/UDP 服务的转发规则。
upstream 服务器组：定义后端服务节点，支持 max_fails（最大失败次数）和 fail_timeout（失败检测周期）实现健康检查 —— 超过失败次数后自动剔除故障节点，超时后重新检测。
listen 指令：指定代理服务器监听的端口和协议（udp 需显式声明，默认 TCP），如 listen 53 udp 对应 DNS 的 UDP 服务，listen 3306 对应 MySQL 的 TCP 服务。
proxy_pass：将监听端口的请求转发到定义的 upstream 服务器组，实现负载均衡。
适用场景与优势
通用性：支持所有 TCP/UDP 服务（DNS、MySQL、SSH、Redis 等），解决七层代理（仅 HTTP）的局限性；
高性能：转发逻辑简单（不解析应用层数据），资源消耗低，可支撑高并发场景；
高可用：通过健康检查自动剔除故障节点，结合备用服务器可实现服务无感知切换；
易扩展：新增后端服务器只需在 upstream 中添加节点，无需修改客户端配置。
通过四层代理配置，Nginx 突破了仅处理 HTTP 服务的限制，成为通用的传输层负载均衡器，为底层服务（如数据库、DNS）提供分流与高可用保障，是构建企业级分布式架构的重要组件。