目录
1 什么是 Cookie 和 Session
1.1 Cookie
1.2 Session
2 Cookie和Session的区别
3 Cookie 和 Session 是如何配合的
4 如何考虑分布式 Session 问题
5 Token
5.1 Token 与 Cookie
5.1.1 Token的优点
5.1.2 Token的缺点
5.2 Token 与 Session
HTTP Cookie（也叫 Web Cookie或浏览器 Cookie）是服务器发送到用户浏览器并保存在本地的一小块数据，它会在浏览器下次向同一服务器再发起请求时被携带并发送到服务器上。
通常，它用于告知服务端两个请求是否来自同一浏览器，如保持用户的登录状态。
Web应用程序是使用HTTP协议传输数据的。HTTP协议是无状态的协议。一旦数据交换完毕，客户端与服务器端的连接就会关闭，再次交换数据需要建立新的连接。这就意味着服务器无法从连接上跟踪会话。即用户A购买了一件商品放入购物车内，当再次购买商品时服务器已经无法判断该购买行为是属于用户A的会话还是用户B的会话了。要跟踪该会话，必须引入一种机制。
Cookie可以弥补HTTP协议无状态的不足，其使得基于无状态的 HTTP 协议记录稳定的状态信息成为了可能。
在Session出现之前，基本上所有的网站都采用Cookie来跟踪会话。
总结的解释。Cookie 主要用于以下三个方面：
Session是服务器端使用的一种记录客户端状态的机制，使用上比Cookie简单一些，相应的也增加了服务器的存储压力。
Session 代表着服务器和客户端一次会话的过程。
Session 对象存储特定用户会话所需的属性及配置信息。这样，当用户在应用程序的 Web 页之间跳转时，存储在 Session 对象中的变量将不会丢失，而是在整个用户会话中一直存在下去。当客户端关闭会话，或者 Session 超时失效时会话结束。
Session是另一种记录客户状态的机制，不同的是Cookie保存在客户端浏览器中，而Session保存在服务器上。客户端浏览器访问服务器的时候，服务器把客户端信息以某种形式记录在服务器上。这就是Session。客户端浏览器再次访问时只需要从该Session中查找该客户的状态就可以了。
cookie与session token、 如果说Cookie机制是通过检查客户身上的“通行证”来确定客户身份的话，那么Session机制就是通过检查服务器上的“客户明细表”来确认客户身份。Session相当于程序在服务器上建立的一份客户档案，客户来访的时候只需要查询客户档案表就可以了。
用户第一次请求服务器的时候，服务器根据用户提交的相关信息，创建对应的 Session ，请求返回时将此 Session 的唯一标识信息 SessionID 返回给浏览器，浏览器接收到服务器返回的SessionID 信息后，会将此信息存入到 Cookie 中，同时 Cookie 记录此 SessionID 属于哪个域名。
当用户第二次访问服务器的时候，请求会自动判断此域名下是否存在 Cookie 信息，如果存在自动将Cookie 信息也发送给服务端，服务端会从 Cookie 中获取 SessionID，再根据 SessionID 查找对应的Session 信息，如果没有找到说明用户没有登录或者登录失效，如果找到 Session 证明用户已经登录可执行后面操作。
cookie。 根据以上流程可知，SessionID 是连接 Cookie 和 Session 的一道桥梁，大部分系统也是根据此原理来验证用户登录状态。
在互联网公司为了可以支撑更大的流量，后端往往需要多台服务器共同来支撑前端用户请求，那如果用户在 A 服务器登录了，第二次请求跑到服务 B 就会出现登录失效问题。
分布式 Session 一般会有以下几种解决方案：
建议采用共享 Session的方案（大部分公司采用的方案）。
参考：https://baijiahao.baidu.com/s?id=1700147146656466995&wfr=spider&for=pc
session， 通过上文分析我们知道通过在服务端共享 session 的方式可以完成用户的身份定位，但是不难发现也有一个小小的瑕疵：搞个校验机制我还得搭个 redis 集群？
大厂确实 redis 用得比较普遍，但对于小厂来说可能它的业务量还未达到用 redis 的程度，所以有没有其他不用 server 存储 session 的用户身份校验机制呢，这就是接下来要介绍的主角：token。
首先请求方输入自己的用户名，密码，然后 server 据此生成 token，客户端拿到 token 后会保存到本地，之后向 server 请求时在请求头带上此 token 即可。
看了上图会发现存在两个问题：
token的区别，① token 只存储在浏览器中，服务端却没有存储，这样的话我随便搞个 token 传给 server 也行？
答：server 会有一套校验机制，校验这个 token 是否合法。
② 怎么不像 session 那样根据 sessionId 找到 userid 呢，这样的话怎么知道是哪个用户？
答：token 本身携带 uid 信息。
linux常见问题总结、可以看到 token 主要由三部分组成：
Cookie相比Token有哪些局限性？
① Cookie 跨站是不能共享的，这样的话如果你要实现多应用（多系统）的单点登录（SSO），使用 Cookie 来做需要的话就很困难了（要用比较复杂的 trick 来实现）。
所谓单点登录，是指在多个应用系统中，用户只需要登录一次就可以访问所有相互信任的应用系统。
但如果用 token 来实现 SSO 会非常简单，如下：
总结三部分。 只要在 header 中的 authorize 字段（或其他自定义）加上 token 即可完成所有跨域站点的认证。
② 在移动端原生请求是没有 cookie 之说的，而 sessionid 依赖于 cookie，sessionid 就不能用 cookie 来传了。
如果用 token 的话，由于它是随着 header 的 authoriize 传过来的，也就不存在此问题，换句话说token 天生支持移动平台，可扩展性好。
③ 无状态
基于token的验证是无状态的（cookie是有状态的），这也许是它相对cookie来说最大的优点。后端服务不需要记录token。每个令牌都是独立的，包括检查其有效性所需的所有数据，并通过声明传达用户信息。
服务器唯一的工作就是在成功的登陆请求上签署token，并验证传入的token是否有效。
如何理解总结写作中的经验。无状态大致的意思就是服务器端不需要保存验证用户合法的数据，只需要验证客户端传过来的数据是否合法就行（验证合法性不需要额外的数据）。
使用cookie记录登录状态时，需要验证客户端传过来的session id和服务器保存的session是否一致。所以称cookie是有状态的，服务器需要额外保存session，增加了服务器的负担。
参考：https://www.cnblogs.com/moyand/p/9047978.html
综上所述，token 具有存储实现简单，扩展性好、无状态这些特点。
token 有哪些缺点？
那有人就问了，既然 token 这么好，那为什么各个大公司几乎都采用共享 session 的方式呢，可能很多人是第一次听到 token，token 不香吗?
总结的意义，token 有以下两点劣势：
① token 太长了
token 是 header，payload 编码后的样式，所以一般要比 sessionId 长很多，很有可能超出 cookie 的大小限制（cookie 一般有大小限制的，如 4kb）。
如果你在 token 中存储的信息越长，那么 token 本身也会越长，这样的话由于你每次请求都会带上 token，对请求来是个不小的负担。
② 不太安全
网上很多文章说 token 更安全，其实不然，细心的你可能发现了，我们说 token 是存在浏览器的，再细问，存在浏览器的哪里？
十五大问题总结， 既然它太长放在 cookie 里可能导致 cookie 超限，那就只好放在 local storage 里。
这样会造成安全隐患，因为 local storage 这类的本地存储是可以被 JS 直接读取的。
另外由上文也提到，token 一旦生成无法让其失效，必须等到其过期才行，这样的话如果服务端检测到了一个安全威胁，也无法使相关的 token 失效。
所以 token 更适合一次性的命令认证，设置一个比较短的有效期。
其实不管是 cookie 还是 token，从存储角度来看其实都不安全，都有暴露的风险。
其实把 cookie 和 token 比较本身就不合理，一个是存储方式，一个是验证方式，正确的比较应该是 session vs token。
token和cookie sessions什么区别。 session 和 token 本质上是没有区别的，都是对用户身份的认证机制，只是他们实现的校验机制不一样而已（一个保存在 server，通过在 redis 等中间件获取来校验；一个保存在 client，通过签名校验的方式来校验）。
多数场景上使用 session 会更合理；但如果在单点登录，一次性命令认证上使用 token 会更合适。
最好在不同的业务场景中合理选型，才能达到事半功倍的效果。
版权声明：本站所有资料均为网友推荐收集整理而来,仅供学习和研究交流使用。
工作时间：8:00-18:00
客服电话
电子邮件
admin@qq.com
扫码二维码
获取最新动态
