GZIP压缩原理分析（08）——第四章 基于gzip的HTTP压缩详解（四02） 原理

经过压缩的HTTP应答报文是由浏览器解压的，用wireshark抓包可以看到客户端主机接收到的HTTP应答报文仍然是压缩的，而且wireshark可以将该HTTP应答解压（是否让wireshark解压是可以设置的，兹不赘述）。比起压缩，解压的速度是非常快的（只要数据正常，可以解压的话），所以不用担心浏览器用于解压的时间会降低用户体验。事实上，浏览器解压消耗的这点时间比起数据包因为网络拥堵而耽误的时间要少的多也可控的多。

在浏览器发给服务器的HTTP请求报文中，使用Accept-Encoding字段标明自己支持的压缩格式，即自己可以解压哪几种压缩报文（gzip、zlib库提供的deflate）。服务器回复客户端的HTTP应答报文中，使用Content-Encoding字段标明该应答报文使用哪种压缩方式。如下图所示，

必须要说明的是，这里有些地方，实际的实现方式和RFC文档中提到的方式并不相同。《HTTP权威指南》第370页明确说明Accept-Encoding字段支持Q值，而且说“如果HTTP请求没有包含Accept-Encoding首部，服务器就可以假设客户端能够接受任何编码方式”。可现实是，对于一般大型网站，比如百度、新浪、腾讯等，只有客户端HTTP请求带着Accept-Encoding字段，对应的HTTP应答才会将HTTP应答数据压缩（而且有的网站根本不关心客户端支持哪种压缩格式，只判断有没有这个首部，如果有，就统一用gzip压），如果不带这个字段，服务器发来的HTTP应答数据就是未经过压缩的（显然服务器并没有默认客户端能够接收任何编码方式）！！！而且服务器“根本不识别Q值”！！！发送一个带着Q值的HTTP请求报文，得到的结果却并没有按照Q值的规则来！！！更可气的是，我原以为只有国内的网站这么做，后来测试了下国外网站，发现都是这样。对于一些特别细节的地方，比如对某些异常的处理（e.g.请求报文中Accept-Encoding字段只有该首部而没有对应的内容，就像这个样子“Accept-Encoding： ”而不是“Accept-Encoding： gzip, deflate”），不同的网站具体的处理方式也是不同的，这里不再赘述，想要分析，直接抓包即可。关于Q值的问题，因为现网处理非常简单粗暴，因此这里也不再赘述，只要大家知道现网是这么干的就够，这里就不贴图了，想实践直接抓包就行。