七、nginx gzip压缩提升网站速度

原创

济南极梦 2023-02-16 13:01:00 ©著作权

文章标签 缓存 php 服务器 文章分类 JavaScript 前端开发

©著作权归作者所有：来自51CTO博客作者济南极梦的原创作品，请联系作者获取转载授权，否则将追究法律责任

nginx+php的编译

apache一般是把php当做自己的一个模块来启动的.
而nginx则是把http请求变量(如get,user_agent等)转发给 php进程,即php独立进程,与nginx进行通信. 称为 fastcgi运行方式.
因此,为apache所编译的php,是不能用于nginx的.

注意: 我们编译的PHP 要有如下功能:
连接mysql, gd, ttf, 以fpm(fascgi)方式运行
./configure --prefix=/usr/local/fastphp
–with-mysql=mysqlnd
–enable-mysqlnd
–with-gd
–enable-gd-native-ttf
–enable-gd-jis-conv
–enable-fpm
编译完毕后:

nginx+php的配置比较简单,核心就一句话----
把请求的信息转发给9000端口的PHP进程,
让PHP进程处理指定目录下的PHP文件.

如下例子:

location ~ \.php$ {
            root html;
            fastcgi_pass   127.0.0.1:9000;
            fastcgi_index  index.php;
            fastcgi_param  SCRIPT_FILENAME  $document_root$fastcgi_script_name;
            include        fastcgi_params;

        }

1:碰到php文件,
2: 把根目录定位到 html,
3: 把请求上下文转交给9000端口PHP进程,
4: 并告诉PHP进程,当前的脚本是 $七、nginx gzip压缩提升网站速度_php$ fastcgi_scriptname
(注:PHP会去找这个脚本并处理,所以脚本的位置要指对)
网页内容的压缩编码与传输速度优化

我们观察news.163.com的头信息

请求:

Accept-Encoding:gzip,deflate,sdch

响应:

Content-Encoding:`gzip`
Content-Length:`36093`

再把页面另存下来,观察,约10W字节,实际传输的36093字节 原因-------就在于gzip压缩上.

原理:
浏览器—请求----> 声明可以接受 gzip压缩或 deflate压缩或compress 或 sdch压缩
从http协议的角度看–请求头声明 acceopt-encoding: gzip deflate sdch (是指压缩算法,其中sdch是google倡导的一种压缩方式,目前支持的服务器尚不多)
服务器–>回应—把内容用gzip方式压缩---->发给浏览器
浏览<-----解码gzip-----接收gzip压缩内容----

推算一下节省的带宽:

假设 news.163.com  PV  2亿
2*10^8  *  9*10^4 字节 == 
2*10^8 * 9 * 10^4  * 10^-9 = 12*K*G = 18T

节省的带宽是非常惊人的

gzip配置的常用参数


gzip on	off;
gzip_buffers 32 4K`\|` 16 8K	#缓冲(压缩在内存中缓冲几块? 每块多大?)
gzip_comp_level [1-9]	#推荐6 压缩级别(级别越高,压的越小,越浪费CPU计算资源)
gzip_disable	#正则匹配UA 什么样的Uri不进行gzip
gzip_min_length 200	# 开始压缩的最小长度(再小就不要压缩了,意义不在)
gzip_http_version 1.0`\|`1.1	# 开始压缩的http协议版本(可以不设置,目前几乎全是1.1协议)
gzip_proxied	# 设置请求者代理服务器,该如何缓存内容
gzip_types text/plain application/xml	# 对哪些类型的文件用压缩如txt,xml,html ,css
gzip_vary on`\|`off	# 是否传输gzip压缩标志

注意:

图片/mp3这样的二进制文件,不必压缩
因为压缩率比较小, 比如100->80字节,而且压缩也是耗费CPU资源的.

比较小的文件不必压缩,
nginx的缓存设置提高网站性能
对于网站的图片,尤其是新闻站, 图片一旦发布, 改动的可能是非常小的.我们希望能否在用户访问一次后, 图片缓存在用户的浏览器端,且时间比较长的缓存.
可以, 用到 nginx的expires设置 .
nginx中设置过期时间,非常简单,
在location或if段里,来写.
格式

expires 30s;
  expires 30m;
  expires 2h;
  expires 30d;

(注意:服务器的日期要准确,如果服务器的日期落后于实际日期,可能导致缓存失效)
另: 304 也是一种很好的缓存手段
原理是: 服务器响应文件内容是,同时响应etag标签(内容的签名,内容一变,他也变), 和 last_modified_since 2个标签值
浏览器下次去请求时,头信息发送这两个标签, 服务器检测文件有没有发生变化,如无,直接头信息返回 etag,last_modified_since
浏览器知道内容无改变,于是直接调用本地缓存.
这个过程,也请求了服务器,但是传着的内容极少.
对于变化周期较短的,如静态html,js,css,比较适于用这个方式

Nginx具体的压缩配置

常用以下配置
gzip on|off
gzip_buffers 4K|8K 缓冲(和硬盘块相当)
gzip_comp_level [1-9] 推荐6
gzip_disable 正则匹配如User-Agent,针对古老浏览器不压缩
gzip_min_length 200
gzip_http_version 1.0|1.1
gzip_types text/plain , application/xml (各mime之间,一定要加空格,不是逗号)
gzip_vary on|off

Vary的作用:

Vary是用来标志缓存的依据.
如上图: 看出,这个新闻页面由

思考:
1: 如果2个人,一个浏览器支持gzip,一个浏览器不支持gzip
2个同时请求同个页面, chinaCache缓存压缩后,还是未压缩的?

2: 如果1人,再次请求页面,chinaCache返回压缩后的缓存内容,还是压缩前的缓存内容?

这个时候 Vary的作用体现出来.
即------缓存的内容受 Accept-Encoding头信息的影响.

所以如果–
请求时,不支持gzip, 缓存服务器将会生成一份未gzip的内容.
请求时,支持gzip, 缓存服务器将会生成一份gzip的内容.

下次再请求时, 缓存服务器会考虑客户端的Accept-Encoding因素,并合理的返回信息

Nginx对于图片,js等静态文件的缓存设置
注:这个缓存是指针对浏览器所做的缓存,不是指服务器端的数据缓存.

主要知识点: location expires指令

location ~ \.(jpg|jpeg|png|gif)$ {
    expires 1d;
}
location ~ \.js$ {
   expires 1h;
}

设置并载入新配置文件,用firebug观察,
会发现图片内容,没有再次产生新的请求,原因–利用了本地缓存的效果.

注: 在大型的新闻站,或文章站中,图片变动的可能性很小,建议做1周左右的缓存Js,css等小时级的缓存.

如果信息流动比较快,也可以不用expires指令,
用last_modified, etag功能(主流的web服务器都支持这2个头信息)

原理是:
响应: 计算响应内容的签名, etag 和上次修改时间
请求: 发送 etatg, If-Modified-Since 头信息.
服务器收到后,判断etag是否一致, 最后修改时间是否大于if-Modifiled-Since
如果监测到服务器的内容有变化,则返回304,
浏览器就知道,内容没变,直接用缓存.

304 比起上面的expires 指令
多了1次请求,
但是比200状态,少了传输内容.