cookie,session,token三剑客
一：基础知识
HTTP协议
1.概念：
1.HTTP协议：超文本传输协议，是以TCP/IP协议（注意：TCP/ip具有面向连接的特性）为基础而设计的用于传输网络数据（html文本，图片，数据等）的网络传输协议。
三次握手：c/s结构（客户端/服务器）
C--->S C请求S，表示请求建立连接
C<---S S应答C，表示同意建立连接
C--->S C回复S，表示接收到S的应答
》》》》连接已建立，可以进行数据交互
四次挥手：
C---->S C请求S，表示请求断开连接
C<----S S回复C，表示收到断开连接的请求
C<----S S告知C，你可以进行连接断开
C---->S C告知S，我要断开连接了。
》》》》连接中断
2.HTTP请求具体流程：
当客户端访问URL时，先解析URL并构造HTTP请求数据包，由所建立的TCP连接进行数据包的发送，服务器收到数据包后进行解析，并发送响应数据包，一次完整的http请求包含请求和响应两部分
1.域名解析 -->
2.发起TCP的3次握手 -->
3.建立TCP连接后发起http请求 -->
4.服务器响应http请求，浏览器得到html代码 -->
5.浏览器解析html代码，并请求html代码中的资源（如js、css、图片等） -->
6.浏览器对页面进行渲染呈现给用户.
知识点补给站：
在网页的右键检查里Network->Name->Request Headers view parsed下
的Connection:keep-alive保持常连接，就不用频繁的三次握手和四次挥手！
2.HTTP请求报文格式：
1.http请求包一般格式：
GET / HTTP/1.1 #请求行
Host: fanyi.youdao.com #请求头
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:94.0) Gecko/20100101 Firefox/94.0
Accept: */*
Accept-Language: zh-CN,zh;q=0.8,zh-TW;q=0.7,zh-HK;q=0.5,en-US;q=0.3,en;q=0.2
Accept-Encoding: gzip, deflate
Connection: close
Cookie: ************ #请求头
2.请求方法
常用的请求方法为POST,GET两种方法
POST：
- 主要负责向服务器提交，上传数据
- 没有限制大小（一般为2m)
- 比GET形式传递的数据量大，但是传递速度慢
GET：
- 主要负责从服务器获取数据
- 有大小限制，一般为1024bit
- 比POST更加高效，方便
- URL中添加参数，显示在地址栏
请求行
请求行由请求方法字段、URL字段和HTTP协议版本字段3个字段组成，它们用空格分隔。比如 GET /data/info.html HTTP/1.1
方法字段就是HTTP使用的请求方法，比如常见的GET/POST
其中HTTP协议版本有两种：HTTP1.0/HTTP1.1 可以这样区别：
HTTP1.0对于每个连接都只能传送一个请求和响应，请求就会关闭，HTTP1.0没有Host字段;而HTTP1.1在同一个连接中可以传送多个请求和响应，多个请求可以重叠和同时进行，HTTP1.1必须有Host字段。
HTTP请求头
格式：
名字+：+空格+值
- HOST：指定请求资源的域名（主机，端口号）HTTP请求必须包含host，否则会报400错误
- User-Agent: UA头域的内容包含发出请求的用户信息。浏览器类型，如果Servlet返回的内容与浏览器类型有关则该值非常有用。
- Accept-Encoding：浏览器能够进行解码的数据编码方式，比如gzip。服务器能够向支持gzip的浏览器返回经gzip编码的HTML页面。但是这样会有乱码显示，可以选择不进行压缩返回
- Accept-Language：浏览器所希望的语言种类，当服务器能够提供一种以上的语言版本时要用到。
- Accept：告诉服务器客户端可以接收的数据类型
- cookie：含有用户的隐私信息
- From：请求发送者的email地址，由一些特殊的Web客户程序使用，浏览器不会用到它。
- Referer：客户机通过这个头告诉服务器，它是从哪个资源来访问服务器的(防盗链)。包含一个URL，用户从该URL代表的页面出发访问当前请求的页面。
- Content-Length：表示请求消息正文的长度。
请求数据
若方法字段是GET，则此项为空，没有数据
若方法字段是POST,则通常来说此处放置的就是要提交的数据
比如要使用POST方法提交一个表单，其中有user字段中数据为“admin”, password字段为123456，那么这里的请求数据就是 user=admin&password=123456，使用&来连接各个字段。
3.HTTP响应报文格式
与请求报文格式类似
常见状态码：
响应数据报头的常见内容
4.HTTP协议特点：
- HTTP是无连接的：无连接的含义是每次仅处理一个请求，当请求处理完成并收到客户端的应答后，便断开连接，这样可以节省资源
- HTTP是媒体独立的：即，只要客户端与服务器确定如何处理数据后，便可通过HTTP协议传输任意类型数据
- HTTP是无状态的：无状态指协议对于事务处理没有记忆能力，缺少状态意味着，当后续处理需要之前操作的信息时，必须重传，会增大数据量。而当不需要之前操作的信息时，数据量会减少。
无状态HTTP官方详解：
HTTP的无状态是指HTTP协议对事务处理是没有记忆能力的，也就是说服务器不知道客户端是什么状态。当我
们向服务器发送请求后，服务器解析此请求，然后返回对应的响应，服务器负责完成这个过程，而且这个过程是完全
独立的，服务器不会记录前后状态的变化，也就是缺少状态记录。这意味着如果后续需要处理前面的信息，则必须重
传，这导致需要额外传递一些前面的重复请求，才能获取后续响应，然而这种效果显然不是我们想要的。为了保持前
后状态，我们肯定不能将前面的请求全部重传一次，这太浪费资源了，对于这种需要用户登录的页面来说，更是棘手。
这时两个用于保持HTTP连接状态的技术就出现了，它们分别是会话和Cookies。下面会介绍到哦！
二：cookie
1.引入原理：
由上文可知，HTTP协议为无状态协议，当后续访问处理需要使用到前面的信息时，重传会消耗大量资源，所以作为web服务器必须
能够采用某种方式来唯一识别同一个用户
可以记录该用户的状态。
而这同一个客户端与服务器端的在一段时间内的多次交互，我们就可以称该客户端为该服务器端的一个客户端会话窗口，有了会话窗口，我们就能确定哪个请求是哪个用户发出的了，从而可以实现会话跟踪，并记录用户的行为。
概念：
会话：可以理解为用户打开浏览器》》访问服务器多个资源》》》关闭浏览器 的这一个过程成为会话
有状态的会话：浏览器发送的每一次请求，每一个会话都要有唯一的标识来唯一标识自己，当浏览器发送请求的时候就带上这个标识来让服务器识别，从而实现有“状态”的会话。
（cookie与session都为实现会话的机制）
2.基本介绍
1）当浏览器访问URL时，服务器会生成set-cookie键值对，包含在HTTP响应头中发送给客户端，客户端接收到之后，会在本地内存或外存中将客户端发送的cookie键值对保存下来，当下一次访问该URL或URL下的资源时，会将该cookie伴随HTTP请求包发送给服务器（至于怎么区分不同网站的cookie的，很简单，每个网站都给他一个唯一标识比如网址等，每次打开某网址时，就查询该网站下的所有cookie值即可。）
2）每一个cookie都有一个name和一个value，且name是唯一的。相同名字时，后者会覆盖掉前者（类似哈希表的key的效果）。
3）一个WEB浏览器也可以存储多个WEB站点提供的Cookie。浏览器一般只允许存放300个Cookie，每个站点最多存放20个Cookie，每个Cookie的大小限制为4KB。
cookie为本地生成本地保存，发送给
分类
1.会话级别cookie：服务器产生后发给客户端，客户端保存在浏览器中（内存中）伴随浏览器的关闭，cookie会被删除
2.存储级别cookie：若希望浏览器将该cookie存储在磁盘上，则需要设置该cookie的生命周期setMaxAge，并给出一个以秒为单位的时间。将最大时效设为0则是命令浏览器删除该cookie。
作用域
domain：规定cookie作用的URL范围,即：访问哪些URL或域名时会携带有cookie
path：规定cookie作用URL的路径，默认情况下为任意路径
三：session
当浏览器使用cookie时，因为cookie最大长度为4096B，cookie虽然在一定程度上解决了“保持状态”的需求，但是由于cookie本身最大支持4096字节，以及cookie本身保存在客户端，可能被拦截或窃取
因此就需要有一种新的东西，它能支持更多的字节，并且他保存在服务器，有较高的安全性。这就是session。
1.基本原理
当用户发送一个请求到服务器端时，服务器会先检查请求中是否含有sessionid(存在cookie中或者在url中)，
》》如果不存在sessionid(说明是第一次请求)，就会为该请求用户创建一个session对象，并将该session对象的sessionid（放到响应头的set-cookie中，格式set-cookie:sessionid,下次再请求时cookie中就会有一个name为jsessionid的cookie，value就是sessionid）响应给客户端。
》》如果存在sessionid，就会在服务器端查找是否有该sessionid对应的session，如果有就使用，没有就创建一个。
所以说，服务器端的session和客户端的cookie是息息相关的，若是没有了cookie，又不做其他处理的话，服务器端的session也没了。
2.概念
session：存储于cookie中的一种信息，用于区分用户。此机制采用服务器端存储session，将session-id回送给客户端，当客户端访问会话时，为了区别用户，请求数据包中会含有jssession-id，服务器收到jssession-id后会与所存储的session-id对照表进行对照，确定访问用户，实现会话状态的延续。
为了加速session的读取和存储，web服务器中会开辟一块内存用来保存服务器端所有的session，每个session都会有一个唯一标识sessionid，根据客户端传过来的jsessionid(cookie中)，找到对应的服务器端的session。为了防止服务器端的session过多导致内存溢出，web服务器默认会给每个session设置一个有效期, （30分钟）若有效期内客户端没有访问过该session，服务器就认为该客户端已离线并删除该session。
保存session-id的方式
存于cookie中
在cookie中会有session字段，存有jsession-id，伴随HTTP请求头一起发送给服务器
URL重写
当浏览器Cookie被禁时用。
就是把session的id附加在URL路径的后面。附加的方式也有两种，一种是作为URL路径的附加信息，另一种是作为查询字符串附加在URL后面。
做法：
1、response.encodeURL(String url)用于对表单action和超链接的url地址进行重写
2、response.encodeRedirectURL(String url) 用于对sendRedirect方法后的url地址进行重写。
这两个方法很智能，若浏览器禁用了cookie，就默认会进行url重写(url中带上sessionid)，当用户浏览器没有禁用cookie时，就不在URL后附加sessionid。
用法就是代替response.sendRedirect(String url)
四：token
1.概念
token：可以翻译成"令牌"，本质上它是一个全局唯一的字符串，用来唯一识别一个客户端。但它不像cookie和session一样是一种web规范，个人认为他是借鉴了cookie和session工作的原理，进而延伸出来的一种维持用户会话状态的机制。
2.解决的问题
token解决了session依赖于单个Web服务器的问题。
单体应用时用户的会话信息保存在session中，session存在于服务器端的内存中，由于前前后后用户只针对一个web服务器，所以没啥问题。
但是一到了web服务器集群的环境下（我们一般都是用Nginx做负载均衡，若是使用了轮询等这种请求分配策略），就会导致用户小a在A服务器登录了。
session存在于A服务器中，但是第二次请求被分配到了B服务器，由于B服务器中没有用户小a的session会话，导致用户小a还要再登陆一次，以此类推。这样用户体验很不好。
当然解决办法也有很多种，比如同一个用户分配到同一个服务器处理、使用cookie保持用户会话信息等。
我们今天讨论的是用户会话信息集中存储的这种方案。类比之前cookie和session的机制，在请求中根据cookie中的jesessionid来自动找到服务器端的session，从而从session中取出当前用户的会话信息。
3.token机制详解
- 随机生成全局唯一任意字符串口令： cookie中是根据jesessionid来找到服务器端的session的，jesessionid就是一个全局唯一的随机字符串，我们也可以生成一个全局唯一的字符串比如使用UUID或时间戳加随机字符串的形式；
- 服务器端的会话信息存储： web服务器在内存中存储所有的session，每个session都有一个唯一的id标识，value就是session本身，session里面又有好多键值对。数据在内存中、key-value形式的、value里面又有好多键值对，这简直就是对redis的哈希表十分准确的描述啊，所以我们可以使用redis的哈希类型来模型服务器端的session。
- 构造全局字符串与会话信息存储的对应关系
cookie和session机制中是根据cookie中的jesessionid来自动找到服务器端的session，说是自动查找，其实是我们调用了他封装好的方法request.getSession()获取的，这个request中就包含了本次请求的所有信息，而调用的getSession()方法中，肯定做了这件事——获取请求头中cookie的jesessionid的值，根据这个值到服务器的内存中找到对应的session并返回。所以我们也完全可以模仿它这种机制：我们可以在用户第一次请求该web服务器时或是用户登录该web服务器时，生成一个全局唯一的token返回给前端存储，同时将该用户信息存到redis中并设置有效期，之后每次请求中都在请求头中带着这个token，服务器端根据这个token到redis中查找对应的用户信息，即得到了我们所说的
“session”。
五：总结
- cookie的工作原理是：由服务器产生内容，浏览器收到请求后保存在本地；当浏览器再次访问时，浏览器会自动带上cookie，这样服务器就能通过cookie的内容来判断这个是“谁”了。
cookie虽然在一定程度上解决了“保持状态”的需求，但是由于cookie本身最大支持4096字节，以及cookie本身保存在客户端，可能被拦截或窃取，因此就需要有一种新的东西，它能支持更多的字节，并且他保存在服务器，有较高的安全性。这就是session。 - 问题来了，基于http协议的无状态特征，服务器根本就不知道访问者是“谁”。那么上述的cookie就起到桥接的作用。
- 我们可以给每个客户端的cookie分配一个唯一的id，这样用户在访问时，通过cookie，服务器就知道来的人是“谁”。然后我们再根据不同的cookie的id，在服务器上保存一段时间的私密资料，如“账号密码”等等。
- 总结而言：cookie弥补了http无状态的不足，让服务器知道来的人是“谁”；但是cookie以文本的形式保存在本地，自身安全性较差；所以我们就通过cookie识别不同的用户，对应的在session里保存私密的信息以及超过4096字节的文本。
- 而token则解决了当服务器端为web集群服务器时，具有多个服务器的session存储问题，当A服务器存有session，B无session，则客户端访问B还需要重新登陆。所以使用token将用户信息存储在Regis中，并将全局唯一的token发送给客户端，记录在cookie中。解决了session中存在的访问冗余问题