原理:

瀏覽器---請求----> 宣告可以接受 gzip壓縮 或 deflate壓縮 或compress 或 sdch壓縮

從http協議的角度看--請求頭 宣告 acceopt-encoding: gzip deflate sdch (是指壓縮演算法,其中sdch是google倡導的一種壓縮方式,目前支援的伺服器尚不多)

伺服器-->迴應---把內容用gzip方式壓縮---->發給瀏覽器

瀏覽<-----解碼gzip-----接收gzip壓縮內容----

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_types text/plain application/xml # 對哪些型別的檔案用壓縮 如txt,xml,html ,css

gzip_vary on|off  # 是否傳輸gzip壓縮標誌

注意:

圖片/mp3這樣的二進位制檔案,不必壓縮

因為壓縮率比較小, 比如100->80位元組,而且壓縮也是耗費CPU資源的.

比較小的檔案不必壓縮,

expires 快取時間設定

對於網站的圖片,尤其是新聞站, 圖片一旦釋出, 改動的可能是非常小的.我們希望 能否在使用者訪問一次後, 圖片快取在使用者的瀏覽器端,且時間比較長的快取.

可以, 用到 nginx的expires設定 .

nginx中設定過期時間,非常簡單,

在location或if段裡,來寫.

格式  expires 30s;

     expires 30m;

     expires 2h;

     expires 30d;

(注意:伺服器的日期要準確,如果伺服器的日期落後於實際日期,可能導致快取失效)

另: 304 也是一種很好的快取手段

原理是: 伺服器響應檔案內容是,同時響應etag標籤(內容的簽名,內容一變,他也變), 和 last_modified_since 2個標籤值

瀏覽器下次去請求時,頭資訊傳送這兩個標籤, 伺服器檢測檔案有沒有發生變化,如無,直接頭資訊返回 etag,last_modified_since

瀏覽器知道內容無改變,於是直接呼叫本地快取.

這個過程,也請求了伺服器,但是傳著的內容極少.

對於變化週期較短的,如靜態html,js,css,比較適於用這個方式