【网络通信与信息安全】之深入分析Token、session和cookie的使用场景和区别

在 Web 开发领域，相信大家对于 Cookie 和 Session 都很熟悉，Cookie 和 Session 都是会话保持技术的解决方案。随着技术的发展，Token 机制出现在我们面前，不过很多开发者对于 Token 和 Cookie、Session 的区别及使用场景分辨不清。

首先要知道HTTP请求是无状态的，也就是不知道这一次的请求和上一次请求是否有关系，比如我们登录一个系统的时候，验证用户名密码之后，打开系统各个页面的时候就不需要再进行登录操作了，直到我们主动退出登录或超时退出登录；这里为了避免访问每个都登录一下，就要用到 session、cookie；

cookie 是在客户端(浏览器)保存用户信息的一种机制；而且每种浏览器存储大小会有一些差异，一般不超过4KB；

session是在服务端保存，可以用于记录客户状态，比如我们经常会用 session 保存客户的基本信息、权限信息等；用户第一次登录之后，服务器就会创建一个 session，浏览器再次访问时，只需要从该 session 中查找该客户的信息就可以了。

要知道我们访问网站都是通过 HTTP 协议或 HTTPS 协议来完成的，HTTP 协议它本身是无状态的协议（即：服务器无法分辨哪些请求是来源于同个客户）。而业务层面会涉及到客户端与服务器端的交互（同网站下多个页面间能共享数据），此时服务器端必须要保持会话状态，这样才能进行用户身份的鉴别。

由于 HTTP 无状态的特性，如果要实话客户端和服务器端的会话保持，那就需要其它机制来实现，于是 Cookie 和 Session 应运而生。

通常情况下，Session 和 Cookie 是搭配在一起使用的。

在这里会有个问题，服务器要保存所有用户的 session 信息，开销会很大，如果在分布式的架构下，就需要考虑 session 共享的问题，需要做额外的设计和开发，例如把 session 中的信息保存到 Redis 中进行共享；所以因为这个原因，有人考虑这些信息是否可以让客户端保存，可以保存到任何地方，并且保证其安全性，于是就有了Token。

Token 是服务端生成的一串字符串，可以看做客户端进行请求的一个令牌。

当客户端第一次访问服务端，服务端会根据传过来的唯一标识 userId，运用一些加密算法，生成一个 Token，客户端下次请求时，只需要带上 Token，服务器收到请求后，会验证这个 Token。

有些公司会建设统一登录系统（单点登录），客户端先去这个系统获取 Token，验证通过再拿着这些 Token 去访问其他系统；API Gateway 也可以提供类似的功能，我们公司就是这样，客户端接入的时候，先向网关获取 Token，验证通过了才能访问被授权的接口，并且一段时间后要重新或者 Token。

Token 俗称为“令牌”，它的构成是：

uid：用户唯一身份标识；

timestamp：当前时间戳；

sign：签名字符串，防止第三方伪造数据；签名密钥是存储在服务器端的，其它人无法知道；

其它附加参数。

客户端使用用户名、密码做身份验证；

服务端收到请求后进行身份验证(也可能是统一登录平台、网关)；

验证成功后，服务端会签发一个 Token 返回给客户端；

客户端收到 Token 以后可以把它存储起来（可以放在）；每次向服务端发送请求的时候，都要带着 Token；

Token 会有过期时间，过期后需要重新进行验证；

服务端收到请求，会验证客户端请求里面的 Token，验证成功，才会响应客户端的请求；

cookie：

保存在浏览器中，有大小限制，有状态；

由于存放在客户端，所以是不安全的，人为可以清除；

cookie 有过期时间设定，如果不设置过期时间，说明这个 cookie 就是当前浏览器的会话时间，浏览器关了，cookie 就存在了。如果有过期时间，cookie 就会存储到硬盘上，浏览器关闭不影响 cookie。下次打开浏览器，cookie 还存在；

cookie 有大小的限制，4KB。

session：保存在服务器中，服务器有资源开销，分布式、跨系统不好实现；

Token：客户端可以将 Token 保存到任何地方，无限制，无状态，利于分布式部署。

网络

版权声明：本文内容由网络用户投稿，版权归原作者所有，本站不拥有其著作权，亦不承担相应法律责任。如果您发现本站中有涉嫌抄袭或描述失实的内容，请联系我们jiasou666@gmail.com 处理，核实后本网站将在24小时内删除侵权内容。