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

强的小企业网站建设百度教育会员

wzjs 2025/7/22 18:25:53
强的小企业网站建设,百度教育会员,金华建站方案,做日用品的网站什么是代理？代理是作为中间层，作用于上下游两端。将下游的“请求”转移提交到上游，将上游的“响应”提交给下游。代理不仅在设计模式等程序设计中有比较广泛的使用，同时在大型的系统工程中使用也比较广泛，在web服务器领…

什么是代理？代理是作为中间层，作用于上下游两端。将下游的“请求”转移提交到上游，将上游的“响应”提交给下游。代理不仅在设计模式等程序设计中有比较广泛的使用，同时在大型的系统工程中使用也比较广泛，在web服务器领域，代理出现的频率也是很高的。

目录

一、 ngx_http_proxy_module模块介绍

1.1 代理的本质与应用场景：从中间层到工程实践

1.1.1 重新定义“代理”：不只是桥梁

1.1.2 正向代理 vs 反向代理：穿透迷雾的对比

1.1.3 反向代理的不可替代性：

1.1.4 Nginx代理体系：proxy与upstream的默契配合

1.1.5 代理链路的全流程解析

1.1.6  避免常见误区：代理的进阶认知

1.2  ngx_http_proxy_module参数详解

参数1：proxy_set_header

参数2：proxy_buffering on;

参数3：proxy_buffer_size 4k;

参数4：proxy_buffers 8 4k;

参数5：proxy_busy_buffer_size 16k;

参数6： proxy_temp_path

参数7： proxy_max_temp_file_size

1.3 proxy_pass 代理七层转发

1.4 proxy_pass时url末尾带“/”与不带“/”的区别

二、代理层cache与处理cache

2.1 代理层的proxy_cache机制

2.2 代理层的proxy_cache应用

一、 ngx_http_proxy_module模块介绍

地址：Module ngx_http_proxy_module

1.1 代理的本质与应用场景：从中间层到工程实践

1.1.1 重新定义“代理”：不只是桥梁

        在分布式架构中，代理（Proxy）常被比作“中间人”，但其核心价值远不止传递数据。它的核心使命是解耦上下游：

  • 对下游：隐藏上游的拓扑细节（如服务器IP、负载策略），提供统一的接入入口。

  • 对上游：过滤非法请求（如DDoS攻击）、预处理数据（如压缩/加密），减轻业务服务器压力。

PS: 上游与下游的解释

基本概念

  • 下游（Downstream）：请求的发起方或数据接收端，通常是更靠近客户端的一侧。

  • 上游（Upstream）：请求的接收方或数据提供端，通常是更靠近服务端的一侧。
    核心规则：数据流动方向决定上下游关系，下游是“索取者”，上游是“提供者”。

反向代理中的上下游，在典型Nginx反向代理场景中：

客户端（下游） → Nginx（上游） → 后端服务器（更上游）

  • 客户端视角：Nginx是上游（直接交互的对象）。

  • Nginx视角：后端服务器是上游（实际处理请求的服务）。

  • 后端服务器视角：Nginx是下游（请求来源）。

1.1.2 正向代理 vs 反向代理：穿透迷雾的对比

许多资料混淆二者的差异，关键在于视角和场景：

维度

正向代理

反向代理

使用角色

客户端主动配置（如浏览器代理）

服务端部署，客户端无感知

核心目的

突破访问限制（如科学上网）

负载均衡、安全防护、缓存加速

典型场景

企业内网代理、爬虫IP池

Nginx网关、API Gateway

流量方向

集中客户端分散请求 → 统一出口

分散客户端请求 → 集中入口处理

1.1.3 反向代理的不可替代性：

  • 安全性：屏蔽真实服务器IP，防止直接暴露于公网。

  • 扩展性：通过横向扩展代理节点，轻松应对高并发。

  • 灵活性：动态路由、A/B测试、灰度发布等高级功能的基础。

1.1.4 Nginx代理体系：proxy与upstream的默契配合

Nginx的代理能力由两大模块协同实现：

1） proxy模块：协议适配与流量治理

  • 核心职责：

    • 修改请求头（如X-Forwarded-For传递真实客户端IP）

    • 响应内容处理（如Gzip压缩、SSL证书卸载）

    • 流量控制（限速、缓冲区优化、超时熔断）

  • 关键配置示例：

    location /api/ {proxy_pass http://backend;  # 请求转发proxy_set_header Host $host;  # 透传原始域名proxy_read_timeout 5s;       # 防止慢请求阻塞proxy_buffers 8 16k;         # 内存缓冲区优化proxy_http_version 1.1;      # 强制使用HTTP长连接
}

2） upstream模块：连接池与负载均衡

  • 核心职责：

    • 维护后端服务器池（健康检查、故障转移）

    • 负载均衡算法（轮询、权重、IP Hash等）

    • 连接复用（Keepalive优化，降低TCP握手开销）

  • 高阶用法：

    upstream backend {zone backend_zone 64k;     # 共享内存区，统计状态server 10.0.1.1:8080 max_fails=3;  # 自动剔除故障节点server 10.0.1.2:8080 backup;       # 备用服务器least_conn;                # 最少连接数策略keepalive 32;              # 连接池复用长链接
}

1.1.5 代理链路的全流程解析

当Nginx处理一个反向代理请求时，实际经历了多个阶段的精细化控制：

  • 请求拦截：通过location匹配URL规则（如按路径或域名分流）。

  • 上游选择：从upstream池中按策略选取目标服务器。

  • 请求重写：修改请求头、URL路径（如rewrite规则）。

  • 数据中转：双向流式传输数据，支持零拷贝优化。

  • 响应处理：过滤敏感头、压缩内容、记录日志。

  • 异常熔断：超时、502错误自动重试或降级。

1.1.6  避免常见误区：代理的进阶认知

  • 代理≠性能瓶颈：通过内核级优化（如Linux的sendfile机制），Nginx的代理吞吐可达百万QPS。

  • 代理≠单向透传：可通过sub_filter修改响应内容，实现动态内容替换。

  • 代理≠仅限HTTP：Nginx的stream模块支持四层TCP/UDP代理（如数据库、游戏服务器）。

官网地址见：Module ngx_http_proxy_module

1.2  ngx_http_proxy_module参数详解

设置背景：

  • 客户端：192.168.0.63 访问 www.51xue.com

  • 代理层：192.168.0.64 配置 www.51xue.com转发到业务层的www.51xuebak.com

  • 业务层：192.168.0.65 配置 www.51xuebak.com并处理请求到后端层

  • 后端层：192.168.0.66 配置mysql集群

语法格式：

  • 作用：proxy_set_header是用来设置请求头的，设置了请求头后，后端服务器就可以获取到这些变量值。

  • 语法：proxy_set_header field value;

    • field ：为要更改的项目，也可以理解为变量的名字，比如host

    • value ：为变量的值

1.2.1 请求头重写：proxy_set_header的攻防博弈

proxy_set_header 是代理流量治理的「指纹修改器」，它决定了后端如何感知客户端身份。以下通过渗透测试场景解析其深层作用：

1.2.2 基础身份伪装：host与host与proxy_host

  • 场景：隐藏真实业务域名，防止被扫描工具识别

    location / {proxy_pass http://192.168.0.65;  # 直连IP，不暴露域名proxy_set_header Host www.mirr.com;  # 伪装域名
}

    • 攻击者视角：只能看到www.mirr.com，无法关联真实业务www.51xuebak.com

    • 防御价值：增加黑产逆向工程成本，阻断基于域名的漏洞扫描

1.2.3 多租户隔离：$http_host的精准路由

当Nginx代理多个租户服务时：

server {listen 80;server_name tenant1.com;proxy_set_header Host $http_host;  # 透传原始域名proxy_pass http://backend;
}server {listen 80;server_name tenant2.com;proxy_set_header Host $http_host;proxy_pass http://backend; 
}

  • 后端服务：通过Host头区分租户，实现单集群多域名隔离，比如你请求的是tenant1.com，就自动匹配到第一个server下。

  • 性能优势：避免为每个租户启动独立进程。

1.2.4  IP溯源体系：X-Forwarded-For的信任链构建

多层代理下的真实IP提取算法：

def get_real_ip(xff_header):ips = xff_header.split(', ')return ips[0] if len(ips) > 0 else None  # 首段为真实客户端IP

  • 安全威胁：若首段IP可伪造，可能导致IP欺骗

  • 加固方案：

    set_real_ip_from 192.168.0.0/16;  # 只信任内网代理
real_ip_header X-Forwarded-For;  
real_ip_recursive on;              # 跳过可信代理IP

1.2.5  缓冲机制：proxy_buffer的性能生死线

缓冲配置不当可直接导致吞吐量雪崩，通过Linux内核参数优化突破瓶颈：

1） 缓冲区的「三区两界」模型

  • Header区（proxy_buffer_size）：存储响应头，建议4K对齐（匹配SSD块大小）

  • Body区（proxy_buffers）：环形缓冲队列，推荐8×4K（适配HTTP平均包大小）

  • Busy区（proxy_busy_buffer_size）：冲刷阈值，建议≥16K（减少内核态切换）

2） 零拷贝优化：sendfile与buffer的化学反应

启用内核级零拷贝：

proxy_buffering on; 
sendfile on;         # 绕过用户空间，直接从页缓存发送

  • 性能收益：减少CPU拷贝次数，提升静态资源传输效率40%

  • 适用场景：大文件下载、视频流传输

1.2.6 临时文件黑洞：proxy_temp的容灾设计

临时文件是代理服务的「阿喀琉斯之踵」，需从架构层面规避风险：

1）多级存储隔离
proxy_temp_path /dev/shm/nginx_temp 1 2;  # 内存盘存储活跃文件
proxy_max_temp_file_size 2G;               # 防磁盘写满
proxy_temp_file_write_size 16k;            # 匹配SSD最佳写入单元

  • 内存盘优势：I/O速度比SSD快100倍，系统重启自动清理

  • 兜底方案：Crontab定时清理旧文件

    */30 * * * * find /dev/shm/nginx_temp -type f -mmin +30 -delete
2）故障注入测试

  • Case 1：磁盘空间耗尽 → 触发499日志并返回503状态码

  • Case 2：文件权限错误 → 通过SELinux沙盒自动修复

  • 防御策略：

    proxy_temp_path /var/nginx_temp 1 2;
error_page 500 502 503 504 =503 @failsafe;
location @failsafe {return 503 "Service Degraded";
}

1.3 proxy_pass 代理七层转发

公共代理参数文件：在跟nginx.conf配置文件同一目录下，建立一个proxy.conf文件，添加以下信息：

proxy_redirect off;
proxy_set_header Host $host;
proxy_set_header X-Forwarded-For $remote_addr;
proxy_connect_timeout 90;
proxy_send_time 90;
proxy_read_time 90;
proxy_buffer_size 4k;
proxy_buffers 4 32k;
proxy_busy_buffers_size 64k;
proxy_temp_file_write_size 64;

  • 然后再nginx.conf文件中包含proxy.conf文件进来：

server {listen 80;server_name ceshi1.10jqka.com.cn;root /var/www/html;proxy_ignore_client_abort on;access_log logs/ceshi1.access.log main;error_log logs/ceshi1.error.log notice;location = /break {rewrite ^/break/(.*) /test/$1 break;proxy_set_header Via "";proxy_set_header X-Real-IP $remote_addr;proxy_pass http://192.168.205.187/last/$1;}location ^~ /last/ {rewrite ^/last/(.*) /test/$1 last;proxy_set_header Via "";proxy_set_header X-Real-IP $remote_addr;proxy_pass http://www.ceshi2.com/$1;}
}

1.4 Nginx路径拼接规则：proxy_pass斜杠的「蝴蝶效应」

1.4.1 本质原理：URI的三种拼接模式

Nginx处理proxy_pass路径时，根据目标URL是否含URI，分为三种处理策略：

proxy_pass格式匹配模式路径处理规则
http://backend不含URI透传客户端完整路径
http://backend/含URI（根路径）删除location匹配部分，拼接剩余路径
http://backend/api含URI（非根路径）同上，但保留自定义前缀

1.4.2  斜杠触发「路径手术」的底层逻辑

1） 规则公式
代理目标URI = proxy_pass的URI部分 + (客户端URI - location匹配部分)
2） 核心代码逻辑（伪代码）
def process_proxy_pass(client_uri, location_match, proxy_pass_uri):if proxy_pass_uri.endswith('/'):# 精确切除location匹配部分cut_length = len(location_match)return proxy_pass_uri + client_uri[cut_length:]else:# 全量透传（含location匹配部分）return proxy_pass_uri + client_uri

1.4.3  四象限分析：斜杠的排列组合

假设客户端请求：http://nginx-host/test/tes.jsp

1） 象限1：location带斜杠 & proxy_pass带斜杠
location ^~ /test/ {        # 匹配部分：/test/proxy_pass http://backend/server/;  # 目标URI：/server/
}

代理路径：
/server/ + (tes.jsp) = http://backend/server/tes.jsp
：'/server/ + （tes.jsp） = http://backend/server/tes

2） 象限2：location无斜杠 & proxy_pass带斜杠
location ^~ /test {         # 匹配部分：/testproxy_pass http://backend/server/;  # 目标URI：/server/
}

代理路径：
/server/ + (/tes.jsp) = http://backend/server//tes.jsp
（双斜杠可能导致后端路由异常）

3） 象限3：location带斜杠 & proxy_pass无斜杠
location ^~ /test/ {        # 匹配部分：/test/proxy_pass http://backend;  # 目标URI：空
}

代理路径：
空 + (tes.jsp) = http://backend/test/tes.jsp
（透传原始路径，可能暴露内部结构）

4） 象限4：location无斜杠 & proxy_pass无斜杠
location ^~ /test {         # 匹配部分：/testproxy_pass http://backend;  # 目标URI：空
}

代理路径：
空 + (/test/tes.jsp) = http://backend/test/tes.jsp

1.4.4  高级调试：抓包验证路径传递

1） tcpdump抓包命令
tcpdump -i eth0 -A -s 0 'port 8080' | grep "GET /"
2） 测试案例对比
场景预期路径实际抓包结果
象限2配置/server//tes.jspGET //tes.jsp HTTP/1.1
象限3配置/test/tes.jsp /测试/GET /test/tes.jsp HTTP/1.1
获取 /test/tes.jsp HTTP/1.1

总结：斜杠的「四要四不要」

要不要
保持location与proxy_pass斜杠一致混合使用有无斜杠配置
用rewrite标准化路径依赖后端容忍异常路径
开启merge_slashes优化允许双斜杠出现在关键路径
定期扫描access_log验证忽视HTTP 400类错误日志

通过理解路径拼接的量子化特性，可避免90%的代理配置故障。

二、代理层cache与处理cache

2.1 代理层的proxy_cache机制

  • proxy_cache和fastcgi_cache构成了Nginx的缓存。

  • proxy_cache主要用于反向代理时，对后端内容源服务器进行缓存，可能是任何内容，包括静态的和动态，缓存减少了nginx与后端通信的次数，节省了传输时间和后端宽带；

  • fastcgi_cache在下一章节说明。

  • 涉及到的其他模块

    • 清除缓存模块：ngx_cache_pure

    • 扩展包下载地址：FRiCKLE Labs / nginx / ngx_cache_purge

2.2 代理层的proxy_cache的应用

http {proxy_temp_path /memdisk/proxy/proxy_dir;proxy_cache_path /memdisk/proxy levels=1:2 keys_zone=cache_proxy:1024m inactive=15m max_size=8168m;server {listen 80;server_name ceshi1.10jqka.com.cn;root /var/www/html;proxy_ignore_client_abort on;access_log logs/ceshi1.access.log main;error_log logs/ceshi1.error.log notice;location @fetch {internal;#proxy_next_upstream error timeout invalid_header http_502;#proxy_next_upstream_timeout 10;proxy_cache cache_proxy;proxy_cache_key $uri$is_args$args;proxy_cache_valid 200 2m;proxy_cache_use_stale error timeout invalid_header http_500 http_502;proxy_set_header Host stock.10jqka.com.cn;proxy_pass http://front_server;}}
}

2.2.1 缓存清理

  • 浏览图片文件：http://www.osyunwei.com/images/nopic.gif

  • 清除这个文件缓存：http://www.osyunwei.com/purge/images/nopic.gif

  • 提示：Successful purge，缓存文件清除成功，如果这个文件没有被缓存过，则提示：404 Not Found

备注：

  • purge是ngx_cache_pure 模块指令

  • images/nopic.gif 是要清除的缓存文件URL路径

2.2.2  proxy_cache_path的引用介绍

1) proxy_temp_path：缓存构建的「临时车间」
proxy_temp_path /memdisk/proxy/proxy_dir;
1.1) 核心作用

当Nginx从上游服务器接收响应时，若响应数据无法直接写入缓存（如大文件分块传输或缓存未就绪），会先存入临时目录，待完整接收后再原子化移动到缓存区。

1.2) 参数详解

  • 路径设计：/memdisk/proxy/proxy_dir

    • /memdisk：通常为内存盘挂载点（如tmpfs），利用内存I/O加速临时文件操作

    • 三级目录结构：避免单目录文件数过多引发inode竞争

  • 未显式配置的参数：

    • levels：默认无层级，适用于高频写入场景

    • use_temp_path：默认开启，需结合proxy_cache_path的use_temp_path调优

1.3) 性能影响
存储介质写入延迟适用场景
内存盘0.1-1ms 0.1-1 毫秒高频交易行情数据
 SSD 固态硬盘2-5ms电商大促页面缓存
机械硬盘10-50ms低频访问日志归档
1.4 风险预警

  • 内存盘容量溢出：若临时文件总量超过内存盘大小，引发OOM（需监控/memdisk使用率）

  • 原子移动失败：网络抖动导致临时文件未完整迁移，触发proxy_next_upstream重试机制

2) proxy_cache_path：缓存系统的「核心仓库」
proxy_cache_path /memdisk/proxy levels=1:2 keys_zone=cache_proxy:1024m inactive=15m max_size=8168m;
参数逐层拆解
2.1)  存储拓扑：levels=1:2

  • 目录结构：

    /memdisk/proxy
├── a/    ← 1级目录（1字符命名，16进制）
│   ├── 1b/  ← 2级目录（2字符命名）
│   │   └── 缓存文件（MD5哈希值命名）
│   └── c3/
└── d/

  • 设计价值：

    • 避免单目录文件数超过ext4的5000万inode限制

    • 提升SSD随机读性能（目录分散降低锁竞争）

2.2) 内存元数据区：keys_zone=cache_proxy:1024m

  • 内存消耗公式：

    每条缓存元数据 ≈ 200字节  
最大缓存键数量 = 1024MB / 200B ≈ 5,368,709 条
2.3) 生命周期管理

  • inactive=15m：

    • 含义：15分钟内未被访问的缓存视为冷数据，触发LRU淘汰

    • 误删防御：结合proxy_cache_background_update on实现热更新保活

  • max_size=8168m：

    • 动态权重：实际占用空间 = 文件大小 + 文件系统块开销（通常+10%）

    • 溢出处理：触发cache manager进程按LRU清理，写入error_log警告

2.4) 极端场景测试
测试用例预期行为日志关键字
写入8.5G缓存触发LRU清理cache manager process exited abnormally
内存盘写满返回502错误no space left on device
共享内存溢出新缓存被拒could not add new key

http://www.dtcms.com/wzjs/52756.html

相关文章：

  • 协会网站建设的作用铜陵seo
  • 电脑版和手机版网站怎么做的b2b商务平台
  • 购物网站首页怎么设计培训机构哪家最好
  • 门户网站方案微博推广方式
  • 网站建设的数据储存在哪里杭州哪家seo公司好
  • 搜狗收录网站网络推广项目代理
  • 网站开发 业务流程图网站如何提升seo排名
  • 沈阳正规制作网站公司浏览器大全
  • 公司做网站需要给百度交钱吗抚州网站seo
  • 网站设计开发方案湛江百度网站快速排名
  • wordpress微店插件下载seo网站优化方案书
  • 室内设计网站哪里可以看上海aso优化公司
  • 企业网站管理中心买域名
  • 手工艺品网站建设侧胡顺2023北京封控了
  • flash网站代做在线建站平台
  • 成都网站建设桔子科技成都网站优化排名推广
  • 购物网站平台建设小程序定制开发
  • 代做论文毕业设计网站靠谱不推广目标怎么写
  • wordpress调整页面布局长春seo外包
  • 网站建设在哪里学网站维护是什么意思
  • 给公司建立网站不可以做到的广州网站推广平台
  • 天津做家政的网站厦门网站优化公司
  • 株洲 网站建设 公司2022新闻大事件摘抄
  • 会员管理系统哪个好用seo优化方案项目策划书
  • 上海网站公安备案号竞价托管收费标准
  • 网站开发基本要求千锋教育学费
  • 网站制作需求分析天津seo实战培训
  • 做网站时导航条一般用什么样式宁波seo搜索排名优化
  • 微官网登录郑州搜索引擎优化
  • 如何自己搭建一个网站热门关键词排名查询