title: 3种Web会话管理方式
date: 2017-09-01 14:45:04
categories:
- web
- http
tags: - web
- session
- cookie
icon: fa-comments
3种Web会话管理方式
无状态的HTTP
一次请求结束、链接断开。服务器再收到下一个请求、它就不知道是哪个用户发过来了。但是服务器会知道是从哪个客户端发起的、不过我们管理的是用户、不是客户端。所以就有了会话管理
server端session
过程
- 用户第一次请求 --> 服务器创建session对象(每个session会分配有唯一id，以及设置有失效时间) --> 服务器通过cookie返回sessionid到浏览器
- 用户请求 --> 服务器获取cookie里的sessionid --> 验证session有效 --> 服务器延长失效时间
- session超过失效时间 --> 服务器销毁该session --> 用户请求 --> 服务器创建新session --> 重新登录
- 用户登录成功 --> 服务器往session里设置登录凭证
- 用户请求 --> sessionid通过cookie携带发送到服务器 --> 服务器验证对应session的登录凭证 --> 响应请求
- 用户登出 --> 服务器清除登录凭证
优点
- Java、.net、PHP原生支持，开发简单
- 安全性好。只要sessionid足够随机
缺点
- 多用户同时在线会占据较大内存
- 应用采用集群部署时需要处理多台服务器之间session共享的问题
- 多台服务器之间共享session时，还可能需要处理跨域问题
- 不适合用在native app：不好管理cookie
- 不适合用来做纯API服务的登录认证
解决方法
- 对缺点1和2：可以采用中间服务器管理session
- 对缺点3：前后端解决sessionid的cookie跨域即可
- 实际使用时可以采用单点登录框架
cookie-base
过程
- 用户登录 --> 服务器创建登录凭证、数字签名、对称加密 --> key-value形式写入cookie
- 用户请求 --> 服务器获取cookie、解密、数字签名认证 --> 判断登录凭证有效期 --> 重新登录/响应请求
优点
- 减轻服务端内存压力，只需要创建和验证cookie
- 没有多服务器共享session的问题，只需要登录逻辑、数字签名和密钥文件在服务器之间共享
- 很多web开发平台(比如PHP的yii)或框架默认使用该方式
缺点
- cookie的大小限制
- 依然用了cookie，所以也有跨域问题
- 不适合用在native app：不好管理cookie
- 不适合用来做纯API服务的登录认证
token-base
过程
- (类似cookie-based)用户登录 --> 服务端返回token到客户端
- 用户请求(通过url参数或者http header主动带上token) --> 服务端验证token
优点
- 适用于native app、SPA
缺点
- 仅限于纯API的web应用，不适用于点击链接直接请求的情况
- 可能会有跨域问题，不过很容易解决
- token刷新的问题需要注意
