【前端】基本功，人话解释session，token，cookie。

前言

从未整理过关于网络方面的知识，老知识了，但又十分重要，各位看官将就哈！

cookie

cookie，翻译过来就是 饼干/小甜点 的意思，cookie一种在浏览器用于存储来自不同网站的信息，cookie由键值对的形式存储，能够永久存储于浏览器的一种数据形式，因为cookie是存储于浏览器（客户端）的，所以浏览器对cookie做了一些限制确保cookie不会被恶意使用，同时又不会占据太多空间，所以每个域能够在客户端存储的cookie是有限的。

文中提到的session和token都是以cookie的形式存储在客户端的浏览器的。

session

session，会话，用于标记每个不同客户端。

首先我们要知道HTTP是一种无状态的协议，这也就意味着，每次客户端访问服务器，服务器收到的都是一个全新的请求，不知道谁是谁，等于说一次访问前后就失去了关联。

张三（客户端）：你好，我是张三。												//客户端登录
李四（服务端）：好的，张三，我知道你，你是我们这儿的会员，请问你需要什么帮助？		//服务端验证通过
张三（客户端）：我想要查询我的个人信息。										//客户端操作（新的请求）
李四（服务端）：你是谁？你还没告诉我？											//服务端提示未登录
。。。

所以session的出现了，客户端第一次请求的时候，服务端生成一串随机字符串id，给客户端一份，自己在数据库存储一份，客户端下次请求的时候带上这串id，服务端到自己数据库查找客户端带过来的id，便知道这次请求是哪个客户端发起的了。

张三（客户端）：你好，我是张三。												
李四（服务端）：好的，张三，我知道你，你是我们这儿的会员，这是你的门卡，下次过来请带上？ 
张三（客户端）：我想要查询我的个人信息。(并且交出了门卡给李四瞧一眼)							
李四（服务端）：好的张三，这是你的个人信息。（服务端到自己的卡库里面查找张三给的这张纸，验证是否是之前自己发给张三过）									
。。。

session的出现，解决了HTTP无状态带来的问题，客户端舒服了，但是服务器就惨了，具体由session引发的问题在下面发展史会讲。

token

token的出现，是为了解决由于session带来的问题，一种升级版的HTTP无状态问题解决方案。

首先token是一串通过HMAC-SHA256算法加密过的字符串

一次完整的token验证流程为：

1. 客户端首次发起请求，带上自己的独有信息（例如浏览器信息，ip地址，用户名等等）
2. 服务端接收到请求，将客户端的带来的信息，和自己一串私有的密钥，通过HMAC-SHA256算法加密生成一串token字符串，响应的时候讲这串token字符串返回，自己不存储这串token。
3. 客户端将token保存在自己的本地，再次发起请求的时候带上这串token。
4. 服务端将客户端带来的独有信息，通过和自己私有的密钥，通过HMAC-SHA256算法加密生成一串token字符串，再将这串新生成的token和客户端带来的token进行比较，如果一致，则访问通过。

发展史

早期的上网模式，浏览器访问某个网站都是文档形式浏览，服务端仅仅是将客户端请求的东西返回回去，不需要记录谁再某一段时间内浏览了什么内容，所以每次HTTP请求都是一次全新的请求，服务端也不用管对方是谁，你要啥我给你啥就完事了。

随着web的发展，像购物网站，论坛等的发展，最简单的，只要是需要登录的网站，服务器必须管理会话，必须知道谁是谁，而不是你要啥我就给你啥，这时候session出现了。

你访问我，我给你一串session id，我自己备份一个，你下次过来，我对比下我自己记录的session id，我就可以知道你是谁了。

随机带来的问题也很严重：

1. 内存开销：因为往往一个网站是有成千上万的人同时来访问，如果每个人我都要存一份session id在我这，那么对于我的服务器的存储是一个巨大的开销。
2. 拓展限制：服务器A想拓展自己的服务器，多开一个服务器B来做负载均衡，那就是一个棘手的问题：
   1. 例如客户端小a访问服务器A，服务器A给了小a一份session id，自己存一份，小a又来发请求，但是这次请求被转发到了服务器B，服务器B并没有存储小a的session id，那么小a这时候又得重新验证。
   2. 如果每次服务器创建一个新的session id，就往自己其他的服务器复制粘贴一份，开销代价就会升高。
   3. 如果统一集中将session id都存在一个服务器，其他的服务器都来这里做验证，万一这个session服务器挂了，那么全部都挂了。
3. 安全问题：客户端session id一旦泄露，他人便可带着这个session id来访问我的服务器，我服务器经过验证这个session id是可以通过的（之前存储过），那么便会造成了其他人冒名顶替的问题，这里有个专业名词叫CSRF(跨站请求伪造)

于是乎token横空出世，我服务器不保存这个可恶的session id，我给你个token，你下次来访问我带上token，我临时再赶紧算一下这个token对不对，对就让你过了，所以事情目前也就得到了解决方案。

小结

​ token的出现解决的大头问题的服务器端的压力，但是本质上换汤不换药（个人理解），新的验证形式罢了。