Android_Banner.jpg
HTTP本身是【无状态】，对于HTTP来说无状态这个特点是一把双刃剑
优点就是服务器不用存储状态。可以容易组成集群，缺点就是无法记录有状态的连续事务操作；
后来出现了Cookie机制，由于HTTP本身的优点中有一点是可扩展，Cookie机制的加入这就给HTTP增加了【记忆功能】
Cookie的工作过程
头字段
响应头字段【Set-Cookie】和请求头字段【Cookie】
工作过程
创建Cookie
当浏览器第一次访问服务器时，服务器不知道这哥们是谁，就需要创建一个身份标识数据，格式时【key=value】，然后放进Set-Cookie字段里，随着响应报文一同发给浏览器；
接受存储Cookie
浏览器收到响应报文时就查找Set-Cookie中给的身份，并且【存储起来】，等着下次请求时就自动把这个值放进Cookie字段里面发送给服务器；
使用Cookie
当第二次请求时，请求报文中就携带了Cookie字段，服务器收到后就知道这哥们我认识，就拿出Cookie中的值，识别出了用户画像，提供个性化服务；
有时服务器会在响应头中添加多个Set-Cookie，浏览器这边就存储多对【key-value】，浏览器这边再次请求时就使用一个Cookie，对应多对【key-value】使用【;】进行分隔；
Cookie工作示意图
HTTP中Cookie的工作机制.png
需要明确
cookie是由客户端存储的（浏览器），当我们换浏览器或者设备时（电脑）服务器就不认得我们啦；
Cookie的属性
所谓的Cookie属性就是用来保护Cookie防止外泄或者窃取；
Cookie的生存周期
Cookie的有效期，让它只能在一段时间内可以用；
Cookie的有效期可以使用【Expires】和【Max-Age】两个属性设置；
Expires
俗称过期时间，可以理解为截止日期
Max-Age
用的是相对时间，当客户端收到报文的时间点加上Max-Age，就可以得到失效的绝对时间；
客户端会 优先采用Max-Age的机制计算失效期；
Cookie的作用域
原理很简单，响应报文中Set-Cookie中，会携带【Domain】和【Path】的属性，
当我们浏览器请求时会从URI中提取host和path部分，对比Domain和Path的属性，如果匹配不成功，请求头字段中就不带Cookie了；
使用Cookie作用域可以为不同的域名和路径设置不同的Cookie；
Cookie的安全性
在日常的开发中。FE同学可以在JS脚本中用【document.cookie】来读写Cookie数据，这就带来隐患，可能会导致【跨站脚本】攻击窃取数据；
HTTPOnly
会告诉浏览器，该Cookie只能通过浏览器HTTP协议传输，禁止其他的方式访问；
那么JS引擎就会禁用documen.cookie的API
SameSite
可以防范【跨站请求伪造】攻击，有如下三种值可设置；
SameSite=Strict
严格规定Cookie不能随着跳转链接跨站发送
SameSite=Lax
稍微宽松一点，允许GET/HEAD等方法携带，但是禁止POST跨站携带发送
SimeSite=None;Secure
标识这个Cookie发送只能使用HTTPS协议加密传输，明文的HTTP协议会禁止发送；
最近在做Target31升级，就涉及到SameSite属性变更的改造（WebView；升级到Target31后Cookie中SameSite属性默认是Lax），由于业务方很多包含客户端、Server、FE这个改造成本很大，后面有机会写写这个改造过程；
Cookie的应用
身份识别
用户携带用户的登录信息，实现连续的会话务；
广告跟踪
当我们上网时看过很多广告的图片，这些广告图片背后都是广告商网站，它会给你悄悄搞上Cookie，这样你上其他网站别的地方广告就能用这个Cookie读出你的身份，做出分析，给你接着推广告；
网友评论