近段時間都是在更新前端學習相關的文章，今天來學習和總結一下一個web通用知識： 瀏覽器緩存，Cookie和Session。這玩意對前端的性能優(yōu)化也有一定作用，應該屬于前端必須掌握的知識之一了。

緩存

在說這些之前，先說說瀏覽器的緩存。為什么會出現瀏覽器的緩存技術？不想下東西唄。同樣的東西，我每次請求都要下一次，不管是從用戶體驗還是速度的方面考慮，都非常的僵硬。于是聰明的前端——哦不，瀏覽器設計者就想到了增加緩存這個東西。

前端想要自己控制緩存，可以在header上設置cache control(Link至MDN,以下部分內容來自MDN)。不算非標準的拓展命令，可以使用的屬性值為以下：

緩存請求指令：

Cache-Control: max-age=<seconds>、max-stale[=<seconds>]、 min-fresh=<seconds>、 no-cache 
、no-store、 no-transform、 only-if-cached

緩存響應指令：

Cache-control: must-revalidate、no-cache、no-store、no-transform、 public、 private、proxy-revalidate、 max-age=<seconds>、 s-maxage=<seconds>

一個個說的話就太麻煩了，還是直接看MDN比較好。這里我畫一個簡單的思維導圖做輔助記憶用。

http://image109.360doc.com/DownloadImg/2017/09/0816/110402526_1_20170908045436225.jpg

Cache-control

看圖細心的話應該能夠發(fā)現，圖中有一個s-maxage，對它的設置會覆蓋maxage和Expire。Expire是什么？這就是我們能夠在Header中設置的另外一個值。將Expires-cache contrl設置為一個時間，那么只要當前時間沒有到這個時間，我們所有對服務器進行的請求都將不被接受轉而直接走硬盤。（Expire的解釋在MDN上沒有中文，我認為應該直接翻譯為“過期時間”?）

但是Expire有一個小小的問題，就是這個時間怎么來。要知道，瀏覽器的取時間方法（比如getTime)都是直接取得系統時間，這樣就帶來一個問題。根據客戶端信息不可靠原則，如果我本地的時間錯亂（比如我這種裝了雙系統然后Linux每次都會莫名改寫windows時間的），那么Expire就形同虛設。所以嘛，一般不推薦使用Expire.

我們還能夠設置的一個屬性則是Last-Modified。如果設置了Last-Modified，那么它將默認保存緩存的內容300S。

Cookie

Cookie是啥我想我就不需要解釋了，最簡單的Cookie設置方法就是document.cookie/Cookies.set方法。在Set Cookies以后，對相同域名的所有請求都會帶上這個Cookie回傳。Cookie一般分為兩種類型，分別為非持久Cookie(內存Cookie)和持久Cookie(硬盤Cookie)。內存Cookie由瀏覽器維護，保存在內存中，瀏覽器關閉后就消失了，而硬盤Cookie則有一個過期時間，過期時間內是持續(xù)有效的。

為什么要有Cookie?

因為HTTP協議是無狀態(tài)的，服務器無法記錄用戶上一次的操作，這樣就造成了交互上的阻礙。而Cookie就可以做到繞開HTTP的無狀態(tài)。服務器借由從Cookie中讀取包含的信息，借以維護用戶和服務器會話中的狀態(tài)。（比如購物/登錄）。

Cookie的路徑

Cookie一般都是由于用戶訪問一個頁面才產生的，但是我們會遇到一個問題——并不是只有在創(chuàng)建Cookie的頁面才需要訪問這個Cookie。如果出于安全考慮，只有與創(chuàng)建Cookie的頁面出于同一個目錄或在創(chuàng)建Cookie頁面的子目錄下的網頁才可以訪問。

那么這樣就又會帶來一個問題：如果者說我希望其父級乃至整個網頁都能夠使用Cookie，怎么做呢？

可以這樣：

document.cookie="userName=CoderMageFox;path=/";

Cookie的域

路徑問題解決了，又一個問題擺在了面前。如果我們在同一個主域下有不同的域名（如img.codermagefox.com和test.codermagefox.com)那么如何互相訪問呢？要知道，這個需求的場景相當多。這個時候，我們可以選擇指定可訪問Cookie的主機名來進行設置。

document.cookie="name=codermagefox;domain=codermagefox.com path=/;"

這樣就可以解決啦。

Cookie的缺陷

（以下引用自MDN）
1.Cookie會被附加在每個HTTP請求中，所以無形中增加了流量。
2.由于在HTTP請求中的Cookie是明文傳遞的，所以安全性成問題。（除非用HTTPS）
3.Cookie的大小限制在4KB左右。對于復雜的存儲需求來說是不夠用的。[3]

然而我在翻閱《JavaScript權威指南》的時候發(fā)現了一點，現代瀏覽器遵循的HTTP標準是RFC2965。

書上原文：

而這個標準中對于這一段是這么寫的：

5.3  Implementation Limits

   Practical user agent implementations have limits on the number and
   size of cookies that they can store.  In general, user agents' cookie
   support should have no fixed limits.  They should strive to store as
   many frequently-used cookies as possible.  Furthermore, general-use
   user agents SHOULD provide each of the following minimum capabilities
   individually, although not necessarily simultaneously:

      *  at least 300 cookies

      *  at least 4096 bytes per cookie (as measured by the characters
         that comprise the cookie non-terminal in the syntax description
         of the Set-Cookie2 header, and as received in the Set-Cookie2
         header)

      *  at least 20 cookies per unique host or domain name

看到這里我有點懵逼了。不是說at least 嗎？所以說這些標準其實是瀏覽器自己定的而不是文檔規(guī)定的？這個坑我暫時沒弄明白，以后弄明白了再回來填。

Session

正如同上面所說，HTTP的傳輸有一個很大的問題，就是明文傳輸。明文傳輸會導致一個什么問題？我可以抓包來獲取很多用戶信息（比如使用WireShark\Fiddle等工具）而且HTTP請求是可以篡改的，并且十分容易篡改。又根據客戶端信息不可靠原則，我們需要一個東西來驗證用戶的身份怎么辦呢？

這個時候，Session就出馬了。Session也可以做到Cookie的部分功能，不過，Session是保存在服務器上的。服務端的信息無法隨便篡改，所以Session可以做到可靠。具體的做法一般是服務端和客戶端之間不傳輸明文數據，而是傳輸一段經過特殊加密的密文，密文對應的服務器硬盤數據中才是真實的數據。這段數據在Session激活后從服務器磁盤中取出到內存中，再返回給瀏覽器。

需要注意的是，Session是一種抽象的概念，開發(fā)者為了實現中斷和繼續(xù)等操作，將 user agent 和 server 之間一對一的交互，抽象為“會話”，進而衍生出“會話狀態(tài)”。而而 cookie 是一個實際存在的東西，http 協議中定義在 header 中的字段。Session可以被認為是一種Cookie的后端無狀態(tài)實現。

當然，現在很多大流量的網站使用的一般是Secret Cookie,這又是另外一種做法了。

便于記憶的思維導圖：

寫了這么多，對于Cookie/Session的理解算是有一些了。今天收獲不錯，Nice!