原理简介
HTTP 压缩能够大大提升浏览网站的速度,它的原理是,在客户端请求服务器对应资源后,从服务器端将资源文件压缩,再输出到客户端,由客户端的浏览器负责解压缩并浏览。相对于普通的浏览过程HTML ,CSS,Javascript , Text ,它能够节省40%左右的流量。更为重要的是,它能够对动态生成的,包括CGI、PHP , JSP , ASP , Servlet,SHTML等输出的网页也能进行压缩,压缩效率也很高。
配置方法
Tomcat5.0之后的版本是支持对输出内容进行压缩的,使用的是gzip压缩格式 。
修改%TOMCAT_HOME%/conf/server.xml,修订节点以下:
- <Connector port="80" protocol="HTTP/1.1"
- connectionTimeout="20000"
- redirectPort="8443" executor="tomcatThreadPool" URIEncoding="utf-8"
- compression="on"
- compressionMinSize="50" noCompressionUserAgents="gozilla, traviata"
- compressableMimeType="text/html,text/xml,text/javascript,text/css,text/plain" />
从上面节点的属性能够看出,要使用gzip压缩功能,你须要在Connector节点中加上以下属性
- compression="on" 打开压缩功能
- compressionMinSize="50" 启用压缩的输出内容大小,默认为2KB
- noCompressionUserAgents="gozilla, traviata" 对于如下的浏览器,不启用压缩
- compressableMimeType="text/html,text/xml,text/javascript,text/css,text/plain" 哪些资源类型须要压缩
对于某些文本文件好比:log、txt等文件,咱们也可让服务器采用gzip压缩传输,修改conf目录下web.xml,添加 javascript
<mime-mapping>
<extension>log</extension>
<mime-type>text/plain</mime-type>
</mime-mapping>css
等,就能够指定压缩传输了。一般状况下,压缩传输能大幅度提升展现速度。html
Nginx和Tomcat同时启用GZIP的后果:前端
http://www.iteye.com/topic/1118087java
新部署的一台服务器在作了性能调优之后发现FCK在线编辑器IE、firefox都出现报错,只有chrome正常。百思不得其解,差点就把FCK换掉。通过千辛万苦终于找到了缘由(本人找错误缘由的运气一直都很是好):nginx
开始觉得是脚本乱码,看了文件头的那段注释之后确认不是这个问题。web
在firefox的firedebug上面看到的脚本一直报找不到对象的错误,难道是公司的网络龟速致使脚本加载顺序不协调所致?几回刷新之后问题还在,304状态码说明不是网络龟速的缘由。chrome
最后把FCK的javascript脚本下载到本地之后一看
,只有20k左右,而完整的是249K,看来我找到缘由了~~后端
仍是百思不得其解,好好的静态脚本文件为何会下载了一部分就完了呢?并且首次下载的状态码是200,以后的刷新都是304,这违反了我对HTTP状态码的理解。浏览器
撇开前端的Nginx,直接访问tomcat竟然页面就正常了。so~问题在nginx。nginx处理静态资源的能力历来都没有怀疑过(这再次违反了我对XXX的理解)。
灵光一闪,先后端的服务器最近都进行了调优,难道是此次修改了 配置文件致使的?so首先关闭nginx的gzip off;,重启Nginx后全世界正常了。随后关闭后端tomcat的compression="off",从新启用Nginx的gzip,问题终于解 决了。
总结:多层服务器结构的系统启用gzip压缩要注意一个问题:前端服务器启用了gzip之后,后端的服务器就不要启用gzip压缩了,否则部分浏览器会下载到不完整的文件。
测试方法
启用了TOMCAT这个压缩功能后,咱们如何来测试压缩是否有效呢?
首先Tomcat是根据浏览器请求头中的accept-encoding来判断浏览器是否支持压缩功能,若是这个值包含有gzip,就代表浏览器支持gzip压缩内容的浏览,咱们能够用两种方法来验证压缩是否生效。
经过浏览器直接请求
你们直接经过浏览器访问启用了压缩配置的服务器,而后经过抓包工具查看抓到的数据包,若是内容有不少你看不懂,就说明已经启用压缩功能了。
经过程序模拟请求
咱们用httpclient写一个简单的测试程序,代码以下:
- @Test
- public void testGzip() {
- HttpClient httpClient = new HttpClient();
- GetMethod getMethod = new GetMethod("http://localhost/admin.jsp");
- try {
- getMethod.addRequestHeader("accept-encoding", "gzip,deflate");
- getMethod.addRequestHeader("user-agent","Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0; Alexa Toolbar; Maxthon 2.0)");
- int result = httpClient.executeMethod(getMethod);
- if (result == 200) {
- System.out.println(getMethod.getResponseContentLength());
- String html = getMethod.getResponseBodyAsString();
- System.out.println(html);
- System.out.println(html.getBytes().length);
- }
- } catch (HttpException e) {
- e.printStackTrace();
- } catch (IOException e) {
- e.printStackTrace();
- } finally {
- getMethod.releaseConnection();
- }
- }
执行这个junit程序,看看它所输出的是什么内容,若是输出的是一些乱码,而且打印内容的长度远小于实际的长度,就说明咱们的配置生效了,经过一些其它验证工具,会发现网站浏览速度会明显提高。
备注:若是发现内容没有被压缩,能够考虑调整compressionMinSize大小,若是请求资源小于这个数值,则不会启用压缩。