很簡短的兩段定義，但是已經道出了cookie和session本質的區別，一個位於客戶端，一個位於服務端。這個特性帶著濃重的色彩，實際中的應用都離不開這個定義。

如果拋開其他特性來說，cookie本質上是瀏覽器（http請求）提供的一種客戶端儲存的資料，但是這個儲存資料有自己的一些特性，比如：cookie長度的限制，跨域的限制（當然可以在服務端配合的情況下的突破這種限制）等。就像所有的儲存一樣，cookie也可以儲存在記憶體中，也可以儲存在磁碟中，只不過儲存在磁碟的時候是在瀏覽器的儲存目錄下，畢竟cookie是基於http的，http請求又基於瀏覽器。

session在很多情況下被稱為會話，本質上是一種服務端的儲存資料。誕生的主要原因是為了解決http無狀態這種特性。既然是資料，其實就可以儲存於任何介質中，像實際應用中，有儲存於記憶體中的，也有儲存於redis的。所以只要看透了它的本質，儲存在哪裡可能就只是一個驅動的問題了。其實完全可以自己寫一個程式把session的資料儲存在txt中，只不過效能上可能需要多加考慮。

當用戶第一次訪問並登陸一個網站的時候，cookie的設定以及傳送會經歷以下4個步驟：

1. 客戶端傳送一個請求到伺服器 --》 

2. 伺服器傳送一個HttpResponse響應到客戶端，其中包含Set-Cookie的頭部 --》 

3. 客戶端儲存cookie，之後向伺服器傳送請求時，HttpRequest請求中會包含一個Cookie的頭部 --》

4. 伺服器返回響應資料

以上過程很明顯是一個最常見的場景，cookie的特性以及值是由服務端來下發，但是不要忘記cookie本質上是一種客戶端技術，所以客戶端其實同樣能操作cookie，比如：登入的時候服務端的返回結果中可以不包含set-cookie的頭部，而是把值通過正文來返回，客戶端指令碼通過讀取返回的正文解析出結果，然後寫入cookie同樣能達到相同的效果。set-cookie只不過是http協議中已經約定好的格式，服務端告訴客戶端需要設定cookie的協議而已。當然cookie還有其他很多特性（可能隨著發展有所增加或者減少）：

由於瀏覽器的安全策略，不同域名（何為不同域名，請百度）的cookie是不允許的，但是可以通過服務端的配置可以解決這個問題。

session的建立目的初衷就是為了讓服務端記住會話，簡而言之就是讓服務端能識別出來是哪個客戶端，既然要記住，那服務端必須要儲存每個會話的資料，比如：實際專案中最常用的使用者資訊等。服務端儲存這些使用者資料沒問題，最大的一個障礙是怎麼樣識別諸多請求中哪些是同一個會話。要解決這個問題，只依靠服務端無法解決，必須需要客戶端來配合：需要上傳會話的標識。

客戶端上傳會話的標識，必須是客戶端和服務端都能支援的協議和資料，其實也可以看做是http請求支援的協議和資料，既然是基於http請求，最方便的就是利用cookie，cookie是一種key-value的資料儲存格式，value的值正適合作為session的標識（session也是一種key-value的儲存），在這種情況下cookie終於和session有了一定的聯絡。

session機制利用cookie來作為標識的傳輸機制，並不意味著只能用cookie，只要是服務端和客戶端約定好了位置，session標識我可以放到http請求的任何位置（當然http請求必須得支援傳輸才可以）。你完全可以把session的標識放到http頭Authorization欄位，只要服務端能正確的讀到此值並且正確解析即可。

有些面試官喜歡問cookie和session的相同和不同，甚至他們的聯絡，這樣的提問在某種程度上是不太好的，容易讓人錯誤的認為cookie和session的聯絡很密切，但是其實他們的聯絡很單純，純潔的朋友利用關係。

此文篇幅屬於5分鐘系列，更能有效利用碎片化時間，下一篇，我們也許可以討論一下基於cookie和session的認證

完