python愛玩客

首先要說明的是，我們現在使用的網際網路服務，是基於透過一個較HTTP的通訊協定來傳送資料，HTTP是一種stateless（無狀態保存）的網路傳輸。

HTTP（網際網路共用的通訊協定）成就了網際網路的無遠弗屆，但還得要靠session及cookies的運用來滿足用戶使用上的便利。

在介紹session及cookies的作用前，要先從網際網路的基本概念說起．．．．．．．．

我們如何使用網路取得所要的資訊呢？概念上用簡單的下圖示意：

我們用戶就稱為client，而資訊提供者就稱為server

但internet的連線通訊協定http卻簡單的如下圖一般，當您點即送出請求後，資訊提供者完成資訊送出後，這一次的連線服務即告結束

所以當我們在一個網站裡，點擊及讀取各項資料的過程中，若不經過之後我們要介紹的session及cookies的技巧，對server來說，每一次的請求跟連線都是獨立事件，這一次您點擊的連線請求跟上一次的及下一次的對http通訊協定而言,都是獨立事件且與之前跟之後的請求毫無相關，所以對網站的服務而言，同一個發起端的用戶請求資料時，每一次都是獨立的請求，每一個請求都是一個新面孔（即便發起端都是你用同一台電腦或同一台手機）。

當然，聰明的你不禁懷疑？為什麼http通訊協定要設計成這麼笨，不能聰明一些。就您的生活體驗上，任何一件事都有其正反兩面，當http是這麼的陽春時，就代表他在通訊的負擔上最輕盈，不需要瞻前顧後，以至於他能有能力服務更多同時拜訪的客人，造就了網際網路的效率，同時因為其stateless的特性，義即是同一位用戶提出的每一次請求，都可以分別由同一個網站，不同的網站伺服器單獨執行，這樣就可以將這些瀏覽請求任意分散到不同的網站伺服器上，所以符合同時可以服務大量的資料請求業者，並用伺服器農場（server farm）橫向擴充來滿足到訪的客戶。如亞馬遜，即使請求數量很大，也不會全數集中在特定伺服器上產生執行瓶頸。即便當使用者數量越來越多以後，只要增加更多的網站伺服器，就可以來分擔所有的來訪，換句話說，採取Stateless設計架構的網站可以輕易地擴充使用規模。

所謂是有一好沒有兩好，這樣的通訊方式很有效率，但是若不進行其他的加工，對使用者來說就會變得很不友善。下面三個例子就說明使用者在不經加工的http通訊協定來往方式會碰到的問題：

• 明明購物車就已經放了在此網頁要選購的東西，怎麼點擊下一頁繼續購物時，購物車的東西不見了。
• 已經用帳號密碼登入後，明明身分已經驗證後，點擊該網站其他內容時，他又不認得我，又要再輸入帳密一次

• 申請一個加入會員的表單，不小心關掉的網頁，或跳到另外一頁，剛剛填的資料全部見了，都要重填。

如果您有以上的經驗，那就得懷疑該拜訪的網站，設計的能力有問題，使用環境並不友善。

所以當我們在設計網站時，為了強化http通訊協定的不足，需要運用一些工具及技巧，來改善網站的友善服務，目的是讓用戶的使用有接續的感覺，同時也讓您的網站有對熟面孔認識的溫度。

那在網站拜訪怎麼樣變成有溫度呢？

就好像各位去OUTLET購物一般，不論您剛剛去GUCCI或下一刻去LV，相信除了您自己之外，沒有一家店員知道您去過哪裡，買過什麼東西，你是誰？

但是，換了另一種場景，當您去做例行的健康檢查時，到了某關檢查時，助理人員或護士小姐總是知道你檢查過什麼或還沒檢查過什麼，更清楚你是誰。

聰明的您，這時候應該可以想想這兩者間存在什麼差異，那就是差在有一個報到後並領卡的過程，在網站的設計上，就是建立一個session，並賦予第一次報到的你一個全球唯一的session ID。

並賦予你有一張包含您身分資料的表單，並讓您將此資料記錄在您的電腦哩，那就是cookies，剛剛網站給你的session ID及您個人的相關資料就可以記錄在這張卡片上。

有了這個程序及這個小文件，讓在未來拜訪該網站的過程中，您的身分､狀態､甚至於喜好都可以被有系統的記錄及追蹤。

Session及cookies的功能

當使用者的瀏覽器在第一次拜訪特定網站時，沒使用任何拜訪者的身分資料，在設計上，我們一般會設計讓伺服器幫我們產生一個唯一且全新的session ID，通常都採用128位元的GUID（Globally Unique Identifier）以避免與他人重複，除了在服務端的伺服器記憶體或緩衝區或資料庫中儲存此session外，並連同回應的資料回應給使用者的瀏覽器，並由使用者的瀏覽器產生一塊資料區塊記錄此session ID，這個由使用者瀏覽器產生的資料記憶區塊就是會記錄在您電腦裡的cookies。當使用者繼續拜訪該網站時，瀏覽器再傳送請求資料的request時，就一併會將這區塊的資料（cookies）傳送給該網站，當網站收到的請求中包含cookies資料時（包含並檢驗該網站給予的session ID），就可以辨識及認得，該請求用戶的狀態及之前保留在此cookies的內容資料，包含session ID裡所記錄的資料。

透過這樣唯一的識別代號並夾帶在資料的傳送之中，讓我們能解決http先天stateless的缺憾，轉變成stateful，意思是說，讓用戶端及網站端藉著帶有session ID的小紙條cookies得以紀錄並傳遞這個用戶與網站的關係，中間的往來就如同下圖一般，讓拜訪者及提供服務者之間的狀態可以往來及接續，所以我們這下瞭解了，session及cookies必須互相配合才能補強stateless的不足。

所以這樣的狀態接續，看來，解決了我們之前提到的stateless的遺憾，善加利用儲存於網站那一端的session及儲存在用戶電腦瀏覽器端的cookies，可以解決我們之前提到的

• 明明購物車就已經放了在此網頁要選購的東西，怎麼點擊下一頁繼續購物時，購物車的東西不見了。

因為我們可以利用cookies將曾經拜訪過特定網站過程中放入購物車中的紀錄記載在cookies中，再將內容傳遞給網站端

• 已經用帳號密碼登入後，明明身分已經驗證後，點擊該網站其他內容時，他又不認得我，又要再輸入帳密一次？

當您的身分透過網站認證後，session會記的您是誰，同時也將你已經認證過會員身分的狀態記錄在cookies中，以至於接下來的拜訪，他不會一直問您是誰？您是會員嗎？

• 申請一個加入會員的表單，不小心關掉的網頁，或跳到另外一頁，剛剛填的資料全部見了，都要重填!

網頁在設計時，善用cookies，讓您登打的資料也暫存在cookies中，當不小心或設備網路發生意外時，您過去的努力是可以讓它依然存在的。

        那您也可以想想，善用這種session及cookies的設計可以感受到那些友善的溫度呢？

譬如

• 第一次的拜訪，網站遞送給您的導覽及使用說明，當您再一次拜訪，變成老司機之後就不會用這些導覽打擾您。
• 曾經看過的商品，未來不斷的對您疲勞轟炸（有時候是優點也是缺點）？
• 一般的設計上，經過您的同意，會將您的帳號記錄在cookies中，方便您在以後的未來，自動提供您這台電腦這個瀏覽器上針對這個網站層經登入的帳號，免除您忘了或要重複輸入帳號的麻煩。

以上的這些服務，可以透過session及cookies配套的運作，達到友善的效果。

但是這樣便利的運用不是全無副作用的。

• cookie的大小個數有限制

您的瀏覽器針對一個網站能存放的cookie數量不能超過20個，每一個cookies的大小不能超過4k，同時cookies記錄的資料越多，所傳送需求的負擔越大，因為自有某個網站的cookies後，每次的拜訪都會帶著cookies中的資料送給網站，當然，在網站那端，如何保留session及相關記錄也是網站甜蜜的負擔。

• 潛在安全風險

cookie可能被攔截，篡改，所以在設計上，當然要避免將隱私的資料記錄在cookies中，即便要這樣做，一般合格的設計人員或網站，都會透過加密及電子簽章的方式，以確保cookies中的資料不能被竄改及盜用。

• 基於安全，有些瀏覽器是會不允許cookies的運行的

這時候，保持溫度或認識彼此的工作就必須靠其他的機制來滿足，怎麼運用其他的機制來滿足這樣的溝通，未來我們有機會再談囉。