Cookie，Session，Token区别

放风讲故事

已于 2023-11-02 20:58:39 修改

阅读量1.8k

点赞数 85

于 2023-10-27 21:39:18 首次发布

本文链接：https://blog.csdn.net/2301_80092713/article/details/134083616

版权

计算机网络专栏收录该内容

1 篇文章 0 订阅

订阅专栏

声明

本文主要是Cookie，Session，Token区别的理解文章，如果有什么需要改进的地方还请大佬指出💐

🥦作者简介：大家好，我是青衿😉
🍄博客首页：CSDN主页石马农青衿
🌸每日一句：努力一点，优秀一点

3.1 Cookie 和 Session 的区别及痛点

一，Cookie解析

1.1 什么是Cookie？

Cookie 最开始被设计出来是为了弥补HTTP在状态管理上的不足。HTTP 协议是一个无状态协议，客户端向服务器发请求，服务器返回响应，故事就这样结束了，但是下次发请求如何让服务端知道客户端是谁呢？这种背景下，就产生了 Cookie。
Cookie 存储在客户端： cookie 是服务器发送到用户浏览器并保存在本地的一小块数据，它会在浏览器下次向同一服务器再发起请求时被携带并发送到服务器上。因此，服务端脚本就可以读、写存储在客户端的cookie的值。
cookie 是不可跨域的：每个 cookie 都会绑定单一的域名（绑定域名下的子域都是有效的），无法在别的域名下获取使用，同域名不同端口也是允许共享使用的。

1.2 Cookie的使用

一个cookie的设置以及发送过程分为以下四步：

客户端发送一个http请求到服务器端
服务器端发送一个http响应到客户端，其中包含Set-Cookie头部
客户端发送一个http请求到服务器端，其中包含Cookie头部
服务器端发送一个http响应到客户端

二，Session解析

2.1什么是Session？

Session其实就是另一种记录客户状态的机制，不同的是Cookie保存在客户端浏览器中，而Session保存在服务器上。客户端浏览器访问服务器的时候，服务器把客户端信息以某种形式记录在服务器上。这就是Session。客户端浏览器再次访问时只需要从该Session中查找该客户的状态就可以了。

需要注意的是：服务器使用session把用户的信息临时保存在了服务器上，用户离开网站后session会被销毁。这种用户信息存储方式相对cookie来说更安全，可是session有一个缺陷：如果web服务器做了负载均衡，那么下一个操作请求到了另一台服务器的时候session会丢失。

2.2Session的使用？

一，用户第一次请求服务器的时候，服务器根据用户提交的相关信息，创建对应的 Session
二，请求返回时将此 Session 的唯一标识信息 SessionID 返回给浏览器
三，浏览器接收到服务器返回的 SessionID 信息后，会将此信息存入到 Cookie 中，同时 Cookie 记录此 SessionID 属于哪个域名
四，当用户第二次访问服务器的时候，请求会自动判断此域名下是否存在 Cookie 信息，如果存在自动将 Cookie 信息也发送给服务端，服务端会从 Cookie 中获取 SessionID，再根据 SessionID 查找对应的 Session 信息，如果没有找到说明用户没有登录或者登录失效，如果找到 Session 证明用户已经登录可执行后面操作。
在这里插入图片描述

三，Token解析

3.1Cookie 和 Session 的区别及痛点

安全性：Session 是存储在服务器端的，Cookie 是存储在客户端的。所以 Session 相比 Cookie 安全，
存取值的类型不同：Cookie 只支持存字符串数据，想要设置其他类型的数据，需要将其转换成字符串，Session 可以存任意数据类型。
有效期不同： Cookie 可设置为长时间保持，比如我们经常使用的默认登录功能，Session 一般失效时间较短，客户端关闭（默认情况下）或者 Session 超时都会失效。存储大小不同：单个 Cookie 保存的数据不能超过4K，Session 可存储数据远高于 Cookie，但是当访问量过多，会占用过多的服务器资源。
拓展：Session痛点，看起来通过cookie + session 的方式是解决了问题，但是我们忽略了一个问题，上述情况能正常工作是因为我们假设 server是单机工作的，但实际在生产上，为了保障高可用，一般服务器至少需要两台机器，通过负载均衡的方式来决定到底请求该打到哪台机器上。

拓展：Session痛点

看起来通过 cookie + session 的方式是解决了问题，但是我们忽略了一个问题，上述情况能正常工作是因为我们假设 server 是单机工作的，但实际在生产上，为了保障高可用，一般服务器至少需要两台机器，通过负载均衡的方式来决定到底请求该打到哪台机器上。

假设登录请求打到了 A 机器，A 机器生成了 session 并在 cookie 里添加 sessionId 返回给了浏览器，那么问题来了：下次添加购物车时如果请求打到了 B 或者 C，由于 session 是在 A 机器生成的，此时的 B,C 是找不到 session 的，那么就会发生无法添加购物车的错误，就得重新登录了，此时请问该怎么办。主要有以下三种方式：

（1 ）session 复制

A 生成 session 后复制到 B, C，这样每台机器都有一份 session，无论添加购物车的请求打到哪台机器，由于 session 都能找到，故不会有问题

这种方式虽然可行，但缺点也很明显：

同一样的一份 session 保存了多份，数据冗余
如果节点少还好，但如果节点多的话，特别是像阿里，微信这种由于 DAU 上亿，可能需要部署成千上万台机器，这样节点增多复制造成的性能消耗也会很大。

（2）session 粘连

这种方式是让每个客户端请求只打到固定的一台机器上，比如浏览器登录请求打到 A 机器后，后续所有的添加购物车请求也都打到 A 机器上，Nginx 的 sticky 模块可以支持这种方式，支持按 ip 或 cookie 粘连等等，如按 ip 粘连方式如下

这样的话每个 client 请求到达 Nginx 后，只要它的 ip 不变，根据 ip hash 算出来的值会打到固定的机器上，也就不存在 session 找不到的问题了，当然不难看出这种方式缺点也是很明显，对应的机器挂了怎么办？

（3）session 共享

这种方式也是目前各大公司普遍采用的方案，将 session 保存在 redis，memcached 等中间件中，请求到来时，各个机器去这些中间件取一下 session 即可。

3.2 什么是Token？

Token，直译就是“令牌”的意思。因此它就是服务端生成的一串字符串，来作为客户端进行请求的一个令牌。当客户端第一次访问服务端时，服务端会根据传过来的唯一标识userId，运用一些算法，并加上密钥，生成一个Token，然后通过BASE64编码一下之后将这个Token返回给客户端，客户端将Token保存起来（可以通过数据库或文件形式保存本地）。下次请求时，客户端只需要带上Token，服务器收到请求后，会用相同的算法和密钥去验证Token。
最简单的Token组成:uid(用户唯一的身份标识)、time(当前时间的时间戳)、sign(签名，由Token的前几位盐以哈希算法压缩成一定长的十六进制字符串，可以防止恶意第三方拼接Token请求服务器)。

3.3 Token的验证流程

当用户登录成功之后, 服务器端就会通过指定算法生成一个 token，并设置过期时间，（可以将token 存储在redis，）再将这个token值返回给客户端；
客户端拿到 token 值之后,进行保存；
当客户端调用接口请求数据时,就会携带token值发送给服务器；
服务器接收到客户端的请求之后,会取出token值与保存（在redis中的）token值做对比。
如果token对比成功，说明用户处于登录状态，否则表示登录状态失效，需要用户重新登陆。用户每次重新登陆会刷新token的过期时间。

在这里插入图片描述

3.4 Token的优势

无状态、可扩展

在客户端存储的Tokens是无状态的，并且能够被扩展。基于这种无状态和不存储Session信息，负载负载均衡器能够将用户信息从一个服务传到其他服务器上。

如果我们将已验证的用户的信息保存在Session中，则每次请求都需要用户向已验证的服务器发送验证信息(称为Session亲和性)。用户量大时，可能会造成一些拥堵。

但是不要着急。使用tokens之后这些问题都迎刃而解，因为tokens自己hold住了用户的验证信息。

安全性

请求中发送token而不再是发送cookie能够防止CSRF(跨站请求伪造)。即使在客户端使用cookie存储token，cookie也仅仅是一个存储机制而不是用于认证。不将信息存储在Session中，让我们少了对session操作。

token是有时效的，一段时间之后用户需要重新验证。我们也不一定需要等到token自动失效，token有撤回的操作，通过token revocataion可以使一个特定的token或是一组有相同认证的token无效。

可扩展性

Tokens能够创建与其它程序共享权限的程序。例如，能将一个随便的社交帐号和自己的大号(Fackbook或是Twitter)联系起来。当通过服务登录Twitter(我们将这个过程Buffer)时，我们可以将这些Buffer附到Twitter的数据流上(we are allowing Buffer to post to our Twitter stream)。

使用tokens时，可以提供可选的权限给第三方应用程序。当用户想让另一个应用程序访问它们的数据，我们可以通过建立自己的API，得出特殊权限的tokens。

多平台跨域

我们提前先来谈论一下CORS(跨域资源共享)，对应用程序和服务进行扩展的时候，需要介入各种各种的设备和应用程序。

Having our API just serve data, we can also make the design choice to serve assets from a CDN. This eliminates the issues that CORS brings up after we set a quick header configuration for our application.

只要用户有一个通过了验证的token，数据和资源就能够在任何域上被请求到。

Access-Control-Allow-Origin: *

四，总结

cookie 储存在用户本地终端上的数据，服务器生成，发送给浏览器，下次请求统一网站给服务器。

session 会话，代表服务器与浏览器的一次会话过程，这个过程是连续的，也可以时断时续。 cookie中存放着一个sessionID，请求时会发送这个ID； session因为请求（request对象）而产生； session是一个容器，可以存放会话过程中的任何对象； session的创建与使用总是在服务端，浏览器从来都没有得到过session对象；

Token 令牌，是一种用于用户身份的验证方式

4.1Cookie与Session

1、cookie数据存放在客户的浏览器上，session数据放在服务器上。

2、cookie不是很安全，别人可以分析存放在本地的COOKIE并进行COOKIE欺骗，考虑到安全应当使用session。

3、session会在一定时间内保存在服务器上。当访问增多，会比较占用你服务器的性能，考虑到减轻服务器性能方面，应当使用COOKIE。

4、单个cookie保存的数据不能超过4K，很多浏览器都限制一个站点最多保存20个cookie

4.2 Session与Token

从身份认证的角度来看，token安全行比session好； Session 认证只是简单的把User 信息存储到Session 里，因为SID 的不可预测性，暂且认为是安全的。这是一种认证手段。而Token ，如果指的是OAuth Token或类似的机制的话，提供的是认证和授权，认证是针对用户，授权是针对第三方应用的。其目的是让其有权利访问某用户的信息。

4.3 Token与Cookie

Cookie是不允许垮域访问的，但是Token是支持的，前提是传输的用户认证信息通过HTTP头传输；

当我们授权（登录）一个程序时，Token就是作为一个依据，判断我们是否已经授权该软件；Cookie就是写在客户端的一个文件，里面包括我们的登录信息之类的，这样我们下次在登录某个网站，就会自动调用Cookie自动登录用户名；Session和Cookie差不多，只是Session是写在服务器端的文件，也需要在客户端写入Cookie文件，但是文件里是你的浏览器编号.Session的状态是存储在服务器端，客户端只有Session id；而Token的状态是存储在客户端。

文章到此就结束了，感谢各位小伙伴儿们的支持，点个关注把💐
在这里插入图片描述

放风讲故事

关注

85
点赞
踩
63

收藏

觉得还不错? 一键收藏
107
评论
Cookie，Session，Token区别

Cookie 最开始被设计出来是为了弥补HTTP在状态管理上的不足。HTTP 协议是一个无状态协议，客户端向服务器发请求，服务器返回响应，故事就这样结束了，但是下次发请求如何让服务端知道客户端是谁呢？这种背景下，就产生了 Cookie。Cookie 存储在客户端： cookie 是服务器发送到用户浏览器并保存在本地的一小块数据，它会在浏览器下次向同一服务器再发起请求时被携带并发送到服务器上。因此，服务端脚本就可以读、写存储在客户端的cookie的值。
复制链接

扫一扫