什么是Session, 什么是Cookie?
Session是由应用服务器维持的一个服务器端的存储空间，用户在连接服务器时，会由服务器生成一个唯一的SessionID,用该SessionID为标识符来存取服务器端的Session存储空间。而SessionID这一数据则是保存到客户端，用Cookie保存的，用户提交页面时，会将这一SessionID提交到服务器端，来存取Session数据。这一过程，是不用开发人员干预的。所以一旦客户端禁用Cookie，那么Session也会失效。Cookie是客户端的存储空间，由浏览器来维持。
Url重写
服务器也可以通过URL重写的方式来传递SessionID的值，因此不是完全依赖Cookie。如果客户端Cookie禁用，则服务器可以自动通过重写URL的方式来保存Session的值，并且这个过程对程序员透明。可以试一下，即使不写Cookie，在使用request.getCookies();取出的Cookie数组的长度也是1，而这个Cookie的名字就是JSESSIONID，还有一个很长的二进制的字符串，是SessionID的值。实质上 URL 重写是通过向 URL 连接添加参数，并把 session ID 作为值包含在连接中。然而，为使这生效，你需要为你的 servlet 响应部分的每个连接添加 session ID.
同源下http cookie的协议
在同源时,不管是ajax请求还是普通的get post请求，浏览器访问时都是会带着本域下所有的cookie一起访问服务端。服务端在响应时又会通过http header中的set cookie返回给浏览器。浏览器把cookie再写入该域名下的cookie存储空间。如此来循环
跨域下http cookie的协议
当跨域时，浏览器端请求服务端都不会带着cookie的信息。在使用ajax请求时，如果不进行特殊的处理还会有同源错误产生，更不用说带着cookie了。 服务端返回的cookie，浏览器也不会写入其对应的域名下的存储空间。那么怎么解决这个问题，xmlhttprequest 2 给出了解决方案。
方案：
需要在 ajax请求参数中带上 withCredentials ，值为true。如果是 jquery方式，则是这样设置：
$.ajax({
url: a_cross_domain_url,
// 将XHR对象的withCredentials设为true
xhrFields:{
withCredentials:true
}});
针对这样一般的浏览器（IE11以下版本不支持，还有个别垃圾浏览器不支持，这点请注意）就会允许跨域资源共享。
同时服务器端还需要设置 Access-Control-Allow-Credentials 为true。
如下面是 java 的设置方式：
response().setHeader("Access-Control-Allow-Credentials", "true");
response().setHeader("Access-Control-Allow-Origin", "fromeDomain.com");
注意，这里fromeDomain.com 不能设置为 * 来允许全部，如果在 Credentials 是true 的情况下。因为浏览器会报错如下：
A wildcard '*' cannot be used in the 'Access-Control-Allow-Origin' header when the credentials flag is true. Origin 'http://xxxxxxxxxx' is therefore not allowed access
所以只能乖乖的设置成客户端页面的 域名。
有一点需要注意，设置了widthCredentials为true的请求中会包含远程域的所有cookie，但这些cookie仍然遵循同源策略，所以你是访问不了这些cookie的。
是当提交一个请求到异域时，后台尝试在响应中绑定cookie信息，以告知浏览器去保存这个cookie,但是默认情况下，浏览器是不会去为你创建cookie的，具体现象就是你发现在响应中已经有set-cookie的响应头了并且有值，而且浏览器也会有信息显示已接收到cookie了，但是就是在cookie中找不到。没错，该现象就是因为你是跨域提交的创建cookie的请求。那么如果我们非要浏览器去创建这个cookie怎么办呢？这里就要使用到一个xmlHttpRequest对象的属性xhrFields,官方文档的解释如下： A map of fieldName-fieldValue pairs to set on the native XHR object. For example, you can use it to setwithCredentials to true for cross-domain requests if needed.
设置了withCredentials:true 之后可以解决一个发送，一个设置的问题
、允许创建来自不同域的cookie信息；、每次的跨域请求都允许带上该cookie信息
另外：ajax在异域请求的时候有时会发送option请求
1.第一步 服务端设置响应头
header('Access-Control-Allow-Origin:*'); //支持全域名访问，不安全，部署后需要固定限制为客户端网址
header('Access-Control-Allow-Methods:POST,GET,OPTIONS,DELETE'); //支持的http 动作
header('Access-Control-Allow-Headers:x-requested-with,content-type'); //响应头 请按照自己需求添加。
2.第二部 了解IE chrome 等浏览器 对于 跨域请求并要求设置Headers自定义参数的时候的 "预请求" 就是如果遇到 跨域并设置headers的请求，所有请求需要两步完成！
A 第一步：发送预请求 OPTIONS 请求。此时 服务器端需要对于OPTIONS请求作出响应 一般使用202响应即可 不用返回任何内容信息。（能看到这份手稿的人，本人不相信你后台处理不了一个options请求）
B 第二步：服务器accepted 第一步请求后 浏览器自动执行第二步 发送真正的请求。此时 大多数人 会发现请求成功了，但是 有那么几个人会发现 请求成功了但是没有任何信息返回 why？因为你自定义的请求头在服务器响应中不存在！
查看console输出 会发现一个问题：
“Access-Control-Allow-Headers 列表中不存在请求标头 XXXXXX”【IE】，
request header field xxxxxx is not allowed by Access-Control-Allow-Header【chrome】
这是因为 你的XXXX请求头 没有在服务器端被允许哦~
遇到这个问题 只有通过修改服务器端来完成，举例：需要设置 requesttype这么一个自定义头，那么 你需要在 服务端里面 将header('Access-Control-Allow-Headers:x-requested-with,content-type，requesttype'); 同学们自行体会吧 这种语法就是根据“,”分割 自己需要设置什么头，必须要在 服务端请求的响应头里面设置好，不然客户端永远永远提交不上去！