一、Cookie
由于HTTP是一种无状态协议，每次请求时，例如需要登陆的界面如购物车界面，服务器没有办法单单从网络连接上面知道访问者的身份，为了解决这个问题，就诞生了Cookie。
Cookie : 主要用来记录用户状态，区分用户。客户端向服务器发送请求，服务器生成Cookie同响应数据一同返回给客户端，客户端保存Cookie，状态保存在客户端。
大多数的应用都是用 Cookie 来实现Session的跟踪，在 Cookie 里面记录一个Session ID，以后每次请求把这个会话ID发送到服务器来进行识别。如果客户端的浏览器禁用了 Cookie 怎么办？一般这种情况下，会使用一种叫做URL重写的技术来进行会话跟踪，即每次HTTP交互，URL后面都会被附加上一个诸如 sid=xxxxx 这样的参数，服务端据此来识别用户。
Cookie存储的数据量有限，且都是保存在客户端浏览器中。不同的浏览器有不同的存储大小，但一般不超过4KB。因此使用Cookie实际上只能存储一小段的文本信息。
Cookie其实还可以用在一些方便用户的场景下，设想你某次登陆过一个网站，下次登录的时候不想再次输入账号了，怎么办？这个信息可以写到Cookie里面，访问网站的时候，网站页面的脚本可以读取这个信息，就自动帮你把用户名给填了，能够方便一下用户。
Cookie的主要用途：
- 会话状态管理（如用户登录状态、购物车）
- 个性化设置（如用户自定义设置）
- 浏览器行为跟踪（如跟踪分析用户行为）
Cookie的处理步骤
- 服务器向客户端发送Cookie
- 通常使用HTTP协议规定的Set-Cookie头操作。
- 规范规定Cookie的格式为name = value格式，且必须包含这部分。
- 浏览器将Cookie保存
- 每次请求浏览器都会将 Cookie 发向服务器
| key | 是否可选 | value |
|---|---|---|
| name | true | xxx |
| value | true | xxx |
| path | false | 路径 |
| expires | false | UTC 格式时间 |
| maxAge | false | 是 cookie 多久后过期的相对时间 |
| secure | false | 为true时cookie 在 HTTP 中是无效 在 HTTPS 中才有效 |
| httpOnly | false | 浏览器不允许脚本操作 document.cookie 去更改 cookie。一般情况下都应该设置这个为 true，这样可以避免被 xss 攻击拿到 cookie。 |
Cookies 长什么样子？
当服务器收到HTTP请求时，可以在响应头里面增加一个Set-Cookie头部。浏览器收到响应之后会取出Cookie信息并保存，之后对该服务器每一次请求中都通过Cookie请求头部将Cookie信息发送给服务器。大概都长的都是这个格式：
Set-Cookie: <cookie名称>=<cookie值>
所以一个简单的 Cookie 像这样：
language=zh_CN; expires=Sat, 16-Jan-2019 08:00:00 GMT; Max-Age=2592000; path=/; domain=192.75.17.211:6603
二、Session
Session：主要用来记录用户状态，区分用户。服务端要为特定的用户创建特定的Session，用于标识这个用户，并且跟踪用户的后续操作，状态保存在服务器端。
当有客户端访问服务器时，服务器根据需求设置Session，将会话信息保存在服务器上（主要存储的的SessionID和Session内容，同时也包含了很多自定义的内容如：用户基础信息、权限信息、用户机构信息、固定变量等），这个数据可以保存在集群、数据库、文件中，用于跟踪用户的状态。客户端浏览器访问服务器的时候，服务器把客户端信息以某种形式记录在服务器上，客户端浏览器再次访问时只需要从该Session中查找该客户的状态就可以了。
用户第一次登录后，浏览器会将用户信息发送给服务器，服务器会为该用户创建一个SessionID，并在响应内容（Cookie）中将该SessionID一并返回给浏览器，浏览器将这些数据保存在本地. 当用户再次发送请求时，浏览器会自动的把上次请求存储的Cookie数据自动的携带给服务器。服务器接收到请求信息后，会通过浏览器请求的数据中的SessionID判断当前是哪个用户，然后根据SessionID在Session库中获取用户的Session数据返回给浏览器。
例如：购物车，添加了商品之后客户端处可以知道添加了哪些商品，而服务器端如何判别呢，所以也需要存储一些信息就用到了Session。
如果说Cookie机制是通过检查客户身上的“身份证”来确定客户身份的话，那么Session机制就是通过检查服务器上的“客户明细表”来确认客户身份。Session相当于程序在服务器上建立的一份客户档案，客户来访的时候只需要查询客户档案表就可以了。Session生成后，只要用户继续访问，服务器就会更新Session的最后访问时间，并维护该Session。为防止内存溢出，服务器会把长时间内没有活跃的Session从内存删除。这个时间就是Session的超时时间。如果超过了超时时间没访问过服务器，Session就自动失效了。
三、Token
HTTP请求都是以无状态的形式对接。即HTTP服务器不知道本次请求和上一次请求是否有关联。所以就有了Session的引入，即服务端和客户端都保存一段文本，客户端每次发起请求都带着，这样服务器就知道客户端是否发起过请求。
这样，就导致客户端频繁向服务端发出请求数据，服务端频繁的去数据库查询用户名和密码并进行对比，判断用户名和密码正确与否。而Session的存储是需要空间的，频繁的查询数据库给服务器造成很大的压力。
在这种情况下，Token应用而生。
Token是服务端生成的一串字符串，以作客户端进行请求的一个令牌。当客户端第一次访问服务端，服务端会根据传过来的唯一标识userId，运用一些算法，并加上密钥，生成一个Token，然后通过BASE64编码一下之后将这个Token返回给客户端，客户端将Token保存起来（可以通过数据库或文件形式保存本地）。下次请求时，客户端只需要带上Token，服务器收到请求后，会用相同的算法和密钥去验证Token。
最简单的Token组成:uid(用户唯一的身份标识)、time(当前时间的时间戳)、sign(签名，由Token的前几位+盐以哈希算法压缩成一定长的十六进制字符串，可以防止恶意第三方拼接Token请求服务器)。
使用基于 Token 的身份验证方法，在服务端不需要存储用户的登录记录。大概的流程是这样的：
- 客户端使用用户名跟密码请求登录
- 服务端收到请求，去验证用户名与密码
- 验证成功后，服务端会签发一个Token，再把这个Token发送给客户端
- 客户端收到Token以后可以把它存储起来，比如放- 在Cookie里或者数据库里
- 客户端每次向服务端请求资源的时候需要带着服务端签发的Token
- 服务端收到请求，然后去验证客户端请求里面带着的 Token，如果验证成功，就向客户端返回请求的数据
APP登录的时候发送加密的用户名和密码到服务器，服务器验证用户名和密码，如果成功，以某种方式比如随机生成32位的字符串作为Token，存储到服务器中，并返回Token到APP，以后APP请求时，凡是需要验证的地方都要带上该Token，然后服务器端验证Token，成功返回所需要的结果，失败返回错误信息，让他重新登录。对于同一个APP同一个手机当前只有一个Token；手机APP会存储一个当前有效的Token。其中服务器上Token设置一个有效期，每次APP请求的时候都验证Token和有效期。
