慎用url重写

本文探讨了URL重写对网站性能的影响,特别是当所有文件类型均通过重写处理时所导致的问题,并提出了改进措施。
     为了使url地址更加友好(当然可能有别的原因),很多站点使用了url重写,如 http://www.cnblogs.com/life,在asp.net中通常要处理这样的url重写,必须在IIS中将*.*映射到aspnet_isapi.dll(C:/WINDOWS/Microsoft.NET/Framework/v1.1.432/aspnet_isapi.dll),然后在web.config进行相应的配置,最后在写相应的处理程序,多数情况我们是那么做的,搏客园也是那么做的,这似乎没有什么问题。

      但是搏客园很久以来一直存在性能问题,dudu和园子的很多朋友也想了很多法子去提高性能,取得了不小的成绩,但是还是不是很理想,我也很想出一份力,因为我很喜欢搏客园,我在园子学了很多东西,基本上是早中晚都要看上面的文章,直到昨天晚上一个技术群的朋友问我一个url重写的问题之后,突然醒悟搏客园的性能问题很可能是url重写造成的。

我朋友的问题是这样:
http://www.wodecity.com/foodhttp://www.wodecity.com/food.html(该链接现在已经失效)都是通过url重写定位到同一个页面http://www.wodecity.com/page/food.aspx ,都是用同样的处理程序,唯一不同的是为了处理http://www.wodecity.com/food这样没有扩展名的地址他必须将*.*映射到aspnet_isapi.dll,而http://www.wodecity.com/food.html则是将*.html映射到aspnet_isapi.dll,结果发现http://www.wodecity.com/food.html的性能比http://www.wodecity.com/food好十至二十倍,他是用loadrunner进行测试的,他对这样的结果感到很郁闷。我开始的时候也感到不可思议,*.*和*.html到底什么区别呢,*.*就是该页面所有的请求,包括css文件和所有的图片文件都有用他写的url重写处理程序去处理,*.html则没有,只是一个请求,问题就出现在这里了,http://www.wodecity.com/food这个页面有超过20个图片吧,请求一个页面要同时用url重写处理程序去处理那么多图片,能不慢吗?怎么办呢?因为他们想用http://www.wodecity.com/food这样的url,这样比较友好,所以还是要用*.*,思考一会儿之后我告诉他,让你的url重写程序不处理那些图片文件就行了,怎么做呢?有两个方法:方法1,把存放图片所在的文件夹转化成一个虚拟目录,在然后移处该虚拟目录*.*的映射,这样一来他的url重写程序就不会去处理图片文件,当然存放别的不需要url重写程序的文件也要象图片文件夹做类似的处理,方法2,新建一个站点,如用http://img.wodecity.com/存放图片文件,原理是一样的,都是让你的url重写处理程序不处理那些图片文件。

一切ok,他跟我说今天早上他到公司测试一下。

为了验证我的想法,我今天自己也写了一个程序去测试,性能也是相差近20倍,good,我的想法是正确。


或许我的想法或测试结果有错误,这里欢迎PK。msn:cxbsky#hotmail.com。

也希望这篇文章对搏客园的性能问题有所帮助,因为搏客园出现的问题可能和我朋友的站点很相似。

ps:写完这篇文章的时候我问了一下我那朋友的测试结果,他说:“原来只能撑到50个人。现以700以上都没有问题 。”

 
<think>嗯,用户需要我用Nginx反向代理一个HTTPS地址,具体是https://192.168.18.60:9076/PY920/PurchaseOrderManager?WSDL。首先,我得确认用户的需求是什么。反向代理通常用来隐藏后端服务器,提供负载均衡或者SSL终止等功能。但这里的目标地址已经是HTTPS,可能需要特别注意证书问题。 用户可能是在内部网络中,希望通过Nginx来代理这个内部服务,让外部或不同网络的客户端通过Nginx访问。但后端服务已经是HTTPS,所以Nginx作为反向代理时,是否需要处理SSL?通常反向代理可以配置为SSL终止,即Nginx处理HTTPS,然后以HTTP转发给后端,但这里后端是HTTPS,所以可能需要Nginx以HTTPS协议转发请求,也就是SSL穿透。 这时候需要确认Nginx是否支持代理到HTTPS后端。通常使用proxy_pass指令时,如果后端是HTTPS,Nginx需要验证证书吗?默认情况下,Nginx不会验证后端证书,但可能需要配置SSL参数,比如proxy_ssl_verify关闭验证,否则如果后端证书是自签名的,可能会出错。 用户提供的地址是IP地址,可能使用的是自签名证书,或者内部CA颁发的证书。如果Nginx在代理时不做SSL验证,可能需要设置proxy_ssl_verify off;否则,连接可能会失败。此外,需要注意代理的路径是否正确,是否需要在Nginx配置中重写URL。 另外,用户提供的URL有查询参数?WSDL,这可能是一个Web服务的WSDL文件,用于SOAP服务。需要确保代理配置正确处理查询参数,避免被截断或丢失。在Nginx的proxy_pass中,通常会将原始请求的URI传递给后端,但如果有路径重写,需要注意处理。 接下来,我需要考虑配置的具体写法。假设用户希望外部通过Nginx的某个端口(比如80或443)访问,然后Nginx代理到https://192.168.18.60:9076。如果Nginx本身需要启用SSL,那么需要配置SSL证书;如果用户希望外部用HTTP访问,Nginx则用HTTPS转发到后端,或者外部用HTTPS,Nginx也用HTTPS转发。 根据用户之前的对话历史,他们之前提到过移除HTTPS证书但仍以HTTPS访问的问题,可能现在这个需求是类似的,但这次是正确设置反向代理。用户可能对Nginx配置不太熟悉,所以需要给出详细的步骤和配置示例,并解释关键参数的作用。 另外,需要注意Nginx的proxy_set_header设置,确保Host头正确传递,避免后端服务器因为Host头不正确而拒绝请求。特别是当后端服务依赖于Host头来生成正确的WSDL地址时,可能需要设置Host头为后端服务器的IP或域名。 最后,测试配置是否正确,包括检查Nginx配置语法,重新加载配置,以及通过curl或浏览器访问Nginx的代理地址,查看是否能正确获取WSDL文件。如果有错误,需要查看Nginx的错误日志来排查问题,比如SSL握手失败、连接超时等。</think>以下是使用Nginx反向代理配置代理HTTPS后端服务的详细步骤: --- ### **一、需求分析** 需要将外部请求通过Nginx转发至内部服务 `https://192.168.18.60:9076/PY920/PurchaseOrderManager?WSDL`,典型场景包括: 1. 隐藏后端服务器真实IP 2. 统一入口管理多个服务 3. 添加额外安全层(如访问控制、限流等) --- ### **二、基础配置模板** ```nginx server { listen 80; # 可改为443并配置SSL证书 server_name your-domain.com; # 替换为实际域名或IP location /PY920/PurchaseOrderManager { proxy_pass https://192.168.18.60:9076/PY920/PurchaseOrderManager; # 关键代理参数 proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header X-Forwarded-Proto $scheme; # 忽略后端SSL证书验证(若后端使用自签名证书) proxy_ssl_verify off; } } ``` --- ### **三、关键配置说明** #### **1. 路径匹配与转发** - `location /PY920/PurchaseOrderManager` 匹配以该路径开头的请求,例如: `http://your-domain.com/PY920/PurchaseOrderManager?WSDL` - `proxy_pass` 需完整保留路径,若后端服务路径与代理路径一致,可直接使用完整URL。 #### **2. 请求头传递** - `Host $host`:保持客户端原始域名,避免后端服务因Host错误拒绝请求。 - `X-Forwarded-*`:传递客户端真实IP和协议信息。 #### **3. SSL穿透配置** - `proxy_ssl_verify off` 若后端使用自签名证书或无有效证书,需关闭证书验证(生产环境慎用)。 --- ### **四、高级场景配置** #### **场景1:Nginx启用HTTPS加密** 若需对外提供HTTPS访问: ```nginx server { listen 443 ssl; server_name your-domain.com; # SSL证书配置 ssl_certificate /path/to/cert.pem; ssl_certificate_key /path/to/key.pem; location /PY920/PurchaseOrderManager { proxy_pass https://192.168.18.60:9076/PY920/PurchaseOrderManager; # 其他参数同上 } } ``` #### **场景2:路径重写** 若需要隐藏后端路径(例如代理到根路径): ```nginx location /proxy-path/ { proxy_pass https://192.168.18.60:9076/PY920/PurchaseOrderManager; rewrite ^/proxy-path/(.*)$ /$1 break; # 去除路径前缀 } ``` --- ### **五、操作验证步骤** 1. **检查配置语法** ```bash sudo nginx -t ``` 2. **重载Nginx配置** ```bash sudo systemctl reload nginx ``` 3. **测试代理是否生效** ```bash curl -v http://your-domain.com/PY920/PurchaseOrderManager?WSDL # 若配置了HTTPS,替换为https:// ``` 4. **排查错误** - 查看Nginx错误日志: ```bash tail -f /var/log/nginx/error.log ``` - 常见错误: - `502 Bad Gateway`:Nginx无法连接到后端服务,检查IP和端口是否可达。 - `SSL_do_handshake() failed`:后端证书问题,尝试启用 `proxy_ssl_verify off`。 --- ### **六、安全性增强建议** 1. **限制访问来源** ```nginx location /PY920/PurchaseOrderManager { allow 192.168.1.0/24; # 允许内网IP deny all; # 禁止其他IP } ``` 2. **启用速率限制** ```nginx limit_req_zone $binary_remote_addr zone=po_limit:10m rate=5r/s; location /PY920/PurchaseOrderManager { limit_req zone=po_limit burst=10; } ``` --- ### **总结** - **基础功能**:通过简单配置可实现反向代理。 - **安全风险**:若后端使用自签名证书,需权衡 `proxy_ssl_verify off` 的安全影响。 - **扩展能力**:Nginx可叠加缓存、负载均衡等功能,适应复杂场景。
评论 1
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值