一、什么是Cookie？
Cookie 技能产生源于 HTTP 协议在互联网上的连忙发展。随着互联网时期的发达发展，人们须要更繁芜的互联网交互活动，就必须同做事器保持活动状态。
于是，在浏览器发展初期，为了适应用户的需求技能上推出了各种保持 Web 浏览状态的手段，个中就包括了 Cookie 技能。Cookie 在打算机中是个存储在浏览器目录中的文本文件，当浏览器运行时，存储在 RAM 中发挥浸染 （此种 Cookies 称作 Session Cookies），一旦用户从该网站或做事器退出，Cookie 可存储在用户本地的硬盘上 （此种 Cookies 称作 Persistent Cookies）。
Cookie 起源：1993 年，网景公司雇员 Lou Montulli 为了让用户在访问某网站时，进一步提高访问速率，同时也为了进一步实现个人化网络，发明了本日广泛利用的 Cookie。（以是，适当的偷
Cookie时效性：目前有些 Cookie 是临时的，有些则是持续的。临时的 Cookie 只在浏览器上保存一段规定的韶光，一旦超过规定的韶光，该 Cookie 就会被系统打消。
Cookie利用限定：Cookie 必须在 HTML 文件的内容输出之前设置；不同的浏览器 (Netscape Navigator、Internet Explorer) 对 Cookie 的处理不一致，利用时一定要考虑；客户端用户如果设置禁止 Cookie，则 Cookie 不能建立。 并且在客户端，一个浏览器能创建的 Cookie 数量最多为 300 个，并且每个不能超过 4KB，每个 Web 站点能设置的 Cookie 总数不能超过 20 个。
实行流程：A：首先，客户端会发送一个http要求到做事器端。
B： 做事器端接管客户端要求后，发送一个http相应到客户端，这个相应头，个中就包含Set-Cookie头部。
C：在客户端发起的第二次要求（把稳：如果做事器须要我们带上Cookie，我们就须要在B步骤上面拿到这个Cookie然后作为要求头一起发起第二次要求），供应给了做事器端可以用来唯一标识客户端身份的信息。这时，做事器端也就可以判断客户端是否启用了cookies。只管，用户可能在和运用程序交互的过程中溘然禁用cookies的利用，但是，这个情形基本是不太可能发生的，以是可以不加以考虑，这在实践中也被证明是对的。
流程实行图
那么，在浏览器上面的要求头和Cookie在那？下图给大家截取了个中一种。
在Android开拓中，我们该如何去管理和利用Cookie？
Okhttp作为经典到爆的网络框架，理论上，我们只需在构建单例OkhttpClient的时候，设置cookiejar或者拦截器，然后详细的操作（详细的操作也便是保存Cookie，取Cookie），Okhttp框架就会帮我们自动管理Cookie。如下图：
这是个中一种通过凑集的增查特性，就可以大略有效的帮我们管理Cookie。但我们还是要通过源代码去一探究竟。首先，CookieJar是一个接口。
CookieJar这个接口为HTTP cookies供应了强大的支持和干系策略。这种策略的实现浸染会卖力选择接管和谢绝那些cookie。一个合理的策略是谢绝所有的cookie，只管这样会滋扰须要cookie的基于会话的自身身份验证方案。作为Cookie的持久性，该接口的实现也必须要供应Cookie的存储。一种大略的实现可以将cookie存储在内存中;繁芜的系统可以利用文件系统用于保存已接管的cookie的数据库。这里的链接https://tools.ietf.org/html/rfc6265 指定cookie存储模型更新和过期的cookie的策略。
连续剖析CookieJar接口里面的方法，依旧上源码
里面有方法一个是saveFromResponse(HttpUrl url, List cookies)、loadForRequest(HttpUrl url)。
saveFromResponse方法翻译：根据这个jar的方法，可以将cookie从一个HTTP相应保存到这里。如果相应，此方法可能被称为第二次HTTP相应，包括一个追踪。对付这个暗藏的HTTP特性，这里的cookie只包含其追踪的cookie。大略点理解便是如果我们利用了这个方法，就会进行追踪（说白了便是客户端要求成功往后，在相应头里面去存cookie）。
将cookie从这个方法加载到一个HTTP要求到指定的url。这个方法从网络上返回的结果可能是一个空凑集。大略的实现将返回尚未过期的已接管的cookie去进行匹配。（说白了便是加载url的时候在要求头带上cookie）。
通过以上代码就可以完成了Cookie的非持久化。在上面说道，Cookie是具有时效性的，以是，Cookie的管理又分为持久化Cookie和非持久化Cookie。非持久化Cookie存储在内存中，其生命周期基本和app保持同等,app关闭后，Cookie丢失。而持久化Cookie则是存储在本地磁盘中，app关闭后不丢失。那么，如果要利用Cookie的持久化策略，思想可以参考上面的非持久化策略，只须要将存储办法改一下即可：
A：通过相应拦截器从response取出cookie并保存到本地，通过要求拦截器从本地取出cookie并添加到要求中
B：自定义CookieJar，在saveFromResponse()中保存cookie到本地，在loadForRequest()从本地取出cookie。
先容如何通过Okhttp逼格值较高的拦截器去进行持久化cookie操作。
保存cookie拦截器-1
这个SaveCookiesInterceptor拦截器的实现，是首先从response获取set-cookie字段的值，然后通过SharedPreferences保存在本地。
保存cookie拦截器-2
这个SaveCookiesInterceptor拦截器的实现，是首先从response获取set-cookie字段的值，然后通过SharedPreferences保存在本地。
将Cookie添加到要求头
AddCookiesInterceptor要求拦截器，这个拦截的浸染便是判断如果该要求存在cookie，则为其添加到Header的Cookie中。写好这两个拦截器之后，我们只须要将实例工具放进OkhttpClient里面即可快速的完成Cookie持久化操作。（PS：这两个拦截器在同步Cookie的时候也是超级好用）。
Okhttp利用cookie拦截器
二、Session
Session是对付做事端来说的，客户端是没有Session一说的。Session是做事器在和客户端建立连接时添加客户端连接标志，终极会在做事器软件（Apache、Tomcat、JBoss）转化为一个临时Cookie发送给给客户端，当客户端第一要求时做事器会检讨是否携带了这个Session（临时Cookie），如果没有则会添加Session，如果有就拿出这个Session来做干系操作。
我们知道用浏览器打开一个网页，用到的是HTTP协议，理解打算机的该当都知道这个协议，它是无状态的，什么是无状态呢？便是说这一次要乞降上一次要求是没有任何关系的，互不认识的，没有关联的。但是这种无状态的的好处是快速。以是就会带来一个问题便是，我希望几个要求的页面要有关联，比如：我在www.a.com/login.php里面上岸了，我在www.a.com/index.php 也希望是上岸状态，但是，这是2个不同的页面，也便是2个不同的HTTP要求，这2个HTTP要求是无状态的，也便是无关联的，以是无法纯挚的在index.php中读取到它在login.php中已经上岸了！
那咋办呢？我不可能这2个页面我都去上岸一遍吧。或者用笨方法这2个页面都去查询数据库，如果有上岸状态，就判断是上岸的了。这种查询数据库的方案虽然可行，但是每次都要去查询数据库不是个事，会造成数据库的压力。以是正是这种诉求，这个时候，一个新的客户端存储数据办法涌现了：cookie。cookie是把少量的信息存储在用户自己的电脑上，它在一个域名下是一个全局的，只要设置它的存储路径在域名www.a.com下 ，那么当用户用浏览器访问时，php就可以从这个域名的任意页面读取cookie中的信息。以是就很好的办理了我在www.a.com/login.php页面上岸了，我也可以在www.a.com/index.php获取到这个上岸信息了。
虽然这种方案很不错，也很快速方便，但是由于cookie 是存在用户端，而且它本身存储的尺寸大小也有限，最关键是用户可以是可见的，并可以随意的修正，很不屈安。那如何又要安全，又可以方便的全局读取信息呢？于是，这个时候，一种新的存储会话机制：session 出身了。
Session 便是在一次会话中办理2次HTTP的要求的关联，让它们产生联系，让2两个页面都能读取到找个这个全局的session信息。session信息存在于做事器端，以是也就很好的办理了安全问题。
三、Token
常日叫它令牌。最大略的token组成:uid(用户唯一的身份标识)、time(当前韶光的韶光戳)、sign(署名，由token的前几位+哈希算法压缩成一定长的十六进制字符串，可以防止恶意第三方拼接token要求做事器)。还可以把不变的参数也放进token，避免多次查库。
1、运用处景：
A：当用户首次登录成功（注册也是一种可以适用的场景）之后, 做事器端就会天生一个 token 值，这个值，会在做事器保存token值(保存在数据库中)，再将这个token值返回给客户端.
B：客户端拿到 token 值之后,进行本地保存。（SP存储是大家能够比较支持和易于理解操作的存储）
C：当客户端再次发送网络要求(一样平常不是登录要求)的时候,就会将这个 token 值附带到参数中发送给做事器.
D：做事器吸收到客户真个要求之后,会取出token值与保存在本地(数据库)中的token值做比拟
比拟一：如果两个 token 值相同， 解释用户登录成功过!当前用户处于登录状态!
比拟二：如果没有这个 token 值, 则解释没有登录成功.
比拟三：如果 token 值不同: 解释原来的登录信息已经失落效,让用户重新登录.
2、Cookie和Session的差异：
A、cookie数据存放在客户的浏览器上，session数据放在做事器上。
B、cookie不是很安全，别人可以剖析存放在本地的cookie并进行cookie欺骗,考虑到安全应该利用session。
C、session会在一定韶光内保存在做事器上。当访问增多，会比较占用你做事器的性能,考虑到减轻做事器性能方面，应该利用cookie。
D、单个cookie保存的数据不能超过4K，很多浏览器都限定一个站点最多保存20个cookie。
E、建议：将上岸信息等主要信息存放为session，其他信息如果须要保留，可以放在cookie中。
3、Token 和 Session 的差异：
session和 token并不抵牾，作为身份认证token安全性比session好，由于每个要求都有署名还能防止监听以及重放攻击，而session就必须靠链路层来保障通讯安全了。如果你须要实现有状态的会话，仍旧可以增加session来在做事器端保存一些状态。
App常日用restful api跟server打交道。Rest是stateless的，也便是app不须要像browser那样用cookie来保存session,因此用session token来标示自己就够了，session/state由api server的逻辑处理。如果你的后端不是stateless的rest api,那么你可能须要在app里保存session.可以在app里嵌入webkit,用一个隐蔽的browser来管理cookie session.
Session是一种HTTP存储机制，目的是为无状态的HTTP供应的持久机制。所谓Session认证只是大略的把User信息存储到Session里，由于SID的不可预测性，暂且认为是安全的。这是一种认证手段。而Token，如果指的是OAuth Token或类似的机制的话，供应的是 认证 和 授权 ，认证是针对用户，授权是针对App。其目的是让 某App有权利访问 某用户 的信息。这里的Token是唯一的。不可以转移到其它App上，也不可以转到其它 用户 上。转过来说Session。Session只供应一种大略的认证，即有此SID，即认为有此User的全部权利。是须要严格保密的，这个数据该当只保存在站方，不应该共享给其它网站或者第三方App。以是大略来说，如果你的用户数据可能须要和第三方共享，或者许可第三方调用API接口，用Token。如果永久只是自己的网站，自己的App，用什么就无所谓了。
token便是令牌，比如你授权（登录）一个程序时，他便是个依据，判断你是否已经授权该软件；cookie便是写在客户真个一个txt文件，里面包括你登录信息之类的，这样你下次在登录某个网站，就会自动调用cookie自动登任命户名；session和cookie差不多，只是session是写在做事器真个文件，也须要在客户端写入cookie文件，但是文件里是你的浏览器编号.Session的状态是存储在做事器端，客户端只有session id；而Token的状态是存储在客户端。
