十分鐘能看清-HTTP詳解-請求、響應、緩存

. HTTP請求格式

做過Socket編程的人都知道，當我們設計一個通信協議時，“消息頭/消息體”的分割方式是很常用的，消息頭告訴對方這個消息是干什么的，消息體告訴對方怎么干。HTTP協議傳輸的消息也是這樣規定的，每一個HTTP包都分為HTTP頭和HTTP體兩部分，消息體是可選的，而消息頭是必須的。每當我們打開一個網頁，在上面點擊右鍵，選擇“查看源文件”，這時看到的HTML代碼就是HTTP的消息體，那么消息頭可以通過瀏覽器的開發工具或者插件可以看到，如果火狐的Firebug，IE的Httpwatch。

客戶端通過發送 HTTP 請求向服務器請求對資源的訪問。它向服務器傳遞了一個數據塊，也就是請求信息，HTTP 請求由三部分組成：請求行、請求頭和請求正文。

請求行：請求方法 URI 協議/版本

請求頭(Request Header)

請求正文

下面是一個HTTP請求的數據：

POST /index.php HTTP/1.1

Host: localhost

User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:10.0.2) Gecko/20100101 Firefox/10.0.2

Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8

Accept-Language: zh-cn,zh;q=0.5

Accept-Encoding: gzip, deflate

Connection: keep-alive

Referer: http://localhost/

Content-Length：25

Content-Type：application/x-www-form-urlencoded

username=aa&password=1234

1、請求行：請求方法URI協議/版本

請求的第一行是“方法 URL 協議/版本”，并以回車換行作為結尾。請求行以空格分隔。格式如下：

POST /index.php HTTP/1.1

以上代碼中“GET”代表請求方法，“//ndex.php”表示URI，“HTTP/1.1代表協議和協議的版本。

根據HTTP標準，HTTP請求可以使用多種請求方法。例如：HTTP1.1支持7種請求方法：GET、POST、HEAD、OPTIONS、PUT、DELETE和TARCE。在Internet應用中，最常用的方法是GET和POST。

URL完整地指定了要訪問的網絡資源，通常只要給出相對于服務器的根目錄的相對目錄即可，因此總是以“/”開頭，最后，協議版本聲明了通信過程中使用HTTP的版本。

請求方法

在 HTTP 協議中，HTTP 請求可以使用多種請求方法，這些方法指明了要以何種方式來訪問 Request-URI 所標識的資源。HTTP1.1 支持的請求方法如下表所示：

HTTP1.1 中的請求方式：

方法

作用

GET

請求獲取由 Request-URI 所標識的資源

POST

請求服務器接收在請求中封裝的實體，并將其作為由 Request-Line 中的 Request-URI 所標識的資源的一部分

HEAD

請求獲取由 Request-URI 所標識的資源的響應消息報頭

PUT

請求服務器存儲一個資源，并用 Request-URI 作為其標識符

DELETE

請求服務器刪除由 Request-URI 所標識的資源

TRACE

請求服務器回送到的請求信息，主要用于測試或診斷

CONNECT

保留將來使用

OPTIONS

請求查詢服務器的性能，或者查詢與資源相關的選項和需求

重點介紹 GET、POST 和 HEAD 三個方法：

（1）GET

GET 方法用于獲取由 Request-URI 所標識的資源的信息，常見的形式是：

GET Request-URI HTTP/1.1

GET方法是默認的HTTP請求方法，例如當我們通過在瀏覽器的地址欄中直接輸入網址的方式去訪問網頁的時候，瀏覽器采用的就是 GET 方法向服務器獲取資源。

我們可以使用GET方法來提交表單數據，用GET方法提交的表單數據只經過了簡單的編碼，同時它將作為URL的一部分向服務器發送，因此，如果使用GET方法來提交表單數據就存在著安全隱患上。例如：

Http://localhost/login.php?username=aa&password=1234

從上面的URL請求中，很容易就可以辯認出表單提交的內容。（？之后的內容）另外由于GET方法提交的數據是作為URL請求的一部分所以提交的數據量不能太大。這是因為瀏覽器對url的長度有限制

各種瀏覽器也會對url的長度有所限制，下面是幾種常見瀏覽器的url長度限制:(單位:字符)

IE : 2803

Firefox:65536

Chrome:8182

Safari:80000

Opera:190000

（2）POST

POST方法是GET方法的一個替代方法，它主要是向Web服務器提交表單數據，尤其是大批量的數據。在請求頭信息結束之后的兩個回車換行之后（實際是空一行），就是表單提交的數據。如上面提到的post表單數據：

username=aa&password=1234

POST方法克服了GET方法的一些缺點。通過POST方法提交表單數據時，數據不是作為URL請求的一部分而是作為標準數據傳送給Web服務器，這就克服了GET方法中的信息無法保密和數據量太小的缺點。因此，出于安全的考慮以及對用戶隱私的尊重，通常表單提交時采用POST方法。

　從編程的角度來講，如果用戶通過GET方法提交數據，則數據存放在QUERY＿STRING環境變量中，而POST方法提交的數據則可以從標準輸入流中獲取。

GET與POST方法有以下區別：

1、在客戶端，Get方式在通過URL提交數據，數據在URL中可以看到；POST方式，數據放在HTTP包的body中。

2、 GET方式提交的數據大小有限制（因為瀏覽器對URL的長度有限制），而POST則沒有此限制。

3、安全性問題。正如在（1）中提到，使用 Get 的時候，參數會顯示在地址欄上，而 Post 不會。所以，如果這些數據是中文數據而且是非敏感數據，那么使用 get；如果用戶輸入的數據不是中文字符而且包含敏感數據，那么還是使用 post為好。

4.、服務器取值方式不一樣。GET方式取值，如php可以使用$_GET來取得變量的值，而POST方式通過$_POST來獲取變量的值。

（3）HEAD

HEAD 方法與 GET 方法幾乎是相同的，它們的區別在于 HEAD 方法只是請求消息報頭，而不是完整的內容。對于 HEAD 請求的回應部分來說，它的 HTTP 頭部中包含的信息與通過 GET 請求所得到的信息是相同的。利用這個方法，不必傳輸整個資源內容，就可以得到 Request-URI 所標識的資源的信息。這個方法通常被用于測試超鏈接的有效性，是否可以訪問，以及最近是否更新。

要注意的是，在 HTML 文檔中，書寫 get 和 post，大小寫都可以，但在 HTTP 協議中的 GET 和 POST 只能是大寫形式。

2. 請求頭

每個頭域由一個域名，冒號（:）和域值三部分組成。域名是大小寫無關的，域值前可以添加任何數量的空格符，頭域可以被擴展為多行，在每行開始處，使用至少一個空格或制表符。

HTTP最常見的請求頭如下：

Transport 頭域

Connection：

作用：表示是否需要持久連接。

如果服務器看到這里的值為“Keep-Alive”，或者看到請求使用的是HTTP 1.1（HTTP 1.1默認進行持久連接）,它就可以利用持久連接的優點，當頁面包含多個元素時（例如Applet，圖片），顯著地減少下載所需要的時間。要實現這一點，服務器需要在應答中發送一個Content-Length頭，最簡單的實現方法是：先把內容寫入 ByteArrayOutputStream，然后在正式寫出內容之前計算它的大小；

例如：　Connection: keep-alive 當一個網頁打開完成后，客戶端和服務器之間用于傳輸HTTP數據的TCP連接不會關閉，如果客戶端再次訪問這個服務器上的網頁，會繼續使用這一條已經建立的連接

例如： Connection: close 代表一個Request完成后，客戶端和服務器之間用于傳輸HTTP數據的TCP連接會關閉，當客戶端再次發送Request，需要重新建立TCP連接。

Host（發送請求時，該報頭域是必需的）

Host請求報頭域主要用于指定被請求資源的Internet主機和端口號，它通常從HTTP URL中提取出來的。

eg：http://；localhost/index.html

瀏覽器發送的請求消息中，就會包含Host請求報頭域，如下：

Host：localhost

此處使用缺省端口號80，若指定了端口號8080，則變成：Host：localhost:8080

Client 頭域

Accept：

作用：瀏覽器可以接受的媒體類型（MIME類型）,

例如： Accept: text/html 代表瀏覽器可以接受服務器回發的類型為 text/html 也就是我們常說的html文檔, 如果服務器無法返回text/html類型的數據，服務器應該返回一個406錯誤(non acceptable)。

通配符 * 代表任意類型。例如 Accept: */* 代表瀏覽器可以處理所有類型，(一般瀏覽器發給服務器都是發這個)

Accept-Encoding：

作用：瀏覽器申明自己接收的編碼方法，通常指定壓縮方法，是否支持壓縮，支持什么壓縮方法（gzip，deflate），（注意：這不是只字符編碼）;

例如： Accept-Encoding: gzip, deflate。Server能夠向支持gzip/deflate的瀏覽器返回經gzip或者deflate編碼的HTML頁面。許多情形下這可以減少5到10倍的下載時間，也節省帶寬。

Accept-Language：

作用：瀏覽器申明自己接收的語言。

語言跟字符集的區別：中文是語言，中文有多種字符集，比如big5，gb2312，gbk等等；

例如： Accept-Language:zh-cn 。如果請求消息中沒有設置這個報頭域，服務器假定客戶端對各種語言都可以接受。

User-Agent：

作用：告訴HTTP服務器，客戶端使用的操作系統和瀏覽器的名稱和版本.

我們上網登陸論壇的時候，往往會看到一些歡迎信息，其中列出了你的操作系統的名稱和版本，你所使用的瀏覽器的名稱和版本，這往往讓很多人感到很神奇，實際上，服務器應用程序就是從User-Agent這個請求報頭域中獲取到這些信息User-Agent請求報頭域允許客戶端將它的操作系統、瀏覽器和其它屬性告訴服務器。

例如： User-Agent: Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 5.1; Trident/4.0; CIBA; .NET CLR 2.0.50727; .NET CLR 3.0.4506.2152; .NET CLR 3.5.30729; .NET4.0C; InfoPath.2; .NET4.0E)

Accept-Charset：

作用：瀏覽器申明自己接收的字符集，這就是本文前面介紹的各種字符集和字符編碼，如gb2312，utf-8（通常我們說Charset包括了相應的字符編碼方案）；

例如：Accept-Charset:iso-8859-1,gb2312.如果在請求消息中沒有設置這個域，缺省是任何字符集都可以接受。

Authorization：授權信息，通常出現在對服務器發送的WWW-Authenticate頭的應答中；

Authorization請求報頭域主要用于證明客戶端有權查看某個資源。當瀏覽器訪問一個頁面時，如果收到服務器的響應代碼為401（未授權），可以發送一個包含Authorization請求報頭域的請求，要求服務器對其進行驗證。

Cookie/Login 頭域

Cookie:

作用：最重要的header, 將cookie的值發送給HTTP 服務器

Entity頭域

Content-Length

作用：發送給HTTP服務器數據的長度。即請求消息正文的長度；

例如： Content-Length: 38

Content-Type：

作用：

例如：Content-Type: application/x-www-form-urlencoded

Miscellaneous 頭域

Referer:

作用：提供了Request的上下文信息的服務器，告訴服務器我是從哪個鏈接過來的，比如從我主頁上鏈接到一個朋友那里，他的服務器就能夠從HTTP Referer中統計出每天有多少用戶點擊我主頁上的鏈接訪問他的網站。

例如: Referer:http://translate.google.cn/?hl=zh-cn&tab=wT

Cache 頭域

If-Modified-Since：

作用：把瀏覽器端緩存頁面的最后修改時間發送到服務器去，服務器會把這個時間與服務器上實際文件的最后修改時間進行對比。如果時間一致，那么返回304，客戶端就直接使用本地緩存文件。如果時間不一致，就會返回200和新的文件內容。客戶端接到之后，會丟棄舊文件，把新文件緩存起來，并顯示在瀏覽器中。

例如：If-Modified-Since: Thu, 09 Feb 2012 09:07:57 GMT。

If-None-Match：

作用: If-None-Match和ETag一起工作，工作原理是在HTTP Response中添加ETag信息。當用戶再次請求該資源時，將在HTTP Request 中加入If-None-Match信息(ETag的值)。如果服務器驗證資源的ETag沒有改變（該資源沒有更新），將返回一個304狀態告訴客戶端使用本地緩存文件。否則將返回200狀態和新的資源和Etag. 使用這樣的機制將提高網站的性能

例如: If-None-Match: "03f2b33c0bfcc1:0"

Pragma：

作用：防止頁面被緩存，在HTTP/1.1版本中，它和Cache-Control:no-cache作用一模一樣

Pargma只有一個用法，例如： Pragma: no-cache

注意: 在HTTP/1.0版本中，只實現了Pragema:no-cache, 沒有實現Cache-Control

Cache-Control：

作用: 這個是非常重要的規則。這個用來指定Response-Request遵循的緩存機制。各個指令含義如下

Cache-Control:Public 可以被任何緩存所緩存（）

Cache-Control:Private 內容只緩存到私有緩存中

Cache-Control:no-cache 所有內容都不會被緩存

2. HTTP響應格式

在接收和解釋請求消息后，服務器會返回一個 HTTP 響應消息。與 HTTP 請求類似，HTTP 響應也是由三個部分組成，分別是：狀態行、消息報頭和響應正文。如：

HTTP/1.1 200 OK

Date: Sun, 17 Mar 2013 08:12:54 GMT

Server: Apache/2.2.8 (Win32) PHP/5.2.5

X-Powered-By: PHP/5.2.5

Set-Cookie: PHPSESSID=c0huq7pdkmm5gg6osoe3mgjmm3; path=/

Expires: Thu, 19 Nov 1981 08:52:00 GMT

Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0

Pragma: no-cache

Content-Length: 4393

Keep-Alive: timeout=5, max=100

Connection: Keep-Alive

Content-Type: text/html; charset=utf-8

<html>

<head>

<title>HTTP響應示例<title>

</head>

<body>

Hello HTTP!

</body>

</html>

1、狀態行

狀態行由協議版本、數字形式的狀態代碼，及相應的狀態描述組成，各元素之間以空格分隔，結尾時回車換行符，格式如下：

HTTP-Version Status-Code Reason-Phrase CRLF

HTTP-Version 表示服務器 HTTP 協議的版本，Status-Code 表示服務器發回的響應代碼，Reason-Phrase 表示狀態代碼的文本描述，CRLF 表示回車換行。例如：

HTTP/1.1 200 OK (CRLF)

狀態代碼與狀態描述

狀態代碼由 3 位數字組成，表示請求是否被理解或被滿足，狀態描述給出了關于狀態碼的簡短的文字描述。狀態碼的第一個數字定義了響應類別，后面兩位數字沒有具體分類。第一個數字有 5 種取值，如下所示。

1xx：指示信息——表示請求已經接受，繼續處理
2xx：成功——表示請求已經被成功接收、理解、接受。
3xx：重定向——要完成請求必須進行更進一步的操作
4xx：客戶端錯誤——請求有語法錯誤或請求無法實現
5xx：服務器端錯誤——服務器未能實現合法的請求。

常見狀態代碼、狀態描述、說明：

200 OK //客戶端請求成功

400 Bad Request //客戶端請求有語法錯誤，不能被服務器所理解

401 Unauthorized //請求未經授權，這個狀態代碼必須和WWW-Authenticate報頭域一起使用

403 Forbidden //服務器收到請求，但是拒絕提供服務

404 Not Found //請求資源不存在，eg：輸入了錯誤的URL

500 Internal Server Error //服務器發生不可預期的錯誤

503 Server Unavailable //服務器當前不能處理客戶端的請求，一段時間后可能恢復正常

2、響應正文

響應正文就是服務器返回的資源的內容，響應頭和正文之間也必須用空行分隔。如：

<html>
<head>
<title>HTTP響應示例<title>
</head>
<body>
Hello HTTP!
</body>
</html>

3 、響應頭信息

HTTP最常見的響應頭如下所示：

Cache頭域

Date：

作用：生成消息的具體時間和日期，即當前的GMT時間。

例如：　Date: Sun, 17 Mar 2013 08:12:54 GMT

Expires：

作用: 瀏覽器會在指定過期時間內使用本地緩存，指明應該在什么時候認為文檔已經過期，從而不再緩存它。

例如: Expires: Thu, 19 Nov 1981 08:52:00 GMT　　

Vary

作用：

例如: Vary: Accept-Encoding

Cookie/Login 頭域

P3P

作用: 用于跨域設置Cookie, 這樣可以解決iframe跨域訪問cookie的問題

例如: P3P: CP=CURa ADMa DEVa PSAo PSDo OUR BUS UNI PUR INT DEM STA PRE COM NAV OTC NOI DSP COR

Set-Cookie

作用：非常重要的header, 用于把cookie 發送到客戶端瀏覽器，每一個寫入cookie都會生成一個Set-Cookie.

例如: Set-Cookie: PHPSESSID=c0huq7pdkmm5gg6osoe3mgjmm3; path=/

Entity實體頭域：

實體內容的屬性，包括實體信息類型，長度，壓縮方法，最后一次修改時間，數據有效性等。

ETag：

作用: 和If-None-Match 配合使用。（實例請看上節中If-None-Match的實例）

例如: ETag: "03f2b33c0bfcc1:0"

Last-Modified：

作用：用于指示資源的最后修改日期和時間。（實例請看上節的If-Modified-Since的實例）

例如: Last-Modified: Wed, 21 Dec 2011 09:09:10 GMT

Content-Type：

作用：WEB服務器告訴瀏覽器自己響應的對象的類型和字符集,

例如:

Content-Type: text/html; charset=utf-8

　　Content-Type:text/html;charset=GB2312

　　Content-Type: image/jpeg

Content-Length：

指明實體正文的長度，以字節方式存儲的十進制數字來表示。在數據下行的過程中，Content-Length的方式要預先在服務器中緩存所有數據，然后所有數據再一股腦兒地發給客戶端。

　　例如: Content-Length: 19847

Content-Encoding：

作用：文檔的編碼（Encode）方法。一般是壓縮方式。

WEB服務器表明自己使用了什么壓縮方法（gzip，deflate）壓縮響應中的對象。利用gzip壓縮文檔能夠顯著地減少HTML文檔的下載時間。

例如：Content-Encoding：gzip

Content-Language：

作用： WEB服務器告訴瀏覽器自己響應的對象的語言者

例如： Content-Language:da

Miscellaneous 頭域

Server：

作用：指明HTTP服務器的軟件信息

例如:Apache/2.2.8 (Win32) PHP/5.2.5

X-Powered-By：

作用：表示網站是用什么技術開發的

例如： X-Powered-By: PHP/5.2.5

Transport頭域

Connection：

例如： Connection: close 代表一個Request完成后，客戶端和服務器之間用于傳輸HTTP數據的TCP連接會關閉，當客戶端再次發送Request，需要重新建立TCP連接。

Location頭域

Location：

作用：用于重定向一個新的位置，包含新的URL地址

實例請看304狀態實例

HTTP協議是無狀態的和Connection: keep-alive的區別

　　無狀態是指協議對于事務處理沒有記憶能力，服務器不知道客戶端是什么狀態。從另一方面講，打開一個服務器上的網頁和你之前打開這個服務器上的網頁之間沒有任何聯系。

　　HTTP是一個無狀態的面向連接的協議，無狀態不代表HTTP不能保持TCP連接，更不能代表HTTP使用的是UDP協議（無連接）。

　　從HTTP/1.1起，默認都開啟了Keep-Alive，保持連接特性，簡單地說，當一個網頁打開完成后，客戶端和服務器之間用于傳輸HTTP數據的TCP連接不會關閉，如果客戶端再次訪問這個服務器上的網頁，會繼續使用這一條已經建立的連接。

　　Keep-Alive不會永久保持連接，它有一個保持時間，可以在不同的服務器軟件（如Apache）中設定這個時間。

3. 瀏覽器緩存

瀏覽器緩存：包括頁面html緩存和圖片js，css等資源的緩存。如下圖，瀏覽器緩存是基于把頁面信息保存到用戶本地電腦硬盤里。

1、緩存的優點：

1）服務器響應更快：因為請求從緩存服務器（離客戶端更近）而不是源服務器被相應，這個過程耗時更少，讓服務器看上去響應更快。

2）減少網絡帶寬消耗：當副本被重用時會減低客戶端的帶寬消耗；客戶可以節省帶寬費用，控制帶寬的需求的增長并更易于管理。

2、緩存工作原理

頁面緩存狀態是由http header決定的，一個瀏覽器請求信息，一個是服務器響應信息。主要包括Pragma: no-cache、Cache-Control、 Expires、 Last-Modified、If-Modified-Since。其中Pragma: no-cache由HTTP/1.0規定，Cache-Control由HTTP/1.1規定。

工作原理圖：

從圖中我們可以看到原理主要分三步：

第一次請求：瀏覽器通過http的header報頭，附帶Expires，Cache-Control，Last-Modified/Etag向服務器請求，此時服務器記錄第一次請求的Last-Modified/Etag
再次請求：當瀏覽器再次請求的時候，請求頭附帶Expires，Cache-Control，If-Modified-Since/Etag向服務器請求
服務器根據第一次記錄的Last-Modified/Etag和再次請求的If-Modified-Since/Etag做對比，判斷是否需要更新，服務器通過這兩個頭判斷本地資源未發生變化，客戶端不需要重新下載，返回304響應。常見流程如下圖所示：

與緩存相關的HTTP擴展消息頭

Expires：設置頁面過期時間，格林威治時間GMT

Cache-Control：更細致的控制緩存的內容

Last-Modified：請求對象最后一次的修改時間用來判斷緩存是否過期通常由文件的時間信息產生

ETag：響應中資源的校驗值，在服務器上某個時段是唯一標識的。ETag是一個可以與Web資源關聯的記號（token），和Last-Modified功能才不多，也是一個標識符，一般和Last-Modified一起使用，加強服務器判斷的準確度。

Date：服務器的時間

If-Modified-Since：客戶端存取的該資源最后一次修改的時間，用來和服務器端的Last-Modified做比較

If-None-Match：客戶端存取的該資源的檢驗值，同ETag。

Cache-Control的主要參數

Cache-Control: private/public Public 響應會被緩存，并且在多用戶間共享。 Private 響應只能夠作為私有的緩存，不能再用戶間共享。

Cache-Control: no-cache：不進行緩存

Cache-Control: max-age=x：緩存時間以秒為單位

Cache-Control: must-revalidate：如果頁面是過期的則去服務器進行獲取。

2、關于圖片，css，js，flash的緩存

這個主要通過服務器的配置來實現這個技術，如果使用apache服務器的話，可以使用mod_expires模塊來實現：

編譯mod_expires模塊：

Cd /root/httpd-2.2.3/modules/metadata

/usr/local/apache/bin/apxs -i -a -c mod_expires.c //編譯

編輯httpd.conf配置：添加下面內容

ExpiresActive on

ExpiresDefault "access plus 1 month"

ExpiresByType text/html "access plus 1 months"

ExpiresByType text/css "access plus 1 months"

ExpiresByType image/gif "access plus 1 months"

ExpiresByType image/jpeg "access plus 1 months"

ExpiresByType image/jpg "access plus 1 months"

ExpiresByType image/png "access plus 1 months"

EXpiresByType application/x-shockwave-flash "access plus 1 months"

EXpiresByType application/x-javascript "access plus 1 months"

#ExpiresByType video/x-flv "access plus 1 months"

</IfModule>

解釋：第一句--開啟服務

第二句--默認時間是一個月

在下面是關于各種類型的資源的緩存時間設置

ginx緩存靜態資源，只需幾個配置提升10倍頁面加載速度

首先我們看圖說話

這是在沒有緩存的情況下，這個頁面發送了很多靜態資源的請求：

可以看到，靜態資源占用了整個頁面加載用時的90%以上，而且這個靜態資源還是已經在我使用了nginx配置壓縮以后的大小，如果沒有對這些靜態資源壓縮的話，那么靜態資源加載應該會占用這個頁面展示99%以上的時間。聽起來是不是已經被嚇到了，但是數據已經擺在這里了，這可不是危言聳聽。

然后再看看使用了nginx緩存之后的效果圖：

看到沒有，朋友們，整個頁面只有請求接口的時間和從本地磁盤加載css的時間。頁面加載速度直接提升10倍以上！并且由于我這個頁面沒有采用前后端分離的方式，所以html沒有緩存下來，如果采用了前后端分離架構的話，就連html都可以直接緩存，那提升的速度可想而知。當然由于瀏覽器或者手機端對頁面加載的優化我們并不能很直觀的感受到10倍的提升，實際上以肉眼觀察的話，差不多減少了一半的時間，并且由于并沒有向后端服務器請求這些靜態資源，也相當于對后端服務器做了一層保護措施。

首先在http模塊加配置：

# 開啟gzip
gzip on;
# 啟用gzip壓縮的最小文件，小于設置值的文件將不會壓縮
gzip_min_length 1k;
# gzip 壓縮級別，1-10，數字越大壓縮的越好，也越占用CPU時間。一般設置1和2
gzip_comp_level 2;
# 進行壓縮的文件類型。javascript有多種形式。其中的值可以在 mime.types 文件中找到。
gzip_types text/plain application/javascript application/x-javascript text/css application/xml text/javascript application/x-httpd-php image/jpeg image/gif image/png;
# 是否在http header中添加Vary: Accept-Encoding，建議開啟
gzip_vary on;
# 禁用IE 6 gzip
gzip_disable "MSIE [1-6]\.";
# 設置緩存路徑并且使用一塊最大100M的共享內存，用于硬盤上的文件索引，包括文件名和請求次數，每個文件在1天內若不活躍（無請求）則從硬盤上淘汰，硬盤緩存最大10G，滿了則根據LRU算法自動清除緩存。
proxy_cache_path /var/cache/nginx/cache levels=1:2 keys_zone=imgcache:100m inactive=1d max_size=10g;

關于模塊以及nginx配置信息在上一篇文章有說明。

可以看到在http模塊中主要是使用gzip壓縮，最后一個配置才是和緩存有關的配置。

然后是server中加上location配置

location ~* ^.+\.(css|js|ico|gif|jpg|jpeg|png)$ {
 log_not_found off;
 # 關閉日志
 access_log off;
 # 緩存時間7天
 expires 7d;
 # 源服務器
 proxy_pass http://localhost:8888;
 # 指定上面設置的緩存區域
 proxy_cache imgcache;
 # 緩存過期管理
 proxy_cache_valid 200 302 1d;
 proxy_cache_valid 404 10m;
 proxy_cache_valid any 1h;
 proxy_cache_use_stale error timeout invalid_header updating http_500 http_502 http_503 http_504;
 }
?

加上這兩塊配置之后，就能享受到緩存給你帶來的快樂了。當然系統優化之路還是相當漫長的，nginx緩存只是其中的一塊而已，想要把系統達到完美還需要在很多地方下功夫，比如這些靜態資源完全可以直接在客戶端緩存，這樣連請求都不會往服務端發了，更大的減輕服務器的壓力。

存是個老生長談的問題，對于前端工程師來講更是我們的必修課。或許很多人會說我的項目并沒有問題，根本不需要聊什么緩存。如果真的是這樣，只能證明你前端道路才剛剛開始。

背景

小郭今天分享緩存的原因在于：公司的一個核心APP中嵌入了SPA，而且應用核心都分布在SPA中，功能復雜且重。問題出現了：應用核心頁面打開一直處于加載狀態，排除掉弱網環境的原因，重點就在于沒有緩存，每次進入頁面都需要重載DOM和數據，拖慢頁面打開速度。

那應該處理緩存問題呢？接下來小郭從三個方向來講解。

瀏覽器緩存策略

在了解瀏覽器緩存前，我們需要先了解一下相關的概念：cache-control，expires，last-Modified，ETag。

瀏覽器通過請求頭實現緩存，關鍵的請求頭有cache-control，expires，last-Modified，ETag等。我們從時間和空間兩個角度來看瀏覽器緩存。

時間

瀏覽器發送第一次請求：不緩存，服務端根據設定的緩存策略返回相應的header，如：cache-control，expires，last-Modified，ETag。

瀏覽器發送第二次請求：

強緩存策略：不需要和服務端通信就決定是否使用緩存，cache-control優先級大于expires① 有cache-control且不過期，返回本地磁盤緩存，狀態值200；② 有expires且不過期，返回本地磁盤緩存，狀態值200。
協商緩存策略：需要和服務端通信決定是否用緩存，Etag優先級大于last-Modified。① 有Etag，請求頭添加If-None-Match，值就是上次返回的Etag值，然后發送給服務端。服務端對比If-None-Match與現有的Etag值是否一樣；一樣的話只返回header，狀態碼304，瀏覽器從本地磁盤獲取緩存信息；不一樣走正常流程，返回header+body，狀態碼200；② 有last-Modified，添加請求頭If-Modified-Since，值是上次返回的last-Modified，然后發送給服務端。服務端對比If-Modified-Since與現有的是否一樣；一樣的話返回只返回header，狀態碼304，瀏覽器從本地磁盤獲取緩存信息；不一樣走正常流程，返回header+body，狀態碼200
無緩存

空間

瀏覽器和服務端：服務端需要決定使用哪種緩存策略并在響應頭返回；前端不需要設置，是瀏覽器本身機制。
html和靜態資源：通常html不設置緩存，因為其它資源的入口都是html文件；靜態資源（js，css，圖片等）會設置緩存

部署時緩存的問題

如果緩存就按理論上設置，那就太簡單了。在實際應用有個嚴重的問題，我們不僅要緩存代碼，還需要更新代碼。如果靜態資源名字不變，怎么讓瀏覽器即能緩存又能在有新代碼時更新。最簡單的解決方式就是靜態資源路徑添加一個版本值，版本不變就走緩存策略，版本變了就加載新資源。如下：

<script src="xx/xx.js?v=24334452"></script>

然而這種處理方式在部署時有問題。

解決方法：靜態資源和頁面是分開部署

先部署頁面再部署靜態資源，會出現用戶訪問到舊的資源
先部署靜態資源再部署頁面，會出現沒有緩存用戶加載到新資源而報錯

這些問題的本質是以上的部署方式是“覆蓋式發布”，解決方式是“非覆蓋式發布”。即用靜態資源的文件摘要信息給文件命名，這樣每次更新資源不會覆蓋原來的資源，先將資源發布上去。這時候存在兩種資源，用戶用舊頁面訪問舊資源，然后再更新頁面，用戶變成新頁面訪問新資源，就能做到無縫切換。簡單來說就是給靜態文件名加hash值。

那如何實現呢？

現在前端代碼都用webpack之類的構建工具打包，那么結合webpack該怎么做，怎么才能做到持久化緩存？

webpack持久化緩存

一、webpack給文件名添加hash值是很簡單的，但hash/chunkhash/contenthash要用哪個呢？

官方定義
hash: unique hash generated for every build
chunkhash: hashes based on each chunks' content
contenthash: hashes generated for extracted content

根據分析，contenthash才是我們需要的，內容有更新，hash值才會更新。

二、webpack會打包業務代碼、第三方庫及運行時代碼，為保證緩存互不干擾，應該將它們提取出來。

第三方庫提取方式是設置optimization的splitChunks的cacheGroups。splitChunks能提取模塊，cacheGroups能緩存模塊，并且cacheGroups的配置會覆蓋splitChunks相同配置，既能提取又能緩存，故只需設置cacheGroups。

運行時代碼的提取方式為配置runtimeChunk，默認為false，表示運行時代碼嵌入到不同的chunk文件中；現在將運行時代碼提取出來，并命名為manifest。

module.exports = {
  entry: {
    index: "./src/index.js",
    bar: "./src/bar.js"
  },
  output: {
    filename: "[name].[contenthash].js"
  },
  optimization: {
    splitChunks: {
      cacheGroups: {
        vendor: {
          test:/[\\/]node_modules[\\/]/,
          name: "vendors",
          chunks: "all"
        }
      }
    },
    runtimeChunk: {
      name: "manifest"
    }
  }
};

三、 moduleName 和 chunkName 對文件的影響

module：就是js模塊
chunk：webpack編譯過程中由多個module組成的文件
bundle：bundle是chunk文件的最終狀態，是webpack編譯后的結果

一個文件被分離為3個文件，文件間怎么相互依賴的，會影響彼此打包，解決方法是將moduleId和chunkId改成按照文件路徑生成。

optimization: {
  moduleIds: 'hashed',
  namedModules: true,
  namedChunks: true
}

這樣子moduleId在編譯后的文件是文件目錄的hash值，更加安全。這也是namedChunks在production默認為false的原因，不想依賴的文件路徑在編譯后的文件直接展示，但是為了持久性緩存，這里也只能打開。

四、CSS文件緩存

當css代碼提取成單獨文件，當我們改變css時，怎么保證不影響引用它的js文件呢？配置如下：

plugins: [
  new MiniCssExtractPlugin({
    filename: "[contenthash].css"
  })
]

webpack持久化緩存目標是當且僅當該文件內容變動才改變該文件名字的hash值

const MiniCssExtractPlugin = require("mini-css-extract-plugin");
module.exports = { 
  output: { 
    filename: [name].[contenthash].js, // 讓hash值只在內容變動時更新 
    chunkFilename: [name].[contenthash].js // 動態引入的模塊命名，同上 
  }, 
  module: { 
    rules: [ { 
      test: /\.css$/, 
      use: [ 
        "loader: MiniCssExtractPlugin.loader", // 提取出來css "css-loader" 
      ] 
    } ] 
  }, 
  optimization: { 
    moduleIds: "hashed", // 混淆文件路徑名 
    runtimeChunk: { name: 'manifest' }, // 提取runtime代碼命名為manifest 
    namedModules: true, // 讓模塊id根據路徑設置，避免每增加新模塊，所有id都改變，造成緩存失效的情況 
    namedChunks: true, // 避免增加entrypoint，其他文件都緩存失效 
    cacheGroups: { 
      vendor: { // 提取第三方庫文件 
        test: /[\\/]node_modules[\\/]/, 
        name: 'vendors', chunks: 'all', 
      }, 
    },
  } 
  plugins: [ 
    new webpack.HashedModuleIdsPlugin(), // 與namedModules: true作用一樣 
    new MiniCssExtractPlugin({ 
      filename: "[contenthash].css", // css文件也是按contenthash命名 
      chunkFilename: "[contenthash].css", // 動態引入的css命名，同上 
    }) 
  ], 
}

總結

瀏覽器有其緩存機制，想要既能緩存又能在部署時沒有問題，需要給靜態文件名添加hash值。在webpack中，有些配置能讓我們實現持久化緩存。感興趣的同學可以自行去測試哦！

有任何問題可以在下方留言，想了解更多前端知識歡迎關注公眾號“一郭鮮”，文章也將同步于公眾號，前端學習不迷路

在線咨詢

上一篇：干貨：傾斜攝影數據如何導入到Cesium中
下一篇：mht和html有什么區別?

您的項目需求

*請認真填寫需求信息，我們會在24小時內與您取得聯系。

整合營銷服務商