数字列表项目普通列表项目identity总是可被接受的 (除非显示的标记这个类型q=0),请求头中不存在Accept-Encoding头部或者Accept-Encoding值为空,那么认为也会认为是identity类型
如果服务器可以返回定义在Accept-Encoding 中的任何一种Encoding类型, 那么处理成功(除非q的值等于0, 等于0代表不可接受)
* 代表任意一种Encoding类型 (除了在Accept-Encoding中显示定义的类型)
如果有多个Encoding同时匹配, 按照q值顺序排列(从大到小)
浏览器发送Http request 给Web服务器, request 中有Accept-Encoding: gzip, deflate。 (告诉服务器, 浏览器支持gzip和deflate压缩)
Web服务器接到request后, 生成原始的Response, 其中有原始的Content-Type和Content-Length。
Web服务器通过Gzip,来对Response进行编码, 编码后header中有Content-Type和Content-Length(压缩后的大小), 并且增加了Content-Encoding:gzip. 然后把Response发送给浏览器。
浏览器接到Response后,根据Content-Encoding:gzip来对Response 进行解码。 获取到原始response后, 然后显示出网页
DeflateCompressionLevel 8
Header append Vary Accept-Encoding
AddOutputFilterByType DEFLATE text/plain text/css text/xml application/xml application/javascript application/x-javascript
</ifmodule>
4.2 nginx配置gzip压缩
gzip_buffers 4 16k;
gzip_http_version 1.1;
gzip_types text/plain text/css text/xml application/xml application/javascript application/x-javascript;
gzip_vary on;
普通列表项目如果频道放置于CDN频道的话,注意要开启gzip_vary参数,这样源机的响应头中会包含Vary: Accept-Encoding头部。CDN节点会缓存编码格式不同的多份副本,根据浏览器请求的编码格式不同,响应所需编码格式的响应。
线上存在一个以html,js,css等以文本内容为主的CDN频道。之前该CDN频道即使在源机为明确给出Vary:Accept-Encoding的情况下,CDN节点也可以正常的区分压缩和非压缩的请求,并且给出合适的响应。之后,可能由于配置调整或者CDN系统升级导致该策略失效。在对CDN频道进行周期性遍历的时候发现CDN节点会忽略用户的Accept-Encoding请求,全部发送明文数据。
对源机和CDN频道进行调整优化,下面是没有给出Vary头部和增加Vary头部后的带宽对比。
可以看到带宽降低了有三分之一。
实际的效果与URL的内容有关,文本内容的压缩比会高一些,而一些二进制文件一般经历过压缩,再次压缩的效果不大。