Cookie和Session的區別以及設計測試用例

為什麼要使用Cookie和session？

首先我們要知道一個概念，web程式是使用HTTP協議傳輸的，而HTTP協議是無狀態的協議，對於事務處理沒有記憶能力。缺少狀態意味著如果後續處理需要前面的資訊，則它必須重傳，這樣可能導致每次連線傳送的資料量增大。另一方面，在伺服器不需要先前資訊時它的應答就較快。

登入前和登入後，登入前服務端給瀏覽器一個Cookie，但是這個Cookie裡面沒有使用者資訊，但是登入成功之後，服務端給瀏覽器一個Cookie，這個時候的Cookie已經記錄了使用者的資訊，在系統內任意訪問，可以實現免登入

Session:在計算機中，尤其是在網路應用中，稱為“會話控制”。Session 物件儲存特定使用者會話所需的屬性及配置資訊。這樣，當使用者在應用程式的 Web 頁之間跳轉時，儲存在 Session 物件中的變數將不會丟失，而是在整個使用者會話中一直存在下去。當使用者請求來自應用程式的 Web 頁時，如果該使用者還沒有會話，則 Web 伺服器將自動建立一個 Session 物件。當會話過期或被放棄後，伺服器將終止該會話。

簡單來說Cookie和Session這兩個東西就是處理使用者會話，與登入有關，儲存使用者資訊

下面這篇文章希望能夠幫助大家分清楚這兩個技術的區別和他們對應的使用場景。

一）.cookie的特點：

1. cookie是一門客戶端快取技術
2. cookie資料由伺服器生成，傳送給瀏覽器儲存
3. cookie資料的格式：鍵值對
4. cookie資料過期機制：設定expire值

cookie是一門客戶端技術，一般是由伺服器生成返回給瀏覽器客戶端來儲存的，並且cookie是以鍵值對的形式儲存在瀏覽器客戶端的，每一個cookie都會有名稱，值，過期時間...。cookie有很多使用場景，在專案中比較常見的有：

　　1.登入記住使用者名稱

　　2.記錄使用者瀏覽記錄

　　...

上面應用中大家最熟悉的應該就是記住使用者名稱這個場景了，以京東網站的登入功能為例，當我們登入了一次京東，後面再去登入頁面登入的時候，會發現它會幫你回填之前的使用者名稱，這個場景就是通過cookie技術實現的。

1.開啟火狐瀏覽器，訪問京東登入頁面輸入登入賬號，密碼完成登入：

 

 

2.首頁退出登入：

 

 

3.登入頁面再次登入發現使用者名稱輸入框已經回填了之前的手機號：

 4.F12開啟火狐瀏覽器找到儲存手機號的這個cookie：“mp”，值就是我們填寫的使用者名稱資訊：

總結：此實現過程：登入成功，將手機號寫入到cookie---》回到登入頁面再次登入時，根據mp這個cookie的名稱取出手機號的值回填到使用者名稱輸入框（根據鍵取出值）

 

擴充：cookie是有過期機制的，可以通過設定cookie的過期時間來控制cookie什麼時候過期

這個mp的過期時間為一個月，因此這一個月內只要不清除瀏覽器端的cookie資料，那麼使用火狐瀏覽器來訪問京東的登入頁面都可以看到手機號回填的效果。

 

==============================================================分割線==========================================================================

二）.session

session的特點：

1. session是一門服務端會話快取技術。
2. session由伺服器端的web容器建立，儲存在伺服器端。
3. session儲存資料：鍵值對形式
4. session過期：預設30分鐘

session是服務端的會話技術，當使用者登入了系統，伺服器端的web容器就會建立一個會話，此會話中可以儲存登入使用者的資訊，並且也是以鍵值對的形式去儲存的，現在大部分系統都是使用的session技術來做的鑑權（許可權鑑定），即：當使用者登入完了才可以訪問系統中的一些頁面和資料。

以下面的系統為例：

直接訪問系統lmcanon的首頁index.html無法訪問成功，會被重定向到登入頁面login.html，因為這個系統有做使用者鑑權，沒有登入的使用者無法訪問系統裡面的資料。

如下：

 

2.現在登入系統：

開啟F12可以看到，login登入介面的響應頭裡有一個“set-cookie”的頭資訊，裡面就有“JSESSIONID=8AC39619BB5BEC4426CF999A92E74337”這個資訊，瀏覽器看到這個響應頭就知道要把這個資料寫到cookie當中，cookie名稱為：“JSESSIONID”，值為：“8AC39619BB5BEC4426CF999A92E74337”。這個session會話編號就是伺服器返回的。伺服器端的這個session會話儲存了登入使用者的資訊。

作為cookie快取後，在瀏覽器的cookie中就能看到這個資料，如下圖：

 

 登入完成後再訪問系統中的任何頁面都是有沒有問題的，因為後面每次請求都會帶上瀏覽器裡cookie裡面的這個“JSESSIONID”的值過去，如下圖，訪問“一週排課” 這個選單的時候，請求這個頁面以及頁面的任何一個介面請求都會在請求頭裡面帶上這個會話id“8AC39619BB5BEC4426CF999A92E74337” 然後再提交到伺服器，如下圖的這個請求：

 

 

 

當伺服器收到這個請求的“Cookie”請求頭裡的會話id去伺服器匹配，判斷是同一個session會話，會話中有登入使用者的資訊，從而判斷這個請求是一個登入使用者發出的，從而放行這個請求。

上面這個過程可以用下面的這張圖來表示：

 

 

 

cookie和session兩者區別：

(1)cookie資料存放在客戶的瀏覽器上。儲存大小有限制，單個cookie在客戶端的限制是3K 。session資料放在伺服器上，儲存大小無限制，但是當訪問增多，會比較佔用你伺服器的效能，
(2)安全性不同
session：資料儲存在伺服器，客戶端瀏覽器無法干預資料，較安全。session較多用在金融銀行類的產品。
cookie： 資料儲存在客戶端瀏覽器。使用者可以改造或者刪除cookie資料。

(3)有效期計算方式不同：
session：有效從最後一次請求結束後，開始計時。
cookie: 有效期固定，從建立時開始計時
(4)所以：將登入資訊等重要資訊存放為SESSION;其他資訊如果需要保留，可以放在COOKIE中

Cookie和session設計測試用例：

1、確定登入成後，cookie和session目錄有無該資訊

2、cookie或session過期後，兩個是否正常登入

3、刪除所有的cookie或session檔案，再次會怎麼處理

4、鑑權，有些頁面需要登入，沒有登入直接訪問會怎麼樣

擴充1：session過期處理。

當伺服器端的會話過期了，那麼當你繼續發起請求的時候，因為你從客戶端帶過去的會話編號還是之前的那個，就會驗證不通過，就會提示你會話過期請重新登入。

擴充2：token機制

app專案為例：
一般app專案都會基於一個token做鑑權。
因為此時客戶端不是瀏覽器，因此就沒有cookie這一說了。
當使用者登入app時，伺服器會響應回來一個token資訊（一般都是返回的一串唯一的識別符號，比如說uuid或其他）。
伺服器端會將登入使用者跟token（票據）儲存一個對映關係，一般儲存在redis或者表裡面，伺服器端響應回來的token會快取在手機
的本地快取裡，後面手機去訪問app的其他頁面，就會帶著這個token去伺服器做驗證，如果通過這個token能夠從redis找到登入使用者資訊
那麼就認為你是已經登入了的使用者。

token失效：
一段時間後，伺服器端的token失效了，那麼就會把此token跟使用者的對映關係從redis裡刪掉，那麼後面再來訪問的時候，根據你手機請求帶來的token
就匹配不上登入使用者了，伺服器就告訴客戶端，需要去做重新登入了、