一般来说,gzip压缩是否启用,除了服务器支持外,客户端也要支持。当客户端发送Accept-Encoding:gzip这个request
header,服务器即认为其能接受gzip压缩,就响应一个Content-Encoding:gzip,并发送压缩内容;假如客户端没有发送
Accept-Encoding,那么服务器就把源代码老老实实地打印出去。
但这里就有个怪点子,能不能让客户端无论有没有发送Accept-Encoding,服务器都会发送压缩内容呢?
这有几个好处:
1、进一步节省带宽。
2、防止水平一般的爬虫抓页面偷数据。
经测试,此种做法并不会影响普通用户,因为他们都是用先进的浏览器上网的;另外,也不会影响主流的搜索引擎,收录仍然会正常。
要做到这点,需要有两个nginx,但也有办法配置两个虚拟主机就可以,不用启动两个nginx主进程。为了方便,我就以前后来区分它们。
前端nginx:
gzip压缩不在前端nginx进行,前端主要是用来强制修改request header,即写上:
1. proxy_set_header Accept-Encoding 'gzip';
这样,后台的nginx无论如何都将接收到Accept- Encoding:gzip,而不管客户端有没有发。
完整的测试样本:
1. upstream {
2. server 127.0.0.1:80;
3. }
4. server {
5. server_name
6. listen 80;
7.
8. location / {
9. proxy_pass http://;
10. include proxy.conf;
11. proxy_set_header Accept-Encoding 'gzip';
12. }
13. }
注意proxy_pass到的upstream是,这是在一台机器上配置两个虚拟主机所必需的,否则不就是
个死循环吗?如果还是想用,可以将前端的listen改成外网ip,后端就用127.0.0.1。
另外一个要注意proxy.conf里最好没有写过proxy_set_header
Accept-Encoding,我的proxy.conf默认有将Accept-Encoding设为空的,这会造成配置重复。但
proxy_set_header不会冲突,可以按配置先后顺序生效,我一时忘了是前生效还是后生效,动手测一下便知。
后端nginx:
后端nginx才是负责压缩的,这里要注意gzip的版本,因为nginx是用http1.0方式作代理,因此gzip的版本就不能是默认的1.1版,改成1.0。
1. server {
2. server_name ;
3. listen 80;
4.
5. location / {
6. root /html/;
7. gzip on;
8. gzip_http_version 1.0;
9. }
10. }
这里就简单点了,gzip的其他参数我就不贴上来,想必大家都有现成的配置,留意下version就好。
配好后,测试一下:
1. curl -I http://
发现返回了Content-Encoding:gzip
不加-I参数呢?
1. curl http://
打印出一堆乱码,把SecureCRT的字符都给弄坏了。
http:///nginx/nginx_gzip_always.html
阅读(10931) | 评论(0) | 转发(0) |