前言

cookie 是在 HTTP 背後做掉許多事情的小夥伴，雖然佔的體積不大，但卻是能夠讓後端「記得」前端的一大利器！

以前對於 cookie 的理解不多，只知道出事了就把 cookie 清掉，重新整理就好了XD

因此今天藉這個機會，我們來看看 cookie 對於前後端的影響吧！

先想一下

• cookie 是在什麼樣的時代誕生的？
• cookie 怎麼解決問題？
• cookie 的優缺點是什麼？
• cookie 適合什麼情境？

cookie 是在什麼樣的時代誕生的？

由於 HTTP 是無狀態(stateless)的通訊協定，每一次發送的 API request 都是獨立的，沒有任何地方會存有這位使用者的狀態。

這在靜態網站是個好處，因為不用花空間來儲存狀態，但在目前互動頻繁的網站中，如果沒有儲存狀態，將會無法判斷

• 目前登入網站的會員是誰？
• 購物車有哪些東西？
• 使用者國家、時區等

準確一點來說，是判斷會變很麻煩，以 iThome 網站來說，我們會需要查看自己追蹤了誰、發了哪些文章等，如果在 HTTP 無狀態的情況下，網站會遇到這個困境：

• 登入網站：後端不知道你是誰，請輸入帳號密碼 -> 哦你是小明啊，來這是你的登入頁面
• 查看追蹤：後端不知道你是誰，請輸入帳號密碼 -> 哦你是小明啊，來這是你追蹤的邦友
• 查看文章：後端不知道你是誰，請輸入帳號密碼 -> 哦你是小明啊，來這是你寫過的文章

顯然光是輸入帳密就飽了！但後端又不可能通靈，因為沒有記錄你的狀態。

cookie 怎麼解決問題？

cookie 是一種可以被儲存在瀏覽器內的 key/value 資料，帶有 domain、max-age 等限制，主要的功能就是在前端記錄使用者的狀態。

後端可以要求瀏覽器，把使用者的狀態，紀錄成儲存在瀏覽器裡的 cookie，而前端在每一次發送 request 時，都在 Header 中設定 cookie 屬性，把 cookie 帶上，後端收到後，就能藉由檢視 cookie 的內容，得知使用者的狀態。

也就是說，登入網站的步驟變成：

1. 輸入帳密，發送登入 HTTP request
2. 後端驗證通過，送回 HTTP response，並要求瀏覽器將 user ID (通常後端會先加密)寫入 cookie
3. 使用者想要查看文章，發送檢視文章的 HTTP request，並在 Header 夾帶 cookie
4. 後端檢視 Header 中的 cookie 欄位，將 user ID 解密，得知 user 身分
5. 查詢 user 的文章並返回 response

我們現在只要登入一次 iThome 的網站，就可以查看自己追蹤了誰、發了哪些文章，不會每個動作都要你再登入一次，甚至只要時間不要間隔太久，關掉瀏覽器再打開，還是會保留你登入的「狀態」，因為狀態不是存在前端的程式裡，而是存在瀏覽器裡面。

反過來說，有時候網站發生問題怪怪的，即便重新整理或關掉瀏覽器重開也沒用，這時詢問客服，他們可能會要你先把 cookie 清掉，就是因為 cookie 跟狀態有關，如果網站出錯的原因在於 cookie，就必須清除 cookie 才有辦法恢復正常。

Session

都提到 cookie 了，就要順便提到一個跟它經常放在一起討論的東西 - Session

Session 是一種讓 HTTP request 變成 stateful 的「機制」，這邊特別強調「機制」是因為，Session 本身並不是某一種資料，它單純是在描述一個方式而已。

因此，如果聽到像是

• 把資料存在 Session 裡
• 你的 Session 裡面放什麼

之類的說法，我認為比較好讀的說法是把 Session 換成「HTTP state」：

• 把資料存在 HTTP state 裡
• 你的 HTTP state 裡面放什麼

當然這樣的說法不精確，因為 HTTP 本身是沒有 state 的，只是我們透過 Session 機制讓它「彷彿有 state 一樣」，所以這點還是要先知道唷！

既然 Session 的重點在於要讓 HTTP 變得 stateful，那顯然我們上面討論到的，用 cookie 來實作 Session 機制，就是一種可行的辦法。

其中透過 cookie 又有兩種方案：

1. 只存一個加密後的 Session ID 在 cookie，送到後端之後，再用解密後的 Session ID 查詢出相關的 Session data (即上面提到的方案)
2. 把整包 Session data 都加密存在 cookie 內，送到後端之後，解密直接取得 Session data 使用 (即 cookie-based session)

兩者各有其方便性，但重點都在於，儲存機密性資料時，一定會加密後，才存在 cookie 裡面。

cookie 的優缺點是什麼？

優點

• 能夠將資料存在瀏覽器上，跳脫了應用程式本身
• 讓 HTTP 有方法可以記錄狀態，提升使用者體驗
• 可以設定 domain、expires 等屬性來限制 cookie 範圍與存活時間

缺點

• 使用者有權利禁用 cookie，因此 cookie 只能是輔助功能，不能是必要功能
• cookie 傳輸時為明文傳遞，代表傳輸時沒有任何加密，非常容易篡改
• 容量有限，每個 domain 最多設定 20 個 cookies，每個 cookie 最多 4kB，且會增加 request 流量

cookie 適合什麼情境？

cookie 的使用場景可以很廣泛，但大多集中於，儲存使用者相關的資訊與偏好，比如使用者 ID 或購物車內容等，另外像是 GA、語系等資料也會選擇放在 cookie，只需要切記，機密資料必須加密，並且妥善設定 cookie 的過期時間，減少 cookie 被盜竊的風險。

結語

心智圖放大版

cookie 與 Session 對於前端工程師來說，可能多少會比較陌生，一方面因為要跟後端合作一起處理，另一方面 cookie 最多也就塞 20 個，不會一直頻繁寫到，因此剛好藉這個機會來好好了解一下。

覺得最有趣的應該是，cookie 是在客服排解客戶問題的「三大法」：

• 重新整理
• 重新登入
• 清除 cookie

只差沒有重新開機了

參考資料

web cookie session 是什麼？
白話 Session 與 Cookie：從經營雜貨店開始