Cookie起源
當初 W3C 在設計 Cookie 時實際上考慮的是為了記錄使用者在一段時間內訪問 Web 應用的行為路徑。
由於HTTP 協定是一種無狀態協定， 當使用者的一次訪問請求結束後， 後端伺服器就無法知道下一次來訪問的還是不是上次訪問的用戶。
Cookie 的作用正是在此， 由於是同一個用戶端發出的請求， 每次發出的請求都會帶有上一次訪問時服務端設置的資訊， 這樣服務端就可以根據之前存入 Cookie 的值來做相應的處理(區分訪問的用戶等)。
作用
解決了用戶端和服務端之間的無狀態
通俗地講就是當一個使用者通過 HTTP 協議訪問一個伺服器的時候，
流程簡介
當用戶端流覽器發送請求時， 會根據自身的設置找尋相應條件下的 Cookie 資訊並解析。 若找到， 則設置相應的請求頭資訊， 再發送請求， 否則直接發送請求。
服務端設置好 $_COOKIE 後， 將會通過回應頭返回給流覽器。 注意： Cookie 是在 header 中發送的， 所以之前不能有任何輸出。
缺點
每次請求都會攜帶全部的 Cookie 資訊， 容易造成不必要的頻寬浪費。
每個流覽器對 Cookie 在同一個功能變數名稱下的個數和每個 Cookie 的總大小(4kb)都有相應的限制。
資料存儲在用戶端， 容易被攔截篡改， 不安全。
用戶端可以禁用 Cookie， 導致功能失效。
難於管理， 大型系統裡每個應用都會有自己的 Cookie， 加上以上的限制， 容易出現資料被截取， 導致資料丟失。
Session
基於以上的缺點， Session 來了。
流程簡介
服務端（預設設置）接受請求時， 先查看 $_COOKIE 中是否存在 name 為 PHPSESSID 的鍵值對（value 為服務端生成的 SESSION_ID：bebfaf6c745c1a6e5f341baf2178113b）。
若不存在（第一次請求）， 將會自動生成 SESSION_ID， 寫入到 $_COOKIE 陣列中(name 為 PHPSESSID， value 為 SESSION_ID)， 然後通過回應頭返回給流覽器。
若存在（非第一次請求）， 則根據 value 值到設置的目錄下獲取相應的檔， 反序列化並寫入到 $_SESSION 陣列供後續使用。
當服務端進行 $_SESSION 設置時， 此 $_SESSION 只會維持在記憶體中。 當腳本執行結束時， 將會自動把 $_SESSION 序列化後寫入到 SESSION_ID 對應的檔中（創建或覆蓋）。
優點
只將會話識別字放到 Cookie 裡， 減少頻寬的傳輸。
可以存儲大量的資訊， 基本沒有空間上的限制。
資料存放在服務端， 安全。
可以統一集中式管理。
聯繫
SESSION 為了識別會話， 需要傳輸一個唯一的 SESSION_ID 到用戶端。 一般情況下， 都是借助 Cookie 來傳遞， 當然也可以通過其他方式進行傳遞。
Session 安全延伸
以上分析得出， Session 需要通過 SESSION_ID 來識別用戶端， 這就會導致一個安全隱患。 當 SESSION_ID 落入第三者時， 服務端將無法分辨出是否是合法的請求。
一個簡單的防禦措施就是：每次請求時都生成一個新的 SESSION_ID 關聯到對應的資料並將老的 SESSION_ID 刪除。