什么是Http无状态？Session、Cookie、Token三者之间的区别

1、什么是HTTP无状态？

1.1定义：

HTTP无状态协议，是指协议对于交互性场景没有记忆能力。

1.2举个例子：

在点击一个纯的html网页，请求获取服务器的html文件资源时，每次http请求都会返回一样的信息，由于这个是没有交互的，每一次的请求都是相互独立的。第一个请求和第二个请求也没有前后顺序，返回处理哪一个，结果都是一样的资源页面，由于这种场景是无交互的，不管是什么人请求这个地址，服务器都是返回那个相同的响应。

在无交互场景中上面那样，固然也不会有太大的问题。可是对于涉及到动态交互的场景，就显得很尴尬了，何为交互？有来又有往，对于如出一辙的两个接口，不一样的人在请求第二个接口时可能会基于请求第一个接口的结果而有所不一样。

1.3具体场景：

如今咱们来想一个复杂的场景，如在购物网站上买一个书包，流程以下：

1. 输入帐号密码登录 /login 用户信息
2. 选择一款你喜欢的书包加入到购物车中 /cart 用户信息，产品信息
3. 购买支付 /pay 用户信息，商品信息，金额信息

所谓的登陆只是验证你是不是一个合法用户，如果合法则跳转到信息的页面，不合法则告知用户名密码错误。

可是咱们在第一步给服务器发完/login接口后，服务器就忘记了。。。忘记了你这我的，到底有没有通过认证。

因此在添加商品时/cart 你仍是须要将你的帐号密码和商品信息一块儿提交给 addCart接口，再让服务器作验证。

第三步同理。

1.4存在的问题：

因此咱们说涉及到交互时，情形就彻底不同了，由于这三步是有依赖关系的，第一步验证登陆者是一个合法用户，验证经过给你返回200/OK，可是只要服务器给返回了响应，那么一个http的请求和响应就结束了。服务器怎么知道10秒钟以前你刚刚登陆过呢？很差意思，服务器不知道你有没有登录过，他只是对外提供一个登陆接口，要想证实你是合法用户必须调/login接口。

第二步，将商品加入到购物车中时，你会调用/cart接口，可是注意，这个行为是和第一步是有关联关系的，是谁将什么物品加入到购物车中了？这个谁，有没有在网站上注册帐号呢，是否是一个合法用户呢？因此说在添加购物车的时候，咱们还须要将帐号密码再次加入到请求参数中，每作一次操做购物车操做时，都须要再把以前已经传输过的帐号密码，再反反复复的传输一遍又一遍，这是由于服务器不知道你是否是在20秒以前刚登录过。

1.5总结：

上面的无状态是指的，无登陆状态，即服务器不知道某个用户是否已登陆过了。由于愚蠢的服务器不知道客户端是否已登陆过了,因此每次都要在交互场景(会话)中请求中带上上一次的请求信息，如帐号、密码。明明只须要在/login接口中，才须要对比数据库中的帐号密码和客户端传的是否一致来肯定合法性。这下在添加购物车中也须要再一次的进行一样的重复且没有必要的操做，即下降了响应速度，又对用户不友好（由于每次都须要填帐号，密码）。

缺乏状态意味着若是后续处理须要前面的信息，则它必须重传，这样可能致使每次链接传送的数据量增大。另外人们常说的“会话”概念则是上面的交互行为的另外一种表述方式。

2、让服务器有记忆能力之Cookie、Session

背景：

经过上面咱们知道了Http中无状态是一个什么概念，以及在无状态状况下，要进行添加购物车功能，所带来的困难。

前瞻：

客户端与服务器进行动态交互的Web应用程序出现以后，HTTP无状态的特性严重阻碍了这些应用程序的实现，毕竟交互是须要承前启后的，简单的购物车程序也要知道用户到底在以前选择了什么商品。因而，两种用于保持HTTP链接状态的技术就应运而生了，一个是Cookie，而另外一个则是Session。HTTP自己是一个无状态的链接协议，为了支持客户端与服务器之间的交互，咱们就须要经过不一样的技术为交互存储状态，而这些不一样的技术就是Cookie和Session了。

Cookie

因为HTTP是一种无状态的协议，服务器单纯从网络链接上无从知道客户身份。怎么办呢？就给客户端们颁发一个通行证吧，每人一个，不管谁访问都必须携带本身通行证。这样服务器就能从通行证上确认客户身份了。这就是Cookie的工做原理。 

 

Cookie其实是一小段的文本信息。客户端请求服务器，若是服务器须要记录该用户状态，就使用response向客户端浏览器颁发一个Cookie。客户端浏览器会把Cookie保存起来。当浏览器再请求该网站时，浏览器把请求的网址连同该Cookie一同提交给服务器。服务器检查该Cookie，以此来辨认用户状态。服务器还能够根据须要修改Cookie的内容。

 Cookie的不可跨域名性

 不少网站都会使用Cookie。例如，Google会向客户端颁发Cookie，Baidu也会向客户端颁发Cookie。那浏览器访问Google会不会也携带上Baidu颁发的Cookie呢？或者Google能不能修改Baidu颁发的Cookie呢？

答案是否认的。Cookie具备不可跨域名性。根据Cookie规范，浏览器访问Google只会携带Google的Cookie，而不会携带Baidu的Cookie。Google也只能操做Google的Cookie，而不能操做Baidu的Cookie。

Cookie在客户端是由浏览器来管理的。浏览器可以保证Google只会操做Google的Cookie而不会操做Baidu的Cookie，从而保证用户的隐私安全。浏览器判断一个网站是否能操做另外一个网站Cookie的依据是域名。Google与Baidu的域名不同，所以Google不能操做Baidu的Cookie。

Cookie的一个实例

1.在登陆网站的时候选择记住密码

2.点击以后观察服务器的相应内容

 3.查看Chrome中的Cookie设置

4.观察服务器返回的Cookie内容 

 5.再次访问时，发现不须要输入密码便可直接登陆，观察请求头信息

 

Cookie记录登陆状态的三个方案 

cookie并非单纯为了实现 session机制而生的。而是1993 年，网景公司雇员 Lou Montulli 为了让用户在访问某网站时，进一步提升访问速度，同时也为了进一步实现我的化网络，发明了今天普遍使用的 Cookie。cookie还用一个很普遍的用途就是记住用户的登陆帐号和密码，这样当用户之后再次须要登陆同一个网站或系统的时候就不须要再次填写这两个字段而是直接点击“登陆”按钮就好。这就至关于给了一些“甜头”给用户，这就回应了“cookie”这个词语的字面意思了。

 

若是用户是在本身家的电脑上网，登陆时就能够记住他的登陆信息，下次访问时不须要再次登陆，直接访问便可。

 

实现方法是把登陆信息如帐号、密码等保存在Cookie中，并控制Cookie的有效期，下次访问时再验证Cookie中的登陆信息便可。

 

保存登陆信息有多种方案

• 方案一：最直接的是把用户名与密码都保持到Cookie中，下次访问时检查Cookie中的用户名与密码，与数据库比较。这是一种比较危险的选择，通常不把密码等重要信息保存到Cookie中。

• 方案二：是把密码加密后保存到Cookie中，下次访问时解密并与数据库比较。这种方案略微安全一些。若是不但愿保存密码，还能够把登陆的时间戳保存到Cookie与数据库中，到时只验证用户名与登陆时间戳就能够了。

• 方案三：只在登陆时查询一次数据库，之后访问验证登陆信息时再也不查询数据库。实现方式是把帐号按照必定的规则加密后，连同帐号一块保存到Cookie中。下次访问时只须要判断帐号的加密规则是否正确便可。

一和二两种方案验证帐号时都要查询数据库。

方案三把帐号保存到名为account的Cookie中，把帐号连同密钥用MD5算法加密后保存到名为ssid的Cookie中。验证时验证Cookie中的帐号与密钥加密后是否与Cookie中的ssid相等。

提示：该加密机制中最重要的部分为算法与密钥。因为MD5算法的不可逆性，即便用户知道了帐号与加密后的字符串，也不可能解密获得密钥。所以，只要保管好密钥与算法，该机制就是安全的。

 

Session

因为网页是一种无状态的链接程序，所以没法得知用户的浏览状态。在网上购物的时，把不少商品加入了购物车，而在结帐时网站殊不知道你购物车有哪些物品。为了解决这个问题，服务器端就为特定用户建立了特定的session，用于标示并跟踪这个用户，这样才知道购物车里有哪些商品。

• Session是另外一种记录客户状态的机制，不一样的是Cookie保存在客户端浏览器中，而Session保存在服务器上。

• 客户端浏览器访问服务器的时候，服务器把客户端信息以某种形式记录在服务器上。这就是Session。客户端浏览器再次访问时只须要从该Session中查找该客户的状态就能够了。

• 若是说Cookie机制是经过检查客户身上的“通行证”来肯定客户身份的话，那么Session机制就是经过检查服务器上的“客户明细表”来确认客户身份。

• Session至关于程序在服务器上创建的一份客户档案，客户来访的时候只须要查询客户档案表就能够了。

 

Session和Cookie的关系

• cookie 是一个实际存在的、具体的东西，http 协议中定义在 header 中的字段。
• session 是一个抽象概念、开发者为了实现中断和继续等操做，将client和server之间一对一的交互，抽象为“会话”，进而衍生出“会话状态”，也就是 session 的概念。
• 即session描述的是一种通信会话机制，而cookie只是目前实现这种机制的主流方案里面的一个参与者，它通常是用于保存session ID。

 

 

Token的相关讲解见 http://weixin.niurenqushi.com/article/2017-03-20/4794863.html

HMac介绍：hmac

 

参考文章：

https://www.jianshu.com/p/bdc97c096fbc

http://www.javashuo.com/article/p-wzffznna-hb.html

http://weixin.niurenqushi.com/article/2017-03-20/4794863.html

https://www.cnblogs.com/yupeng/archive/2012/05/24/2515228.html