【计算机网络】八股文

【计算机网络】八股文 | 第四章

零、前言
一些建议及推荐阅读
十、HTTP无状态/安全之Cookie/Session/Token
- Cookie/Session/token的基础 (知识点）
- Cookie/Session面临的问题（知识点）
- Cookie的作用及常用场景
- 客户端禁用 Cookie 首部时，如何传递 Cookie 信息？
- Session的作用及常用场景
- Session可能带来的问题
- Session的作用域
- 当客户端关闭后，服务端不关闭，两次获取Session是同一个？
- 客户端不关闭，服务器关闭后，两次获取的session是同一个吗？
- Session什么时候被销毁？失效时间？
- Cookie与Session的区别
- 既然盗取了Cookie，无论是Session还是Cookie都一样会被冒充，那为什么需要Session呢？
- Cookie和Session怎么选择
- Cookie, localStorage, sessionStorage的区别
- 关于Token是无状态的知识扩展及思考
- Token如何避免查库的思考
- Token保存的位置
- Token的应用场景
- JWT与传统Token的区别
- JWT的应用场景
十一、关于Cookie/Session/Token的总结
- 11.1 三种机制与网络攻击/安全的关系
- - 11.1.1 Cookie
  - 11.1.2 Session
  - 11.1.3 Token
- 11.2 从Cookie到JWT的发展总结
- 11.3 从Cookie到JWT的区别总结
- 11.4 从Cookie到JWT的应用总结
下一章笔记

零、前言

承接前面第一章的笔记：
【计算机网络】八股文 | 第三章

笔记链接：【计算机网络】八股文 | 第三章笔记
主要内容：
主要包括的知识有HHTP的劫持与攻击，DNS与XSS劫持以及相关的定义与方式，HTTP的两种连接法师，Keep-alive的理解与作用，HHTP缓存的相关知识点等知识要点。

本章主要内容为Cookie/Session/token的相关知识点，以及常见面试题目。

原创文章，未经同意请勿转载

一些建议及推荐阅读

建议可以直接看另外的三篇博客，是笔者我原创的相关关于Cookie到Token的详细系列，比起现在这篇笔记，下面这四篇的笔记时间是笔者整理后的，所以更加推荐。

上章：主要介绍一下背景和Cookie。
链接：【前端知识】Cookie, Session,Token和JWT的发展及区别（一）
中章：主要介绍一下Session并总结一下Cookie和Session。
链接：【前端知识】Cookie,Session,Token和JWT的发展及区别（二）
下章：主要介绍Token的相关定义及理解
链接：【前端知识】Cookie,Session,Token和JWT的发展及区别（三）
终章：主要介绍JWT并总结JWT和Token的区别，以及总结Cookie到Token的区别与发展。
链接：【前端知识】Cookie,Session,Token和JWT的发展及区别（四）

⚠ ❗ ❗ ❗ ❗ ❗如果你已经看了上面这四篇就没有必要来看这篇笔记了

HTTP Cookie Session Token_27">十、HTTP无状态/安全之Cookie/Session/Token

建议看这个知识点后，去看一下浏览器的本地存储（这个笔记链接我后面再放吧）

Cookie Sessiontoken__30">Cookie/Session/token的基础 (知识点）

【背景】
首先，介绍一下Cookie/Session的背景，也就是由于HTTP的无状态属性。

HTTP是一种不保存状态，即无状态协议。HTTP协议自身不对请求和响应之间的通信状态进行保存。也就是说这一次请求和上一次的请求是没有关联的。无状态的好处就是可以快速响应。但是如果服务端需要辨别请求时哪个客户端发送，或者需要关联两个请求/响应时，就需要获取请求或者响应的状态，因此，为了使某个域名下的所有网页能够共享某些状态数据，引申出了Session和Cookie。

那么什么是Cookie/Session/token🤔

首先，三者都是用于标识用户的机制。下面分别介绍一下三者的基本定义吧。

Cookie
Cookie是一种小型文本文件(包含一个唯一的标识符)，通常由Web服务器创建，包含用户信息、登录凭证及访问权限等信息。当用户第一次访问网站服务器时，会由Web服务器发送到用户浏览器，并存储在浏览器中。当再次访问同一网站时，浏览器会将该 Cookie 发送回服务器。服务器可以根据 Cookie 中的信息来标识用户。

数据位置：Cookie 通常是放在 HTTP 请求头中的 "Cookie" 字段中。Cookie 被放在请求头中，而不是放在请求体中。这是因为在请求头中，Cookie 可能会被认为是不安全的，因为它可以被截获和篡改。而放在请求头中，可以确保 Cookie 的安全性。同时，服务器端也会检查请求头中的 Cookie 字段，以确保客户端发送的 Cookie 是有效的。

存储位置：客户端浏览器

关于Cookie更加详细的介绍：Cookie详细介绍笔记
Session
与Cookie不同，Session是在存储在服务器上的一种数据结构，可以理解为一个状态列表，用来跟踪用户的状态。对于 Session，在服务器与客户端建立连接时，服务器会为每个客户端创建一个唯一的标识符 Session ID，并将其发送到客户端浏览器中。客户端浏览器会将 Session ID 保存在 Cookie 中，以便在后续的访问中传递给服务器。服务器收到Cookie后解析出Session Id，再去Session列表中查找，才能找到相应Session，用来识别客户端的状态信息。

数据位置：Session 通常放在 HTTP 响应头中。Session ID 放置在 HTTP 响应头中的“Session ID”字段中

存储位置：服务器

关于Session更加详细的介绍：Session详细介绍笔记
Token
1. Token本质
  Token 本质上就是访问资源的凭证。一般是用户通过用户名和密码登录成功之后，服务器将登陆凭证做数字签名，加密之后得到的字符作为token。
2. Token定义
  在浏览器中，Token 是指一种用于身份验证和授权的无状态的字符串，由用户唯一身份标识，当前时间戳，签名（防止第三方恶意拼接）和可选的固定参数（固定参数是为了避免多次查库）组成。通常，Token 是由服务器生成并发送给浏览器的，浏览器会在请求中添加接收到的 Token ，并发送给服务器，以验证用户身份和权限。因此，服务器可以使用 Token 来验证客户端的身份信息，并根据 Token 中的信息对客户端进行授权。此外，服务器通常会将 Token 存储在浏览器的 Cookie 中，以便在后续的请求中使用。（用户信息都被加密到token中，服务器收到token后解密就可知道是哪个用户。）
数据位置：Token可以放在请求体，请求头和URL的query部分。其中:
(1)请求体:Token 可以放在请求体中，放在请求体中，可以确保 Token 的安全性。同时，服务器端也会检查请求体中的 Authorization 头部，以确保客户端发送的 Token 是有效的。

(2)请求头：通常放在 HTTP 请求头中的“Authorization”字段中

(3)URL的query部分:例如 /page?token=ABC123。这样，客户端在访问这个 URL 时，需要同时将 Token 发送回服务器，以便服务器能够验证其合法性和有效性。

💡 url传输token的主要危害: 会暴露token值。URL携带token是不安全的，会暴露token值，token可以放在请求header的Authorization中，在https下传输，保证token传输的安全. token应该在服务端生成，密钥也在服务端，校验在服务端，这是起码的安全，另外token也应该有时效性。

(4) HTTP Cookies: 将 token 存储在浏览器的 Cookies 中，这样每次请求都会自动带上 token，但是需要注意安全性问题。

💡 token 可以放在 Cookie ，但在功能上的话不推荐。token本身提出来就是为了防止CSRF（跨站请求伪造）问题，但把token放在Cookie中，则token还是会随Cookie自动携带至请求中，防止不了CSRF攻击。容易产生CSRF（跨站请求伪造）问题，token一般存储在SessionStorage/localStorage里面。token的出现就是为了解决用户登录后的鉴权问题，如果采用Cookie+Session的鉴权方式，则无法有效地防止CSRF攻击，同时，如果服务端采用负载均衡策略进行分布式架构，Session也会存在一致性问题，需要额外的开销维护Session一致性。

存储位置：token在客户端一般存放于localStorage，Cookie，或sessionStorage中。在服务器一般存于数据库中。

Token存储的位置：
1. 存储在localStorage中，每次调用接口的时候都把它当成一个字段传给后台
2. 存储在Cookie中，让它自动发送，不过缺点就是不能跨域
3. 拿到之后存储在localStorage中，每次调用接口的时候放在HTTP请求头的Authorization字段里面。
4. Token组成
  token 也称作令牌，由uid+time+sign[+固定参数]
  - uid: 用户唯一身份标识
  - time: 当前时间的时间戳
  - sign: 签名, 使用 hash/encrypt 压缩成定长的十六进制字符串，以防止第三方恶意拼接
  - 固定参数(可选): 将一些常用的固定参数加入到 token 中是为了避免重复查库。这些固定参数通常包括:
    1. Token 创建时间:Token 创建的时间戳，以秒为单位。
    2. Token 版本号:Token 版本的数字标识符。
    3. 创建者 ID:Token 创建者的 ID。
    4. 有效期:Token 的有效期，以秒为单位。
💡 为什么可以避免重复查库？
这是因为，在获取 Token 时，服务器只需要验证 Token 的合法性和有效性，而不需要每次访问都查询数据库。通常情况下，服务器需要查询数据库来获取用户的信息，例如用户 ID、用户名、密码等，以便验证用户的身份。如果 Token 中包含这些用户信息，那么服务器只需要验证 Token 的合法性和有效性，就可以知道用户是否登录成功，而不需要查询数据库。这样就可以减少系统的负载，提高系统的性能和响应速度。

关于Token更加详细的介绍：Token详细介绍笔记

Cookie Session_99">Cookie/Session面临的问题（知识点）

Cookie面临的问题
- CSRF(跨站请求伪造)攻击，这个也好解决，很多框架都屏蔽这个问题
- 有的客户端不支持Cookie，需要手动设置，比如小程序
- 浏览器对Cookie有限制，不能手动设置Cookie，对于混合嵌套的开发有问题，比如小程序跳转H5页面，不能携带Cookie
- 浏览器对单个Cookie保存的数据不能超过4K，很多浏览器都限制一个站点最多保存20个Cookie
Session面临的问题
- 负载均衡多服务器的情况，不好确认当前用户是否登录，因为多服务器不共享seesion。这个问题也可以将Session存在一个服务器中来解决，但是就不能完全达到负载均衡的效果。
- 每个客户端只需存储自己的Session Id，但是服务端却需要存储所有用户Session Id，对服务器也是一个压力。

Cookie 和 token 都存放在 header 中，为什么不会劫持 token？
由于浏览器会自动发送 Cookie 到服务器，因此攻击者可以利用这种特点进行 csrf 攻击。

而通常 token 是不放到 Cookie 中的，需要浏览器端使用 JS 自行保存到 localstorage 中，在请求时也需要手动的加入到请求头中，因此不容易引发 csrf 攻击。

Cookie_113">Cookie的作用及常用场景

常用场景总结：（1）登录状态及用户信息的管理；（2）跟踪用户行为，统计分析，广告定位；（3）记住用户偏好设置，定制页面；（4）创建购物车；（5）缓存数据，用于搜索历史和浏览记录；（6）跨页面数据传递，实现数据共享与同步 …
展开：
- 登录状态及用户信息的管理——》用户身份认证，登录状态保持：用户登录和用户信息管理是常见的功能。可以使用 cookie 来存储用户登录状态信息，例如用户的登录凭证、用户信息等。通过 Cookie，可以在客户端和服务器之间传递用户信息，实现用户登录状态的保持，避免了每次访问页面都需要重新验证身份的问题。
- 跟踪用户行为（自动性）——》统计分析，统计用户访问网站的习惯，广告定位：通过记录用户行为等信息，跟踪用户的访问、页面浏览、点击等数据，进行统计分析，根据这些统计分析信息，可以为客户提供定制化的上网服务。同时，广告商也可借此为向用户展示相关的广告。
- 记住用户偏好设置（设置性/被动）——》定制页面，提供个性化服务：可以使用 Cookie 来存储用户的偏好设置信息来提供个性化的服务，例如用户的语言、主题等，使得用户下次打开浏览器时可以继续使用之前的偏好设置。
- 缓存数据——》用于搜索历史和浏览记录，减少服务器压力：可以使用 Cookie 来存储搜索历史和浏览记录等信息，提高网站的性能。比如自动填写表单场景，如果用户曾经输入过某些信息，那么这些信息可以被保存在 Cookie 中，在用户返回该页面时可以自动带出。
- 跨页面数据传递——》实现数据的共享与同步：Cookie 可以在同一个网站的不同页面之间传递数据，比如购物车中的商品信息。
经典场景之购物车：Cookie购物车一般指网站上的电子商务功能，在用户浏览产品后，将所选商品信息保存到浏览器的Cookie中，并在结账时读取Cookie中的信息以便显示或更新所选商品内容和数量。通常情况下，Cookie购物车还会在用户离开网站后保存所选商品信息，以便用户下次访问同一网站时继续购物，或在用户登录到网站时提供更个性化的服务。然而，由于安全原因，有些用户可能不愿意让浏览器储存他们的个人信息（例如地址和支付方式），因此一些商家采用了其他方法来保存购物车内容。需要注意的是，使用 Cookie 存储数据时应当注意数据的安全性和敏感性。敏感信息，例如用户的密码、支付信息等，不应当存储在Cookie中，而应当使用更加安全的方式。

CookieCookie123">客户端禁用 Cookie 首部时，如何传递 Cookie 信息？

可以将 Cookie 信息放到 URL的 params 中或者请求的 body 中，但一般的解决方案是放在 url 的 params 中，通过重写 URL的方式传递。

由于Cookie可以被人为的禁止，必须有其他机制以便在Cookie被禁止时仍然能够把session id传递回服务器。经常被使用的一种技术叫做URL重写，就是把Session id直接附加在URL路径的后面，附加方式也有两种：

一种是作为URL路径的附加信息，表现形式为http://…/xxx;jsessionid=ByOK3vjFD75aPnrF7C2HmdnV6QZcEbzWoWiBYEnLerjQ99zWpBng!-145788764
另一种是作为查询字符串附加在URL后面，表现形式为
http://…/xxx?jsessionid=ByOK3vjFD75aPnrF7C2HmdnV6QZcEbzWoWiBYEnLerjQ99zWpBng!-145788764
这两种方式对于用户来说是没有区别的，只是服务器在解析的时候处理的方式不同，采用第一种方式也有利于把session id的信息和正常程序参数区分开来。

Session_132">Session的作用及常用场景

常用场景总结：（1）登录状态及用户信息的管理；（2）跟踪用户行为，统计分析，个性化推荐；（3）实现数据共享，多步骤操作；（4）网站安全；（5）处理后台任务；（6）消息提醒及表单数据存储等 …
展开：
- 登录状态及用户信息的管理——》用户登录认证，登录状态保持：当用户成功登录网站时，服务器会创建一个Session，保存用于标识该用户的id等信息，在用户注销或超时后清除Session。这样，在用户持续访问网站时，服务器就可以识别匹配上述信息的Session，从而知道该请求来自哪个用户。
- 跟踪用户行为（自动性）——》统计分析，个性化推荐：通过Session保存用户活动信息，比如搜索历史记录，点击次数等，可以更好地了解用户的兴趣和喜好，从而为用户提供更好的服务和推荐。
- 实现数据共享，多步骤操作：Session可以被多个页面和请求之间共享使用，如在购物车中添加多个商品时，可以使用Session来保存这些数据，并在结账时将它们全部加载出来。当用户需要通过多个步骤完成某项操作时，如注册、预订、支付等，使用Session可以在不同的页面间共享数据，并确保数据的完整性和正确性。
- 网站安全：某些网站采用Session技术来记录用户的行为。例如，如果网站监测到同一个ip地址下连续登录失败次数过多，则可能认为攻击者正在尝试用暴力破解的方式攻击该帐号，那么服务器就可以采取措施比如限制登录尝试次数等。
- 处理后台任务：某些web应用程序利用后台任务处理框架，以便在后台执行后台操作。 Session是一种适合处理此类情况的方法，可以保障任务执行的独立性和任务的执行状态。
- 消息提醒：当应用程序需要在某些页面上显示未读消息数目时，可以将未读消息数量保存在Session中，这样在用户访问页面时直接从Session中获取未读消息数量即可。
- 表单数据存储：当用户填写表单或提交数据时，使用Session来缓存表单数据，以便用户在一定时间内重新打开页面时可以继续编辑。

Session_143">Session可能带来的问题

面临的挑战当然也包括Session本身的缺点，这里主要从解决的角度来讲：

内存占用问题 ——》解决方法：需要合理利用Session存储数据，避免存储过多的无用信息，定时清理过期Session，使用缓存等技术。
分布式问题 ——》解决方法：可以从存储和分布的角度分别来解决。
- 从存储的角度，可以使用集中式Session存储方案，如使用Redis或Memcached等缓存中间件存储Session信息，将Session交由这些中间件来管理。
- 从分布的角度，可以让相同 IP 的请求在负载均衡时都打到同一台机器上。以 Nginx 为例，可以配置 ip_hash 来实现。
安全问题 ——》解决方法：在传输过程中使用加密技术，使用HTTPS协议，在服务端对Session进行有效期和有效性等方面进行控制等。
生命周期问题，Session过期问题 ——》解决方法：使用定时器定时刷新Session，或者将Session的过期时间设置得更长一些，以确保Session不会过早失效。
负载均衡问题 ——》解决方法：可以使用集中式Session存储方案，如使用Redis或Memcached等缓存中间件存储Session信息，将Session交由这些中间件来管理；也可以使用Session复制或Session共享等技术。
Session固定攻击问题：Session固定攻击是一种攻击方式，攻击者通过获取到攻击目标的Session ID，然后模拟该Session ID进行攻击。为了避免这种攻击，应该在Session创建时随机生成一个Session ID，不要使用容易猜测和重复的ID。
并发问题：当多个用户同时访问同一个资源时，容易发生并发问题，例如两个用户同时修改一个Session中的值，会造成数据不一致。为了避免这种问题，应该使用同步技术来保证数据的一致性。

Session_154">Session的作用域

一般来说，每次请求不同的域都会新创建一个Session。
对于多标签的浏览器来说，在一个浏览器窗口中，多个标签同时访问一个页面，Session是一个。
对于多个浏览器窗口之间，同时或者相隔很短时间访问一个页面，Session是多个的，和浏览器的进程有关。
对于一个同一个浏览器窗口，直接录入URL访问同一应用的不同资源，Session是一样的。

Session_160">当客户端关闭后，服务端不关闭，两次获取Session是同一个？

默认情况下不是。
如果需要相同，则可以创建Cookie，键为JSESSIONID，设置最大存活时间，让Cookie持久化保存。
在客户端关闭后，服务端并不会立即关闭Session。但是取决于Session的实现方式和配置。
- 如果使用基于Cookie的Session，首次创建Session时会往客户端浏览器发送一个Cookie，当浏览器关闭后该Cookie会被删除。当用户再次访问站点时，浏览器并不会发送已经删除掉的Cookie，因此会重新创建一个新的Session。所以两次获取Session是不同的。
- 如果使用基于URL重写的Session实现，URL中会带有Session ID参数，服务器会基于这个Session ID来匹配已经存在的Session。当用户关闭浏览器后，打开一个新的浏览器访问时，URL中不再带有上一个Session的ID，服务器就会认为这是一次新的会话，并重新创建一个新的Session。因此，两次获取Session也是不同的。
- 如果使用了持久化Session管理技术，例如集中式缓存、数据库等存储机制，服务端的Session在客户端关闭后并不会受到影响，并且通过相同的Session ID，可以继续访问这个Session。因此两次获取Session是同一个。但需要注意的是，在设置Session的过期时间等方面需要进行合理的控制，以防Session信息长时间占用服务器资源，影响系统性能。

客户端不关闭，服务器关闭后，两次获取的session是同一个吗？

不是同一个，创建Session的对象分配的地址值是随机的。但是要确保数据不丢失。tomcat自动完成以下工作

Session的钝化：在服务器正常关闭之前，将Session对象系列化到硬盘上。
Session的活化：在服务器启动后，将Session文件转化为内存中的Session对象即可。

Session_171">Session什么时候被销毁？失效时间？

服务器关闭。
Session对象调用invalidate()。
Session默认失效时间：30分钟，可以配置修改

Cookie Session_175">Cookie与Session的区别

Session更像用户信息档案表，里面包含了用户的认证信息和登录状态等信息。而Cookie就更像用户通行证

存储位置不同：Cookie数据是存储在客户端（浏览器）的，而Session数据则是存储在服务器端的，通常会保存在内存或者数据库中。
安全性： Session 比 Cookie 安全，Cookie 以明文形式存储在客户端，Session数据只保留了一个会话ID在客户端，具体数据都存放在服务端，相对来说具有较高的安全性。
支持的数据类型不同：Cookie 只支持存字符串数据，Session 可以存任意数据类型。
有效期不同： Cookie 可设置为长时间保持，比如我们经常使用的默认登录功能。Cookie可以设置生命周期，即在设置的时间段内一直存在于客户端，过期后才会被删除。Session则一般是在用户关闭浏览器或者长时间不操作后自动失效。
存储大小不同：单个Cookie通常最多支持4KB的数据存储，而Session则没有严格的限制，可以存储更大的数据量。
主要场景不同：对于简单而且不敏感的数据通常使用Cookie保存，如购物车信息、用户在站点的行为记录等；而对于复杂且敏感的数据使用Session保存，如用户的账号信息等。

Cookie Session Cookie Session_183">既然盗取了Cookie，无论是Session还是Cookie都一样会被冒充，那为什么需要Session呢？

在这里插入图片描述
（1）安全性：虽然Session和Cookie都可以被盗取，但Session比Cookie更安全，因为在使用Session时，Session信息是保存在服务器端的，而非客户端。当客户端请求服务器时，服务器会验证Session是否合法，只有合法的Session才会返回相应的数据。这样做的好处是在一定程度上确保了客户端请求的安全性，即使有人盗取了Session ID，也无法通过合法的请求来获取数据。
（2）设计目的：当然，如果应用程序不安全，存在漏洞或弱口令等问题，那么盗取 Cookie 的行为可能会绕过 Session 验证，从而访问到 Session 数据。尽管盗取 Cookie 可以被用于冒充身份，但 Session 本身并不是为了防范盗取 Cookie 而设计的。相反，Session更加偏向是一种数据存储方式，用于在用户与 Web 应用程序之间保持联系，目的是提供一个安全的、可靠的方式来标识和跟踪用户身份，以便对其进行访问控制和授权。
（3）Cookie只是实现Session机制的其中一种方案，并不是唯一的方法：除了使用Cookie来存储Session ID外，还可以使用其他方式来实现Session机制。比如URL 重写，隐藏表单域等。
（4）考虑客户端压力：用Session只需要在客户端保存一个ID，实际上大量数据都是保存在服务端。如果全部用Cookie，数据量大的时候客户端是没有那么多空间的。并且客户端数据量变大，网络传输的数据量也会变大。

💡 现在大多都是Session + Cookie，但是只用Session不用Cookie，或是只用Cookie，不用Session在理论上都可以保持会话状态。可是实际中因为多种原因，一般不会单独使用。

【如何回答】

Session 本身不是为了防范盗取 Cookie 而设计的，但它可以防止未经授权的访问，从而保护应用程序的数据安全。

Session 本身并不是为了防范盗取 Cookie 而设计的。相反，Session 是一种数据存储方式，用于在用户与 Web 应用程序之间保持联系。在使用 Session 的情况下，每当用户访问 Web 应用程序时，应用程序会创建一个 Session 对象，并将 Session ID 附加到用户的 Cookie 中。浏览器会将该 Cookie 发送给服务器，服务器会验证该 Cookie 并允许用户访问应用程序。因此，即使盗取了 Cookie，也无法直接访问 Session 数据，因为 Session 数据被存储在服务器上，而不是在 Cookie 中。当然，如果应用程序不安全，存在漏洞或弱口令等问题，那么盗取 Cookie 的行为可能会绕过 Session 验证，从而访问到 Session 数据。
之所以需要 Session，是因为在许多应用程序中，需要对用户身份进行跟踪和标识，以便对其进行访问控制和授权。如果没有 Session，则需要使用其他方式来跟踪用户身份，例如用户名和密码等。但是，这种方式可能存在安全风险，因为黑客可能会尝试盗取这些信息。
- Cookie只是实现Session的其中一种方案。虽然是最常用的，但并不是唯一的方法。禁用Cookie后还有其他方法存储，比如放在url中
- 现在大多都是Session + Cookie，但是只用session不用Cookie，或是只用Cookie，不用session在理论上都可以保持会话状态。可是实际中因为多种原因，一般不会单独使用
- 用session只需要在客户端保存一个id，实际上大量数据都是保存在服务端。如果全部用Cookie，数据量大的时候客户端是没有那么多空间的。
- 如果只用Cookie不用Session，那么账户信息全部保存在客户端，一旦被劫持，全部信息都会泄露。并且客户端数据量变大，网络传输的数据量也会变大

Cookie Session_203">Cookie和Session怎么选择

Session 解决方案需要在服务端存储客户端的数据，分布式服务器需要设置单独且唯一的数据中心，占用资源较大。但是客户端携带的Session Id 不包含的用户信息，较为安全。
Cookie的解决方案不需要在服务器存储客户端的数据，占用资源较小，可拓展性较高；请求携带的Cookie 携带着用户信息，相对来说，没那么安全；从数据量上来看，Cookie 一般都比 Session Id 大，传输过程中占用较大资源。
简而言之, Session 有如用户信息档案表, 里面包含了用户的认证信息和登录状态等信息. 而 Cookie 就是用户通行证

Cookie_localStorage_sessionStorage_209">Cookie, localStorage, sessionStorage的区别

Cookie, localStorage, sessionStorage的区别
在这里插入图片描述

Token_212">关于Token是无状态的知识扩展及思考

🤔 如何理解Token是无状态的? 这里的无状态是指什么？

这里先略微的说一下：Token并不一定都是无状态的！只不过我们平常说的Token更多偏向于说的是JWT，而JWT标准的访问令牌Token通常被设计成无状态的，所以并不是所有的Token都是无状态的，需要根据Token类型和场景来做判断。比如，Session Token和基于OAuth2.0的授权码。Session Token通常是服务器端生成的一段字符串，用于标识用户会话信息。服务器会将该Token存储在缓存或数据库中，以便在用户请求时验证其有效性。由于Token存储在服务器上，因此可以视为具有状态。

🙄 Token无状态的定义
Token无状态属性是指后端服务的状态，而非HTTP协议本身的状态。所以这里的无状态定义与HTTP无状态的属性定义是不一样的！

那什么是后端服务的状态呢？
后端服务的状态根据两个来自相同发起者的请求在服务器端是否具有上下文关系分为两种：有状态服务和无状态服务。
1. 无状态服务（stateless service）：对单次请求的处理，不依赖其他请求，也就是说，处理一次请求所需的全部信息，要么都包含在这个请求里，要么可以从外部获取到（比如说数据库），服务器本身不存储任何信息。
2. 有状态服务（stateful service）： 则相反，它会在自身保存一些数据，先后的请求是有关联的。
3. 简单来说就是： 有状态就是把一个通信分多次传输，后面的通信会受制于前面的通信，而无状态就是一次全给他也不管他能不能接收，前后通信无关联。
Token无状态
之所以说Token是无状态，是因为Token是包含有关用户身份和权限信息的字符串，所有的状态信息附加在Token上，服务端并可以不保存Token的相关信息，即不会保存关于客户端的任何状态信息，也就是说在每次请求中都需要提供Token并由服务器进行验证，而不是依赖服务器缓存存储的信息来验证权限。
简单来说，Token的无状态属性是相对服务端而言的。对于服务端来说，它并不保存任何关于Token的信息，只是根据Token所携带的信息来做出响应。

🤔 Token不是为了解决HTTP无状态吗？那岂不是矛盾了？那无状态是怎么解决的？
根据上面的介绍，我们知道Token的无状态特性与HTTP无状态特性不能等同，它们之间是无关的。因此，Token确实是为了解决HTTP无状态而产生的一种解决方案，但在使用过程中并不会与Token的无状态属性矛盾。Token的作用是提供一个短暂的标识符，通过在发送请求时携带该标识符，并通过服务器对Token的验证来获取客户端的状态信息。这种利用客户端的存储机制可以在无状态的HTTP协议上实现“记住”客户端身份和许可状态，而不需要服务器端存储大量的用户信息，从而提高了Web应用程序的可扩展性和性能。简单来说，Token通过在客户端和服务器之间传递信息来维护通信状态。

这里推荐一个知乎答主对无状态的解释，感觉比较专业👍：HTTP是一个无状态的协议。这句话里的无状态是什么意思？ - 灵剑的回答 - 知乎

🤔 那Cookie和Session是不是无状态的？
与Token的无状态不同，Cookie - Session 模型是常见的有状态模型。根据前面对无状态的定义及Session,Cookie的介绍，我们知道Session会在服务端维持一个状态列表信息，因此，Session是有状态的。当然这里的有状态定义与通信协议本身的有状态定义并无关联。当然单独的Cookie跟Token的设置可以是无状态也可以是有状态，但现在一般Cookie都会与SessionID结合适用，所以一般来说Cookie也就是我们上面所说的有状态。

✍ 服务状态与HTTP协议状态无关
HTTP协议是无状态的协议，这个其实跟服务的状态是无关的。一个服务不管使用何种协议，都可以在服务层面上是有状态的，因为这和通信协议无关，只需要它在响应请求时改变自己的状态即可。所以说，服务本身有没有状态、支不支持会话，其实跟HTTP协议是否有状态是无关的。

Token_240">Token如何避免查库的思考

🤔 为什么可以避免重复查库？(这里主要是指JWT，不是传统的Token）
这是因为，在获取 Token 时，服务器只需要验证 Token 的合法性和有效性，而不需要每次访问都查询数据库。在基于Session的身份认证中，服务器需要查询数据库来获取用户的信息（前面我们根据Session ID来查库），以便验证用户的身份。而 Token 则包含用户的信息（其实这里就是在内存检索缓存的结果，Token保存在客户端），不需要进行数据库的查询，也就说服务器只需要验证 Token 的合法性和有效性，就可以知道用户是否登录成功。这样就可以避免重复查询数据库，减少系统的负载，进而提高系统的性能和响应速度。

Token_244">Token保存的位置

在HTTP通信过程中的数据位置：
Token可以放在请求体，请求头和URL的query部分。其中：
- HTTP 请求头：Token 通常放在 HTTP 请求头中的“Authorization”字段中
- URL的query部分：例如 /page?token=ABC123。这样，客户端在访问这个 URL 时，需要同时将 Token 发送回服务器，以便服务器能够验证其合法性和有效性。
  
  💡 url传输Token的主要危害: 会暴露token值。URL携带token是不安全的，会暴露Token值，Token可以放在请求header的Authorization中，在https下传输，保证Token传输的安全。 Token应该在服务端生成，密钥也在服务端，校验在服务端，这是起码的安全，另外Token也应该有时效性。
- HTTP Cookies: 将Token存储在浏览器的 Cookies 中，这样每次请求都会自动带上
  Token，但是需要注意安全性问题。
  
  💡 Token 可以放在 Cookie ，但在功能上的话不推荐。Token本身提出来就是为了防止CSRF（跨站请求伪造）问题，但把token放在cookie中，则Token还是会随Cookie自动携带至请求中，防止不了CSRF攻击。容易产生CSRF（跨站请求伪造）问题，Token一般存储在sessionStorage/localStorage里面。token的出现就是为了解决用户登录后的鉴权问题，如果采用Cookie+Session的鉴权方式，则无法有效地防止CSRF攻击，同时，如果服务端采用负载均衡策略进行分布式架构，Session也会存在一致性问题，需要额外的开销维护Session一致性。
Token存储的位置：
Token在客户端一般存放于localStorage，Cookie，或sessionStorage中。
- 存储在Cookie中 ：好处就是比较简单，可以自动发送，方便管理，但存储在Cookie中需要确保其被设置为 HttpOnly 和 Secure 标志，以避免恶意代码窃取或使用 Cookie，进而进行 CSRF 或 XSS 攻击。同时 Token 应该尽可能地缩短过期时间，增加其安全性。同时，由于Cookie存储空间有限（一般4KB左右），所以无法存储过大的Token。
- 存储在localStorage中 ：localStorage 是一种 HTML5 标准中定义的数据存储机制，可以将键值对永久地存储在浏览器中。与 Cookie 相比，localStorage 的读取速度更快，而且大小空间也相较于 Cookie 大得多，通常可达到 5MB 左右。将Token存储在localStorage中，则每次调用接口时会将Token当成一个字段传给后端。使用 localStorage 虽然可以有效避免 CSRF 攻击，但容易受到 XSS 攻击，使得攻击者能够访问本地存储数据。由于 Token 的保密性较强，如果将其存储为 localStorage，需要设置合适的加密和验证机制，以防止泄露和污染等风险。
- 存储在sessionStorage中 ：sessionStorage 和 localStorage 类似，但是在关闭浏览器窗口或标签页之后就会立即失效。如果应用程序需要重新加载，Token 将不能继续使用，需要重新生成或登录获取新的 Token。
🤔三种存储方式如何选择？
总结：标记用户与跟踪用户行为的情况，推荐使用Cookie；适合长期保存在本地的数据（令牌），推荐使用localStorage；敏感账号一次性登录，推荐使用sessionStorage；存储大量数据的情况、在线文档（富文本编辑器）保存编辑历史的情况，推荐使用indexedDB。
- Cookie：如果只需要在当前请求之后再使用 Token，或者仅允许实现某些页面交互所需的信息传输，则可考虑使用 Cookie 存储 JWT Token。适用于需要存储用户喜好设置、最近搜索历史信息等业务场景。同时，记住密码功能通常也使用 Cookie 存储登录凭证。
- localStorage：对于一些需要跨或长期保存身份认证信息、购物车明细等结构化数据来说，可以选择使用 localStorage 存储。适用类似于购物车、筛选器状态等需要长期缓存的应用场景。例如，将文本编辑器中的草稿保存在本地以防丢失。
- sessionStorage：如果是临时保留会话数据或交互式操作组件状态等需要短暂保存的数据，则选择 sessionStorage 更为恰当。适用于对性能要求较高或会话期间经常更改的数据，例如表格列位置和大小设置、选项卡之前切换所选提示等操作信息。

Token_266">Token的应用场景

美国对Token的定义有三类，第一类是货币型；第二类是应用型；第三类是证券型。从这三种类型，我们也可以知道Token的应用还有哪些了。

下面是Token的一些常见应用和用途：

身份认证和授权控制：Token可以用于身份验证和授权访问，例如在网站或应用程序中使用Token作为登录凭据。
可以作为支付方式，进行数字货币和加密货币交易：Token可以用于代表特定数量的货币、股票或其他资产，以方便快速交易，例如比特币(Bitcoin)、莱特币(Litecoin)等。
可以作为奖励和积分：一些企业使用Token作为奖励计划和积分系统的一部分，鼓励用户参与并推广其产品和服务。Token是游戏内经济体系的基础，例如某些游戏会有金币、钻石、积分等类型的Token。
安全性口令：Token可以用于增加系统的安全性，例如在密钥加密、口令哈希、对称密钥配对等领域。
门禁控制：Token也可以用于门禁控制，例如智能卡或RFID标签等。
区块链：Token是区块链上的重要组成部分，例如以太币(ETH)就是以太坊(Ethereum)平台上的Token，用于支付交易手续费或购买其他Token等。
广告投放：在移动应用广告中，应用程序可以生成具有唯一用户标识符的Token并将其发送到广告服务平台。根据收到的Tokens服务平台可以更好地衡量广告效果，并更准确地针对广告受众群体。
辅助追溯，进行审查和监视：Token还可以增加系统的审计跟踪和可追溯性。每个Token都包含特定的元数据，例如时间戳、用户标识符、访问权限等，可以追踪谁在什么时候访问了什么资源，并便于对其进行审查和监视。

在软件设计与开发方面，Token机制常见的应用场景:

用户在Winform系统，如C/S架构的客户端登录系统,使用系统服务；
用户在web浏览器端登录系统,使用系统服务；
用户在手机端（Android/iOS）登录系统,使用系统服务；
用户使用开放接口登录系统,调用系统服务；
用户在PC处理登录状态时通过手机扫码授权手机登录（使用得比较少）；
用户在手机处理登录状态进通过手机扫码授权PC进行登录（比较常见）

JWT Token_286">JWT与传统Token的区别

前面提到Token不是也是说避免多次查库吗？需要注意的是现在很多文章中讲到的Token更多的偏向JWT，而不是传统的Token。所以看文章时，需要注意一下这一点。因此，这里讨论的主要是JWT跟我们传统的Token的区别是什么。其实它们的区别主要体现在接收的信息是否需要进入数据库查询信息。传统的Token需要查库是因为它们通常采用的是基于带状态的用户认证机制，也就是我们前面所说的有状态的Token。在这种有状态的机制下，每个Token就必须与后端存储（比如数据库或者服务器缓存）进行交互，以此来验证Token的合法性和有效性。而我们现在所讲的JWT也就是我们前面所说的无状态Token啦。与传统的Token不同，JWT将用户信息加密到Token里面，服务器不保存任何用户信息，服务器通过使用保存密钥验证JWT Token的准确性，只要准确即可通过验证。

因此，JWT的出现改善了传统Token需要查库验证用户信息，而JWT不用查库或者少查库，直接在服务端进行校验。因为用户的信息及加密信息包含在JWT的第二分部Payload（有效荷载）和第三部分的Signature（签名）中，只要在服务端进行校验便可，并且校验也是JWT自己实现的。

这里JWT校验是JWT自己实现是指JWT校验过程中，检查JWT合法性的算法是服务器根据JWT中的规范来完成的。在验证JWT时，需要对比从请求中获取到的JWT前面和服务端根据相同的密钥计算出来的签名是否一致，所以我们通常说JWT校验是JWT自己实现，JWT自己提供签名及签名算法规范。

JWT_292">JWT的应用场景

JWT主要应用在两个方面，一个是鉴权，另外一个是信息交换。有效地使用JWT可以减少服务器查询数据库的次数。

Authentication（鉴权）：JWT也是我们常见的授权登录方案。当使用JWT登录鉴权，则一旦用户登录，每个后继的请求都包含HWT，从而允许用户访问该令牌允许的路由，服务和资源。由于JWT的轻量性及跨域性，JWT也被广泛地应用在单点登录等场景中。
Information Exchange（信息交换） ：除了经典的登录鉴权，JWT也跟Token一样，可用于信息交换。JWT可以在各通信方间安全传输信息，而且根据前面的描述，JWT中可以包含自定义数据，借助自定义数据我们也可以传输一些非默认字段的数据。

那根据前面对JWT两大应用方向的描述，JWT有哪些具体的使用场景呢？

单点登录（Single Sign-On，SSO）：JWT可以适用于分布式的单点登录场景，可用于实现SSO，使用户只需登录一次，就可以在多个应用程序或网站中访问受保护的资源。
无状态认证：传统的基于会话（session）的身份验证需要在服务器上维护会话状态，而JWT是一种无状态的认证机制，完全由客户端持有，不需要在服务器端存储任何信息，因此可以轻松地将认证信息传递给多个服务端。
安全的跨域数据传输：JWT可以使用跨域认证解决方案，而且可以通过在令牌里加入签名，来保证数据在传输过程中不被篡改和窃取。
基于角色的访问控制：JWT可以编码包含用户角色等信息的声明（Claim），从而方便根据用户角色控制对资源的访问权限。
前端分离项目、移动应用程序开发（移动app、小程序、H5）：由于移动应用程序通常没有基于会话的身份验证的概念，所以可以使用 JWT 来进行安全身份验证。

虽然相比于传统的Token，JWT具有无状态及安全性高等优点，但JWT并不适用于所有的应用场景，如果需要频繁更改权限、需要回收某些权限、需要撤销访问令牌等情况下，则使用JWT就不适合了。

Cookie Session Token_305">十一、关于Cookie/Session/Token的总结

11.1 三种机制与网络攻击/安全的关系

从Cookie到Token，我们也知道他们的安全系数也在逐渐的增强，那它们与前面提到的网络攻击有什么关系，存在怎么样程度的安全风险呢？

Cookie_308">11.1.1 Cookie

🎯 Cookie与CSRF攻击的关系
因为Cookie在浏览器发出任何请求中都会被自动携带同时发送，包括跨站请求。所以攻击者可以很容易利用Cookie的这个属性来伪造一个跨站请求，然后诱导用户在已经登录目标网站的情况下，执行该跨站请求，从而利用用户的Cookie实现用户信息的窃取。因此，Cookie很容易受到CSRF攻击。
一般来说，普通的CSRF攻击只是利用了用户的Cookie来盗用信息。需要注意的是，CSRF攻击者并不能直接读取或者修改到受害者的 Cookie 内容，而是拿着受害者提交的完整报文（包括 Cookie）去攻击目标网站。
🎯 Cookie如何应对CSRF攻击？
1. 为了防范 CSRF 攻击，可以使用过期时间短、HttpOnly、Secure、SameSite、StateSite等属性来增加 Cookie 的安全性。 其中，HttpOnly、Secure、SameSite 和 StateSite 都是 Cookie 中用于增强 Cookie 的安全性和保护用户隐私：
  - HttpOnly 属性可以来限制客户端 JavaScript 对 Cookie 的访问。
  - Secure 属性告诉浏览器仅在通过 HTTPS 访问网站时发送该 Cookie。当设置了 Secure 属性的 Cookie，则只能在安全的 HTTPS 连接中传输，而无法被非 HTTPS 传输协议所使用（如普通的 HTTP 协议），从而可以大幅度降低 Cookie 被窃听、篡改和伪造的风险。
  - SameSite属性用于防止 CSRF 攻击和用户隐私泄露。该属性有两种取值：Strict 和 Lax。
    - Strict：在同站点情况下，不管是否携带认证凭证，浏览器都禁止跨站点访问，即完全禁止第三方请求。
    - Lax：在跨站点 GET 请求时传递 Cookie，但在 POST、PUT、DELETE 或其他方法请求时则不会。这样，可以兼顾 CSRF 攻击和用户体验的安全问题。
  - StateSite属性整合了 Secure 和 SameSite 两个属性的特点，并提供更细粒度的配置方式。它有以下取值：
    - Strict：只支持 HTTPS 网站，并且完全禁止第三方 Cookie。
    - Lax：允许跨站点 GET 请求携带 Cookie，但不允许POST 等其他方法。
    - None：元素都不限制。
2. 在编码和设计时，可以采用 Token、服务端Referer 校验、双重 Cookie 验证、Ajax等方法来加强验证机制，以防止 CSRF 攻击的发生。
  - 服务端Referer 校验：Referer 是 HTTP 请求头部信息中的一个字段，记录了当前请求者来源页面的访问路径。在服务端进行 Referer 校验时，系统会检查请求头中 Referer 字段中网址的来源是否符合条件，若符合则视为有效请求，否则请求被视为异常操作予以拒绝。
  - 双重 Cookie 验证：双重 Cookie 验证适用于已登录用户的操作场景下，在表单或请求参数中添加一个存储在 Cookie 中的随机令牌，同时服务器认证该随机值是否与当前用户相关联，从而验证用户权限并防止 CSRF 攻击。
  - Token（在11.1.3节中介绍）
  - Ajax跨域请求：Ajax跨域请求不会自动携带cookie，源自浏览器的ajax同源策略，要想ajax自动携带cookie，需要在服务端进行配置。
🎯 Cookie与XSS攻击的关系
XSS可能会偷取Cookie信息，进而拿到用户的登录态进行模拟登录，并可修改Cookie。XSS 攻击者往往会利用网站漏洞插入恶意脚本代码（如跨站脚本攻击），从而在用户访问时执行该恶意代码，在用户浏览器中注入恶意请求，通过获取用户的 Cookie 状态信息以达到窃取或篡改 Cookie 的目的。例如：攻击者可以在评论区域写入一段JS代码，如果用户点击这个评论超链接，就可能导致用户的Cookie被盗取。
🎯 Cookie如何应对XSS攻击？
1. 为了防范 XSS 攻击，可以使用HttpOnly属性来增加 Cookie 的安全性。 HttpOnly 是很好的防御 XSS 攻击的工具之一，它可以从客户端禁止 JavaScript 访问特定的 Cookie，使Cookie不会被JS盗取，从而确保用户的隐私和安全。
2. 使用正则校验：XSS攻击的一个主要攻击途径就是通过表单提交来注入服务端的数据库。所以，在前端中，我们可以对表单数据进行正则验证，通过验证之后，才能提交数据。而在服务端，也应该对接收的数据进行规则校验，不符合规则的数据不应该入库。从接口层面，保证数据安全。
3. 进行数据转义：如果无法保证数据库的数据都是安全的，前端可以把所有需要展示到页面的数据，进行转义，比如遇到script标签，直接replace处理。或者遇到标签标识‘<’以及‘>’这类特殊字符，添加‘\’进行处理。
4. 加签名防止篡改：为了提高 Cookie 安全性，可以使用加密算法对 Cookie 进行加密处理，攻击者获取到 Cookie 后解密相对困难，从而保护用户敏感信息不被盗取。但需要注意的是，在使用加密算法时，也要确保算法的安全性和可靠性。

Session_338">11.1.2 Session

🎯 Session与CSRF攻击/XSS攻击的关系
和Cookie一样容易受到CSRF攻击，也可能受到XSS攻击。因为Session ID 存储在Cookie中，Cookie容易被CSRF攻击所截取利用，因此存储在其中的Session ID也容易被CSRF攻击者利用伪造。
🎯 Session如何应对CSRF攻击/XSS攻击？
防御方法跟Cookie的大差不差，这里就不再赘述了。

Token_343">11.1.3 Token

🎯 Token与CSRF攻击的关系
Token比Cookie和Session更安全，并且不容易受到CSRF攻击。CSRF（跨域请求伪造）的攻击特点是需要用户自己点击恶意网站的隐藏HTTP请求链接，这个发出去的HTTP请求会自动的携带上用户的Cookie信息给服务器，于是完成了请求伪造攻击。而Token因为是自定义字符串，所以HTTP请求不会自动携带它，CSRF也就无法得手了（即使用户点击了恶意网站的请求也无法被拿走Token），之所以说Token天然防CSRF，但也不是绝对的，前提是不把Token存储到浏览器的Cookie里。
🎯 Token与XSS攻击的关系
如果Token是存储在浏览器的localstorage或sessionstorage中，则可能会受到XSS攻击。这是因为，通过恶意脚本，攻击者可以直接从浏览器存储中访问Token的值。

Cookie JWT_348">11.2 从Cookie到JWT的发展总结

虽然从Cookie到JWT都是用于标识客户端的，但从发展上来看可以看成网络安全的一个发展吧。

首先，Cookie由服务器创建的，只保存在浏览器中的小型文本文件，一般包含用户信息，登录及访问权限等。
考虑到Cookie保存在客户端被窃取的风险较大，Session机制把服务器与浏览器的会话信息（验证信息）临时的保存在服务器上，并利用Session ID 进行客户端的识别。这样子，用户就没有权限操作服务器，可以避免非法用户窃取Session中的数据，从而保证数据的安全性。
虽然Session把用户状态和行为信息放在服务器上，可以提高一定的安全性，但Session ID保存在Cookie中，也有被窃取的可能，跟Cookie一样，Session也会受到CSRF的攻击，而且Session请求的体积比较大，也会增加服务器的成本（需要考虑分布式和服务器负载均衡的问题）。因此，Token机制采用打包加证件的方式来保证安全和信息的轻量化。
也就是Token机制将信息打包到Cookie中，这种样子可以减少服务器压力，同时Token自己作为访问资源的凭证（客户端唯一的标识），可以用于身份验证和授权。有点类似Cookie，但更加安全，Token是服务器将验证后的登陆凭证做数字签名，加密之后得到的字符串。
JWT的出现改善了传统Token需要查库验证用户信息，而JWT不用查库或者少查库，直接在服务端进行校验，并且不用查库。因为用户的信息及加密信息在第二部分payload和第三部分签证中已经生成，只要在服务端进行校验就行，并且校验也是JWT自己实现的。

Cookie JWT_355">11.3 从Cookie到JWT的区别总结

Cookie:保存在浏览器中，有大小限制，有状态
Session：保存在服务器中，服务器有资源开销，分布式、跨系统不好实现
Token：客户端可以将token保存到任何地方，无限制，无状态，利于分布式部署

形式不同：Cookie是小型文本文件，Session是用户状态列表，Token/JWT是字符串。
存储位置不同：Cookie、Token/JWT 存储在客户端；而Session 存储在服务端。
存储核心内容不同：Cookie 通常表示用户标识信息、会话状态或其余业务相关信息；Session 存储敏感数据（比如用户的密码等）；而 Token/JWT 表示会话安全令牌。
安全性不同：Cookie 可能面临 CSRF/ XSS 等风险；Session 更加地安全，不过由于 Session ID 可以猜测到，容易被伪造导致 Session 端口扫描等攻击；Token/JWT 则采用了数字签名或其他方式保证了数据的完整性和安全性，应用相对更加安全。
可跨域性不同：通过设置 domain 和 path 属性，Cookie 能够使用户在不同域名和路径间共享信息；Session 只能实现子域名间的数据共享，而 Token/JWT 不需要考虑域名、路径问题。
占用空间不同：
- Cookie 只适合小型的数据（单个Cookie通常最多支持4KB的数据存储），无法存储大量数据。
- Session 可以存储更多，但给服务器造成压力。Session没有严格的限制，可以存储的数据量相对较大，但是与服务器内存大小有关。虽然Session 的体积大小并没有明确的限制，但是在实际应用中一般也不会超过几KB。
- 而 Token/JWT 是一种轻便且高效的方案，Token的大小不同取决于使用的加密算法和使用的Token格式。相对于Cookie和Session，Token一般比较轻量级，通常只需要几十个字节。
- Cookie 通常适用于轻量级数据；Session 更适合小型、散乱位置的内容；而 Token/JWT 适用于处理分布式系统等较复杂的情形。
支持数据类型不同：
- Cookie 可以存储任何字符串类型的值（例如文本、数字、日期等），但是大小受到限制，一般不超过4KB。
- 和 Cookie 类似，Session 也可以存储各种字符串类型的值，包括文本、数字、日期等。但是，与 Cookie 不同的是，Session 还可以存储复杂的对象类型（例如数组、哈希表、类实例等），这些类型的数据独立于应用程序之外，并在每个会话生命周期内保存。
- Token 可以存储任何类型的数据，也可以存储复杂的 JSON 对象或者序列化后的二进制数据等类型。但是，建议只存储必要的信息，并避免存储敏感数据，从而保证安全性。
有效期不同，默认生命周期不同：
- Cookie 默认生命周期为会话级别，也就是说，当用户关闭浏览器或在一定时间段内没有活动时，Cookie 将自动失效。如果需要设置 Cookie 的有效期，则需要在服务器端设置相应参数，比如 Expires，当 Expires 时间到达时，服务器会将该 Cookie 删除或重新设置。一般来说，Cookie 的有效期比较短。如果未设置过期时间，那么Cookie在关闭浏览器时就会被删除。
- Session ID 的过期时间由 Web 服务器配置来决定，通常默认为为30分钟，也有20分钟到24小时不等的。在服务端，Session 的生命周期决定于服务器的配置和超时规则。如果服务器未设置 Session 过期时间，那么 Session 将一直存在，直到服务器被关闭或者手动结束。
- 默认情况下，Token使用期限是永久的，只有服务器才能终止该Token。但Token 的有效期可由开发者自行设置。JWT 则需要在 Token 中包含过期时间，并且服务器会对 Token 的有效性进行检查，如果过期，则需要重新获取 Token。如果 Token 未设置有效期，它将永远有效，这可能导致安全问题。
主要应用场景不同：见11.4

Cookie JWT_378">11.4 从Cookie到JWT的应用总结

总结：Cookie通常用于用户的浏览器行为跟踪和个性化设置等方面，Session更多地是进行一些会话管理与服务，Token和JWT则更多的是用于身份认证，在跨域下进行身份认证和授权。其中,
JWT更加适合在单页应用程序或分布式系统。Cookie
展开：
- Cookie应用场景
  - 通过在客户端存储数据（如用户 ID 和一些设置），允许服务器跟踪认证状态。Cookie 适合在需要持续跟踪会话状态时使用，例如购物车或社交媒体网站，还可以根据对浏览器行为跟踪分析用户行为，进行个性化的设置及推荐。
  - 之前总结果的常用场景：（1）登录状态及用户信息的管理；（2）跟踪用户行为，统计分析，广告定位；（3）记住用户偏好设置，定制页面；（4）创建购物车；（5）缓存数据，用于搜索历史和浏览记录；（6）跨页面数据传递，实现数据共享与同步 …
- Session应用场景
  - 会话适合在需要高度安全性和可靠性的应用程序中使用，例如在线银行或金融服务。对于简单而且不敏感的数据通常使用Cookie保存，如购物车信息、用户在站点的行为记录等；而对于复杂且敏感的数据使用Session保存，如用户的账号信息等。
  - 之前总结果的常用场景：（1）登录状态及用户信息的管理；（2）跟踪用户行为，统计分析，个性化推荐；（3）实现数据共享，多步骤操作；（4）网站安全；（5）处理后台任务；（6）消息提醒及表单数据存储等 …
- Token应用场景
  - 包含有关特定用户身份验证的信息，可以防止 CSRF 攻击。通常，Token 是 JSON 对象，可以在 Web 应用程序之间进行传输，并在本地存储。Token 适合在需要反复跨越多个域进行身份验证和授权时使用，例如REST API或移动应用程序。
  - 之前总结果的常用场景：（1）身份认证和授权控制；（2）可以作为支付方式，进行数字货币和加密货币交易；（3）可以作为奖励和积分；（4）安全性口令；（5）门禁控制；（6）辅助追溯，进行审查和监视 …
- JWT应用场景
  - 与Token 类似，但它是一种开放的标准（由 IETF 组织制定），使用 JSON 对象包含有关用户身份验证的信息，并被数字签名以确保其完整性。JWT 适合在需要可扩展性和安全性的 Web 应用程序中使用，例如单点登录、单页应用程序、前后端分离项目或分布式系统。
  - 之前总结果的常用场景：（1）登录鉴权；（2）信息交换 …

下一章笔记

下一章笔记的链接：第五章
笔记链接：【计算机网络】八股文 | 第五章
主要知识点：主要是关于TCP/UDP的相关知识