tomcat服务器开启gzip功能的方法

814247614

　　http://blog.iyunv.com/wang_159369/article/details/8107163
　　
　　tomcat5.0以后的版本是支持对输出内容进行gzip格式的压缩的。该功能默认是关闭的，如果需要启用该功能，我们需要修改tomcat的配置文件server.xml，修改的方法是在server.xml的节点
　　处加上属性：  compression=”on”  ，即
　　下面是tomcat5.5.20 中的$tomcat_home$/conf/server.xml的原内容



1  < Connector port ="80" maxHttpHeaderSize ="8192"
2                 maxThreads ="150" minSpareThreads ="25" maxSpareThreads ="75"
3                 enableLookups ="false" redirectPort ="8443" acceptCount ="100"
4                 connectionTimeout ="20000" disableUploadTimeout ="true" URIEncoding ="utf-8" />
5  
7
8  
　　
　　从上面的第8行内容可以看出，要使用gzip压缩功能，你可以在Connector实例中加上如下属性即可
1) compression=”on” 打开压缩功能
2) compressionMinSize=”2048&Prime; 启用压缩的输出内容大小，这里面默认为2KB
3) noCompressionUserAgents=”gozilla, traviata” 对于以下的浏览器，不启用压缩
4)  compressableMimeType="text/html,text/xml,text/javascript,text/css,text/plain,image/png,image/jpg,image/gif"　压缩类型
　　对于某些文本文件比如：log、txt等文件，我们也可以让服务器采用gzip压缩传输，修改conf目录下web.xml，添加   
　　
         log
         text/plain

　　等，就可以指定压缩传输了。通常情况下，压缩传输能大幅度提高展示速度。
　　
　　Nginx和Tomcat同时启用GZIP的后果：
　　http://www.iteye.com/topic/1118087
　　
　　新部署的一台服务器在做了性能调优以后发现FCK在线编辑器IE、firefox都出现报错，只有chrome正常。百思不得其解，差点就把FCK换掉。经过千辛万苦终于找到了原因（本人找错误原因的运气一直都非常好）：
　　
　　开始以为是脚本乱码，看了文件头的那段注释以后确认不是这个问题。
　　
　　在firefox的firedebug上面看到的脚本一直报找不到对象的错误，难道是公司的网络龟速导致脚本加载顺序不协调所致？几次刷新以后问题还在，304状态码说明不是网络龟速的原因。
　　
　　最后把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压缩了，不然部分浏览器会下载到不完整的文件。