Web 技術中的 Session 是什麼?


很久沒更新了,自從十二月底退伍之後,一直忙著將書完稿給出版社,沒空坐下來好好在 Blog 上寫點東西。沒辦法,在當兵時閒不下來,就答應了出版社的邀約開始寫 Node.js 的書,因此欠下了書的債。還好,如預期的寫完了,預計這一兩個月應該就會上市,還請各界多多捧場!

會寫這篇文章的原故,是因為在 Facebook 的社群上,有人問起了關於 Session 和 Cookie 相關性的問題。其實,社群的人都很好,有許多熱心的網友願意幫助別人。不過,為了幫忙回答問題,大家七嘴八舌的東說一句西說一句,甚至引起莫明的論戰,實在不是一個好的現象。況且,使用不同語言、有不同技術背景的人,都各自用自己的角度去描述和解說,讓原本就已經不懂的人更有如瞎子摸象,見不到全貌,搞更糊塗了。對發問的人來說,也不知該聽誰的好。

說來湊巧,筆者剛好在剛截稿的 Node.js 書籍中,對 Session 概念也有許多著墨。所以之前稍微在網路上查過,發現鮮少有人提出對 Session 技術的完整說明,而多半是討論 ASP、.Net、Java、PHP 等語言或框架中如何使用 Session,以及一些延伸的特性,以致很多人對 Session 的概念相當片面。因此這次的事件後,一些網友也建議我把在 Facebook 上回應的完整內容,在 Blog 發表記錄下來,讓更多人對 Session 有個比較完整且正確的認識。

本文目標


在 Web 的世界裡,Session 已經是被廣泛使用的一種技術,大多數的 Web 開發者,肯定都能運用自如。在現今的各類 Web 應用程式的開發框架和工具中,Session 也已經被包裝成容易使用的模式,所以本文也就不再多討論 Session 怎麼去使用,而是著重在 Session 的原理和實現上。要知道,無論是使用哪一種語言,這 Session 概念上都是通用的,沒有什麼不一樣。

Session 是什麼?


Session 之所以會存在,是因為 HTTP 為 stateless 的設計,Server 和 Client 不會一直保持連線狀態,也不會有雙方狀態的即時更新,所以,Server 並不知道 Client 的狀態(像是是否已經登入)。因此,後來的網站開發者,採用 Session 這樣的設計來解決這問題。有趣的是,Session 機制在最早的 CGI 年代,是完全要程式設計師徒手寫出來的,搞死了很多人,不像現在的網站開發者有現成的許多解決方案可以選擇,不必完全了解也可以使用。

Session 的原理


很多人在討論 Session 時,不免與 Cookie 牽扯上關係,反而不小心偏了重點,所以在了解 Session 時必須有個觀念,就算沒有 Cookie 的存在,Session 機制也可以正常運作。Cookie 在 Session 機制中,可以扮演許多角色,也可以對原始的 Session 機制做許多改良,但不用急著過早討論。從 Session 為什麼被需要來切入,自運作原理來了解,反而比較實際也易懂。最後再來討論 Cookie 在裡面所扮演的角色,才會比較清楚。

簡單來說,Session 的機制就像是你去飲料店下了單以後,得到號碼牌,然後你走開幾步,店員就忘了你是誰。所以,如果你想去取飲料,你就得靠這張號碼牌,去跟店員領,店員會跟據這號碼牌,認定你是顧客、是否點過餐、知道你點了什麼東西,然後可以接著給你屬於你的飲料。

理解 Session 的原理後,回到 HTTP 上就是一樣的。只是,在網頁技術中,有兩種方法讓 Client 取得號碼牌,一個是用 Cookie,另一個是直接輸出並嵌入頁面之中的方法(就是要你把號碼背起來)。

拿號碼牌去 Server 要資料,主要也分為兩種方法,Cookie 和運用標準的 Query string/POST body方法。(其實只要能把號碼傳到 Server 上,任何方法都行)

只不過,因為實作上的困難度考量,還有現今的 Browser 預設都支援 Cookie,所以在現有的網站框架中,都預設採用 Cookie 來發號碼牌和兌換資料。Cookie 的交換會在建立連線時,在背景自動完成,因此開發者不必考慮Client/Server的號碼牌交換問題。因為 Browser 會在建立連線後,第一時間就自動在背景把 Cookie 上傳到 Server,Server 也在回傳資料時,第一時間自動把 Cookie 回傳給 Client。

所以,除非是有必要(像是 Browser/Client 不支援 Cookie 的情況),才會保留另一種實作。

BTW, 飲料店拿號碼牌的例子應該很容易解釋清楚 Session 的原理。

Cookie-based Session


這邊要注意的是,有一種 Session 會讓很多很多人感到混亂,就是 cookie-based session。問題在於名稱上的誤導,你可能會想,既然幾乎所有的 Session 機制都會用到 cookie,是否都可以稱做 cookie-based session?

其實大多數人說的 cookie-based session ,指的是儲存資料方式的不同,不是指領號碼牌時,是否有用到 cookie。(不過如果早個十年,當時講的 cookie-based session,可能多半指的就是領號碼牌時,有沒有用到 cookie。摔碗!)

很多人在討論 Cookie 與 Session 的關係時,兩種用到 Cookie 的地方,時常混在一起講,這就不免要雞同鴨講筆戰一番了。

事實上,在最原始的 Session 設計,大多開發者都將資料存在 Server 上,也就是你點了什麼飲料,都是記錄在 Server 裡,可能是 Database、記憶體或是檔案,可以以任何一種形式儲存。然後,當你去領飲料時,店員會輸入你的號碼,用你的號碼得知你是否點過餐、點了什麼東西。

一般的小網站,這樣的解決方案並沒有什麼問題。但是對今天這種超大流量的網站服務來說,因為他們有無數台對外的 Server,有如無數個服務窗口,讓顧客總是隨機進入其中一個窗口來兌換飲料,所以後端怎麼存放和共享這個 session 資料,又要兼顧效能和方便維護,就變成是很大的問題。

因此 Cookie-based Session 就被提出為一個解決方案,把資料暫存放在 Cookie 中,讓 Client 自己負責保存。簡單來說,就是把你點什麼飲料,通通直接寫在號碼牌上。Server 就可以直接看你的號碼牌上寫了什麼,而不必花大量時間去後面建立大規模的 Server 來處理 Session 。

不過,這邊要特別提到,因為 cookie 有 4K 資料大小的限制,很多網站服務會選擇 cookie-based 和後端儲存並行的方案。

或許有人會問到 Cookie 是否有可能被篡改?這類安全問題,通常會使用加密手段來解決。一般來說,Cookie-based session 的 cookie 會被加密,只有 Server 才知道如何解開,Client 並沒有能力可以存取,只是得到一個看不懂的包裹,所以不會有安全性的問題(當然還是有機會被破)。

由於仍然存在風險,這也是其中一個原因,為什麼有些網站仍然會採用 cookie-based 和後端儲存 Session 並行的解決方案,或是會避免把敏感資料放在 Cookie-based Session 上。

什麼是 Session 傳值?


時常會聽到『使用 Session 傳值』這類說法,其實就是利用 Session 機制儲存資料,讓不同頁面之間可以互相傳遞資料。其原理通常是使用 Query String 或 POST body 等方法,把資料往 Server 傳之後,在 Server 端將 Client 上傳的資料存在 Session 之中。之後的連線或開啟其它頁面時,因為你拿的號碼牌是同一個,所以在不同的頁面之下,仍然可以讀到前一次所儲存在 Session 的狀態。

後記


當完兵回來了,腦袋還好還算靈活呀。:-)

留言

  1. It’s good to have a website like this. I can read all the opinions of others as well as i gained information to each and everyone here on your site. Just keep on going dude.
    Check over here: 경마

    回覆刪除
  2. Well I can read all the opinions of others as well as i gained information to each and everyone here on your site. Just keep on going dude. 바카라사이트

    回覆刪除
  3. Your post got my attention and shows me different perception for how we should boost our site. This is a really perfect for a new blogger like me who doesn’t want their site to be messy with those spammers who don’t even read your post but they have the guts to comment in your site. Thanks again. 온라인경마

    回覆刪除
  4. 感謝詳細說明!最近剛好會用到~

    回覆刪除

張貼留言

這個網誌中的熱門文章

有趣的邏輯問題:是誰在說謊

淺談 USB 通訊架構之定義(二)

淺談 USB 通訊架構之定義(一)

Reverse SSH Tunnel 反向打洞實錄