1. 网站交互体验升级

作为网友的我们，每天都会使用浏览器来逛各种网站，来满足日常的工作生活需求。

现在的交互体验还是很丝滑的，但早期并非如此，而是一锤子买卖。

1.1 无状态的 HTTP 协议

无状态的 HTTP 协议是什么鬼？

HTTP 无状态协议，是指协议对于业务处理没有记忆能力，之前做了啥完全记不住。每次请求都是完全独立互不影响的，没有任何上下文信息。

缺少状态意味着如果后续处理需要前面的信息，则它必须重传关键信息，这样可能导致每次连接传送的数据量增大。

如果大家没明白，可以想一下《夏洛特烦恼》里面的桥段：

大概明白了吧，假如一直用这种原生无状态的 HTTP 协议，我们每换一个页面可能就得重新登录一次，那还玩个球。

所以必须要解决 HTTP 协议的无状态，提升网站的交互体验，否则星辰大海是去不了的。

1.2 解决之道

整个事情交互的双方只有客户端和服务端，所以必然要在这两个当事者身上下手。

客户端来买单

客户端每次请求时把自己必要的信息封装发送给服务端，服务端查收处理一下就行。

服务端来买单

客户端第一次请求之后，服务端就开始做记录，然后客户端在后续请求中只需要将最基本最少的信息发过来就行，不需要太多信息了。

2. Cookie方案

Cookie 总是保存在客户端中。按在客户端中的存储位置，可分为内存 Cookie 和硬盘Cookie。

内存 Cookie 由浏览器维护，保存在内存中，浏览器关闭后就消失了，其存在时间是短暂的。硬盘 Cookie 保存在硬盘里，有一个过期时间。除非用户手工清理或到了过期时间，硬盘Cookie不会被删除，其存在时间是长期的。

2.1 Cookie 定义和作用

HTTP Cookie（也叫 Web Cookie 或浏览器 Cookie）是服务器发送到用户浏览器并保存在本地的一小块数据。它会在浏览器下次向同一服务器再发起请求时，被携带并发送到服务器上。

通常 Cookie 用于告知服务端两个请求是否来自同一浏览器，如保持用户的登录状态。Cookie 使基于无状态的HTTP协议记录稳定的状态信息成为了可能。

Cookie 主要用于以下三个方面：

• 会话状态管理（如用户登录状态、购物车等其它需要记录的信息）
• 个性化设置（如用户自定义设置、主题等）
• 浏览器行为跟踪（如跟踪分析用户行为等）

2.2 服务端创建 Cookie

当服务器收到 HTTP 请求时，服务器可以在响应头里面添加一个 Set-Cookie 选项。

浏览器收到响应后通常会保存下 Cookie，之后对该服务器每一次请求中都通过 Cookie 请求头部将 Cookie 信息发送给服务器。另外，Cookie 的过期时间、域、路径、有效期、适用站点都可以根据需要来指定。

2.3 B/S 的 Cookie 交互

服务器使用 Set-Cookie 响应头部向用户浏览器发送 Cookie信息。

一个简单的 Cookie 可能像这样：

Set-Cookie: <cookie名>=<cookie值> HTTP/1.0 200 OKContent-type: text/htmlSet-Cookie: yummy_cookie=chocoSet-Cookie: tasty_cookie=strawberry

客户端对该服务器发起的每一次新请求，浏览器都会将之前保存的Cookie信息通过 Cookie 请求头部再发送给服务器。

GET /sample_page.html HTTP/1.1Host: www.example.orgCookie: yummy_cookie=choco; tasty_cookie=strawberry

我来访问下淘宝网，抓个包看看这个真实的过程：

2.4 存在的问题

Cookie 常用来标记用户或授权会话，被浏览器发出之后可能被劫持，被用于非法行为，可能导致授权用户的会话受到攻击，因此存在安全问题。

还有一种情况就是跨站请求伪造 CSRF，简单来说 比如你在登录银行网站的同时，登录了一个钓鱼网站，在钓鱼网站进行某些操作时可能会获取银行网站相关的Cookie信息，向银行网站发起转账等非法行为。

跨站请求伪造（英语：Cross-site request forgery），也被称为 one-click attack 或者 session riding，通常缩写为 CSRF 或者 XSRF， 是一种挟制用户在当前已登录的 Web 应用程序上执行非本意的操作的攻击方法。跟跨网站脚本（XSS）相比，XSS 利用的是用户对指定网站的信任，CSRF 利用的是网站对用户网页浏览器的信任。

跨站请求攻击，简单地说，是攻击者通过一些技术手段欺骗用户的浏览器去访问一个自己曾经认证过的网站并运行一些操作（如发邮件，发消息，甚至财产操作如转账和购买商品）。

由于浏览器曾经认证过，所以被访问的网站会认为是真正的用户操作而去运行。这利用了 Web 中用户身份验证的一个漏洞：简单的身份验证只能保证请求发自某个用户的浏览器，却不能保证请求本身是用户自愿发出的。

不过这种情况有很多解决方法，特别对于银行这类金融性质的站点，用户的任何敏感操作都需要确认，并且敏感信息的 Cookie 只能拥有较短的生命周期。

同时 Cookie 有容量和数量的限制，每次都要发送很多信息带来额外的流量消耗、复杂的行为 Cookie 无法满足要求。

特别注意：以上存在的问题只是 Cookie 被用于实现交互状态时存在的问题，但并不是说 Cookie 本身的问题。

试想一下：菜刀可以用来做菜，也可以被用来从事某些暴力行为，你能说菜刀应该被废除吗？

3. Session 方案

3.1 Session 机制的概念

如果说 Cookie 是客户端行为，那么 Session 就是服务端行为。

Cookie 机制在最初和服务端完成交互后，保持状态所需的信息都将存储在客户端，后续直接读取发送给服务端进行交互。

Session 代表服务器与浏览器的一次会话过程，并且完全由服务端掌控，实现分配ID、会话信息存储、会话检索等功能。

Session 机制将用户的所有活动信息、上下文信息、登录信息等都存储在服务端，只是生成一个唯一标识 ID 发送给客户端，后续的交互将没有重复的用户信息传输，取而代之的是唯一标识 ID，暂且称之为 Session-ID 吧。

3.2 简单的交互流程

• 当客户端第一次请求 session 对象时候，服务器会为客户端创建一个 session，并将通过特殊算法算出一个 session 的 ID，用来标识该 session 对象；
• 当浏览器下次请求别的资源的时候，浏览器会将 sessionID 放置到请求头中，服务器接收到请求后解析得到 sessionID，服务器找到该 id 的 session 来确定请求方的身份和一些上下文信息。

3.3 Session 的实现方式

首先明确一点，Session 和 Cookie 没有直接的关系。可以认为 Cookie 只是实现 Session 机制的一种方法途径而已，没有 Cookie 还可以用别的方法。

Session和Cookie的关系就像加班和加班费的关系，看似关系很密切，实际上没啥关系。

Session 的实现主要两种方式：Cookie 与 URL 重写，而 Cookie 是首选方式。因为各种现代浏览器都默认开通 Cookie 功能，但是每种浏览器也都有允许 Cookie 失效的设置，因此对于 Session 机制来说还需要一个备胎。

将会话标识号以参数形式附加在超链接的URL地址后面的技术称为 URL 重写

原始 URL：

http://taobao.com/getitem?name=baymax&action=buy

重写后的 URL:

http://taobao.com/getitem?sessionid=1wui87htentg&?name=baymax&action=buy

3.4 存在的问题

由于 Session 信息是存储在服务端的，因此如果用户量很大的场景，Session 信息占用的空间就不容忽视。

对于大型网站必然是集群化&分布式的服务器配置。如果 Session 信息是存储在本地的，那么由于负载均衡的作用，原来请求机器 A 并且存储了 Session 信息，下一次请求可能到了机器 B，此时机器 B 上并没有 Session 信息。

这种情况下要么在 B 机器重复创建造成浪费，要么引入高可用的 Session 集群方案，引入 Session 代理实现信息共享，要么实现定制化哈希到集群 A，这样做其实就有些复杂了

4. Token 方案

Token 是令牌的意思，由服务端生成并发放给客户端，是一种具有时效性的验证身份的手段。

Token 避免了 Session 机制带来的海量信息存储问题，也避免了 Cookie 机制的一些安全性问题，在现代移动互联网场景、跨域访问等场景有广泛的用途。

4.1 简单的交互流程

• 客户端将用户的账号和密码提交给服务器；
• 服务器对其进行校验，通过则生成一个 token 值返回给客户端，作为后续的请求交互身份令牌；
• 客户端拿到服务端返回的 token 值后，可将其保存在本地，以后每次请求服务器时都携带该 token，提交给服务器进行身份校验；
• 服务器接收到请求后，解析关键信息，再根据相同的加密算法、密钥、用户参数生成 sign 与客户端的 sign 进行对比，一致则通过，否则拒绝服务；
• 验证通过之后，服务端就可以根据该 Token 中的 uid 获取对应的用户信息，进行业务请求的响应。

4.2 Token 的设计思想

以 JSON Web Token（JWT）为例，Token主要由三部分组成：

• Header 头部信息：记录了使用的加密算法信息；
• Payload 净荷信息：记录了用户信息和过期时间等；
• Signature 签名信息：根据 header 中的加密算法和 payload 中的用户信息以及密钥key来生成，是服务端验证服务端的重要依据。

header 和 payload 的信息不做加密，只做一般的 base64 编码。服务端收到 token 后剥离出 header 和 payload 获取算法、用户、过期时间等信息，然后根据自己的加密密钥来生成 sign，并与客户端传来的 sign 进行一致性对比，来确定客户端的身份合法性。

这样就实现了用 CPU 加解密的时间换取存储空间，同时服务端密钥的重要性就显而易见，一旦泄露整个机制就崩塌了，这个时候就需要考虑 HTTPS 了。

4.3 Token 方案的特点

• Token 可以跨站共享，实现单点登录；
• Token 机制无需太多存储空间。Token 包含了用户的信息，只需在客户端存储状态信息即可，对于服务端的扩展性很好；
• Token 机制的安全性依赖于服务端加密算法和密钥的安全性；
• Token 机制也不是万金油。

5. 总结

Cookie、Session、Token 这三者是不同发展阶段的产物，并且各有优缺点，三者也没有明显的对立关系，反而常常结伴出现，这也是容易被混淆的原因。

Cookie 侧重于信息的存储，主要是客户端行为。Session 和 Token 侧重于身份验证，主要是服务端行为。

三者方案在很多场景都还有生命力，了解场景才能选择合适的方案。

本文分享自华为云社区《Cookie、Session、Token 背后的故事-云社区-华为云》，作者： 龙哥手记。

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

Cookie和Session的用途

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

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

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

Token是什么

上面说到的Session和Cookie机制来保持会话，会存在一个问题：客户端浏览器只要保存自己的SessionID即可，而服务器却要保存所有用户的Session信息，这对于服务器来说开销较大，而且不利用服务器的扩展（比如服务器集群时，Session如何同步存储就是个问题）！

于是有人思考，如果把Session信息让客户端来保管而且无法伪造不就可以解决这个问题了？进而有了Token机制。

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

• uid：用户唯一身份标识

• timestamp：当前时间戳

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

• 其它附加参数。

Token机制下的认证流程

Token机制其实和Cookie机制极其相似，主要有以下流程：

1、用户登录进行身份认证，认证成功后服务器端生成Token返回给客户端；

2、客户端接收到Token后保存在客户端（可保存在Cookie、LocalStorage、SessionStorage中）；

3、客户端再次请求服务器端时，将Token作为请求头放入Headers中；

4、服务器端接收请求头中的Token，将用户参数按照既定规则再进行一次签名，两次签名若一致则认为成功，反之数据存在篡改请求失败。

（生成签名示例图）

（验证签名示例图）

Token与Cookie+Session的区别

Cookie其实也充当的是令牌作用，但它是“有状态”的；而Token令牌是无状态的，更利于分布式部署。

以上就是我的观点，对于这个问题大家是怎么看待的呢？欢迎在下方评论区交流 ~ 我是科技领域创作者，十年互联网从业经验，欢迎关注我了解更多科技知识！

session和cookie

在讲Token之前，先简单说说什么是session和cookie。

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

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

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

Token

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

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

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

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

基于Token的认证流程

整体的流程是这样的：

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

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

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

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

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

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

总结

• cookie：保存在浏览器种，有大小限制，有状态；
  

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

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

希望我的回答，能够帮助到你！我将持续分享Java开发、架构设计、程序员职业发展等方面的见解，希望能得到你的关注。

由Session到Token的身份验证演变过程理解Session、Cookie、Token

本文将从Web应用 由传统身份验证到基于Token的身份验证的演变过程的角度，介绍Session、Cookie、Token。

很久以前，Web 应用基本用作文档的浏览，如网络黄页。既然仅仅是浏览，因此服务器不需要记录具体用户在某一段时间里都浏览了哪些文档，每次请求都是一个新的HTTP协议，对服务器来说都是全新的。

基于Session的身份验证

随着交互式Web应用的兴起，比如，购物等需要登录的网站。引出了一个新的问题，那就是要记录哪些用户登录了系统进行了哪些操作，即要管理会话（什么是会话？简单的讲如果用户需要登录，那么就可以简单的理解为会话，如果不需要登录，那么就是简单的连接。），比如，不同用户将不同商品加入到购物车中， 也就是说必须把每个用户区分开。因为HTTP请求是无状态的，所以想出了一个办法，那就是给每个用户配发一个会话标识(Session id)，简单的讲就是一个既不会重复，又不容易被找到规律以仿造的随机字符串，使得每个用户的收到的会话标识都不一样， 每次用户从客户端向服务端发起HTTP请求的时候，把这个字符串给一并发送过来， 这样服务端就能区分开谁是谁了，至于客户端（浏览器）如何保存这个“身份标识”，一般默认采用 Cookie 的方式，这个会话标识(Session id)会存在客户端的Cookie中。

虽然这样解决了区分用户的问题，但又引发了一个新的问题，那就是每个用户（客户端）只需要保存自己的会话标识(Session id)，而服务端则要保存所有用户的会话标识(Session id)。 如果访问服务端的用户逐渐变多， 就需要保存成千上万，甚至几千万个，这对服务器说是一个难以接受的开销 。 再比如，服务端是由2台服务器组成的一个集群， 小明通过服务器A登录了系统， 那session id会保存在服务器A上， 假设小明的下一次请求被转发到服务器B怎么办？ 服务器B可没有小明 的 session id。

可能会有人讲，如果使小明登录时，始终在服务器A上进行登录（sticky session），岂不解决了这个问题？那如果服务器A挂掉怎么办呢？ 还是会将小明的请求转发到服务器B上。

如此一来，那只能做集群间的 session 复制共享了， 就是把 session id 在两个机器之间进行复制，如下图，但这对服务器的性能和内存提出了巨大的挑战。

因此，又想到如果将所有用户的Session集中存储呢，也就想到了缓存服务Memcached——由于 Memcached 是分布式的内存对象缓存系统，因此可以用来实现 Session 同步。把session id 集中存储到一台服务器上， 所有的服务器都来访问这个地方的数据， 如此就避免了复制的方式， 但是这种“集万千宠爱于一身”使得又出现了单点故障的可能， 就是说这个负责存储 session 的服务器挂了， 所有用户都得重新登录一遍， 这是用户难以接受的。

那么索性存储Session的服务器也搞成集群，增加其可靠性，避免单点故障，但不管如何，Session 引发出来的问题层出不穷。

于是有人就在思考， 为什么服务端必须要保存这session呢， 只让每个客户端去保存不行吗？可是服务端如果不保存这些session id ，又将如何验证客户端发送的 session id 的确是服务端生成的呢？ 如果不验证，服务端无法判断是否是合法登录的用户，对，这里的问题是验证， session 只是解决这个验证问题的而产生的一个解决方案，是否还有其它方案呢？

基于Token 的身份验证

例如， 小明已经登录了系统，服务端给他发一个令牌(Token)， 里边包含了小明的 user id， 后续小明再次通过 Http 请求访问服务器的时候， 把这个 Token 通过 Http header 带过来不就可以了。

服务端需要验证 Token是自己生成的，而非伪造的。假如不验证任何人都可以伪造，那么这个令牌(token)和 session id没有本质区别，如何让别人伪造不了？那就对数据做一个签名（Sign）吧， 比如说服务端用 HMAC-SHA256 加密算法，再加上一个只有服务端才知道的密钥， 对数据做一个签名， 把这个签名和数据一起作为 Token 发给客户端， 客户端收到 Token 以后可以把它存储起来，比如存储在 Cookie 里或者 Local Storage 中，由于密钥除了服务端任何其他用户都不知道， 就无法伪造令牌(Token)。

如此一来，服务端就不需要保存 Token 了， 当小明把这个Token发给服务端时，服务端使用相同的HMAC-SHA256 算法和相同的密钥，对数据再计算一次签名， 和 Token 中的签名做个对比， 如果相同，说明小明已经登录过了， 即验证成功。若不相同， 那么说明这个请求是伪造的。

这样一来， 服务端只需要生成 Token，而不需要保存Token， 只是验证Token就好了 ，也就实现了时间换取空间（CPU计算时间换取session 存储空间）。没了session id 的限制， 当用户访问量增大， 直接加机器就可以轻松地做水平扩展，也极大的提高了可扩展性。

Token顾名思义就是令牌、凭证、钥匙。只有这把钥匙，你才能打开门。token一般都是服务端生成，比如一个web系统，用户登录的时候，服务端校验用户名密码通过以后，会生成一个token，同时会生成refreshToken和一个过期时间。然后将refreshToken和token返回给客户端。客户端会将token保存下来。后续所有的请求都会携带这个token。服务端会判断当前token是否存在已经是否过期。如果token不存在或者过期就会拒绝本次请求。如果token过期怎么办，就用refreshToken刷新时间。当然这里可能还有别的方案。比如只生成token，每次请求的时候都刷新过期时间。如果长时间没有刷新过期时间，那token就会过期。

session就是回话，这是服务端的一种操作。当你第一次访问一个web网站的时候，服务端会生成一个session，并有一个sessionid和他对应。这个session是存储到内存中的，你可以向这个session中写入信息，比如当前登录用户的信息。sessionid会被返回到客户端，客户端一般采用cookie来保存。当然这个cookie不用人为写入。用tomcat容器来举个例子。当后端调用HttpServletRequest对象的getSession的方法的时候，tomcat内部会生成一个jsessonid（tomcat sessionid的叫法）。这个jsessonid会随本次请求返回给客户端。响应头信息

HTTP/1.1 200 OK
Set-Cookie: JSESSIONID=xxxxxxxxxxxxxxxxxxx

这个jessionid就会写到cookie中。之后jessionid就会通过cookie传递到服务端。

这里我们就会很清楚了，session的数据是存储到内存中。那问题就来了，如果我们的服务是分布式部署，有多台机器的话，可能我们第一次登陆的时候，我们把用户的信息存储到了session，但是后面的请求到了B机器上，那B机器是获取不到用户的session的。另外就是session存储在内存中，那服务器重启，session就丢失了，这就是他的弊端。现在有一些技术，例如session共享、iphash、session持久等也可以解决上述问题。

cookie是浏览器的一种策略。上述讲到了sessionid就是存储在cookie中的。我们知道http协议是无状态的，cookie就是用来解决这个问题的。cookie中可以用来保存服务端返回的一些用户信息的，例如前文提到的token、sessionid。每一次的请求，都会携带这些cookie。服务端从请求头中取到cookie中的信息，就可以识别本次请求的来源，这样，http是不是就变成有状态的了。

这里说几点cookie注意事项。

1、cookie存放在客户端，所以是不安全的。人为可以清除

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

3、cookie有大小的限制，4KB。