原理簡介
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大小,若是請求資源小於這個數值,則不會啓用壓縮。