高性能网络开发(5)减少请求和响应的数据量

GZIP压缩gzip是目前所有浏览器都支持的压缩格式，IE6需要SP1及以上支持(且不说你还在用IE5，~_~)。Gzip可以说是最方便的，也是最大限度减少响应数据量的方法之一。说它方便，是因为你不需要为它编写任何额外的代码，只需要给http服务器添加配置就可以了，而且现在主流的http服务器都支持gzip，所以这里就不介绍各种服务器的配置了(其实我也不知道怎么搭配)。nginx的配置可以参考我的文章：www.blogjava.net/bearrui/archive/2010/01/29/web _ performance _ server . html我们先来看看gzip的压缩比。这里，我们使用jquery 1.4.2的min和src2版本进行测试。使用nginx服务器，gzip压缩级别为4:

请注意上面图片的红色部分，启用gzip后，jquery src文件的大小减少了70%。

从这张图可以看出，启用gzip后，即使是压缩的min.js，其大小也减少了65%。不要为图片启用gzip。如果你知道gzip强大的压缩能力，你想为服务器上的所有文件启用gzip吗？我们先来看看图片中启用gzip后会发生什么。

Hoho，gif图片压缩后会变大吗？这是因为图片是压缩格式，gzip不能再压缩了，但是会增加一些额外的头部信息，所以图片会变大。测试过程中发现，gzip压缩后的jpg图像会变小。不知道为什么，可能和图像压缩方法有关。但是压缩比比较小，所以即使是jpg，也建议不要开启gzip压缩。适合gzip压缩的文件如下：1。javascript 2。CSS 3。HTML，xml 4，纯文本，不要乱用cookies。现在几乎没有网站不使用cookie，但如何使用cookie更合适。Cookies有几个重要属性：path(路径)、domain(域)和expires(过期时间)。根据这三个属性，浏览器判断发送请求时是否需要带这个cookie。使用cookie的最好方法是在请求的资源需要时带上cookie。其他请求不附带cookie。但其实很多人在使用cookie的时候，已经习惯性的设置为：path=/domain=.domain.com，结果就是任何请求都会带来cookie，即使你是被请求的镜像(img.domain.com)、静态资源服务器(res.domain.com)，这些根本不需要cookie的，浏览器还是会带来这些无用的cookie。我们来看看现实中的一个列表，Blog Park (www.cnblogs.com):我们先来看看Blog Park中的cookies是如何设置的。这是火狐在博客公园查看cookies的截图：。

Cnblogs总共有5个cookie值，所有设置都是path=/domain=.cnblogs.com.了解cookie设置后，我们将监控博客公园主页的请求。监控的统计数据如下：请求总数：39(包括22张图片、7个js和2个css2)。其中，js、css和image主要来自三个静态资源服务器：common.cnblogs.com和pic.cnblogs.com。Static.cnblogs.com查看了请求图片之一的请求头(/upload/201005/20100514004349115 . gif):hoststatic.cnblogs.com用户代理Mozilla/5.0(windows；u；Windows NT 5.2美国；RV :1 . 9 . 2 . 3)Gecko/20100401 Firefox/3 . 6 . 3 GTBDFff gtb 7.0接受image/png，image/*；q=0.8，*/*；q=0.5Accept-Language zh-cn，en-us；q=0.7，en；q=0.3Accept-Encoding gzip，通缩Accept-Charset ISO-8859-1，utf-8；q=0.7，*；q=0.7 keep-Alive 115 proxy-Connection keep-Alive ferer http://www.cnblogs.com/Cookie _ _ gads=ID=a15d 7 CB 5c 3413 e 56:t=1272278620:s=ALNI _ MZNMr6 _ d _ pcjgkjnjeeqxkmz3 bxtq；_ _ utma=226521935 . 1697566422 . 127227278366 . 1。_ _ utmb=226521935 . 2 . 10 . 1272278366_ _ utmc=226521935_ _ utmz=226521935 . 1272278367 . 1 . 1 . utmcsr=(direct)| utmccn=(direct)| utmcmd=(none)我们发现，在请求图片banner_job.gif时，浏览器带来了所有来自cnblogs.com的cookie(对其他图片的请求是一样的。也许你认为这些cookie的大小只有300字节左右，所以没关系。让我们做一个简单的计算。我们假设每天有50W个PV(实际情况应该不止这些)，每个PV大概有15个静态资源请求，15*500000*300/1024/1024=2145M。也就是说，这些cookie每天大概会消耗掉博客园区的2G带宽。当然，这种简单的计算方法必然有失偏颇。毕竟，我们还没有考虑静态资源缓存。但我个人认为，如果把cookie的域设置在博客公园的www.cnblogs.com会更好。大家都很清楚，在精彩的204状态http中使用200，404，500个状态，但是204状态可能用得比较少。204状态意味着服务器成功处理了客户端请求，但是服务器没有返回内容。204是HTTP中数据量最少的响应状态，204的响应中没有正文，Content-Length=0。当许多人使用ajax向服务器提交一些数据而服务器没有返回时，他们经常在服务器上使用以下代码：response.getWriter()。print(')，返回一个空白页，是一个200的请求。它仍然有一个正文，内容长度将不等于0。实际上，此时您可以直接返回到204状态(response.setStatus(204))。204是一些web分析代码中最常用的，只需要从客户端向服务器提交一些信息。让我们看看谷歌主页上的一个204回复。谷歌主页上的最后一个请求返回204的状态，但是我猜不出这个请求是为了什么：。

【声明】请注明来源于：http://www.blogjava.net/BearRui/.禁止商业使用！