最近作了個項目,遇到這麼一個問題:服務器返回給客戶端的json數據量太大(大概65M),在客戶端加載了1分多鐘才渲染完畢(固然這加載時間也和本地的下行帶寬有關),費時耗流量,用戶體驗極其很差。後來網上搜優化的方法,就是Http壓縮。javascript
HTTP壓縮能夠大大提升瀏覽網站的速度,它的原理是,在客戶端請求服務器對應資源後,從服務器端將資源文件壓縮,再輸出到客戶端,由客戶端的瀏覽器負責解壓縮並瀏覽。即:經過減少HTTP響應大小來減小響應時間。相對於普通的瀏覽過程HTML ,CSS,Javascript , Text ,它能夠節省40%左右的流量。更爲重要的是,它能夠對動態生成的,包括CGI、PHP , JSP , ASP , Servlet,SHTML等輸出的網頁也能進行壓縮,壓縮效率也很高。而GZIP自己就是一種網絡流壓縮算法,並且應用至關普遍。本文是針對apache tomcat 8.0.47進行配置GZIP壓縮的。瀏覽器使用Mozilla Firefox 35.0.1,調試用自帶的Firebug,如下和網絡有關的截圖來自Firebug控制檯。css
1. HTTP 協議支持GZIP 壓縮機制,也稱協議壓縮。 HTTP GZIP壓縮是由WEB服務器和瀏覽器共同遵照的協議,也就是說WEB服務器和瀏覽器都必須遵照。目前主流的服務器和瀏覽器都支持GZIP壓縮技術。包括 Chrome、IE、FireFox、Opera 等;服務器有 tomcat、Apache 和 IIS 等。html
2. GZIP 主要用來壓縮html,css,javascript,等靜態文本文件,也支持對動態生成的,包括CGI、PHP , JSP , ASP , Servlet,SHTML等輸出的網頁也能進行壓縮。java
3. GZIP 壓縮的比率一般在3~10 倍之間,這樣能夠大大節省服務器的網絡帶寬,大大提高瀏覽器的瀏覽速度。程序員
4. GZIP 是一種數據壓縮格式,默認且目前僅使用deflate算法壓縮data部分;deflate是一種壓縮算法,是huffman編碼的一種增強。正則表達式
5. 協議壓縮就是依據HTTP協議進行壓縮,不須要程序員進行壓縮,解壓編碼,而是把壓縮過程交給WEB服務器,將解壓過程交給客戶端。 若是客戶端爲支持GZIP壓縮的瀏覽器,那麼解壓過程也不須要程序員參與,瀏覽器會按照必定的規則自動進行解壓縮;若是客戶端爲HttpClient ,那麼就須要手動進行GZIP解碼了。算法
6. 壓縮過程:客戶端發送http請求,若是請求頭header中攜帶Accept-Encoding: gzip,deflate (如今的瀏覽器通常默認都是這樣),那麼瀏覽器的意思是:服務器須要進行GZIP壓縮,再看響應內容的類型是否知足服務器配置的須要壓縮的類型,若是符合,那麼WEB服務器在傳輸響應內容以前,會對響應內容進行壓縮,並在響應頭中添加Content-Encoding gzip;若是不符合,那麼將不壓縮,直接返回。apache
7. 解壓過程:(瀏覽器)客戶端接收到響應,若是響應頭中包含Content-Encoding GZIP,那麼瀏覽器會自動將響應內容進行GZIP解壓縮,而後再呈如今頁面上。若是不包含,那麼將直接呈如今頁面上。json
8.GZIP的缺點。相對於沒有進行GZIP的工程來講,使用GZIP要增長服務器壓縮的壓力(cpu消耗)、客戶端解壓縮的壓力,故而對服務器的配置需求更高。另外壓縮也要耗費時間,想佔用更小的空間,獲得高壓縮比率,確定要犧牲較長的時間;反之,若是時間較爲寶貴,要求快速,那麼所得的壓縮比率必定較小,固然會佔用更大的空間了(壓縮比率=原內容大小/壓縮後大小,壓縮比率越大,則代表壓縮後佔用空間的壓縮包越小),這就是物理空間與時間的矛盾。後端
版本要求:Tomcat5.0以上。 修改%TOMCAT_HOME%/conf/server.xml,修訂節點以下:
1 <Connector port="8080" 2 protocol="HTTP/1.1" 3 connectionTimeout="20000" 4 redirectPort="8443" 5 compression="on" 6 compressionMinSize="2048" 7 noCompressionUserAgents="gozilla, traviata" 8 compressableMimeType="text/html,text/xml,text/javascript, 9 application/javascript,text/css,text/plain,text/json"/>
參數說明:
一、compression="on" 開啓壓縮。可選值:"on"開啓,"off"關閉,"force"任何狀況都開啓。
二、compressionMinSize="2048"大於2KB的文件才進行壓縮。用於指定壓縮的最小數據大小,單位B,默認2048B。注意此值的大小,若是配置不合理,產生的後果是小文件壓縮後反而變大了,達不到預想的效果。
三、noCompressionUserAgents="gozilla, traviata",對於這兩種瀏覽器,不進行壓縮(我也不知道這兩種瀏覽器是啥,百度上沒找到),其值爲正則表達式,匹配的UA將不會被壓縮,默認空。
四、compressableMimeType="text/html,text/xml,application/javascript,text/css,text/plain,text/json"會被壓縮的MIME類型列表,多個逗號隔,代表支持html、xml、js、css、json等文件格式的壓縮(plain爲無格式的,但對於具體是什麼,我比較概念模糊)。compressableMimeType很重要,它用來告知tomcat要對哪種文件進行壓縮,若是類型指定錯誤了,確定是沒法壓縮的。那麼,如何知道要壓縮的文件類型呢?能夠經過如下這種方法找到。
修改完以後重啓下tomcat便可,最後去檢測網站:http://seo.chinaz.com/?host=iitshare.com 查詢下效果
可經過如下步驟排查:
一、tomcat中的配置參數寫錯位置了。注意配置參數應該寫到下圖中A區而不是B區,就是protocol="HTTP/1.1"那個Connector中。
二、響應數據不是compressableMimeType參數配置的類型。我就遇到了這個坑,咱們項目先後端傳輸用的是json。因此我最開始覺得是「text/json」,後來打開Firebug的控制檯,原來Content-Type的值是「application/json」。見圖三。
三、響應數據的大小小於compressionMinSize的配置值。
能夠看到 壓縮比率 = 65.6 / 8.4 = 7.810, 時間比率 = 96 / 16.2 = 5.926,已是很理想了。