存储方式详解(cookie、session、Token)

本文详细解析了Cookie、Session和Token的概念及其工作原理,探讨了它们在Web开发中的应用,以及各自的优缺点,帮助读者理解这三种机制在用户身份验证和会话管理中的作用。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >


参考文献
HTTP无状态协议到底指的什么?
浏览器提供的几种存储
vuex页面刷新数据丢失的解决办法
Session Cookie Token 俊
彻底理解

发展


1、在很久以前,Web的工作只是文档浏览的一种方式,无论谁发请求给服务器,它都返回一样的文档,每一个请求对服务器而言都是全新的,是无状态的,不会记住刚刚是谁发的http请求。

2、但是随着Web应用的兴起,出现了像购物网站,需要登录的网站,就会面临一个问题,那就是要管理会话,必须知道是哪些人登录系统,哪个用户发来的请求。也就是说要区分不同的用户。但http是无状态请求的

什么是无状态呢
就是一旦客户端和服务器的数据交换完毕,就会断开连接,再次请求时才会重新连接,此时服务器无法判断用户身份,此时cookie和session就出现了。就是为了解决http无状态请求这个问题的


一、cookie

在这里插入图片描述
Cookie实际上是一小段的文本信息。客户端请求服务器,如果服务器需要记录该用户状态,就使用Response HeaderSet-Cookie向客户端浏览器颁发一个Cookie。客户端浏览器会把Cookie保存起来(自动保存起来了,不用手动保存)。当浏览器再请求该网站时,浏览器通过Request HeaderCookie把请求的网址连同该Cookie一同提交给服务器(也是自动带上的cookie的)。服务器检查该Cookie,以此来辨认用户状态。服务器还可以根据需要修改Cookie的内容。

注意点:

存储位置(客户端):

  1. 设置过期时间失效(只要设置了过期时间cookie就会存储在硬盘里面)
  2. 当会话结束时失效,即关闭浏览器窗口(如果没有设置Expires,cookie就会存储在内存里面

缺点:

  1. 因为是存储在客户端,所以不安全,有可能会被获取伪造(可以考虑加密)
  2. 存储量有限、不超过4k

当 Cookie 带 httpOnly 选项时,客户端则无法通过 js 代码去访问(包括读取、修改、删除等)这个 Cookie。

二、session

除了使用Cookie一种方法,Web应用程序中还经常使用第二种方法Session来记录客户端状态。Session是服务器端使用的一种记录客户端状态的机制,使用上比Cookie简单一些,相应的也增加了服务器的存储压力。
在这里插入图片描述
1、用户向服务器发送用户名和密码
2、服务器通过验证后,会在当前会话(session)里面保存相关数据,比如用户角色,登陆时间等;
3、服务器会通过Response Header的Set-Cookie向用户返回一个sessionId,客户端存入Cookie中
4、用户随后的每一次请求,都会通过Request Header的Cookie,将sessionId发送给服务器
5、服务器收到 sessionId 后,找到之前保存下来的数据,由此得知用户身份

注意点:

  1. 存储位置:服务器中(磁盘文件或数据库里面)
  2. 因为保存在服务端,所以相对于保存在客户端的cookie来说更加安全了

cookie和session区别

Cookie和Session的区别

  1. 存储位置不同:cookie存储在客户端,session存储在服务端
  2. 存储容量不同:cookie最多能保存4KB的数据,session来说没有上限,所以高并发时,session会很耗服务器资源
  3. 存储方式不同:cookie只能保存ASCLL字符串,session能够保存任何类型的数据
  4. 安全性:cookie对客户是可见的,可能会被伪造,session存储在客户端的,相对安全
  5. 有效期不同:cookie可以手动设置有效时间,session在关闭会话窗口之后就会丢失失效

三、token

引入背景(session不足):

1、服务器压力增大:
session是保存在服务端的,客户端只需要保存自己的sessionId,但是服务端要保存所有用户的sessionId,如果访问服务器的人多了,可能有几十万,几百万,这对服务器来说是一个巨大的开销。

2、CSRF跨站伪造请求攻击:
session是基于cookie进行用户识别的,cookie如果被获取,用户就有可能受到CSRF的攻击

3、拓展性不强:
如果将来搭建了多个服务器,比如用多个服务器组成的一个集群,虽然每个服务器处理的业务逻辑都是一样的,但session是保存在服务器里面的,多个服务器之间是不共享的,用户第一次访问服务器A,A将该用户的session保存起来,但是当用户下一次请求的是服务器B,此时B里面就找不到该用户的信息,就判定该用户不合法。

针对session拓展性不强,人们想出了一些小伎俩:

  • session sticky:就是让用户一直访问同一个服务器,俗话说就是黏在一起。但是对应的服务器也会有挂掉的时候,所以不管用
  • session复制,就是让不同服务器都有相同session,从一个服务器复制到其他服务器
  • 把session集中存储到一个地方,所有服务器都来访问此机器。但是此机器也会有挂掉的时候

对小小的session来说,以上的方法都不好,负担沉重

由此,token就应运而生

Token(令牌)认证机制(对比签名)

Token是服务端生成的一串字符串,以作客户端进行请求的一个令牌,当第一次登录后,服务器生成一个Token便将此Token返回给客户端,以后客户端只需带上这个Token前来请求数据即可,无需再次带上用户名和密码。

Token把状态交给用户来管理,这样的确解决了空间问题,但是如果服务器不保存这些会话标识(session要保存在服务器端),我们又改如何确定这些会话标识是不是由我生成的呢。如果无法验证他们是不是合法的,就无法保证登陆的安全性

Token解决这个问题的关键在于验证

验证的关键的生成一个签名,一般服务器运用哈希算法(比如HMAC-SHA256),加上只有服务端才知道的密钥,对数据(比如userId)做一个签名,把这个签名和数据一起作为token发给客户端,由于密钥别人不知道,所以不能伪造token
在这里插入图片描述
这个token服务端不用保存,当客户端把这个token发过来时,服务端再用同样的哈希算法对数据做一个签名,看看此时生成的签名和token带回来的签名是否一致,如果一致,我知道用户已经登录过来,并且可以直接获取到用户的id。
在这里插入图片描述
在这里插入图片描述
其验证过程如下:

  1. 客户端使用用户名跟密码请求登录
  2. 服务端收到请求,去验证用户名与密码
  3. 验证成功后,服务端会签发一个 Token,再把这个 Token 发送给客户端
  4. 客户端收到 Token 以后可以把它存储起来,比如放在 Cookie 里或者 Local Storage 里
  5. 客户端每次向服务端请求资源的时候需要带着服务端签发的 Token
  6. 服务端收到请求,然后去验证客户端请求里面带着的 Token,如果验证成功,就向客户端返回请求的数据

Token的验证是无状态的,我们不用将用户信息保存在服务端,每一次请求都要带上token,token应该在http的头部发送从而保证了http请求无状态。这样我们就可以减轻服务端的压力,实现了用计算时间(因为进行加密解密需要消耗时间)换取空间,session是空间换时间同时也增强了可拓展性

Token生成原理:

什么是token及怎样生成token《JSON Web Token 简介》

  1. 将荷载payload,以及Header信息进行Base64加密,形成密文payload密文,header密文。
  2. 将形成的密文用点号链接起来,用服务端秘钥进行HS256加密,生成签名.
  3. 将前面的两个密文后面用点号链接签名形成最终的token返回给服务端。jwt最终形成的字符串结构如:xxxxx.yyyyy.zzzzz,每一部分都是基于base64url编码的值
    在这里插入图片描述

token优势:
1、无状态、可扩展
在客户端存储的Tokens是无状态的,并且能够被扩展。基于这种无状态和不存储Session信息,负载负载均衡器能够将用户信息从一个服务传到其他服务器上。如果我们将已验证的用户的信息保存在Session中,则每次请求都需要用户向已验证的服务器发送验证信息(称为Session亲和性)。用户量大时,可能会造成 一些拥堵。但是不要着急。使用tokens之后这些问题都迎刃而解,因为tokens自己hold住了用户的验证信息。

2、安全性

请求中发送token而不再是发送cookie能够防止CSRF(跨站请求伪造)。即使在客户端使用cookie存储token,cookie也仅仅是一个存储机制而不是用于认证。不将信息存储在Session中,让我们少了对session操作。token是有时效的,一段时间之后用户需要重新验证。我们也不一定需要等到token自动失效,token有撤回的操作,通过token revocataion可以使一个特定的token或是一组有相同认证的token无效。

3、可扩展性

Tokens能够创建与其它程序共享权限的程序。例如,能将一个随便的社交帐号和自己的大号(Fackbook或是Twitter)联系起来。当通过服务登录Twitter(我们将这个过程Buffer)时,我们可以将这些Buffer附到Twitter的数据流上(we are allowing Buffer to post to our Twitter stream)。使用tokens时,可以提供可选的权限给第三方应用程序。当用户想让另一个应用程序访问它们的数据,我们可以通过建立自己的API,得出特殊权限的tokens。

4、多平台跨域

我们提前先来谈论一下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、localStorage、sessionStorage、indexDB

cookie:

Cookie实际上是一小段的文本信息。是为了解决http无状态请求的问题。客户端请求服务器,如果服务器需要记录该用户状态,就使用Response HeaderSet-Cookie向客户端浏览器颁发一个Cookie。客户端浏览器会把Cookie保存起来(自动保存起来了,不用手动保存)。当浏览器再请求该网站时,浏览器通过Request HeaderCookie把请求的网址连同该请求域下(请求谁就带上谁的cookie)的Cookie一同提交给服务器(也是自动带上的cookie的)。服务器检查该Cookie,以此来辨认用户状态。服务器还可以根据需要修改Cookie的内容。

cookie属性作用
name字段一个cookie的名称
value一个cookie的值
domain可以访问此cookie的域名
path可以访问此cookie的页面路径
Sizecookie大小
httponly若此属性为True,客户端则无法通过 js 代码去访问(包括读取、修改、删除等)这个 Cookie。
secure设置是否只能在https下来传递此条cookie。
expires/Max-Age设置cookie超时时间。如果设置的值为一个时间,则当到达该时间时此cookie失效。不设置的话默认是session,意思是cookie会和session一起失效,当浏览器关闭(并不是浏览器标签关闭,而是整个浏览器关闭)后,cookie失效。
SameSite不跨站发送cookie到第三方网站,减少 CSRF 的攻击;Strict (仅允许一方请求携带 Cookie,即浏览器将只发送相同站点请求的 Cookie,即当前网页 URL 与请求目标 URL 完全一致);Lax(允许部分第三方请求携带 Cookie,除了get请求可以);None (无论是否跨站都会发送 Cookie);之前默认是 None 的,Chrome80 后默认是 Lax
《预测最近面试会考 Cookie 的 SameSite 属性》《阮一峰Cookie 的 SameSite 属性》

使用:

  • document.cookie='名字=值'

cookie不足:

  • 大小:一个cookie的大小被限制在4KB。每个域名有数量限制(不同浏览器可能不同,ie的话限制50个)
  • 带宽:cookie是随HTTP事务一起被发送的,因此会浪费一部分发送cookie时使用的带宽。过多的Cookie会带来巨大的性能/资源浪费。Cookie是紧跟域名的,同一个域名下的所有请求都会携带Cookie。很多场景其实并不需要身份验证,比如请求一张图片或者CSS文件,这种时候携带Cookie也就造成了性能/资源的浪费

4kb指的是:
《Cookie有数量和大小的限制》《浏览器cookie数量和大小限制》
各浏览器的cookie每一个name=value的大小大概在4k;所以4k并不是一个域名下所有的cookie共享的,而是一个名(name)、值(value)和等号(=)的大小;而对于每个域名name个数的限制,发现ie10大概是50个,如果超过了50个,最前面设置的就会挨删除把新的放进去.当出现这种溢出替换的过程时,就会导致当前进程的ie的这个域名无法访问,需要重启浏览器才行;

为了弥补Cookie的局限性,WebStorage就产生了。WebStorage是HTML5中新增的本地存储解决方案,包含了SessionStorage和LocalStorage两类。有了WebStorage之后,Cookie就能够安心只作为客户端与服务器交互的通道(保持客户端状态)了,不用再操心存储的事情。

WebStorage两个主要目标:
(1)提供一种在cookie之外存储会话数据的路径。
(2)提供一种存储大量可以跨会话存在的数据的机制。

LocalStorage

将数据保存在客户端本地的硬件设备(通常指硬盘,也可以是其他硬件设备)中,即使浏览器被关闭了,该数据仍然存在,下次打开浏览器访问网站时仍然可以继续使用。

特点(默认也不能跨域访问):

  • 保存的数据长期存在(没有设置有效期的api,需要设置有效期的话要自己封装实现)
  • 存储限制大小为5MB左右(每个域名下),超过5m不会把旧数据清空而只会报错
  • 仅在客户端使用,不和服务端进行通信

使用:

  • localStorage.setItem(name, val);
  • localStorage.getItem(name);

使用场景:

  • 倾向于用它来存储一些内容稳定的资源。比如图片内容丰富的电商网站可以使用LocalStorage来存储Base64格式的图片字符串。

sessionStorage

译-在多个标签页之间共享sessionStorage
将数据保存在session对象中。所谓session,是指用户在浏览某个网站时,从进入网站到浏览器关闭所经过的这段时间,也就是用户浏览这个网站所花费的时间。session对象可以用来保存在这段时间内所要求保存的任何数据。

特点:

  • 会话级别的浏览器存储,数据只在当前标签页有效,关闭标签页则删除了
  • 每个标签页都是一次会话,只在当前会话生效。(只能在同一标签页下共享)
  • 存储限制大小为5MB左右(每个域名是5M

使用:

  • sessionStorage.setItem('key','value')
  • sessionStorage.getItem('key');

使用场景:

  • SessionStorage更适合用来存储生命周期和它同步的会话级别的信息,这些信息只适用于当前的会话。比如微博就使用SessionStorage存储单次会话的浏览足迹

tip:这两者的区别在于,sessionStorage为临时保存,而localStorage为永久保存。

indexDB

IndexedDB是一种低级的API,使用索引来实现对其间存储数据的高性能搜索,用于客户端需要存储大量结构化数据。他可以看作是一个运行在浏览器上的非关系型数据库。既然是数据库了,那就不是5M、10M这样小打小闹的级别了,理论上来说,IndexedDB是没有存储上限的,一般来说不会小于250M。另外,它不仅可以存储字符串,还可以存储二进制数据

### 回答1: CookieSessionToken是三种常见的Web应用程序认证和授权机制。 Cookie是客户端储认证和授权信息的一种机制,用于在浏览器和服务器之间进行状态管理。当用户首次登录时,服务器会在响应中设置一个包含认证和授权信息的Cookie,然后浏览器会将这个Cookie储起来,并在下一次请求时将其一起发送给服务器,以便服务器能够识别用户。 Session是在服务器储认证和授权信息的一种机制,用于跟踪用户在Web应用程序中的活动。当用户首次访问Web应用程序时,服务器会为其创建一个Session,然后在后续请求中使用这个Session来管理用户状态。Session通常通过Cookie在浏览器和服务器之间交互。 Token是一种轻量级的认证和授权机制,用于在不使用CookieSession的情况下在浏览器和服务器之间进行状态管理。当用户登录成功时,服务器会生成一个Token,并将其发送给浏览器;浏览器在后续请求中将该Token带上,以便服务器能够识别用户并进行授权。Token通常使用JWT(JSON Web Token)格式进行编码和传输。 ### 回答2: cookiesessiontoken是Web开发中常用的三种身份验证与状态管理的技术,它们具有各自的特点和优缺点。 cookie是一种浏览器保在用户计算机中的小文件,可以储一些用户信息和网站状态。它的主要作用是让网站在用户多次访问时可以识别用户,实现用户身份验证和储一些数据。有的站点还会使用cookie来追踪用户行为,以便提供更好的个性化服务。但是,cookie只能保较小的数据量,并且在一些安全风险,比如cookie可被拦截和篡改带来的安全问题。 session是在服务器端保的用户信息,它使用一个服务器端生成的唯一标识符(SessionID)来标识用户,以便让服务器知道它们是同一个用户。一般情况下,SessionID是保cookie中的。用户在访问网站时,服务器会自动创建一个与该用户对应的session,将SessionID写入cookie,并将用户的状态信息储在服务器的内或磁盘上,以便后续使用。相比于cookiesession不能被篡改,避免了安全问题。但是,session储在服务器端,会增加服务器的负担,而且如果用户访问量很大,服务器session数据可能会消耗很多内和磁盘空间。 token是一种基于JSON Web Token(JWT)或其他加密算法的令牌机制,可以用于在客户端和服务器之间进行身份验证和状态管理。它的工作方式与cookiesession不同,它不需要在服务器储用户信息,客户端只需要将token与每个请求一起发送给服务器即可。通过加密算法可以确保token具有不可伪造和可信任的安全性。token相比于cookiesession有以下优点:1)减轻服务器负担,不需要在服务器储状态信息;2)支持跨域访问;3)可以灵活调整token的过期时间和访问权限。但是,token在一些安全问题,比如token可以被窃取和泄露,因此需要加强安全措施,比如使用HTTPS等安全通讯协议。 综上所述,cookiesessiontoken各自具有不同的优缺点和应用场景,开发人员需要根据实际情况选择合适的技术来实现身份验证和状态管理。 ### 回答3: 1. Cookie Cookie(HTTP Cookie)是由Web服务器发送到用户浏览器,储在用户本地计算机上的小文件。当浏览器再次加载该站点时,它会将Cookie发送回服务器。主要用于记录Web站点用户的活动、登录状态、购物车、喜好设置等。 Cookie的特点: - 储在用户本地计算机上,大小约为4KB; - 可以由Web服务器设置失效时间; - 每个Cookie只能储一种信息,因此需要多个Cookie储不同的信息。 2. Session Session(会话)是一种在Web服务器储状态的机制。当用户访问Web站点时,Web服务器为该用户创建一个Session对象。该对象由唯一的Session ID(会话ID)和相关的信息组成,如用户ID、储在服务器上的数据等。 Session的特点: - 储在Web服务器上,可储大量数据; - 可以设置失效时间; - 每个用户只有一个Session对象,可以储多种信息。 3. Token Token(令牌)是在用户登录后由Web服务器生成的一段随机字符串。服务器将令牌发送给客户端(如浏览器),客户端每次请求操作时需要携带这个令牌。服务器会验证令牌的有效性并返回对应的结果。常用于身份验证和访问控制。 Token的特点: - 储在客户端,大小不固定; - 没有失效时间,只有服务器失效(如修改密码)时才会失效; - 可以根据需要设置不同权限的Token,实现不同级别的访问控制。 总体来说,CookieSessionToken都是记录Web站点用户状态的机制。CookieSession储在服务器和客户端之间,主要用于记录用户的活动和状态;而Token储在客户端,用于身份验证和访问控制。不同的机制有不同的特点和应用场景,需要根据实际情况选用合适的方式。
评论 3
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值