跨域解决方案
1.通过jsonp跨域
2.document.domain.iframe跨域
3.location.hash + iframe
4.window.name + iframe跨域
5.postMessage跨域
6.跨域资源共享（CORS）
7.nginx代理跨域
8.nodejs中间件代理跨域
9.WebSocket协议跨域
一、JSONP
JSONP的原理很简单，就是利用<script>标签没有跨域限制的漏洞。通过<script>标签指向一个需要访问的地址并提供一个回调函数来接收数据当需要通讯时。JSONP使用简单且兼容性不错，但是只限于get请求。
function jsonp(url, jsonpCallback, success) { let script = document.createElement('script') script.src = url script.async = true script.type = 'text/javascript' window[jsonpCallback] = function(data) { success && success(data) } document.body.appendChild(script) } jsonp('http://xxx', 'callback', function(value) { console.log(value) })
二、CORS
CORS需要浏览器和后端同时支持。浏览器会自动进行CORS通信，实现CORS通信的关键是后端。只要后端实现了CORS，就实现了跨域。服务器设置Access-Control-Allow-Origin就可以开启CORS。该属性表示哪些域名可以访问资源，如果设置通配符则表示所有网站都可以访问资源。
三、nginx代理跨域
利用Nginx反向代理实现跨域。
虚拟主机的配置
server { listen 8080; # 监听的端口 server_name 192.168.1.1; # 配置访问域名 root /data/toor; # 站点根目录 error_page 502 404 /page/404.html; # 错误页面 location ^~ /api/ { # 使用 /api/ 代理 proxy_pass 的值 proxy_pass http: //192.168.20.1:8080; # 被代理的应用服务器 HTTP 地址 } }
在 Vue 中就可以使用 proxyTable 这个属性进行相关的配置来解决跨域问题带来的烦恼。配置如下：
proxyTable: { '/weixin': { target: 'http://192.168.48.11:8100/', // 接口的域名 secure: false, // 如果是 https 接口，需要配置这个参数 changeOrigin: true, // 如果接口跨域，需要进行这个参数配置 pathRewrite: { '^/weixin': '' } }, },
正向代理和反向代理 TOP
正向代理
1.代理客户;
2.隐藏真实的客户，为客户端收发请求，使真实客户端对服务器不可见;
3.一个局域网内的所有用户可能被一台服务器做了正向代理，由该台服务器负责 HTTP 请求;
4.意味着同服务器做通信的是正向代理服务器;
反向代理
1.代理服务器;
2.隐藏了真实的服务器，为服务器收发请求，使真实服务器对客户端不可见;
3.负载均衡服务器，将用户的请求分发到空闲的服务器上;
4.意味着用户和负载均衡服务器直接通信，即用户解析服务器域名时得到的是负载均衡服务器的 IP ;
共同点
1.都是做为服务器和客户端的中间层
2.都可以加强内网的安全性，阻止 web 攻击
3.都可以做缓存机制
CDN 带来的性能优化
我们在淘宝购物，大部分个人卖家只是在一个地方发货，江浙沪以外的地方好像收货都比较慢。
在京东购物
而我们在京东上买自营产品的话，它会根据我们的收货地点，在全国范围内找离我们最近、送达最快的仓库，不管我们在江浙沪，还是新疆西藏内蒙古，我们的收货时间都会大大减少。京东建立的仓储 系统，就类似于 CDN。
CDN的优势
CDN 节点解决了跨运营商和跨地域访问的问题，访问延时大大降低；
大部分请求在 CDN 边缘节点完成，CDN 起到了分流作用，减轻了源站的负载。
访问速度快是电商网站取胜的必要法宝之一。
比如我们 SHEIN 主站的根服务器中国深圳，CDN 服务器在美国加州，欧洲法国，印度等三个地方（真实的细致很多）。
没有 CDN 服务器
那么全球 6000 万用户请求的资源都是从中国深圳的机房发出的，这样一位美国加州的用户在打开首页的延时可能足够她画一个精致的妆容了。（PS: 深圳前端团队在招前端开发，有需求的可以私信我）
有 CDN 服务器
此时还是这位加州的用户想打开 SHEIN 打算购买一件晚礼服参加晚会。这次她视线还没有移到梳妆台，首页就已经打开了，然后她就开心的购物了。
这就是因为 CDN 服务器。
美国加州的 CDN 服务器，已经将根节点的资源复制过来了。并且我们有个机制，CDN 节点的资源十分钟会回源更新一次。所以在用户请求资源的时候是不会回源到深圳的根服务器请求的。这样不会出现用户在请求资源的时候，因为回源而导致的网络延时。
CDN 的核心点有两个: 一个是缓存，一个是回源。
内容发布：它借助于建立索引、缓存、流分裂、组播（Multicast）等技术，将内容发布或投递到距离用户最近的远程服务点（POP）处；
内容路由：它是整体性的网络负载均衡技术，通过内容路由器中的重定向（DNS）机制，在多个远程 POP 上均衡用户的请求，以使用户请求得到最近内容源的响应；
内容交换：它根据内容的可用性、服务器的可用性以及用户的背景，在POP的缓存服务器上，利用应用层交换、流分裂、重定向（ICP、WCCP）等技术，智能地平衡负载流量；
性能管理：它通过内部和外部监控系统，获取网络部件的状况信息，测量内容发布的端到端性能（如包丢失、延时、平均带宽、启动时间、帧速率等），保证网络处于最佳的运行状态。
前端往往认为 CDN 是不需要了解的知识。可是我们前端工程首先是软件工程师。多了解一些东西肯定是有益的。
CDN & 静态资源
静态资源本身具有访问频率高、承接流量大的特点，因此静态资源加载速度始终是前端性能的一个非常关键的指标。CDN 是静态资源提速的重要手段。
CDN & Cookie
Cookie 是紧跟域名的。同一个域名下的所有请求，都会携带相同的 Cookie。
但是如果我们只是请求一张图片，我们在请求中还要携带一个笨重的 Cookie 来回的跑，Cookie 中的信息和图片又是没有关联的，这种情况就很让人头痛了。Cookie 虽然小，但是随着请求的越来越多，这种的不必要的 Cookie 带来的开销将是无法想象的……
静态资源往往并不需要 Cookie 携带什么认证信息。把静态资源和主页面置于不同的域名下，就可以完美地避免请求中携带不必要的 Cookie。
看起来是一个不起眼的小细节，但带来的效用却是惊人的。电商网站静态资源的流量之庞大，如果没把这个多余的 Cookie 拿下来，不仅用户体验会大打折扣，每年因性能浪费导致的开销也会非常之高。
HTTP 强缓存&协商缓存 TOP
缓存是一种保存资源副本并在下次请求时直接使用该副本的技术。 当 web 缓存发现请求的资源已经被存储，它会拦截请求，返回该资源的拷贝，而不会去源服务器重新下载。
这样带来的好处是缓解服务器端压力，提升性能(获取资源的耗时更短了)。对于网站来说，缓存是达到高性能的重要组成部分。
缓存大致可归为两类：私有缓存与共享缓存。
共享缓存能够被多个用户使用；
私有缓存只能用于单独用户；
HTTP 协议主要是通过请求头当中的一些字段来和服务器进行通信，从而采用不同的缓存策略。
HTTP 通过缓存将服务器资源的副本保留一段时间，这段时间称为新鲜度限值。这在一段时间内请求相同资源不会再通过服务器。
HTTP 协议中 Cache-Control 和 Expires 可以用来设置新鲜度的限值。
强缓存 ( Cache-Control 和 Expires )
强缓存主要是采用响应头中的 Cache-Control 和 Expires 两个字段进行控制的。
其中 Expires 是 HTTP1.0 中定义的，它指定了一个绝对的过期时期。而 Cache-Control 是 HTTP1.1 时出现的缓存控制字段。
Cache-Control:max-age 定义了一个最大使用期。 就是从第一次生成文档到缓存不再生效的合法生存日期。由于Expires是HTTP1.0时代的产物，因此设计之初就存在着一些缺陷，如果本地时间和服务器时间相差太大，就会导致缓存错乱。
这两个字段的效果是类似的，客户端都会通过对比本地时间和服务器返回的生存时间来检测缓存是否可用。如果缓存没有超出它的生存时间，客户端就会直接采用本地的缓存。如果生存日期已经过了，这个缓存也就宣告失效。接着客户端将再次与服务器进行通信来验证这个缓存是否需要更新。
Cache-Control 通用消息头字段被用于在 http 请求和响应中通过指定指令来实现缓存机制。
