web开发中会话跟踪的方法

为什么要对会话进行跟踪？

主要原因是因为 HTTP 请求是无状态的；只有当用户发出请求时，服务器才会做出响应，客户端与服务端之间的联系是离散的、非连续的；如果用户想在同一个网站的多个页面之间转换时，无法确定是否是同一个用户；对会话进行跟踪就是为了解决这样的问题。

常用的会话跟踪技术

token（令牌 ）

token 是无状态的，是服务端生成的一串字符串，以作客户端进行请求的一个令牌，当第一次登录后，服务器生成一个 token 并返回给客户端，以后客户端只需带上这个 token 前来请求数据即可，无需再次带上用户名和密码。tokens 是多用户下处理认证的最佳方式

最简单的 token 组成：uid(用户唯一的身份标识)、time(当前时间的时间戳)、sign(签名，使用 hash/encrypt 压缩成一定长的十六进制字符串，可以防止恶意第三方拼接token请求服务器)。
用户认证流程：　　

　　1、第一次请求服务器，服务器根据用户信息返回对应的 token 给浏览器。
　　2、浏览器接收到 token 并保存到请求头以及 localStorage / cookie /sessionStorage 里。
　　3、用户再次向服务器发起请求时，服务端会验证请求头中的 token，如果验证不成功说明用户没有登录或者登录失效，如果验证成功证明用户已经登录可执行后面操作。

token优势：

　　1、无状态，可扩展和解耦：后端不需要保持 token 的记录，每个 token 都是独立的，服务器端的工作只需要在登录成功后校验 token 是否有效就可以了。
　　2、支持移动端设备
　　3、支持跨程序调用
　　4、安全：加密的字符串，只是在服务端解密判断有效性

cookie

cookie 是服务器生成，发送给浏览器，并以键值对的形式保存在某个目录下的文本文件内，会在浏览器下次向服务器发起请求时被携带并发送给服务器。由于 cookie 是存在客户端的，所以服务端需要加入一些限制确保 cookie 不会被恶意使用；每一个域的 cookie 数量是有限的。

session

session 是有状态的， 存储于服务器或者硬盘中，可以理解为一个状态列表，拥有一个唯一识别符号 sessionID ，客户端通常存放于 cookie 中。服务器收到 cookie 后解析出 sessionID ，再去 session 列表中查找，才能找到相应 session。依赖cookie，如果 cookie 被禁用也可以放在 url 中。

用户认证流程：

　　1、第一次请求服务器，服务器根据用户信息创建 session 并返回对应的 sessionID 给浏览器。
　　2、浏览器接收到 sessionID 并保存到 Cookie 里，同时 Cookie 记录 sessionID 属于哪一个域名。
　　3、用户再次向服务器发起请求时，请求会自动判断此域名下是否存在 Cookie 信息，如果存在会自动将 Cookie 信息也发送给服务端，服务端会从 Cookie 中获取 sessionID，再根据 sessionID 查找对应的 session 信息，如果没有找到说明用户没有登录或者登录失效，如果找到 session 证明用户已经登录可执行后面操作。
　　4、如果web服务器做了负载均衡，那么下一个操作请求到了另一台服务器的时候 session 会丢失。