Cookie 和 Session

Cookie

起源

當初 W3C 在設計 Cookie 時實際上考慮的是爲了記錄用戶在一段時間內訪問 Web 應用的行爲路徑。

因爲HTTP 協議是一種無狀態協議，當用戶的一次訪問請求結束後，後端服務器就沒法知道下一次來訪問的仍是不是上次訪問的用戶。
Cookie 的做用正是在此，因爲是同一個客戶端發出的請求，每次發出的請求都會帶有上一次訪問時服務端設置的信息，這樣服務端就能夠根據以前存入 Cookie 的值來作相應的處理(區分訪問的用戶等)。

做用

解決了客戶端和服務端之間的無狀態

通俗地講就是當一個用戶經過 HTTP 協議訪問一個服務器的時候，服務器會根據須要設置一些 Cookie 信息（Key/Value 鍵值對），並給這些數據加上一些限制條件，再以響應頭的形式返回給客戶端瀏覽器。在條件符合時這個用戶下次訪問這個服務器的時候，數據又被完整地帶回給服務器。

流程簡介

1. 當客戶端瀏覽器發送請求時，會根據自身的設置找尋相應條件下的 Cookie 信息並解析。若找到，則設置相應的請求頭信息，再發送請求，不然直接發送請求。

2. 服務端設置好 $_COOKIE 後，將會經過響應頭返回給瀏覽器。注意： Cookie 是在 header 中發送的，因此以前不能有任何輸出。

缺點

1. 每次請求都會攜帶所有的 Cookie 信息，容易形成沒必要要的帶寬浪費。

2. 每一個瀏覽器對 Cookie 在同一個域名下的個數和每一個 Cookie 的總大小(4kb)都有相應的限制。

3. 數據存儲在客戶端，容易被攔截篡改，不安全。

4. 客戶端能夠禁用 Cookie，致使功能失效。

5. 難於管理，大型系統裏每一個應用都會有本身的 Cookie，加上以上的限制，容易出現數據被截取，致使數據丟失。

Session

基於以上的缺點， Session 來了。

流程簡介

1. 服務端（默認設置）接受請求時，先查看 $_COOKIE 中是否存在 name 爲 PHPSESSID 的鍵值對（value 爲服務端生成的 SESSION_ID：bebfaf6c745c1a6e5f341baf2178113b）。

2. 若不存在（第一次請求），將會自動生成 SESSION_ID，寫入到 $_COOKIE 數組中(name 爲 PHPSESSID， value 爲 SESSION_ID)，而後經過響應頭返回給瀏覽器。

3. 若存在（非第一次請求），則根據 value 值到設置的目錄下獲取相應的文件，反序列化並寫入到 $_SESSION 數組供後續使用。

4. 當服務端進行 $_SESSION 設置時，此 $_SESSION 只會維持在內存中。當腳本執行結束時，將會自動把 $_SESSION 序列化後寫入到 SESSION_ID 對應的文件中（建立或覆蓋）。

優勢

1. 只將會話標識符放到 Cookie 裏，減小帶寬的傳輸。

2. 能夠存儲大量的信息，基本沒有空間上的限制。

3. 數據存放在服務端，安全。

4. 能夠統一集中式管理。

聯繫

SESSION 爲了識別會話，須要傳輸一個惟一的 SESSION_ID 到客戶端。通常狀況下，都是藉助 Cookie 來傳遞，固然也能夠經過其餘方式進行傳遞。

Session 安全延伸

以上分析得出， Session 須要經過 SESSION_ID 來識別客戶端，這就會致使一個安全隱患。當 SESSION_ID 落入第三者時，服務端將沒法分辨出是不是合法的請求。

一個簡單的防護措施就是：每次請求時都生成一個新的 SESSION_ID 關聯到對應的數據並將老的 SESSION_ID 刪除。