web会话管理

[FanWalker]

1、基于server端的session管理

流程：

1、用户第一次请求服务器，服务器创建session对象（分配唯一的sessionid）；
2、服务器将sessionid通过cookie返回给浏览器，浏览器以后向服务器发送请求的时候，会通过cookie把sessionid再传给服务器，服务器通过sessionid找到该用户对应的session对象；
3、session超过失效时间，如2小时，服务器销毁之前session对象，并创建新的session返回给用户，否则在当前的请求时间基础上再延长2小时；
4、用户登录，验证成功，在对应的session对象放入用户登录成功的凭证；
5、用户发送需登录才能访问的请求，sessionid通过cookie携带发送给服务器，服务器根据sessionid找到用户的session对象，判断其中是否有登录凭证；
6、用户登出，服务器清楚session对象里的登录凭证；

流程图：

优点：

1、主流的web开发平台（java , .net , php）都原生支持这种会话管理的方式，开发简单；
2、安全性高，因为sessionid随机产生，不能轻易冒充，即使冒充成功，也要有有效的登录凭证；

缺点：

1、会话信息存储在web服务器里面，用户同时在线量比较多时，这些会话信息会占据比较多的内存；
2、应用采用集群部署的时候，多台web服务器之间如何做session共享的问题；
3、多个应用要共享session时，会遇到跨域问题；
4、不适合用在native app，不适合用来做纯api服务的登录认证。

2、cookie-based的管理方式、

原理：

将用户的登录凭证直接存到客户端，当用户登录成功之后，把登录凭证写到cookie里面，并给cookie设置有效期，后续请求直接验证存有登录凭证的cookie是否存在以及凭证是否有效

流程：

1、用户登录请求，满足登录条件，服务端创建一个登录凭证；
2、服务端对登录凭证做数字签名并用对称算法做加密处理，把签名、加密后的字符串写入cookie，cookie的名字固定；
3、登录后发送请求，根据cookie名字取得cookie值，解密、数字签名认证，获得登录凭证，判断凭证是否过期，重新登录或允许请求；

流程图：

优点：

1、实现了服务端的无状态化，减轻服务器内存；
2、用集群部署时候，没有session共享问题，总能拿到cookie中的登录凭证来进行验证；
3、好多web开发平台或框架都默认使用这种方式来做会话管理

缺点：

1、cookie有大小限制，存储不了太多数据；
2、每次传送cookie，增加了请求的数量，对访问性能也有影响；
3、也有跨域问题；
4、不适合用在native app，不适合用来做纯api服务的登录认证。

3、token-based的管理方式

原理：

和cookie-based相似

流程图：

优点：

1、每次请求的时候，主动把token加到http header里面或者url后面，所以即使在native app里面也能使用它来调用我们通过web发布的api接口；
2、同样适用于网页应用。

缺点：

1、在web应用里也有跨域的问题；
2、得考虑ticket或token的自动刷新的问题。

学习参考文章：

3种web会话管理的方式