1、cookies的属性

从浏览器上可以看到cookies的属性有这些

Name和Value

Name和Value是一个键值对。Name是Cookie的名称，Cookie一旦创建，名称便不可更改，一般名称不区分大小写；Value是该名称对应的Cookie的值，如果值为Unicode字符，需要为字符编码。如果值为二进制数据，则需要使用BASE64编码。

Domain

Domain决定Cookie在哪个域是有效的，也就是决定在向该域发送请求时是否携带此Cookie，Domain的设置是对子域生效的，如Doamin设置为 .a.com,则b.a.com和c.a.com均可使用该Cookie，但如果设置为b.a.com,则c.a.com不可使用该Cookie。Domain参数必须以点(“.”)开始。

Path

Path是Cookie的有效路径，和Domain类似，也对子路径生效，如Cookie1和Cookie2的Domain均为a.com，但Path不同，Cookie1的Path为 /b/,而Cookie的Path为 /b/c/,则在a.com/b页面时只可以访问Cookie1，在a.com/b/c页面时，可访问Cookie1和Cookie2。Path属性需删除线格式 要使用符号“/”结尾。

Expires/Max-age

Expires和Max-age均为Cookie的有效期，Expires是该Cookie被删除时的时间戳，格式为GMT,若设置为以前的时间，则该Cookie立刻被删除，并且该时间戳是服务器时间，不是本地时间！若不设置则默认页面关闭时删除该Cookie。
Max-age也是Cookie的有效期，但它的单位为秒，即多少秒之后失效，若Max-age设置为0，则立刻失效，设置为负数，则在页面关闭时失效。Max-age默认为 -1。

Size

Szie是此Cookie的大小。在所有浏览器中，任何cookie大小超过限制都被忽略，且永远不会被设置。各个浏览器对Cookie的最大值和最大数目有不同的限制，整理为下表(数据来源网络，未测试)：

HttpOnly

HttpOnly值为 true 或 false,若设置为true，则不允许通过脚本document.cookie去更改这个值，同样这个值在document.cookie中也不可见，但在发送请求时依旧会携带此Cookie。

Secure

Secure为Cookie的安全属性，若设置为true，则浏览器只会在HTTPS和SSL等安全协议中传输此Cookie，不会在不安全的HTTP协议中传输此Cookie。

SameSite

SameSite用来限制第三方 Cookie，从而减少安全风险。它有3个属性，分别是：

• Strict
  Scrict最为严格，完全禁止第三方Cookie，跨站点时，任何情况下都不会发送Cookie
• Lax
  Lax规则稍稍放宽，大多数情况也是不发送第三方 Cookie，但是导航到目标网址的 Get 请求除外。
• None
  网站可以选择显式关闭SameSite属性，将其设为None。不过，前提是必须同时设置Secure属性（Cookie 只能通过 HTTPS 协议发送），否则无效。

Priority

优先级，chrome的提案，定义了三种优先级，Low/Medium/High，当cookie数量超出时，低优先级的cookie会被优先清除。
在360极速浏览器和FireFox中，不存在Priority属性，不清楚在此类浏览器中设置该属性后是否生效。

2、cookie发送的过程

• 如果客户端上，一个网站有10个cookie，它将会把10个cookie的名称和值，通过“=”和“；”连接形成一个字符串，接着把这个字符串放于请求头cookies字段中。客户端发送请求的时候会将本地当前网址的cookie一次性全部生成一条字符串，然后通过请求头上传给服务器。
• 例如下图
  
  生成的cookies为：sex=nan;name=beifeng;age=12 这种字符串

3、Cookie 主要使用在以下场景

会话状态管理（如用户登录状态、及其他需要记录的信息）
个性化设置（如用户自定义设置）
浏览器追踪行为（如追踪分析用户行为）

4、session

Session常用属性有：

（1）SessionID：获取Session编号，一般在会话开始的时候由服务器自动分配一个标识SessionId,整个会话过程中的SessionId保持不变。

（2）TimeOut：设置Session对象的超期时间，默认为20分钟。

（3）Keys：根据索引号获取Session变量值

（4）Count：获取Session变量的总数量。

Session常用方法有：

• Session.Add(“name”,“value”)：添加名称为Name,值为value的Session对象。

• Session.Clear()：清除Session变量值。

session的优缺点：

• 缺点
  需要从内存或者数据库里面取数据，进行验证，相对jwt来说更耗时。
  扩展性差，对于分布式应用，需要实现session数据共享。比如，当使用分布式的情况下，可能由于负载均衡的策略，导致访问到了不同的服务器，所以得让用户登录时的seesion状态要共享到其他服务器（其数据库）上。
• 优点
  安全，数据存储在服务器端
  相对于jwt来说，用来传输用户信息的网络流量更少
  相对于jwt来说，适合做会话管理，单点登录。

为什么session比cookies安全？

• 因为session使用过程中，session是把全部信息存储于服务器，客户端只有一个sessionId。而cookies是把所有信息存储于客户端。对于同一个账户而言，cookies有几率可以篡改账户信息，但是session无法篡改用户信息。就如同银行卡（session）比现金（coookies）安全，现金别人捡到了能尝试篡改金额，但是银行卡只有 卡号，不可能篡改金额。

5、token

1. 客户端使用用户名跟密码请求登录

2. 服务端收到请求，去验证用户名与密码

3. 验证成功后，服务端会签发一个 Token，再把这个 Token 发送给客户端

4. 客户端收到 Token 以后可以把它存储起来，比如放在 Cookie 里或者 Local Storage 里

5. 客户端每次向服务端请求资源的时候需要带着服务端签发的 Token

6. 服务端收到请求，然后去验证客户端请求里面带着的 Token，如果验证成功，就向客户端返回请求的数据。

• 举个token的例子

eyJhbGciOiJIUzUxMiJ9.eyJzdWIiOiJ3YW5nIiwiY3JlYXRlZCI6MTQ4OTA3OTk4MTM5MywiZXhwIjoxNDg5Njg0NzgxfQ.RC-BYCe_UZ2URtWddUpWXIp4NMsoeq2O6UF-8tVplqXY1-CI9u1-a-9DAAJGfNWkHE81mpnR3gXzfrBAB3WUAg

• token分成了三部分，每部分用 . 分隔，每段都是用 Base64 编码的。强调Base64并不是加密方式，等同于明文。
• 第一部分Header（头部）一般存储tokne类型和加密算法
• 第二部分是Playload（有效载荷），存储用户信息，因为是明文存储，所以不能存储用户重要的信息，一般会存储uuid（只是其中一个数据）。
• 第三部分是签名，加密后生成的，密文再用Base64编码。签名是为了防篡改有效载荷，判断token是否合法。

参考文档

• Cookie的所有属性详解
• 详解Cookie、Session与Token
• 深入理解有状态和无状态以及JWT和Session
• Token的组成部分