IIS 6.0下HTTP压缩的工作原理

      IIS下HTTP的压缩的性能在前篇文章已经分析过了,虽然说会占用额外的CPU和内存的资源,但是被压缩的文件很小,返回到客户端所需的时间也更少,客户明显察觉网站速度会变快。这篇日志中介绍一下IIS下HTTP压缩的工作原理,翻译自微软官方网站的一篇文章里面的一段,原文是Using HTTP Compression for Faster Downloads
      当IIS收到一个请求的时候,它会客户端发过来的头部信息中检测客户端的浏览器是否支持压缩(现在一般的浏览器都支持压缩,在头部信息会有:"Accept-Encoding: gzip, deflate."这个语句)。IIS再去确定这个请求请求的是静态页面还是动态页面。
      如果请求的是静态页面,IIS会去检查该文件是不是已经被访问过,是否已经存在在保存压缩的临时文件夹中,如果在临时文件夹中没有找到,IIS会给客户端 发送没有压缩的文件,后台的进程同时会给该文件生成一个压缩版本,然后存放在临时文件夹中,当后续的请求请求该文件的时候,IIS直接发送存放在临时文件夹下 的已经压缩的文件。换句话说,当请求的文件已经存在在临时文件夹的情况下IIS才会发送压缩的文件给客户群,否则会返回没有压缩的文件给客户端。
      如果请求的文件是动态的文件,IIS会生成该文件,然后压缩,再发送给客户端。IIS不会把动态文件的压缩存放在临时文件夹下。
      对静态文件压缩的性能消耗是比较低的,并且也只要生成一次,以后的请求都是从临时文件夹中直接读取。对动态文件的压缩比静态文件压缩更消耗性能,因为动态 文件的压缩不会存放在临时目录下,每次的请求都要生成并压缩。当对带宽不充裕的客户端来说,压缩会减小文件的体积,网页加载的速度会快很多。
      当我们启用了HTTP压缩功能,生成的压缩文件的默认的过期时间是1997年的1月1日,这样的设置是为了防止代理服务器返回压缩的文件给那些不支持压缩 的客户端。过期时间的设置同时也强制浏览器去服务器请求最新的文件(该文件以前被浏览器请求过),并不是去(浏览器自己的)缓存中读取。