由于 HTTP协议是无状态的，所以为了能让服务器知道用户当前所处的状态，就需要存储一些信息在当前用户访问的浏览器中，并且需要在下次请求时发送到服务器端，而存储的这些信息就是Cookie；Cookie的意思就是小饼干，就是小而甜的意思。
Cookie的特性
Cookie是不能跨浏览器的，也就说你使用Goole浏览器产生的Cookie信息，IE浏览器是访问不到的
每个浏览器都会限制存储Cookie的个数，像FireFox就限制最多有50个Cookie，单个Cookie文件的大小限制为4KB
由于同源策略的限制（ 协议，域名，端口相同则为同源 ），所以Cookie也有两个参数来设置Cookie的作用域：
- Domain：设置
Cookie可以被那些域名获取到 - Path：设置可以访问
Cookie的路径
浏览器提交Cookie需要满足如下的两个条件：
- 是当前域名和或者父域名的
Cookie - 是当前路径或者父路径的
Cookie
满足上面两个条件的Cookie才能被发送到服务器端，下面举个例子，来说明下Cookie的作用域：
Cookie1:[name=value,domain=.wisepass.com,path=/]
Cookie2:[name=value,doamin=www.wisepass.com,path=/order]
Cookie3:[name=value,domain=www.wisepass.com,path=/]
Cookie4:[name=value,doamin=exmaple.wisepass.com,path=/]
上面列出来四个Cookie，下面来看下www.wisepass.com能获取到那些Cooki:
- Cookie1可以获取到，因为
Cookie1的domain是当前这个域名的父域，Path 的路径也一致 - Cookie2获取不到，虽然他们的域名相同，但是
Cookie2的Path是它的子路径而不是父路径 - Cookie3可以获取到，他们的域名和路径都一致
- Cookie4 获取不到，因为
domain不一致，也不是它的父域名
Session
Session就是会话的意思，也就是客户端访问服务器之后就会和服务器建立一种Session（会话的）关系，当客户端下次访问时就能知道当前这个客户端是谁了
相较于Cookie而言，Session是存储在服务器端的。客户端首次请求时，就会生成一条Session记录，存储在服务器端，同时为这条Session记录生成唯一的SessionID通过SetCookie返回到客户端存储起来，之后客户端再次请求时，服务端通过 Cookie拿到SessionID可以判断客户端身份了
已经有了Cookie了，那为什么还需要Session呢？是因为Cookie其实有很多的限制的，每种浏览器存储Cookie都会有大小限制；Cookie是存储在客户端的所以很容易被篡改；每次发送请求时都会带着Cookie所以一些敏感信息不方便存储在Cookie中；还有就是Cookie有同源限制的问题；所以将一些用户的登录信息存储在Session中比较方便，安全；
Session-Cookie 认证机制
- 用户输入登录信息
- 服务器验证登录信息，如果正确，则生成 session 信息，并且存储到 Redis 中
- 服务端为当前的 Session 信息生成一个唯一的标识
SessionID，然后放入的Response Header中的SetCookie中 - 浏览器收到响应后就会把
Cookie存起来，当下次请求时，浏览器会自动带上该Cookie - 服务端从
Request Header解析Cookie获取到 SessionID，然会通过此SessionID获取保存在服务器端的Session信息进行权限校验 - 当然当浏览器退出登陆时，浏览器端的
Cookie和服务器端的Session都会被清除调
基于 Session - Cookie 认证的优缺点
session-cookie 认证机制在基本上所有的网页浏览器上都能够支持，而且实现方式也很简单
- 当存在多台服务器时会出现
session同步问题 - 很容易遭受到
Cookie欺骗和CRFS攻击 - 服务端存储压力，当很多的
session存储到服务端时，会对服务器的存储造成压力 - 跨域问题，
Cookie是属于同源策略限制的条件之一
