title: 3種Web會話管理方式
date: 2017-09-01 14:45:04
categories:
- web
- http
tags: - web
- session
- cookie
icon: fa-comments
3種Web會話管理方式
無狀態(tài)的HTTP
一次請求結(jié)束荠耽、鏈接斷開钩骇。服務(wù)器再收到下一個請求、它就不知道是哪個用戶發(fā)過來了铝量。但是服務(wù)器會知道是從哪個客戶端發(fā)起的倘屹、不過我們管理的是用戶、不是客戶端慢叨。所以就有了會話管理??
server端session
過程
- 用戶第一次請求 --> 服務(wù)器創(chuàng)建session對象(每個session會分配有唯一id纽匙，以及設(shè)置有失效時間) --> 服務(wù)器通過cookie返回sessionid到瀏覽器
- 用戶請求 --> 服務(wù)器獲取cookie里的sessionid --> 驗證session有效 --> 服務(wù)器延長失效時間
- session超過失效時間 --> 服務(wù)器銷毀該session --> 用戶請求 --> 服務(wù)器創(chuàng)建新session --> 重新登錄
- 用戶登錄成功 --> 服務(wù)器往session里設(shè)置登錄憑證
- 用戶請求 --> sessionid通過cookie攜帶發(fā)送到服務(wù)器 --> 服務(wù)器驗證對應(yīng)session的登錄憑證 --> 響應(yīng)請求
- 用戶登出 --> 服務(wù)器清除登錄憑證
優(yōu)點
- Java、.net拍谐、PHP原生支持烛缔，開發(fā)簡單
- 安全性好。只要sessionid足夠隨機(jī)
缺點
- 多用戶同時在線會占據(jù)較大內(nèi)存
- 應(yīng)用采用集群部署時需要處理多臺服務(wù)器之間session共享的問題
- 多臺服務(wù)器之間共享session時轩拨，還可能需要處理跨域問題
- 不適合用在native app：不好管理cookie
- 不適合用來做純API服務(wù)的登錄認(rèn)證
解決方法
- 對缺點1和2：可以采用中間服務(wù)器管理session
- 對缺點3：前后端解決sessionid的cookie跨域即可
- 實際使用時可以采用單點登錄框架
cookie-base
過程
- 用戶登錄 --> 服務(wù)器創(chuàng)建登錄憑證践瓷、數(shù)字簽名、對稱加密 --> key-value形式寫入cookie
- 用戶請求 --> 服務(wù)器獲取cookie亡蓉、解密晕翠、數(shù)字簽名認(rèn)證 --> 判斷登錄憑證有效期 --> 重新登錄/響應(yīng)請求
優(yōu)點
- 減輕服務(wù)端內(nèi)存壓力，只需要創(chuàng)建和驗證cookie
- 沒有多服務(wù)器共享session的問題砍濒，只需要登錄邏輯淋肾、數(shù)字簽名和密鑰文件在服務(wù)器之間共享
- 很多web開發(fā)平臺(比如PHP的yii)或框架默認(rèn)使用該方式
缺點
- cookie的大小限制
- 依然用了cookie，所以也有跨域問題
- 不適合用在native app：不好管理cookie
- 不適合用來做純API服務(wù)的登錄認(rèn)證
token-base
過程
- (類似cookie-based)用戶登錄 --> 服務(wù)端返回token到客戶端
- 用戶請求(通過url參數(shù)或者h(yuǎn)ttp header主動帶上token) --> 服務(wù)端驗證token
優(yōu)點
- 適用于native app爸邢、SPA
缺點
- 僅限于純API的web應(yīng)用巫员，不適用于點擊鏈接直接請求的情況
- 可能會有跨域問題，不過很容易解決
- token刷新的問題需要注意
