跨域
所有的浏览器都有沙箱机制。
网络安全与沙箱
将个别套接字的管理任务委托给浏览器还有另一个重要的用意：可以让浏览器运用沙箱机制，对不受信任的应用代码采取一致的安全和侧罗的限制。比如，浏览器不允许直接访问原始网络的套接字API，因为这样给恶意应用向任何主机发起的任意请求（端口扫描，连接邮件服务器或发送未知消息）提供可乘之机。
- 连接限制
浏览器管理所有打开的套接字池并强制施加连接数限制，保护客户端和服务器的资源不会被耗尽。 - 请求格式化和响应处理
浏览器格式化所有外发请求以保证格式一致和符合协议的语义，从而保护服务器，类似的，响应解码也会自动完成，以保护用户。 - TLS协商
浏览器执行TSL握手和必要的证书检查。任何证书有问题（比如服务器正在使用自己签发的证书），用户都会收到通知。 - 同源策略
浏览器会限制应用只能向哪个来源发送请求。
上面的安全限制规则只是一部分，但已经体现了“最低特权”原则了，浏览器只想应用代码公开那些必要的API和资源：应用提供数据和URL，浏览器执行请求并负责管理每个连接的整个生命周期。
上面的同源策略中的源是由“应用协议、域名和端口”这三个要件共同定义。其中有一个不同就是跨域请求。
在刚接触跨域的时候，为了能访问到数据，我尝试修改xhr的首部，但是浏览器会拒绝绝对不安全的首部的重写，以保证应用不能假扮用户代理、用户或请求。
有时候，同源策略并不能满足我们的请求，这个时候就出现了“跨源资源共享”
如何实现跨域
CORS请求
针对CORS请求的选择同意认证机制由底层处理：请求发出后，浏览器自动追加受保护的Origin HTTP首部，包含着发出请求的来源。相应的，远程服务器也可以检查Origin首部，决定是否接受该请求，如果接受就返回Access-Control-Allow-Origin响应首部。
但是CORS还会提前采取一系列的安全措施：
- CORS请求会忽略cookie和HTTP认证等用户凭证
- 客户端被限制只能发送“简单的跨域请求”，包括智能使用特定的方法（GET、POST和HEAD），以及只能访问可以通过XHR发送并读取的HTTP首部。
要采用cookie和HTTP认证，客户端必须在发送请求的时候通过XHR对象发送额外的属性（withCredentials），而服务器也必须以适当的首部（Access-Control-Allow-Credential）响应，表示它允许应用发送用户隐私数据。类似的客户端需要写或者读自定义的HTTP首部，或者想要使用“不简单的方法“发送请求，那么它首先需要获取第三方服务器的许可，即向第三方服务器发送一个预备（optins）请求。options请求只会发生一次。
JSONP
只能实现GET请求，因为浏览器允许资源请求可以不受同源的限制
<script type="text/javascript">
function dosomething(data){
//处理获得的数据
}
</script>
<img src="xxxx?callback=dosomething" />
postMessage
待补充…
nginx 反向代理
待补充…