Cookie，Session、Token是什么、区别在哪？

一、HTTP协议深入讲解及它的特点

接口鉴权：鉴定你是否有访问一个接口的权限
接口签名：通过签名的方式鉴定你是否有访问一个接口的权限

1.1 HTTP协议

http协议是一种超文本传输协议，主要分为请求和响应两个部分。
请求：
请求行，
请求头（User-Agent：客户端类型
Accept：客户端接收的数据类型
Cookie
Content-Type：发送给服务器的数据格式
X-requested-with：异步请求Ajax）
空一行，
请求正文
响应：
响应行，
响应头（Set-Cookie），
空一行，
响应正文

1.2 http协议特点

简单、快捷，无连接和无状态（多个请求之间独立运行，无关联）。

1.3 同步、异步请求

1.同步请求
什么叫同步请求呢？
就是在发送一个请求之后，需要等待服务器响应返回，才能够发送下一个请求。
之前学的请求是通过浏览器地址栏发送请求，这种方式就是属于同步请求。

但是其有两个缺陷：
①请求必须要等待响应
如果遇到请求阻塞，网络延迟，用户需要等待，这样用户体验效果不好。

②请求时会携带所有的信息
比如说一个form表单，需要填入用户名，密码，手机号，等多个信息。
如果其中有一个信息填写错了，请求失败，又要全部重新填写，会很麻烦繁琐。
我只填写我填错了的不就好了么？
如何解决这个问题？就需要引入异步的概念了。

2.异步请求
和同步请求相对，异步不需要等待响应，随时可以发送下一次请求。
如果是同步请求，需要将信息填写完整，再发送请求，服务器响应填写是否正确，再做修改。
但是异步请求是局部页面更新。
比如上述的手机号、密码，邮箱名，在填写时就会发送一个异步请求。

若是格式不正确，会提醒修改，而其它已经填写的正确信息不受影响。

二、Cookie以及Cookie鉴权的原理

2.1 什么是Cookie

cookie是指小段的文本信息（key-value格式），是浏览器实现的一种数据存储功能，保存在客户端。cookie由服务器生成，发送给浏览器，浏览器把cookie以键值对形式保存到客户端某个目录下的文本文件内，下一次请求同一网站时会把该cookie发送给服务器。通过对cookie中信息的解析，服务器可以识别请求发送者的身份。由于cookie是存在客户端上的，所以浏览器加入了一些限制，确保cookie不会被恶意使用，同时为了不占据太多磁盘空间，每个域的cookie数量是有限的。
Cookie有两类：
1.持久化Cookie（不会被覆盖）：可以长期保存在硬盘，只是Cookie的失效时间到了才会失效。
2.会话级Cookie（会被覆盖）：在同一个会话里有效，一旦会话中断就失效了。
会话：web项目中，从登录成功到登出成功为止

2.2 Cookie的作用

狭义：保存用户的信息
广义：保存以及传输任意数据

2.3 怎么查看Cookie

1.浏览器–设置–隐私设置和安全性–Cookie
（包含内容：名称、值、作用域名、路径、为何发送、创建时间、到期时间）
2.浏览器–开发者工具–Application–Cookies

2.4 Cookie如何实现鉴权

分两个步骤实现鉴权
1.第一步（传值）：当客户端第一次访问服务器的时候，服务器会生成Cookie，在第一次请求的响应头中通过Set-Cookie传输到客户端。
2.第二步（鉴权）：当客户端从第二次访问服务器开始，就会自动的读取保存在客户端的Cookie，然后加到请求头的Cookie里面发送给服务器，从而实现鉴权。

Postman使用过程中某个bug场景：
Postman中请求的四要素100%对，但是返回的结果就是有问题？
1.你上上次是成功
2.你上一次是失败（在缓存中就是失败的数据报文）
3.后面所有的操作都是失败（先检查cookie，发现cookie是UC安在的就不会去访问服务器，而是访问缓存）
解决方法：清除cookie，重新从服务器获取新的数据
接口自动化里面也需要处理

2.5 Cookie主要有有以下缺点

1、 cookie的数量和长度都有限制
2、潜在的安全风险：cookie可能被截取篡改，如果cookie被拦截，就可能会获取到所有的信息
3、用户可能会配置禁用浏览器或者客户端设备接受cookie的能力，因此可能会限制了这一功能
4、有些状态不可能保存在客户端

三、Session以及Session鉴权的原理

3.1 什么是Session

session也叫会话。session是一种将会话状态保存在服务器端内存的技术，然后把加密后的sessionid传给客户端，默认生命周期是30min，可以比喻成是银行发放给客户的银行卡和银行为每个客户保留的账户档案的结合方式 。客户到银行柜台办理业务时，需要出示自身办理的银行卡，银行办理人员通过银行卡上的卡号查找到对应的客户信息，进而就可以进行相关业务处理了。

与银行卡类似，服务器要知道当前发请求给自己的是谁。为了做这种区分，服务器就要给每个客户端分配不同的“身份标识”，然后客户端每次向服务器发请求的时候，都带上这个“身份标识”，服务器就知道这个请求来自于谁了。
至于客户端怎么保存这个“身份标识”，可以有很多种方式。对于浏览器客户端，大家都默认采用 cookie 的方式。服务器使用session把用户的信息临时保存在了服务器上，用户离开网站后session会被销毁。
这种用户信息存储方式相对cookie来说更安全，可是session有一个缺陷：如果web服务器做了负载均衡，那么下一个操作请求到了另一台服务器的时候，由于另一台服务器没有对应的session，会直接返回认证错误，进而需要用户重新登录。

为了避免类似的问题，需要将session复制到所有的应用服务器，同时由于互联网的巨量用户必然会带来的海量session信息的存储需求，这对服务器存储能力是一个巨大的开销，而且严重限制了服务器的动态扩展能力（为了应对用户的巨量增长，互联网常用的做法是加服务器来保证服务能力的可用性），当然可以采用分布式缓存来对session信息进行集中存储，这又会带来新的问题，比如单点故障等。因为上述种种不便，互联网公司一般采用token的方式来进行验证。

3.2 Session如何实现鉴权

分两个步骤实现鉴权
1.第一步（传值）：当客户端登录的的时候，服务器会生成sessionid，在第一次请求的响应头中通过Set-Cookie（不一定）把sessionid传输到客户端。
2.第二步（鉴权）：当客户端从第二次访问服务器开始，就会自动的读取保存在客户端Cookie里面的sessionid，然后加到请求头的Cookie里面发送给服务器，从而实现鉴权。

四、Token以及Token鉴权的原理

bearer token：restful架构的接口测试里面用于鉴权最多的一种方式。

4.1 什么是token

token即“令牌”，也叫鉴权码，是服务端生成的一串字符串，保存在服务器数据库（硬盘）中，作为客户端进行请求的一个标识。当用户第一次登录后，服务器生成一个token并将此token返回给客户端，客户端收到token后，会把它存储起来（一般采用cookie或者localstorage的方式进行存储），以后客户端只需带上这个token前来请求数据即可，无需再次带上用户名和密码，服务器如果对token验证成功，就会返回客户端请求的数据。

Token一般分两类：
access_token：生命周期15-120min
refresh_token：生命周期15天

4.2 Token如何实现鉴权

分两个步骤实现鉴权
1.第一步：通过登录接口或者一个特定的接口获取到token鉴权码的值。
2.第二步（鉴权）：在后面所有的请求里面通过请求头或者是请求参数的方式发送给服务器实现鉴权。

token一般是由uid(用户唯一的身份标识)、time(当前时间的时间戳)等信息和sign（签名）构成。如下图所示：

服务器一般是通过什么方式来保证该token是否是自己签发，并且信息没有篡改过呢？

这个就需要从token的签名说起了，签名通常是把token除签名部分用一定的加密算法和秘钥（只有服务端知晓）进行加密生成，当客户端把token发送过来时，服务端用同样的加密算法和秘钥对token的除签名部分重新计算，如果和token中的签名一致，很明显，这个token是自己签发，并且信息没有篡改过。

整个过程如下图所示：
当然，如果对应加密的哈希算法和秘钥泄露，token同样可以被篡改。

因为token中的数据是明文存储的（虽然会用base64编码，但那不是加密），所以一般不能用来存储密码等敏感信息，且一般通过https协议来保证传输安全性。

从上面的token的认证机制来看，token自身就可以完成自身的校验，那token是否需要进行存储呢？

这个需要根据token的实际应用场景来看，比如登录场景，类似微信的一次性accesstoken等，都需要进行相关存储，因为类似登录场景，需要进行一系列精细化控制，诸如权限，token的有效期、自身注销、非法用户的拦截等操作进行精确控制。

那为什么需要对token进行有效期设置呢？

我们先从两个例子入手吧。

一个例子是登录密码，一般要求定期改变密码，以防止泄漏（参加工作的同学经常会遇到的一个问题是电脑登录密码一个季度或者半年就强制变更一次），所以密码是有有效期的。

另一个例子是安全证书。SSL 安全证书都有有效期，目的是为了解决吊销的问题，当网站的私钥丢失时，网站应该向证书颁发机构（CA）申请将他们的证书加入到证书吊销列表（CRL）里。这样当用户访问https站点时，浏览器会自动向CA请求吊销列表，如果用户访问的站点提供的证书在CRL里，浏览器就不信任这个证书，因为攻击者可能拥有同样的证书。所以如果证书永久有效，随着越来越多的私钥丢失，吊销列表也越来越大（因为只有加进去的，没有剔除出去的），这既给CA增加流量压力，也会增加浏览器的流量。而一旦有效期只有几年，那么CA就可以将那些已经过期了的证书从CRL里剔除，因为反正浏览器也不信任过期证书。所以无论是从安全的角度考虑，还是从吊销的角度考虑，token 都需要设有效期。

那么有效期设置多长合适呢？

只能说，从系统的安全需要和用户的体验需求出发，尽可能的寻求一个平衡。在保证用户体验的前提下，token应该尽可能的短，但也不能短得离谱。这样新问题产生了，如果用户在正常操作的过程中，token 可能会过期失效，要求用户重新登录……用户体验岂不是很糟糕？

为了解决在操作过程不能让用户感到 token 失效这个问题，有以下两种通用方案。

方案一是在服务器端保存 token 状态，用户每次操作都会自动刷新（推迟） token 的过期时间(session 就是采用这种策略来保持用户登录状态的)。然而仍然存在这样一个问题，在前后端分离、单页 App 这些情况下，每秒钟可能发起很多次请求，每次都去刷新过期时间会产生非常大的代价。如果 token 的过期时间被持久化到数据库或文件，代价就更大了。所以通常为了提升效率，减少消耗，会把 token 的过期时间保存在缓存或者内存中。

方案二是使用 Refresh Token（也就是所谓的长token），它可以避免频繁的读写操作。这种方案中，服务端不需要刷新 token 的过期时间，一旦 token 过期，就反馈给前端，前端使用Refresh Token申请一个全新 token 继续使用。这种方案中，服务端只需要在客户端请求更新token的时候对Refresh Token的有效性进行一次检查，大大减少了更新有效期的操作，也就避免了频繁读写。当然Refresh Token也是有有效期的，但是这个有效期就可以长一点了，比如，以天为单位的时间。

五、Cookie、Session、Token的相同点不同点

5.1 相同点

都是用于鉴权，都由服务器生成

5.2 不同点

1.Cookie保存在客户端的浏览器，Session保存在服务器的内存，Token保存在服务器的数据库（硬盘）。
2.Cookie一般保存一些不重要的信息，Session一般保存登录等重要的信息，Token只用于鉴权。

六、接口签名Sign鉴权的由来

6.1 什么是签名Sign

特定算法，非常严格的自定义算法，通常用于金融、银行项目。

三级标题

四级标题

五级标题

六级标题