做了這麼多年測試,還是分不清什麼是cookie,什麼是session?很正常,很多初級開發工程師可能到現在都搞不清什麼是session,cookie相對來說會簡單很多。
下面這篇文章希望能夠幫助大家厘清楚這兩個技術的差別和他們對應的使用場景。
一).cookie的特點:
- cookie是一門用戶端緩存技術
- cookie資料由伺服器生成,發送給浏覽器儲存
- cookie資料的格式:鍵值對
- cookie資料過期機制:設定expire值
cookie是一門用戶端技術,一般是由伺服器生成傳回給浏覽器用戶端來儲存的,并且cookie是以鍵值對的形式儲存在浏覽器用戶端的,每一個cookie都會有名稱,值,過期時間...。cookie有很多使用場景,在項目中比較常見的有:
1.登入記住使用者名
2.記錄使用者浏覽記錄
...
上面應用中大家最熟悉的應該就是記住使用者名這個場景了,以京東網站的登入功能為例,當我們登入了一次京東,後面再去登入頁面登入的時候,會發現它會幫你回填之前的使用者名,這個場景就是通過cookie技術實作的。
1.打開火狐浏覽器,通路京東登入頁面輸入登入賬号,密碼完成登入:
![](https://img.laitimes.com/img/9ZDMuAjOiMmIsIjOiQnIsIyZuBnL0MzN0UjN1AzMx0CM4EDOyczMxIjNwYDM4EDMy0CM0gjNxQTMvwlNwgTMwIzLcBDN4YTM0EzLcd2bsJ2Lc12bj5ycn9Gbi52YugTMwIzcldWYtl2Lc9CX6MHc0RHaiojIsJye.png)
2.首頁登出:
3.登入頁面再次登入發現使用者名輸入框已經回填了之前的手機号:
4.F12打開火狐浏覽器找到儲存手機号的這個cookie:“mp”,值就是我們填寫的使用者名資訊:
總結:此實作過程:登入成功,将手機号寫入到cookie---》回到登入頁面再次登入時,根據mp這個cookie的名稱取出手機号的值回填到使用者名輸入框(根據鍵取出值)
拓展:cookie是有過期機制的,可以通過設定cookie的過期時間來控制cookie什麼時候過期
這個mp的過期時間為一個月,是以這一個月内隻要不清除浏覽器端的cookie資料,那麼使用火狐浏覽器來通路京東的登入頁面都可以看到手機号回填的效果。
==============================================================分割線==========================================================================
二).session
session的特點:
- session是一門服務端會話緩存技術。
- session由伺服器端的web容器建立,儲存在伺服器端。
- session儲存資料:鍵值對形式
- 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會話,會話中有登入使用者的資訊,進而判斷這個請求是一個登入使用者發出的,進而放行這個請求。
上面這個過程可以用下面的這張圖來表示:
拓展1:session過期處理。
當伺服器端的會話過期了,那麼當你繼續發起請求的時候,因為你從用戶端帶過去的會話編号還是之前的那個,就會驗證不通過,就會提示你會話過期請重新登入。
拓展2:token機制
app項目為例:
一般app項目都會基于一個token做鑒權。
因為此時用戶端不是浏覽器,是以就沒有cookie這一說了。
當使用者登入app時,伺服器會響應回來一個token資訊(一般都是傳回的一串唯一的辨別符,比如說uuid或其他)。
伺服器端會将登入使用者跟token(票據)儲存一個映射關系,一般儲存在redis或者表裡面,伺服器端響應回來的token會緩存在手機
的本地緩存裡,後面手機去通路app的其他頁面,就會帶着這個token去伺服器做驗證,如果通過這個token能夠從redis找到登入使用者資訊
那麼就認為你是已經登入了的使用者。
token失效:
一段時間後,伺服器端的token失效了,那麼就會把此token跟使用者的映射關系從redis裡删掉,那麼後面再來通路的時候,根據你手機請求帶來的token
就比對不上登入使用者了,伺服器就告訴用戶端,需要去做重新登入了、
關于cookie,session,token的分享就到這裡,希望這些能夠幫到大家。有不正确的地方歡迎留言區指正。覺得不錯,别忘記點贊。
=====請大家尊重原創,如要轉載,請注明出處:轉載自:https://www.cnblogs.com/nickjiang/,謝謝!!=====