我們觀察news.163.com的頭資訊
請求:accept-encoding:gzip,deflate,sdch
響應:content-encoding:gzip
content-length:36093
再把頁面另存下來,觀察,約10w位元組,實際傳輸的36093位元組
原因-------就在於gzip壓縮上.
原理:瀏覽器---請求----> 宣告可以接受 gzip壓縮 或 deflate壓縮 或compress 或 sdch壓縮
從http協議的角度看--請求頭 宣告 acceopt-encoding: gzip deflate sdch (是指壓縮演算法,其中sdch是google倡導的一種壓縮方式,目前支援的伺服器尚不多)
伺服器-->回應---把內容用gzip方式壓縮---->發給瀏覽器
瀏覽推算一下節省的頻寬:
假設 news.163.com pv 2億
2*10^8 * 9*10^4 位元組 ==
2*10^8 * 9 * 10^4 * 10^-9 = 12*k*g = 18t
節省的頻寬是非常驚人的
gzip配置的常用引數
gzip on|off; #是否開啟gzip
gzip_buffers 32 4k| 16 8k #緩衝(壓縮在記憶體中緩衝幾塊? 每塊多大?)
gzip_comp_level [1-9] #推薦6 壓縮級別(級別越高,壓的越小,越浪費cpu計算資源)
gzip_disable #正則匹配ua 什麼樣的uri不進行gzip
gzip_min_length 200 # 開始壓縮的最小長度(再小就不要壓縮了,意義不在)
gzip_http_version 1.0|1.1 # 開始壓縮的http協議版本(可以不設定,目前幾乎全是1.1協議)
gzip_proxied # 設定請求者**伺服器,該如何快取內容
gzip_vary on|off # 是否傳輸gzip壓縮標誌
/***這樣的二進位制檔案,不必壓縮
因為壓縮率比較小, 比如100->80位元組,而且壓縮也是耗費cpu資源的.
比較小的檔案不必壓縮
對於**的,尤其是新聞站, 一旦發布, 改動的可能是非常小的.我們希望 能否在使用者訪問一次後, 快取在使用者的瀏覽器端,且時間比較長的快取.
可以, 用到 nginx的expires設定 .
nginx中設定過期時間,非常簡單,
在location或if段裡,來寫.
格式 expires 30s;
expires 30m;
expires 2h;
expires 30d;
.例子：快取30天，js/css快取12小時
(注意:伺服器的日期要準確,如果伺服器的日期落後於實際日期,可能導致快取失效)
另: 304 也是一種很好的快取手段
原理是: 伺服器響應檔案內容是,同時響應etag標籤(內容的簽名,內容一變,他也變), 和 last_modified_since 2個標籤值
瀏覽器下次去請求時,頭資訊傳送這兩個標籤, 伺服器檢測檔案有沒有發生變化,如無,直接頭資訊返回 etag,last_modified_since
瀏覽器知道內容無改變,於是直接呼叫本地快取.
這個過程,也請求了伺服器,但是傳著的內容極少.
對於變化週期較短的,如靜態html,js,css,比較適於用這個方式
nginx配置檔案的gzip壓縮
借鑑了 先把效果圖上來吧 優化後 優化前 對比之後可以明顯的發現配置了gzip後瀏覽器請求的檔案大小小了很多。請求速度也得到了很大的優化 我這裡使用內網穿透工具頻寬只有128k nginx配置gzip gzip on 開啟gzip gzip vary on gzip min length 1k 不壓...
nginx配置gzip壓縮
一 配置引數的詳細介紹 二 大眾的引數配置如下 開啟gzip壓縮 gzip on http的協議版本 ie版本1 6不支援gzip壓縮，關閉 gzip disable msie 1 6 需要壓縮的檔案格式 text html缺省會壓縮，不用新增 設定壓縮緩衝區大小，此處設定為4個8k記憶體作為壓縮結...
nginx配置gzip壓縮
服務端給客戶端響應時若啟用壓縮功能，可以減少傳輸時所需的頻寬，大大提高響應速度。如上圖所示，nginx在把響應報文傳送到客戶端之前，可以對靜態資源檔案進行壓縮，這樣傳輸檔案的大小變得很小，傳輸速度會大幅度提高，之後瀏覽器再進行解壓，得到所請求的靜態資源。先直接上配置檔案吧，具體配置如下所示 可以看到...