了解cookie概念
1，由来
http一个无状态的请求/响应协议，也就是说客户端给服务器发送请求，无论发送了多少次，服务器都不会记得客户的信息。
现代的web站点希望提供个性化的接触，它们希望对连接另一端的用户有更多的了解，并且能在用户浏览页面时对其进行跟踪。早期的web站点设计者们都有自己的用户识别技术，这些技术如下：
承载用户身份信息的HTTP首部。
客户端IP地址跟踪，通过用户的IP地址对其进行识别。
用户登录，用认证方式来识别用户。
胖url,一种在Url中识别信息的技术。
cookie，一种强大且高效的持久身份识别技术。
以上方式被不同的站点使用过，经过时间的检验，cookie这场用户识别技术的战争中胜出，是当前识别用户，实现持久会话的最好方式。cookie的存在也影响了缓存，大多数缓存和浏览器都不允许对任何cookie的内容进行缓存。
2，什么数据适合存放在cookie里？
cookie是存放在浏览器中的，在每一个浏览器安装目录下，都存在一个文件夹，存放 着不同域下对应的cookie。当浏览器通过http请求某一个域时，此时浏览器就会将 该域下面的cookie自动放入request header中。我们需要注意，浏览器自动帮我们 携带，此时如果很多无关紧要的数据都存放在cookie中，都会随着请求发送给后台， 这样就无形当中增加了网络开销。此时我们再想想什么数据在每一次都需要?其实我 们的身份认证信息在每一次都需要携带，所以存放在cookie的数据最合适的是身份认 证信息，其他信息都不合适。
在localStorage出现之前，cookie一直背开发者所滥用，导致很多的无关紧要的数 据被请求携带到服务器。cookie也存在一些限制，每一个域下的cookie最多是4KB, 每一个域下的cookie最多存在20条。
3，cookie分类：
cookie分为会话cookie和持久cookie，它们之间唯一的区别就是过期时间不同.
会话coolie: 是一种临时cookie,它记录了用户访问站点时的设置和偏好。用户退出浏览器时，会话cookie就被删除。
持久cookie: 存在硬盘上，浏览器退出重启它仍然存在。
4，cookie格式：
我们在控制台打印document.cookie就可以拿到当前域下面的全部可以访问的 cookie了(也就是非httpOnly的cookie),注意观察的cookie,是由key=value的形 式组成，并且在每一个key,value之间使用分号和空格隔开。
如何设置cookie 设置cookie分为前端设置cookie和后端设置cookie:
后端设置cookie:
当我们发送ajax请求的时候，服务器返回的请求头(response header),在
response header中存在set-cookie字段，我们可以通过返回set-cookie向浏览
器返回cookie数据。每一个set-cookie只能设置一个cookie。并且服务端可以设
置的属性有expires,domain,path,secure,httpOnly。具体如图所示。
客户端设置cookie:
在控制台执行下面代码(cookie的其余属性没有设置，则设为默认值) document.cookie = "name=ssss"也可以设置多个cookie
补充：
1、在cookie中只有key/domain/path都相同时，才能进行覆盖。
2、在设置domain的value设置多个点，则任何子域名都可以访问。 如不不设置点，则只有该domain才能访问。
cookie的工作原理
- 客户端首次访问网站服务的时候，不会携带对应cookie标识信息，服务器也不能识别客户端
- 服务器返回响应的时候，会通过set-coookie或者set-cookie2http响应首部将对应信息贴到用户身上.
- 用户响应返回的时候，浏览器会从返回的set-cookie或者set-cookie2http首部拿到cookie数据，将其保存在cookie数据库中。
- 当同一用户再次发送请求到相同服务器的时候，浏览器会将对应的cookie数据放在请求首部的cookie字段中。浏览器通过对应的cookie首部就能知道用户的一些身份信息
这里通过一个实例进行演示。
cookie的相关属性
不同的站点会有不同的cookie，当客户访问对应站点的时候，只会发送对应站点设置的cookie.
1，域属性
产生cookie的服务器可以向set-cookie服务器首部添加一个Domain属性来控制哪些站点可以看到这个cookie,例如将cookie user="peicui"的请求首部发给域 “.peicui.com"中的所有站点只需要在设置的时候添加一个domain属性即可：
set-cookie: user="peicui";domain="peicui.com"
2，路径属性 cookie规范允许用户将cookie与部分web站点关联起来，也就是说一
cookie版本
cookie版本分为cookie版本0和cookie版本1
cookie版本0
版本0的规范看起来如下：
Set-Cookie:name=value [; expires-date] [; path=path] [; domain=domain] [;secure]
Cookie: name=value1 [; name=value2] ...
set-cookie属性：
1, name=value:强制的，代表cookie名和值。
2, expires:可选，用来定义cookie的实际生存期，一旦过了这个日期，就不再存储或发布cookie了。
3, domain:可选，可选，对丁浏览器只向指定的服务器主机发送这个cookie.
4, path:可选，这个属性可以为服务器上特定的文档分配cookie.
5，可选，如果包含着一属性，只有在http使用ssk安全连接的时候才会发送cookie.
注意区分domain和path,domain决定向哪个域名发送cookie，path是决定对应域名下的某个文档发送cookie
Cookie首部：
客户端发送请求时，会将所有域，路径和安全过滤器匹配的未过期cookie都发送给站点。所有cookie都被组合到cookie首部中
Cookie:session-id=10001313;session-id-time=24898-800
cookie版本1 RFC 2965定义了一个cookie的扩展版本，这个版本1标准引入了Set-Cookie2首部，但他也能与版本1进行互操作。
cookie2主要做了以下一些改动：
1，为每个cooke关联上解释文本，对其目的进行解释
2，允许浏览器退出时，不考虑过期时间，将cookie强制销毁。
3，用相对秒数，而不是绝对日期累表示cookie的Max-Age
4,通过URL端口号，而不仅仅是域和路径来控制cookie的能力。
5，通过Cookie首部就回送域，短剧和路径过滤器
6，为实现互操作性使用的版本号
7，在Cookie首部从名字中区分附加关键字的$前缀
cookie版本的兼容
新形式的cookie请求首部为Cookie2:$Version="1",如果服务器理解新形式的cookie,就能够识别出Cookie2首部，并在相应首部发送Set-Cookie2.
如果客户端从一个响应中既获得了Set-Cookie首部，又获得了Set-Cookie2首部，就会忽略旧的，使用新的
如果客户端即支持版本0又支持1的cookie，但从服务器获得的是版本0的Set-Cookie首部，就应该呆着版本0的Cookie首部发送cookie.但客户端还应发送Cookie2:$Version="1"来告知服务器他是可以升级的。
cookie与登陆逻辑
- 前端通过用户名密码加密登陆
- 服务端校验密码通过,生成token,并保存在http响应头里
- 浏览器通过在返回的响应头里拿到cookie数据,并保存本地
- 再次请求相同域名,路径以及安全设置的地址时,浏览器会将对应的cookie数据放到请求头里,传送给服务
- 服务器通过cookie数据来区分不同的用户
cookie与session关系
1.浏览器端第一次发送请求到服务器端，服务器端创建一个session，同时会创建一个特殊的cookie，然后将cookie发送至浏览器端
2.浏览器端发送第N（N>1）次请求到服务器端，浏览器端访问服务器端的时候会携带cookie对象
3.服务器端会根据cookie的value值去查询Session对象，从而区分不同用户。
