聊一聊http狀態碼，緩存機制，cookie

Http狀態碼

狀態碼	含義
1XX	請求正在被處理
2XX	請求被成功處理
3XX	請求須要附加操做，常見如重定向
4XX	客戶端出錯致使請求沒法被處理
5XX	服務端處理出錯

2XX

狀態碼	緣由短語	含義
200	OK	請求被正常處理
204	NO CONTENT	請求成功，可是響應的報文中不含實體主體
206	Partial Content	只返回了請求資源的部分

204: 例如option請求，一般被用來作正式請求的預請求，這個請求只須要確認後續的請求能不能經過，即只須要一個結果，而不須要返回其餘內容。

206: 在 http的請求中，頭部添加Range用來表示範圍請求，例如

'Range': byte=5001-10000 // 表示本次要請求資源的5001-10000字節的部分

這種狀況下，若是服務器接受範圍請求而且成功處理，就會返回 206，而且在響應的頭部返回：

'Content-Range':bytes 5001-10000/10000// 表示整個資源有10000字節，本次返回的範圍爲 5001-10000字節

3XX

狀態碼	緣由短語	含義
301	Moved Permanently	資源被永久重定向了
302	Found	資源臨時重定向到location
303	See Other	資源使用GET訪問臨時重定向的location
304	Not Modified	資源未改變，可直接使用緩存
307	Temporary Redirect	嚴格限制重定向不容許從POST轉爲GET

301與 302的惟一區別就在於一個是臨時，一個是永久。

4XX

狀態碼	緣由短語	含義
400	Bad Request	請求中有語法錯誤
401	Unauthorized	未通過認證
403	Forbidden	禁止訪問也就是無權限訪問
404	Not Found	服務端沒有找到所請求的資源

5XX

狀態碼	緣由短語	含義
500	Internal Server Error	服務器故障
503	Service Unavailable	服務器暫時沒法使用

緩存機制

瀏覽器每次發起請求，都會先在瀏覽器緩存中查找該請求的結果以及緩存標識

瀏覽器每次拿到返回的請求結果都會將該結果和緩存標識存入瀏覽器緩存中

強緩存

強緩存不會向服務器發送請求，直接從緩存中讀取資源，在 chrome 控制檯的 Network 選項中能夠看到該請求返回200的狀態碼，而且Size顯示from disk cache或from memory cache。強緩存能夠經過設置兩種 HTTPHeader 實現：Expires和Cache-Control。

1. Expires

緩存過時時間，用來指定資源到期的時間，是服務器端的具體的時間點。也就是說，Expires=max-age + 請求時間，須要和Last-modified結合使用。Expires 是 Web 服務器響應消息頭字段，在響應 http 請求時告訴瀏覽器在過時時間前瀏覽器能夠直接從瀏覽器緩存取數據，而無需再次請求。
Expires 是 HTTP/1 的產物，受限於本地時間，若是修改了本地時間，可能會形成緩存失效。Expires: Wed, 22 Oct 2018 08:41:00GMT 表示資源會在Wed, 22 Oct 2018 08:41:00 GMT後過時，須要再次請求。

2. Cache-Control

在 HTTP/1.1 中，Cache-Control是最重要的規則，主要用於控制網頁緩存。好比當Cache-Control:max-age=300時，則表明在這個請求正確返回時間（瀏覽器也會記錄下來）的 5 分鐘內再次加載資源，就會命中強緩存。
Cache-Control能夠在請求頭或者響應頭中設置，而且能夠組合使用多種指令：

指令	做用
public	響應可被客戶端和代理服務器緩存
private	響應只可被客戶端緩存
max-age=30	緩存 30 秒後過時，須要從新請求
s-maxage=30	覆蓋max-age，做用同樣，只是在代理服務器中生效
no-store	不緩存任何響應
no-cache	資源被緩存，可是當即失效，下次會發起請求驗證資源是否過時，配合協商緩存使用
max-stale=30	30 秒內，即便緩存過時也使用該緩存
min-fresh=30	但願在 30 秒內獲取最新的響應

詳細說明：

• public：全部內容都將被緩存（客戶端和代理服務器均可緩存）。具體來講響應可被任何中間節點緩存，如 Browser<--proxy1<--proxy2<--Server，中間的proxy能夠緩存資源，好比下次再請求同一資源proxy1直接把本身緩存的東西給Browser而再也不向proxy2要。
• private：全部內容只有客戶端能夠緩存，Cache-Control的默認取值。具體來講，表示中間節點不容許緩存，對於Browser<--proxy1<--proxy2<--Server，proxy會老老實實把Server返回的數據發送給proxy1,本身不緩存任何數據。當下次Browser再次請求時proxy會作好請求轉發而不是自做主張給本身緩存的數據。

• no-cache：客戶端緩存內容，是否使用緩存則須要通過協商緩存來驗證決定。表示不使用Cache-Control的緩存控制方式作前置驗證，而是使用Etag或者Last-Modified字段來控制緩存。

  須要注意的是， no-cache這個名字有一點誤導。設置了 no-cache以後，並非說瀏覽器就再也不緩存數據，只是瀏覽器在使用緩存數據時，須要先確認一下數據是否還跟服務器保持一致。

• no-store：全部內容都不會被緩存，即不使用強制緩存，也不使用協商緩存
• max-age：max-age=xxx(xxx is numeric)表示緩存內容將在 xxx 秒後失效
• s-maxage（單位爲 s)：同max-age做用同樣，只在代理服務器中生效（好比 CDN 緩存）。好比當s-maxage=60時，在這 60 秒中，即便更新了 CDN 的內容，瀏覽器也不會進行請求。max-age用於普通緩存，而s-maxage用於代理緩存。s-maxage的優先級高於max-age。若是存在 s-maxage，則會覆蓋掉max-age和Expiresheader。
• max-stale：能容忍的最大過時時間。max-stale指令標示了客戶端願意接收一個已通過期了的響應。若是指定了max-stale的值，則最大容忍時間爲對應的秒數。若是沒有指定，那麼說明瀏覽器願意接收任何 age 的響應（age 表示響應由源站生成或確認的時間與當前時間的差值）。
• min-fresh：可以容忍的最小新鮮度。min-fresh標示了客戶端不肯意接受新鮮度很少於當前的 age 加上 min-fresh 設定的時間之和的響應。

3. Expires 和 Cache-Control 二者對比

其實這二者差異不大，區別就在於 Expires 是 http1.0 的產物，Cache-Control 是 http1.1 的產物，二者同時存在的話，Cache-Control 優先級高於 Expires；在某些不支持 HTTP1.1 的環境下，Expires 就會發揮用處。因此 Expires 實際上是過期的產物，現階段它的存在只是一種兼容性的寫法。

強緩存判斷是否緩存的依據來自因而否超出某個時間或者某個時間段，而不關心服務器端文件是否已經更新，這可能會致使加載文件不是服務器端最新的內容，那咱們如何獲知服務器端內容是否已經發生了更新呢？此時咱們須要用到協商緩存策略。

協商緩存

協商緩存就是強制緩存失效後，瀏覽器攜帶緩存標識向服務器發起請求，由服務器根據緩存標識決定是否使用緩存的過程，主要有如下兩種狀況：

• 協商緩存生效，返回304和Not Modified
• 協商緩存失效，返回200和請求結果

協商緩存能夠經過設置兩種 HTTP 頭Modified和ETag。

1. Last-Modified 和 If-Modified-Since

瀏覽器在第一次訪問資源時，服務器返回資源的同時，在 response header 中添加Last-Modified的 header，值是這個資源在服務器上的最後修改時間，瀏覽器接收後緩存文件和 header；

Last-Modified: Fri, 22 Jul 2016 01:47:00 GMT

瀏覽器下一次請求這個資源，瀏覽器檢測到有Last-Modified這個 header，因而添加If-Modified-Since這個 header，值就是Last-Modified中的值；服務器再次收到這個資源請求，會根據If-Modified-Since中的值與服務器中這個資源的最後修改時間對比，若是沒有變化，返回 304 和空的響應體，直接從緩存讀取，若是If-Modified-Since的時間小於服務器中這個資源的最後修改時間，說明文件有更新，因而返回新的資源文件和200.

可是 Last-Modified 存在一些弊端：

若是本地打開緩存文件，即便沒有對文件進行修改，但仍是會形成 Last-Modified 被修改，服務端不能命中緩存致使發送相同的資源.由於 Last-Modified 只能以秒計時，若是在不可感知的時間內修改完成文件，那麼服務端會認爲資源仍是命中了，不會返回正確的資源.既然根據文件修改時間來決定是否緩存尚有不足，可否能夠直接根據文件內容是否修改來決定緩存策略？因此在 HTTP/1.1 出現了ETag和If-None-Match;

2. ETag 和 If-None-Match

Etag是服務器響應請求時，返回當前資源文件的一個惟一標識(由服務器生成)，只要資源有變化，Etag 就會從新生成。瀏覽器在下一次加載資源向服務器發送請求時，會將上一次返回的 Etag 值放到 request header 裏的If-None-Match裏，服務器只須要比較客戶端傳來的 If-None-Match 跟本身服務器上該資源的 ETag 是否一致，就能很好地判斷資源相對客戶端而言是否被修改過了。若是服務器發現 ETag 匹配不上，那麼直接以常規GET 200回包形式將新的資源（固然也包括了新的 ETag）發給客戶端；若是 ETag 是一致的，則直接返回304知會客戶端直接使用本地緩存便可。

3. 二者之間對比

• 首先在精確度上，Etag 要優於 Last-Modified。

  Last-Modified 的時間單位是秒，若是某個文件在 1 秒內改變了屢次，那麼他們的 Last-Modified 其實並無體現出來修改，可是 Etag 每次都會改變確保了精度；若是是負載均衡的服務器，各個服務器生成的 Last-Modified 也有可能不一致。

• 第二在性能上，Etag 要遜於 Last-Modified，畢竟 Last-Modified 只須要記錄時間，而 Etag 須要服務器經過算法來計算出一個 hash 值。
• 第三在優先級上，服務器校驗優先考慮 Etag。

強制緩存優先於協商緩存進行，若強制緩存(Expires 和 Cache-Control)生效則直接使用緩存，若不生效則進行協商緩存(Last-Modified / If-Modified-Since 和 Etag / If-None-Match)，協商緩存由服務器決定是否使用緩存，若協商緩存失效，那麼表明該請求的緩存失效，返回 200，從新返回資源和緩存標識，再存入瀏覽器緩存中；生效則返回 304，繼續使用緩存。

實際場景應用緩存策略

1. 頻繁變更的資源

Cache-Control: no-cache

對於頻繁變更的資源，首先須要使用Cache-Control: no-cache使瀏覽器每次都請求服務器，而後配合ETag或者Last-Modified來驗證資源是否有效。這樣的作法雖然不能節省請求數量，可是能顯著減小響應數據大小。

2. 不常變化的資源

Cache-Control: max-age=31536000

一般在處理這類資源時，給它們的Cache-Control配置一個很大的max-age=31536000(一年)，這樣瀏覽器以後請求相同的 URL 會命中強制緩存。而爲了解決更新的問題，就須要在文件名(或者路徑)中添加 hash，版本號等動態字符，以後更改動態字符，從而達到更改引用 URL 的目的，讓以前的強制緩存失效(其實並未當即失效，只是再也不使用了而已)。

內容參考:瀏覽器的緩存機制

Cookie的實現機制

Cookie是由客戶端保存的小型文本文件，其內容爲一系列的鍵值對。 Cookie是由HTTP服務器設置的，保存在瀏覽器中， 在用戶訪問其餘頁面時，會在HTTP請求中附上該服務器以前設置的Cookie。

1. 瀏覽器向某個URL發起HTTP請求（能夠是任何請求，好比GET一個頁面、POST一個登陸表單等）
2. 對應的服務器收到該HTTP請求，並計算應當返回給瀏覽器的HTTP響應。
3. 在響應頭加入Set-Cookie字段，它的值是要設置的Cookie。
4. 瀏覽器收到來自服務器的HTTP響應。
5. 瀏覽器在響應頭中發現Set-Cookie字段，就會將該字段的值保存在內存或者硬盤中。

Set-Cookie字段的值能夠是不少項Cookie，每一項均可以指定過時時間Expires。 默認的過時時間是用戶關閉瀏覽器時。

1. 瀏覽器下次給該服務器發送HTTP請求時， 會將服務器設置的Cookie附加在HTTP請求的頭字段Cookie中。

瀏覽器能夠存儲多個域名下的Cookie，但只發送當前請求的域名曾經指定的Cookie， 這個域名也能夠在Set-Cookie字段中指定）。

1. 服務器收到這個HTTP請求，發現請求頭中有Cookie字段， 便知道以前就和這個用戶打過交道了。
2. 過時的Cookie會被瀏覽器刪除。

總之，服務器經過Set-Cookie響應頭字段來指示瀏覽器保存Cookie， 瀏覽器經過Cookie請求頭字段來告訴服務器以前的狀態。 Cookie中包含若干個鍵值對，每一個鍵值對能夠設置過時時間。