第一层：基本含义

可以使无状态的Http协议记录稳定的状态成为可能

什么是Cookie？

简单来说就是客户端存值技术的一种，是服务器发送到用户浏览器并保存在浏览器上的一小块数据，它会在浏览器下次向同一服务器再次发起请求时被携带并发送到服务器上。

Cookie 主要用于以下三个方面：

1、会话状态管理（如用户登录状态、购物车、游戏分数或其它需要记录的信息）

2、个性化设置（如用户自定义设置、主题等）

3、浏览器行为跟踪（如跟踪分析用户行为等）

什么是Session？

简单来说就是服务器存值技术的一种，在服务器上存在着一块区域来存放数据，浏览器可以通过SESSIONID去服务器上进行查询。Session 代表着服务器和客户端一次会话的过程。Session 对象存储特定用户会话所需的属性及配置信息。这样，当用户在应用程序的 Web 页之间跳转时，存储在 Session 对象中的变量将不会丢失，而是在整个用户会话中一直存在下去。当客户端关闭会话，或者 Session 超时失效时会话结束。

第二层：区别

Cookie和Session的区别？

1、作用范围不同：Cookie 保存在客户端（浏览器），Session 保存在服务器端；

2、存取方式的不同：Cookie 只能保存 ASCII，Session 可以存任意数据类型，一般情况下我们可以在 Session 中保持一些常用变量信息，比如说登录的用户信息等；

3、有效期不同：Cookie 可设置为长时间保持（自定义），Session 一般失效时间较短，客户端关闭或者 Session 超时都会失效；

4、隐私策略不同：Cookie 存储在客户端，比较容易遭到不法获取，早期有人将用户的登录名和密码存储在 Cookie 中导致信息被窃取；Session 存储在服务端，安全性相对 Cookie 要好一些；

5、存储大小不同， 单个 Cookie 保存的数据不能超过 4K，Session 可存储数据远高于 Cookie。

第三层：为什么需要 Cookie和Session，两者关联？

浏览器基于无状态的Http协议，那么浏览器不知道是哪个确切的用户在跟服务器打交道。而Cookie和Session配合，能实现浏览器确认本次操作是否有用户登录，以及是哪个用户登录在进行操作

Cookie与Session

用户第一次请求服务器的时候，服务器根据用户提交的相关信息，创建创建对应的 Session ，请求返回时将此 Session 的唯一标识信息 SessionID 返回给浏览器，浏览器接收到服务器返回的 SessionID 信息后，会将此信息存入到 Cookie 中，同时 Cookie 记录此 SessionID 属于哪个域名。

当用户第二次访问服务器的时候，请求会自动判断此域名下是否存在 Cookie 信息，如果存在自动将 Cookie 信息也发送给服务端，服务端会从 Cookie 中获取 SessionID，再根据 SessionID 查找对应的 Session 信息，如果没有找到说明用户没有登录或者登录失效，如果找到 Session 证明用户已经登录可执行后面操作。

第四层：禁用Cookie，怎么解决？

既然服务端是根据 Cookie 中的信息判断用户是否登录，那么如果浏览器中禁止了 Cookie，如何保障整个机制的正常运转？

1、每次请求中都携带一个 SessionID 的参数，也可以Post 的方式提交，也可以在请求的地址后面拼接xxx?SessionID=123456...

2、Token 机制。Token 机制多用于 App 客户端和服务器交互的模式，也可以用于 Web 端做用户状态管理。Token 的意思是“令牌”，是服务端生成的一串字符串，作为客户端进行请求的一个标识。当用户第一次登录后，服务器根据提交的用户信息生成一个 Token，响应时将 Token 返回给客户端，以后客户端只需带上这个 Token 前来请求数据即可，无需再次登录验证。

第五层：如何考虑分布式Session问题？

1、Nginx ip_hash 策略，服务端使用 Nginx 代理，每个请求按访问 IP 的 hash 分配，这样来自同一 IP 固定访问一个后台服务器，避免了在服务器 A 创建 Session，第二次分发到服务器 B 的现象。

2、Session 复制，任何一个服务器上的 Session 发生改变（增删改），该节点会把这个 Session 的所有内容序列化，然后广播给所有其它节点。

3、共享 Session，服务端无状态话，将用户的 Session 等信息使用缓存中间件来统一管理，保障分发到每一个服务器的响应结果都一致。（推荐，如reids）

第六层：如何解决跨域请求？Jsonp跨域原理？

浏览器策略--同源策略

浏览器有一个很重要的概念——同源策略(Same-Origin Policy)。所谓同源是指，域名、协议、端口相同。不同源（项即便两个不同的域名指向同一个 ip 地址也非同源）的客户端脚(javascript、ActionScript)本在没明确授权的情况下，不能读写对方的资源。

不采用同源策略带来的危害：

1、如果Web世界没有同源策略，当登录Gmail邮箱并打开另一个站点时，这个站点上的JavaScript就可以跨域读取Gmail邮箱数据，这样整个Web世界就无隐私可言了（后台偷窥数据）

2、 cookie 劫持：浏览器中的 cookie就变得非常不安全，a 域名下的网页，就可以读取你浏览器中的所有 cookie，如果攻击者能获取到用户登陆凭证的Cookie，甚至可以绕开登陆流程，直接设置这个cookie的值，来访问用户的账号。

跨域问题解决方案：

1、通过代理来避免，比如使用 Nginx 在后端转发请求，避免了前端出现跨域的问题。

2、通过 Jsonp 跨域

3、HTML5规范的CORS功能

4、Java的HttpClient技术

Jsonp跨域原理：

浏览器的同源策略把跨域请求都禁止了，但是页面中的<script><img><iframe>标签是例外，不受同源策略限制。Jsonp 就是利用<script>标签跨域特性进行跨域数据访问（说白了就是以引入js脚本的方式欺骗浏览器，以此来向服务器请求跨域所需要的数据（这个数据必须“包装”成js脚本））。

JSONP 的理念就是，与服务端约定好一个回调函数名，服务端接收到请求后，将返回一段 Javascript，在这段  Javascript 代码中调用了约定好的回调函数，并且将数据作为参数进行传递。当网页接收到这段 Javascript 代码后，就会执行这个回调函数，这时数据已经成功传输到客户端了。

Jsonp带来的潜在风险：

JSONP为解决跨站问题带来便利的同时，也存在一定的潜在风险，下面以实例说明其风险。比如jsonpTest.htm提供jsonp格式的调用，返回如下面格式的callBack({"json":"jsonTest"})的数据。

1、脚本注入

        未对回调的函数名以及输入内容进行过两次。比如用户输入如下面请求:

                xxx.com/jsonpTest.htm?jsonp=alert('OK');

        则若服务器不过滤，响应内容为alert("OK");{"json":"jsonTest"}

        如果 jsonp 请求为：

                xxx.com/jsonpTest.htm?jsonp=<imgonclick=”xxx”/>

        则若服务器不过滤，响应内容为:<img onclick=”xxx”/>;{xx}   用户点击图片，也会有xss攻击。

2、恶意攻击

对输入的内容进行安全转义过滤，却未限定jsonp回调的合法的字符，下面参数经过安全转义后仍然不变。while(true){alert(document.cookie)} 攻击者就可以使用此参数对用户进行恶搞。