http://blog.csdn.net/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 78
从上面的第8行内容可以看出，要使用gzip压缩功能，你可以在Connector实例中加上如下属性即可
1) compression=”on” 打开压缩功能 2) compressionMinSize=”2048″ 启用压缩的输出内容大小，这里面默认为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，添加
<mime-mapping>
<extension>log</extension> <mime-type>text/plain</mime-type> </mime-mapping>等，就可以指定压缩传输了。通常情况下，压缩传输能大幅度提高展示速度。
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压缩了，不然部分浏览器会下载到不完整的文件。