在 Web 開發裡面有一個曆久不衰的議題，那就是 Session 與 Cookie 的區别。

圖片來自 Unsplash

從我剛開始學程序時這一題就常出現在面試考題裡，一直到現在都還是能看見這個問題。

這個問題重要嗎?我覺得蠻重要的。因為 Session 所代表的是「狀态」，如果沒有了狀态，一大堆功能都會失效。

對于工程師來說必須去理解什麼是 Session，以及如何操作它，而 Cookie 就是這之中很重要的一環。

因此這會是一系列的文章，我稱之為 Session 與 Cookie 三部曲，會由淺入深，從不同的面向去看 Session 與 Cookie。

這是系列文的第一篇，想用簡單白話的方式通俗地跟大家解釋什麼是 Session，什麼又是 Cookie，目标是希望沒有任何技術背景的人也能夠看懂。

要向沒有技術背景的人講這種概念性的東西，用一堆專有名詞絕對是最差勁的做法。

而最好的做法通常是舉一個現實生活中很貼近的例子，藉由這種方式比較能讓毫無技術背景的讀者們去理解這到底是個什麼東西。

因此，我們從經營雜貨店開始吧!

小明の雜貨店

四十歲的小明退休以後在家閑得發慌，每一天都過得毫無目标而且渾渾噩噩。

「退休以後不是應該無憂無慮嗎?」小明也是這樣問自己的，但沒辦法，他深知自己的個性就是這樣，沒辦法閑下來，一定要做點事情才行。

于是，小明就用了退休金在家裡附近的巷口開了間雜貨店，并且取名為：「小明の雜貨店」，是個毫無創意的名稱，但把自己的名字放在招牌上一直是他的夢想。

小明平時人緣還算不錯，在倒垃圾時會與旁邊的婆婆媽媽閑聊，說着那個誰誰誰的兒子考上了台大，誰誰誰的女兒最近交了個男友，成為左鄰右舍八卦網絡的一部分。

不隻婆婆媽媽，連年輕的那一代也對他感覺不錯，八成是因為他很識相地不會硬要跟年輕人尬聊，看到他們都隻是簡單點個頭示意一下，而不是像其他人劈頭就把私事全都問了一遍。

因此在開幕那天，雜貨店好比 Apple Store 開幕一般(除了沒有人特地前一天就跑來排隊以外)，周遭的鄰居們都跑來捧場，把整個店擠得水洩不通，單日營收甚至上百萬(台币)。

第一天就能有如此成績，可見人緣是多麼重要的一件事。有人緣，有人潮;有人潮，有錢潮。

但開幕畢竟是開幕，通常都是一家商店這輩子的巅峰，除非有跳樓大拍賣(假的那種不算，例如說每天都在大拍賣的)或是周年慶，不然都很難超越了。

随着日曆一張張被撕開，店裡的生意慢慢恢複正常，還是喜歡傳統便利商店的都跑回去便利商店了，而嫌遠懶得走這麼多路的則選擇雜貨店消費。

看似步上正軌的雜貨店，問題卻随着時間慢慢浮上台面。

臉盲症的困擾

小明身為雜貨店的店長兼唯一的店員，所有大小事都是他一個人在處理。傳統雜貨店跟便利商店最大的差别在哪裡?在于人情味。

就像是你去菜市場買菜的時候會被說帥哥或美女，或者是去買早餐的時候老闆會問你：「一樣?」，你隻要點個頭就行了。這些人與人之間的情感是無論信息怎麼發展都無法取代的。

可是小明沒有辦法，因為他根本記不起來是同一個人。

每一個來店裡的人對小明來說都是一個獨立的個體，是完全不相幹的。你可能會疑惑說：「就算認不出臉，認聲音、衣服、氣味也都可以吧?」，看來你是太低估小明了。

小明不隻認不出臉，他什麼都認不出來。我也不知道小明到底哪裡出了差錯，小明自己也不知道。

但總之就是這樣，就算你每天來，每天穿着一樣的衣服，用着一樣的聲音，他都認不出來你是同一個人。

講一個例子你就知道了，有一次有個顧客結完帳以後把發票忘在櫃台，一出店門口才想起來，就立刻跑回去拿。

結果小明完全沒認出來是同一個人，還以為這人是想來偷拿發票的，跟他确認過買的品項一緻以後才願意把發票還給他。

對，就是這麼誇張，小明每一次結賬都是在幫一個全新的人結賬。

在生活上或許沒什麼問題，反正小明無依無靠也沒朋友，自己一個人生活慣了，可是在經營雜貨店上面就有很大的問題了。

除了會讓人覺得很沒有人情味以外，最大的問題就是有些顧客的需求他沒辦法處理。

有些人逛雜貨店喜歡慢慢挑慢慢選嘛，然後有些物品可能又很重，或者是在結賬的時候才突然想起來還要買什麼，這時候就會把東西先放在收銀台那裡，自己跑回去拿其他品項。

我前面已經提過了，小明認人的能力是零，當客人拿新的物品回去收銀台的時候，小明已經認不出他來了。

因此他不知道收銀台上面那些物品是誰的，客人也很難跟小明證明說：「對，這些是我剛剛想買的」。

這個使用者體驗簡直差到不行，因此店裡的生意每況愈下，隻有那種果斷型顧客會來消費(一進雜貨店就往自己的目标走，拿完之後立刻結賬的那種)。

小明當然注意到了這個狀況，也知道不能再這樣下去了，繼續這樣的話大概不用兩個月店就會倒了。于是小明左思右想，快思慢想，東想西想，終于想到了一個解決方法。

方法雖老舊但有用

前面有提到過小明最大的問題是「每個客人都是新的客人」，他沒辦法認出他們是同一個客人，所以自然也無法記住他們的「狀态」，而這個才是最大的問題。

山不轉路轉，路不轉頭轉，既然小明自己沒辦法記住狀态，寫張紙條不就得了嗎?

當你在收銀台結賬的時候寫一張紙條給你，上面寫着：「五香乖乖x1、義美鮮奶茶x1」，然後你就可以回去挑其他你想要的東西，當你再回來收銀台的時候把這張紙條給小明，小明就知道這些東西是你的。

或者你是個常客，每次來都買一樣的東西，小明就在結賬時寫給你一張紙條，把你常買的東西全都寫上去，這樣下次結賬時你隻要帶那一張紙條過來，小明就知道你常買什麼了!

你有看過那種凄美愛情電影嗎?男女主角其中一方得了罕見疾病，每天都會徹底失憶一次，另一方就會在家裡幫他寫滿便條紙，透過那些便條紙，主角才能知道自己是誰、對方是誰，以及自己到底發生了什麼事。

對，你可以把小明想象成就是失憶的那個，而便條紙就是給客人的紙條。既然自己記不住，就讓這些紙條代勞，把狀态放在上面。

雖然說客人要把紙條留着其實蠻不方便的，但前面說過小明人緣其實不錯，因此常客都會看在他的面子上把紙條帶着，讓這個機制得以繼續運作。而小明店裡的生意也因此好轉一點點。

對，隻有一點點而已，因為随身攜帶一張紙條實在是太麻煩了，所以也沒多少人會這樣做。

再繼續往下講之前，我們先進入中場休息。

中場休息

讓我們先從比喻回到網絡世界裡，HTTP 是無狀态的，所以每一個 Request 都是不相關的，就像是對小明來說每一位客人都是新的客人一樣，他根本不知道誰是誰。

既然你沒辦法把他們關聯，就代表狀态這件事情也不存在。

把左邊換成顧客，右邊換成小明也依然成立。多一個得是我多打了，但我懶得修。

那怎麼辦呢?在故事裡我們用紙條來解決這件事情，小明會在結賬時寫下紙條并遞給客人，客人下次隻要再帶着紙條過來，小明就知道發生什麼事了。

小紙條功不可沒

小明最大的問題就是他自己沒辦法記憶「狀态」，因此需要倚靠一個機制來幫他管理「狀态」，而這個機制我們就叫做 Session。

原本對小明來說，每一個客人都是新的客人，彼此之間毫無關聯，所以也沒有任何狀态可言。

但有了紙條以後，兩個在小明眼中完全不同的客人被關聯了起來，小明就可以知道：「原來這個新的客人是以前那個來買木材的客人!」

所以 Session 是什麼?就是一種讓 Request 變成 Stateful 的機制。以小明的例子來說，Session 就是一種讓客人之間能互相關聯起來的機制。

小明靠紙條來實作 Session 機制，那在網絡世界中可以靠什麼呢?舉一個最簡單的例子，網址!

讓我們假設有個購物網站的網址是：market.tw，當你把蘋果加入購物車的時候，你其實是送一個 Request 給服務器，然後服務器會把你導到 market.tw?

item1=apple，接着你再把火山矽肺病加入購物車，網址就會變成：market.tw?item1=apple&item2=pneumonoultramicroscopicsilicovolcanoconiosis

最後你按下結賬，服務器就靠着你地址欄上的信息來判斷你的狀态是什麼，在這個例子中就等同于看你的購物車裡面有什麼。

簡單來說呢，地址欄上的信息就是小明故事中的紙條，是儲存狀态的地方。而上述例子 Client 與 Server 透過地址欄上的狀态來實作 Session 機制。

好，中場休息差不多到這邊要結束了。這一段是想先拉回網絡的部分，從原本故事中的比喻切回真實世界網絡的運作模式，以及先讓大家理解 Session 到底是個什麼東西。

在接下來的故事裡面，小明會碰到更多更多的問題，他能迎刃而解嗎?讓我們繼續看下去。

到底誰會随身攜帶紙條?

前面已經有提過了，盡管小明靠着這個紙條的機制留住了一些常客，但是新客人呢?有多少人會願意為了再來這間店而特地留下具有狀态的紙條?

基本上沒有，因為這樣子太麻煩了!

有天小明在快要入眠時，忽有一龐然大物拔山倒樹而來，蓋一靈感也。他想到了一個絕妙的 idea：「不會有人随身攜帶紙條，但總會随身攜帶手機吧!」

于是流程就變成這樣子：

• 客人來店裡消費，小明結賬時請他拿出手機，并在手機裡面留了一些信息
• 客人第二次來店裡，小明看看手機裡有沒有之前自己留下的信息

先不用管到底小明把信息放在手機的哪裡，這不是重點;重點是手機裡的信息取代了以前的紙條，客人不用刻意再帶一個沒有用的紙條了，隻需要把本來就會随身攜帶的手機拿出來就好，跟以前相比方便許多。

好，接下來我們終于要講到标題的第二個東西了：Cookie。Cookie 是什麼?Cookie 就是故事裡面存在手機的信息。

想要知道真正使用 Cookie 的流程，你隻要把上面的客人用「浏覽器」來取代，小明用「服務器」來取代，就是答案了：

• 浏覽器發送一個 Request 給 Server，Server 叫浏覽器設置 Cookie，浏覽器便把這些數據存在 Cookie 裡面。
• 浏覽器帶着 Cookie 一起發 Request 給 Server，Server 根據 Cookie 的内容決定狀态。

這次沒有買火山矽肺病了

雖然在現實生活中不是每個人都會随身攜帶手機，但是每個浏覽器都會把 Cookie 一并帶上去，也會按照 Server 的指令來儲存 Cookie。

你可以把 Cookie 稱作是一個機制，Server 可以利用 Set-Cookie 這個語法讓浏覽器儲存一些内容，而這些内容會在浏覽器發送 Request 時一并送上來。

而浏覽器裡儲存的那些内容也叫做 Cookie，就是我們故事中所提的小紙條或者是存在手機裡的信息。

前面有提過 Session 機制可以隻靠地址欄操作，跟 Cookie 可以一點關系都沒有。

但在實際應用上，Session 之所以常常跟 Cookie 綁在一起，就是因為靠 Cookie 來操作 Session 機制的話非常方便。

或者應該這樣說，Cookie 本來就是為了操作 Session 而生的。藉由标準化的規範，制定了一個專門用來讓浏覽器與 Server 交換數據的機制。

如果用故事來比喻，就好比政府制定說每個人随身一定要攜帶手機，然後手機裡面一定要存小明留下來的狀态。

這邊再來做個簡單的總結：

Session 是什麼?就是一種讓 Request 變成 Stateful 的機制。以小明的例子來說，Session 就是一種讓客人之間能互相關聯起來的機制。在故事裡面我們用了紙條跟手機裡的信息來比喻，有多種方式可以達成 Session。

在網絡世界中，也有很多種方式可以來操作 Session，前面介紹過第一種是地址欄，第二種就是靠 Cookie。而 Cookie 就是存在浏覽器裡的一些信息。

講到這邊，差不多就把 Session 與 Cookie 的定義與介紹講完了，但故事還沒完呢，我們還有最後一個問題要來解決。

咖啡寄杯的煩惱

雖然店裡生意還可以，但小明無時無刻不想着怎麼樣發大财賺大錢，讓店裡的生意變得更好。

他觀察到最近好多便利商店開始賣起了咖啡，而且時不時就買一送一或是第二件半價，并且貼心地提供了寄杯的服務。

寄杯就是指說你今天先喝一杯，剩下那杯我幫你記着，你下次來的時候跟我講我再給你。

如果不提供這種服務，那買一送一就一定要兩個人才能喝了(或是你立刻喝兩杯)，根本就是排擠像小明這樣的邊緣人。秉持着将心比心的原則，小明當然是希望提供寄杯服務的。

那該怎麼寄呢?照之前那樣不就得了嗎?原本客人的手機裡面會存着消費習慣之類的東西，現在多存一個還有幾杯咖啡不就行了?

例如說客人買兩杯隻喝一杯，就在上面寫着：coffee=1，代表還剩一杯咖啡，下次來的時候隻要出示這個信息，就再給他一杯。

聽起來十分合理，而且小明也這樣做了，店裡的生意變得更好，買咖啡的人愈來愈多，靠着咖啡就讓單月營收翻了兩倍。

一切看似非常順利，直到小明月底對帳的時候：不對啊，為什麼買咖啡的數量隻有 55 杯，賣出去的卻有 66 杯?

一向很相信人的小明，在那一瞬間見識到了人心的險惡之處。沒錯，有人自己偷改信息，例如說把 coffee=1 加個幾劃改成 coffee=7，就獲得了額外六杯的免費咖啡。

這些奧步讓小明狠狠一夜之間變成了大人，絕望的小明把悲憤轉化成力量，隻花了三個晚上就想到了兩個解決方法。

第一個方法最簡單，就是隻要把存在客人手機上的信息加密就好了。

例如說原本是 coffee=1，經過小明自制的特殊加密算法之後，會變成 ED85B89167A84B631C10B046B5FB7FC0 這串隻有小明知道怎麼解開的密文。

這樣一來，除非客人可以破解這段密碼，否則信息就不可能被竄改。但有一個小缺點，那就是當小明想存的信息愈來愈多之後，這一串字也會愈來愈長，就會在客人的手機裡面占更大的容量。

這個容量是有上限的，客人不會把整台手機都給你存這些信息，所以這點要特别注意。

這個方法解決問題的思路是這樣的：「既然存在手機上的信息會被竄改，那我讓他不能改就好」。

而第二個方法解決問題的思路是這樣的：「既然存在手機上的信息會被竄改，那我把信息存在我這邊不就好了嗎?」

與其把那些消費習慣或是寄杯數量存在客人的手機裡，不如把這些東西記在我的筆記本裡面，并且用一種方式把這兩個信息對應起來，這樣就不怕數據會被改動了。

舉例來說，小明可以在筆記本寫下客人的身份證字号跟相關資訊，例如說：「A111111111 coffee=1」，接着小明隻在客人的手機裡面存「A111111111」。

下次客人再來消費的時候，就透過身份證字号去筆記本裡面查，就知道客人到底還剩幾杯咖啡了。

由于小明的筆記本每天下班都會鎖在保險箱裡面，因此不用害怕被偷或是被改，可以假設它一定是準确的。

而這樣子的方式不把主要信息存在客人那裡，而是存在自己這裡，所以也不會有被竄改的風險。

可是有個問題，如果有人把身份證字号改成其他人的怎麼辦?那不就破功了嗎?就可以僞造其他人的身份。

這個簡單，不如不要用身份證字号，用一個 16 位數的英數字混合亂碼好了，例如說：A59Uhe7I94J330mN，這樣就很難被猜到了吧!

于是流程會變成這樣：

客人那編隻需要報 ID 即可，其他資訊都在小明那裡

跟之前一樣，他們都是透過一張紙條或者是手機裡的信息來溝通，但唯一的差别是客人跟小明之間隻透過 A59Uhe7I94J330mN 這個存在手機裡的 ID 來驗證身份，其他相關資訊都寫在小明的筆記本裡面。

這種驗證的方法就像是我曾經去過的網咖。因為會員打咖比較便宜嘛，一小 60 變成一小 36，不辦白不辦，就辦了一張會員卡。店員特别說明認卡不認人，一定要出示卡片才行。

我隻要去打咖的時候出示這張會員卡，店員就知道我曾經消費過多少錢，也知道我喜歡點的餐點，所有的信息都是存在他們的系統裡面，而我的身份就是透過這張會員卡來表示。

寄杯的例子中，會員卡就是 A59Uhe7I94J330mN 這個 ID，網咖的電腦系統就是小明的筆記本。

小明最後決定用第二種方法，也就是這種靠 ID 認人的方式來管理客人的狀态。

從此之後就沒有客人能夠竄改信息了，而寄杯服務也運行的十分順利，真是皆大歡喜，可喜可賀。

至于後來變得生意太好，讓小明開了分店以後碰到的那些問題，就又是另外一段故事了。

儲存狀态的方式

小明的故事說完了，該來把上面這一段變成網絡的實際案例了。其實在網絡世界中問題也是一樣的。

前面已經提到過我們會把狀态存在 Cookie 裡面，讓 Request 之間能夠變得有關聯。

假設我們今天要來做一個會員系統，那我要怎麼知道這個 Request 代表的是哪一個會員?

最直覺的方式就是登入以後把會員帳号存在 Cookie 裡面嘛，這樣不就知道是誰了嗎?

可是會碰到的問題就跟寄杯的故事一樣，Cookie 裡的東西是可以被竄改的，如果我改成了别人的會員帳号，我就可以僞造他的身份登入了!

解決方法跟上面寄杯的解法一樣：

第一個解法就是把 Cookie 裡面的内容給加密，這樣就無法被竄改了。這種方式就稱之為 Cookie-based session，意思就是你把所有的 Session 狀态都存在 Cookie 裡面。

所以不要把「用 Cookie 來操作 Session 機制」跟「Cookie-based session」搞混了，兩者是不一樣的。

至于缺點的話前面有提到，Cookie 的大小是有限制的，超過大小的話浏覽器就不幫你存了。

因此當你想存的信息越來越多，Cookie 當然也越來越大，就有可能超過這個限制。

或者是哪天你的加密方式以及密鑰被黑客破解，那黑客一樣可以僞造任何人的身份。

第二個解法就是透過一個 ID 來辨識身份，這個 ID 稱之為 Session Identifier，簡稱 Session ID。

Server 隻在 Cookie 裡面存一個 Session ID，其餘的狀态都存在 Server 那邊，我習慣把 Server 那邊的數據稱為 Session Data：

其實就是小明筆記本的翻版而已

Session ID 的産生方式跟前面說的一樣，通常會是一個無法猜測的随機數。

你可能會想說：「很難猜是一回事，但機率不是 0 啊!」，對，的确是有機率能夠猜到，但是那個機率太低太低了(例如說幾千億分之一之類的)。

而且 Server 在你亂猜猜錯幾次之後就有可能把你 ban 掉不讓你繼續猜，所以沒什麼問題。

不過這邊要特别注意的一點是 Session ID 基本上是種認證不認人的方式，也就是說一旦你的 Session ID 被偷走，别人就可以僞造你的身份來登錄了。而這個 Session ID 通常都是保存在 Cookie 之中。

這就是為什麼有些網站發生駭客入侵的情形之後你會突然被注銷，因為黑客可能偷到一批 Session ID，這時候服務器就會把所有 Session 數據全部清空。

以故事來比喻就是把筆記本丢掉，買一本新的，這樣被偷走的那些 Session ID 就沒用了，而 Server 找不到你的 Session ID，自然就無法登入，因此把你給注銷了。

網站發生問題時客服會要你先把 Cookie 清掉也是類似的道理，因為 Cookie 跟狀态有關，有時候可能程序有一些 Bug，把你導到了錯誤的狀态，把 Cookie 清空等于把狀态清空，重新再開始，就有可能變得正常。

總結

其實我原本以為我很懂 Cookie 跟 Session，但越研究越發現好像不是這麼一回事，隻是我自我感覺良好而已。

但把該看的數據都看完一遍之後，再讓自己沉澱個幾天，大緻上就能完全理解整個脈絡的發展。

Session 是什麼?就是一種讓 Request 變成 Stateful 的機制。以小明的例子來說，Session 就是一種讓客人之間能互相關聯起來的機制。

在故事裡面我們用了紙條跟手機裡的信息來比喻，有多種方式可以達成 Session。

在網絡世界中，也有很多種方式可以來實作 Session，前面介紹過第一種是地址欄，第二種就是靠 Cookie，而 Cookie 就是存在浏覽器裡的一些信息。

常見的錯誤認知是一定要有 Cookie 才能實作 Session，這是錯誤的。

有了 Session 之後，會碰到數據被竄改的問題，這時候有兩種解決方式：

一個是 Cookie-based session，意思是你照舊把狀态存在 Cookie，但是加密以後再存。

另一個方法是把狀态存在 Server 端，靠一個 Session ID 來辨識，這個狀态你可以存成檔案，可以存在內存裡，也可以存在數據庫，隻是實作方式的不同而已，但原理都是一樣的。

而這個狀态儲存的地方在口語上也會被稱之為「Session」，例如說：「幫我把 user id 存在 Session 裡」，或者是「注銷記得把 Session 清空」之類的。

作者：胡立來源：medium

更多精彩资讯请关注tft每日頭條，我们将持续为您更新最新资讯!