老鸟请直接看开启压缩进阶篇。

      菜鸟还是慢慢随着老夫的思路看吧，哇哈哈。

       什么是压缩？

         大家还记得我们第一次接触winzip软件吗？非常神奇，一个文件，经过winzip压缩后，大小可以压缩成原来的30%左右。记得当年，很多文件，都是压缩后才可以放到自己的软盘中。

而对于网站，也有这样的压缩技术，可以让你的网页中的文本类文件瘦身，在用户完全不知情的情况下，通过gzip和deflate压缩程序有效减少了网页，让用户更快的打开网站。

压缩有多大用处？

         通过一个小小的测试软件，我对新浪、网易等门户网站进行了访问。

         新浪首页访问情况：

网易首页访问情况：

大家可以明显的看到，网易和新浪的首页，经过压缩后，都缩小了70%以上。

相信大家都知道，当一个网页，减小到30%后，对于最终用户来说，打开网站的效率会提升为原来的3倍。

备注：

该工具地址http://www.gidnetwork.com/tools/gzip-test.php  大家也可以测试下自己的网站压缩后的情况。

用户不支持压缩怎么办？

开启压缩后，会不会由于用户无法访问这种压缩文件，导致用户访问文件失败？

不会，因为Trident、Gecko、Webkit三种内核的浏览器，都在发起请求时，告知服务器，他们支持什么压缩格式，如下图：

而服务器都是按照发起请求中用户支持的压缩格式，进行对应反馈。如果用户发起的请求头中，无Accept-Enconding头，就将返回给用户非压缩格式。

如何开启压缩？

请百度娘之，网上太多教程了，不再赘述。

对哪些内容开启压缩呢？

只需要针对文本类文件的域名开启压缩。图片等，已经都是压缩格式了，再使用压缩，不会减少什么文件大小，反而会导致服务器负载变高，以及会由于这种对图片的不规范压缩使用导致各种各样意想不到的问题。

所以，开启压缩之前，最好先完成域名拆分的工作，具体见如何让网站打开更快第二弹。

技巧点：

开启压缩，建议使用apache服务器。

因为IIS服务器在处理压缩时有个小问题，就是第一次被访问的时候，IIS给出的文件时非压缩的，后续的访问，才直接给出压缩文件。

这个小的bug，其实问题并不大，但是现在很多网站都在用一些缓存服务器或者是CDN，就会导致这个问题被放大，会导致压缩启用并不能完全成功。

而apache是第一次就直接给出压缩后的文件。

当然了，如果你用的是IIS，并且无法替换apache，那就自己麻烦一些，写个脚本，将常用的页面，在开启压缩后，访问2次，可以减少很多问题发生。

开启压缩之进阶篇

当下的中国网络状况

中国网络谁当家，当然是电信和联通两朵花，但是现在越来越看到的现象是百花争艳，除了这两朵花之外，越来越多的涌现小ISP。如移动、电信通、长城、方正、歌华有线、光环新网、甚至南方地区还有些香港过来的小运营商。

这些小运营商都有一个特点，就是会cache文件，他们会为了减少网间结算带宽，而尽量想办法缓存文件，让他们的用户本地访问。

其次，对于很多中大型公司来说，他们也会搭建自己的缓存服务器。

另外，还有很多网站，自身都搭建或者在使用第三方的CDN，也都是缓存服务器。

所以，当下的中国网络情况，基本上就是缓存服务器在提供众多的服务。所以，你的开启压缩，如果不主动配合这些各种各样的缓存服务器，那么你out了，你会发现，你的很多努力，都是笑谈，并无实际作用。

如何适合当下的状况？如何才可以保证用户支持压缩时，网络间传递的就是你想给他的的压缩文件？

那么，请紧记以下要点，并逐个落实。

开启压缩时，需要针对压缩和非压缩文件，都返回Vary:Accept-Encoding头。

这个头部是告诉缓存服务器，要根据用户支持的编码方式提供对应的文件。

该项很重要，很多网站，只是对压缩文件开启该头。在缓存服务器中，如果给出的非压缩的文件不包含该头部，也就是告知缓存服务器，当用户请求时，不需要判断用户支持的编码格式，而直接将该文件传递。所以，最后导致用户请求到缓存服务器时，无论用户支持不支持压缩，都是直接返回非压缩的文件。

开启压缩时，需要同时对HTTP1.1和HTTP1.0均开启压缩。

大家都是认为，HTTP1.0协议的用户，肯定是特别老的用户，肯定是不支持压缩的，所以，很多网站，都是针对HTTP1.0协议提供非压缩文件。

但是，实际中，太多太多的缓存服务器，为了追求最大的兼容性，还在使用HTTP1.0协议。所以，当你只是对HTTP1.1协议开启压缩时，等于抛个媚眼给瞎子看。

例如，新浪的缓存服务器，也是HTTP1.0协议的，但是他们就很聪明的针对HTTP1.0也开启了压缩服务，如下图：

  为什么要讲HTTP头？

1、  非常简单的通过HTTP头，可以让你的用户打开速度快10倍

2、  网上讲HTTP头的文章，都讲的太玄乎和专业，实际价值不大

3、  太多人看了太多乱七八糟的文章，加了很多自己也不知道干嘛用的HTTP头

4、  HTTP头过大会阻塞你的用户访问，你考虑过吗？如何让你的HTTP头正好够用，能够起到效果又不要过于臃肿堵塞你的用户，你考虑过吗？

什么是HTTP头？

         HTTP协议采用了请求/响应模型。

客户端向服务器发送一个请求，请求头包含请求的方法、URI、协议版本、以及包含请求修饰符、客户信息和内容的类似于MIME的消息结构。服务器以一个状态行作为响应，相应的内容包括消息协议的版本，成功或者错误编码加上包含服务器信息、实体元信息以及可能的实体内容。
         以上是抄来的，其实我不想讲，呵呵，但是普及下吧。

下面是我们这一篇中主讲的

HTTP响应头的管理

哪些是常用的HTTP响应头？

      看图：

                    总结来看，常用的HTTP头如下：

哪些头需要好好管理？

Cache-Control

这是个无比妙用的头，它可以让你的首页，从2MB，变成200KB。

没错，就是它。

我们先看看别人用了它之后，做到了啥。

减少了这么多，网站和用户双赢，靠的就是这个头。下面我将讲下具体如何用。

Last-Modify

这个头好用，那就用是了，为什么还要单独拿出来说？

是因为这个头，有个小的隐藏风险，见过很多人中标，我指出来，希望更多的人可以看到，之后避免。

很多网站，在更新网站或者发布网站临时维护信息时，会采用将老的文件，剪切到其他目录，然后本地再上传一个同名文件进行文件更新或者网站的页面更新。当更新的页面出问题或者维护结束他们使用正常页面给用户服务，会立刻把老的文件剪切回来，覆盖旧文件。

这就有一个非常大的问题。

因为对于已经访问过网站的人来说，他们已经把文件缓存到了本地。当用户再次访问网站时，会发送一个If-Modify-Since请求。

老文件  Last-Modified: 旧时间

新文件  Last-Modified: 新时间

当你用旧文件替换新文件后，由于新文件的最后修改时间要早于旧文件的，所以，IE不会让用户拿到没有问题的旧文件，而是让他们使用新文件。

所以，如果你使用用旧文件替代新文件，一定要对旧文件做个小的处理，使其更新最后修改时间，不然，用户依然会访问出问题的页面或者是维护页面。

如何用好Cache-Control？

当你不想让用户缓存时，你只需要添加一个头，no-store即可，其他no-cache、must、must-revalidate、proxy-revalidate等都没必要用，因为no-store一般默认为最高级。

其他可以让用户缓存的页面，区分目录，根据不同的目录，配置不同的max-age头。

max-age啥用处？

用户得到HTTP响应头后，会根据本地时间，加上max-age的时间，形成一个过期时间。例如，用户本次时间为11:00，max-age设置为600，那么文件拿到后，过期时间为11:10分。也就是这个用户，在11:10分以前，访问这个文件，就会直接缓存命中，而不会对服务器发出请求。

所以，max-age的运用就可以让你的网站像那四大门户一样，大小减少到原来的10分之一，请求数也会短期内得到巨大的减少。

如何设置Cache-Control？

如何设置百度娘之。

管理上的建议：

你不可能针对每个文件配置Cache-Control，所以，最好是先拆分域名，将不同应用（文件类一个域名，图片类一个域名等等）配置不同的缓存控制头。

如果你的网站属于大中型网站，如网页访问带宽在100M以上的，可能针对域名配置不同缓存控制头，已经不能满足你的需求了，这个时候，就可以管理好你的目录。

将文件根据你们网站特点分到不同目录，然后针对目录，配置不同的缓存控制头。

max-age设置多大？

以下提出的均为建议值，但是最适合你的，是你自己根据网站特点进行的缓存时间配置。

首页，建议为900，也就是15分钟。

文本类文件，建议为10800，也就是3小时。

图片类文件，建议为86400，也就是24小时。

Swf类文件，建议为604800，也就是7天。

flv、exe类文件，建议为31536000，也就是1年。

作者：王康

文章来源：xmw2.blog.chinaunix.net