如果把人体比作一个web系统的话，cookie、session和token就好像人体的经络和血管一样，而web系统中的数据，就好像人体的血液一样。血液依靠着血管在人体内流动，就如数据根据cookie和session机制在web系统中流动一样。而web系统开发者就好比一个医术精湛的医生，医生需要十分清楚人体的经络和血液流向才能对症下药，而web系统开发者需要十分清楚cookie、session机制，才能迅速解决疑难BUG，开发出更好的web系统。
在SSO单点登录中，已经介绍了http的无状态以及会话机制，这边还是复习一下
- http协议本身是一种无状态的协议，一个普通的请求大致分为三步：
1、客户端发送请求给服务器
2、服务器处理该请求
3、服务器将处理结果响应该客户端。
之后该客户端再次向该服务区发送请求后，服务器端并不能知道这两个请求是否是同一个浏览器或用户发出来的（下一次请求不依赖上一次请求）。所以作为web服务器必须能够采用某种方式来唯一识别同一个用户，并记录该用户的状态。而这同一个客户端与服务器端的在一段时间内的多次交互，我们就可以称该客户端为该服务器端的一个客户端会话窗口，有了会话窗口，我们就能确定哪个请求是哪个用户发出的了，从而可以实现会话跟踪，并记录用户的行为。
- 会话：
可以理解为用户打开浏览器，访问该web服务器的多个资源，然后关闭浏览器，这中间的一系列过程称之为一个会话。
- 有状态的会话
浏览器发送的每一次请求，每一个会话都要有唯一的标识来唯一标识自己，当浏览器发送请求的时候就带上这个标识来让服务器识别，从而实现有“状态”的会话。
- javaweb中有两种实现会话的机制：
1）Cookie机制
2）Session机制
一、cookie机制
1.基本介绍
- cookie机制采用的是在客户端保持 HTTP 状态信息的方案。当浏览器访问WEB服务器的某个资源时，WEB服务器会在HTTP响应头中添加一个键值对传送给浏览器，再由浏览器将该cookie放到客户端磁盘的一个文件中，该文件可理解为cookie域(键值对的集合)，往后每次访问某个网站时，都会在请求头中带着这个网站的所有cookie值。（至于怎么区分不同网站的cookie的，很简单，每个网站都给他一个唯一标识比如网址等，每次打开某网址时，就查询该网站下的所有cookie值即可。）
- 每一个cookie都有一个name和一个value，且name是唯一的。相同名字时，后者会覆盖掉前者（类似哈希表的key的效果）。
- 一个WEB浏览器也可以存储多个WEB站点提供的Cookie。浏览器一般只允许存放300个Cookie，每个站点最多存放20个Cookie，每个Cookie的大小限制为4KB。
2.分类
2.1 会话级别的cookie
默认情况下它是一个会话级别的cookie,存储在浏览器的内存中，用户退出浏览器之后被删除。
2.2 持久化的cookie
若希望浏览器将该cookie存储在磁盘上，则需要设置该cookie的生命周期setMaxAge，并给出一个以秒为单位的时间。将最大时效设为0则是命令浏览器删除该cookie。
|
也就是说，cookie默认的生命周期就是是关闭浏览器之前，但是可以通过setMaxAge设置器其生命周期
|
2.3 cookie的作用域
cookie的domain和path属性定义了cookie的作用范围，即访问哪些网站或url时，会自动的带着该cookie。domain即域名，默认是当前主机(不包括子域名)，path默认是*(所有路径)，即域名后面的的路径。大部分情况下我们都是使用默认的设置即可。
|
cookie的作用域为当前域及其子域。发起http请求时，浏览器能传过去的是种在自己域和父域上的cookie。 假设发起请求的域名是a.qq.com，那如果cookie-xxx是种在qq.com域上的，则该cookie就可以被a.qq.com或者b.qq.com或者qq.com发起的请求所使用；本地配置的dev.wetest.qq.com为其子域，所以自然就能拿到qq站上的cookie。 Domain为设置Cookie的有效域，Path限制有效路径，如以下几种情况： 1.最大可能的作用域 yourdomain.com所有角落（设置Cookie.Domain = "yourdomain.com"，效果为yourdomain.com域下的所有主机的所有位置都可以取到这个Cookie) 2.域下的某主机 www.yourdomain.com（设置Cookie.Domain = "www.yourdomain.com"，效果为www主机下所有位置可以取) 3.某主机的某个文件夹 www.yourdomain.com/bbs (Cookie.Domain ="www.yourdomain.com" ; Cookie.Path = "/bbs"，www主机的bbs下可以取) 默认情况是Domain为当前主机且不限制位置 |
4.基本原理
当一个浏览器访问某web服务器时，web服务器会调用HttpServletResponse的addCookie()方法，在响应头中添加一个名叫Set-Cookie的响应字段用于将Cookie返回给浏览器，当浏览器第二次访问该web服务器时会自动的将该cookie回传给服务器，来实现用户状态跟踪。
5.常用api
javax.servlet.http.Cookie类来封装Cookie信息，它包含有生成Cookie信息和提取Cookie信息的各个属性的方法。
1）public Cookie(String name,String value)
2）setMaxAge(int longTime)与getMaxAge方法：设置和获取cookie的最大有效时长。setMaxAge(0) 表示删除磁盘上的某个cookie。
注意：
cookie没有提供修改方法，当name一样时，覆盖原来的就算是更新了。
删除也是，setMaxAge(0),当name一样时，原来的会被覆盖掉，新建的没有生命周期，也会被立马删除。
3）setPath与getPath方法 :设置或读取Cookie的作用范围。
4）HttpServletResponse接口中定义了一个addCookie(Cookie cookie)方法，它用于在发送给浏览器的HTTP响应消息中增加一个Set-Cookie响应头字段。
5）HttpServletRequest接口中定义了一个getCookies方法，它用于从HTTP请求消息的Cookie请求头字段中读取所有的Cookie项。
6）getName方法 :获取到cookie的name。
7）setValue(String value)与getValue方法：设置和获取cookie的value。
6.基本应用
自动登录、跟踪用户上次访问站点的时间、显示最近浏览信息等。
7.Cookie中存储中文问题
cookie中存储中文会出现中文乱码，需要对value进行额外的编码
1、base64编码
存储：Base64.getEncoder().encodeToString(content.getBytes("utf-8"));
读取：new String(Base64.getDecoder().decode(cookie.getValue()),"utf-8")
2、URLEncoder类
存储：Cookie cookie = new Cookie("userName", URLEncoder.encode("你好世界", "UTF-8"));
读取：URLDecoder.decode(cookie.getValue(), "UTF-8")
二、session机制
1.基本介绍
session机制采用的是在服务器端保持 HTTP 状态信息的方案。为了加速session的读取和存储，web服务器中会开辟一块内存用来保存服务器端所有的session，每个session都会有一个唯一标识sessionid，根据客户端传过来的jsessionid(cookie中)，找到对应的服务器端的session。为了防止服务器端的session过多导致内存溢出，web服务器默认会给每个session设置一个有效期, （30分钟）若有效期内客户端没有访问过该session，服务器就认为该客户端已离线并删除该session。
2.保存sessionID的方式
1）cookie中
通过一个特殊的cookie，name为JSESSIONID，value为服务器端某个 session的ID，默认的方式。但是当浏览器禁用cookie后session就会失效。
2）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)。、
3.基本原理
当用户发送一个请求到服务器端时，服务器会先检查请求中是否含有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也没了。
4.常用API
- getId()方法：得到sessionid。
- invalidate()方法：让session立刻失效。
- getAttribute(String key)：根据key获取该session中的value。
- setAttribute(String key,Object value)：往session中存放key-value。
- removeAttribute(Stringkey)：根据key删除session中的key-value。
- getServletContext()：得到ServletContext。
- setMaxInactiveInterval(long timeout)/getMaxInactiveInterval：设置/获取session的最大有效时间。
- getCreationTime方法：获取session的创建的时间。
- getLastAccessedTime方法：获取session最后一次访问的时间。
- getSession()：从HttpServletRequest中获取session。
5.基本应用
跨浏览器的会话跟踪
因为cookie在多个浏览器之间是共享的(但是不能跨域)，所以可以将sessionid存在cookie中，再把cookie存入磁盘中，然后在其他浏览器中再次访问该服务器时，就会读取到cookie中的sessionid，从而回到上次访问的页面了。
一段示例代码：
session.setMaxInactiveInterval(2*3600);//session 保存俩小时
Cookie cookie=new Cookie("JSESSIONID",session.getId());//sessionid放到cookie中
cookie.setMaxAge(2*3600);//客户端的cookie也保存俩小时
cookie.setPath("/");//cookie作用范围设为整个项目
response.addCookie(cookie);//给浏览器返回该Cookie6.常见问题
1、关闭浏览器后cookie会消失吗？
答：看情况。
经过上面关于cookie的分析之后我们知道，cookie默认是存在于浏览器内存中的，若此时cookie没有持久化，浏览关闭后cookie会消失；若此时cookie进行了持久化，浏览器关闭后cookie不会消失。
2、关闭浏览器后session会消失吗？
答：看起来会实际上不会。
这个问题需要从以下两个方面考虑：
1）从服务器端考虑
我们知道session是存在于服务器端内存中的，和浏览器没有关系，所以浏览器关闭后，服务器端的session不会消失。（除非服务器重启或session达到了过期时间）
2）从浏览器端考虑
我们知道浏览器是根据cookie中的jesessionid值来唯一找到服务器端的session的，此时若cookie没有持久化，浏览器关闭后cookie也跟着消失。所以当用户再次打开浏览器后，由于没有了cookie中的jesessionid，自然也无法唯一找到服务器端的session，对用户来说，确实是浏览器关闭后再次打开就无法找到上次的会话了，误以为是关闭浏览器后服务器端的session也跟着消失，其实还在。
三、token
1.token是什么
token，可以翻译成"令牌"，本质上它是一个全局唯一的字符串，用来唯一识别一个客户端。但它不像cookie和session一样是一种web规范，个人认为他是借鉴了cookie和session工作的原理，进而延伸出来的一种维持用户会话状态的机制。
2.token解决了什么问题
token解决了session依赖于单个Web服务器的问题。单体应用时用户的会话信息保存在session中，session存在于服务器端的内存中，由于前前后后用户只针对一个web服务器，所以没啥问题。但是一到了web服务器集群的环境下（我们一般都是用Nginx做负载均衡，若是使用了轮询等这种请求分配策略），就会导致用户小a在A服务器登录了，session存在于A服务器中，但是第二次请求被分配到了B服务器，由于B服务器中没有用户小a的session会话，导致用户小a还要再登陆一次，以此类推。这样用户体验很不好。当然解决办法也有很多种，比如同一个用户分配到同一个服务处理、使用cookie保持用户会话信息等。
3.模拟cookie和session的这种机制：
①、cookie中是根据jesessionid来找到服务器端的session的，jesessionid就是一个全局唯一的随机字符串，我们也可以生成一个全局唯一的字符串比如使用UUID或时间戳加随机字符串的形式；
②、web服务器在内存中存储所有的session，每个session都有一个唯一的id标识，value就是session本身，session里面又有好多键值对。数据在内存中、key-value形式的、value里面又有好多键值对，这简直就是对redis的哈希表十分准确的描述啊，所以我们可以使用redis的哈希类型来模型服务器端的session。
③、有了客户端的随机字符串，有了服务器端的会话信息存储，接下来就让他们匹配起来就完事了，next：
cookie和session机制中是根据cookie中的jesessionid来自动找到服务器端的session，说是自动查找，其实是我们调用了他封装好的方法request.getSession()获取的，这个request中就包含了本次请求的所有信息，而调用的getSession()方法中，肯定做了这件事——获取请求头中cookie的jesessionid的值，根据这个值到服务器的内存中找到对应的session并返回。所以我们也完全可以模仿它这种机制：我们可以在用户第一次请求该web服务器时或是用户登录该web服务器时，生成一个全局唯一的token返回给前端存储，同时将该用户信息存到redis中并设置有效期，之后每次请求中都在请求头中带着这个token，服务器端根据这个token到redis中查找对应的用户信息，即得到了我们所说的 "session"。
客户端的token我们可以这样传：
$.ajax({
headers:{"token":localStorage.getItem('token')},
type: 'get',
url:'/xxx/xxx/xxx',
dataType: 'json',
success: function(we) {
// some code
});
},服务器端的用户信息我们可以这样获取：
/**
* 返回当前用户
* @return
*/
public User getCurrUser(){
ServletRequestAttributes servletRequestAttributes =
(ServletRequestAttributes)RequestContextHolder.getRequestAttributes();
String token = servletRequestAttributes.getRequest().getHeader("token");
String strUser = RedisUtils.get(token);
return JsonUtils.stringToObject(strUser,User.class);
}