前端新技术（离线缓存、CDN内容分发网络）

一、离线缓存

前端离线技术实现_灬点点的博客-CSDN博客_前端离线存储

定义：离线缓存可以将站点的一些文件缓存到本地，它是浏览器自身的一种机制，将需要的文件缓存下来，以便后期即使没有连接网络，被缓存的页面也可以展示

如何实现：Application Cache 与 Cache Storage、service-worker、PouchDB、Redux-Offline、Redux 与 IndexDB 结合

Application Cache ：

（1）首先，在需要缓存的html文件的根节点（html）添加manifest属性，属性值是当前目录下的一个appcache的文件：文件为：

（2）然后是创建一个(···).appcache的文件,简写如下：

CACHE MANIFEST
manifestFile.html
img/1.jpg
img/2.jpg
img/3.jpg

完整写法包括以下四条： 

•  CACHE:这是缓存文件中记录所属的默认段落。在 CACHE: 段落标题后(或直接跟在 CACHE MANIFEST 行后)列出的文件会在它们第一次下载完毕后缓存起来。
•   NETWORK:在 NETWORK: 需要与服务器连接的白名单资源。所有类似资源的请求都会绕过缓存，即使用户处于离线状态。可以使用通配符“*”代表除以上指定之外全部需要从服务器拉取。
•   FALLBACK:FALLBACK: 段指定了一个后备页面，当资源无法访问时，浏览器会使用该页面。该段落的每条记录都列出两个 URI—第一个表示资源，第二个表示后备页面。两个 URI 都必须使用相对路径并且与清单文件同源。可以使用通配符，类似404.html。
•    CACHE， NETWORK， 和 FALLBACK 段落可以以任意顺序出现在缓存清单文件中，并且每个段落可以在同一清单文件中出现多次。

（3）其次，在服务器端将.appcache文件的mime类型配置成text/cache-manifest

（4）在Application Cache里可以看到缓存的文件。用Cache Storage也可以缓存。

service-worker：

运行在浏览器后台进程里的脚本，它独立于当前页面。使用它可以断网情况下轻松实现拦截用户请求，用已经缓存的页面代替服务器响应，简称离线缓存。

Service worker拥有一个完全独立于Web页面的生命周期。

总结起来Service Worker的生命周期有如下几个关键步骤（就是常常需要监听并制定回调函数的事件）：
1. 安装
2. 激活，激活成功之后，打开chrome://inspect/#service-workers可以查看到当前运行的service worker
3. 监听fetch和message事件，下面两种事件会进行简要描述
4. 销毁，是否销毁由浏览器决定，如果一个service worker长期不使用或者机器内存有限，则可能会销毁这个worker

生命周期中常需监听的几个事件：

• fetch事件：在页面发起http请求时，service worker可以通过fetch事件拦截请求，并且给出自己的响应。w3c提供了一个新的fetch api，用于取代XMLHttpRequest，与XMLHttpRequest最大不同有两点：fetch()方法返回的是Promise对象，通过then方法进行连续调用，减少嵌套。ES6的Promise在成为标准之后，会越来越方便开发人员。提供了Request、Response对象，如果做过后端开发，对Request、Response应该比较熟悉。前端要发起请求可以通过url发起，也可以使用Request对象发起，而且Request可以复用。但是Response用在哪里呢？在service worker出现之前，前端确实不会自己给自己发消息，但是有了service worker，就可以在拦截请求之后根据需要发回自己的响应，对页面而言，这个普通的请求结果并没有区别，这是Response的一处应用。
• message事件：页面和serviceWorker之间可以通过posetMessage()方法发送消息，发送的消息可以通过message事件接收到。这是一个双向的过程，页面可以发消息给service worker，service worker也可以发送消息给页面，由于这个特性，可以将service worker作为中间纽带，使得一个域名或者子域名下的多个页面可以自由通信。
• install事件：当页面加载时触发该事件。常用于缓存离线页面，当断开网络时，在该事件中缓存的页面将被返回给用户。
• acrive事件：当Service Worker被触发时触发该事件。代码更新后，通常需要在activate的callback中执行一个管理cache的操作。因为你会需要清除掉之前旧的数据。我们在activate而不是install的时候执行这个操作是因为如果我们在install的时候立马执行它，那么依然在运行的旧版本的数据就坏了。

serviceworker.js：

'use strict';

var cacheVersion = 0;
var currentCache = {
  offline: 'offline-cache' + cacheVersion
};
const offlineUrl = 'offline.html';

this.addEventListener('install', event => {
  event.waitUntil(
    caches.open(currentCache.offline).then(function(cache) {
      return cache.addAll([
          './offline.svg',
          offlineUrl
      ]);
    })
  );
});

this.addEventListener('fetch', event => {

  if (event.request.mode === 'navigate' || (event.request.method === 'GET' && event.request.headers.get('accept').includes('text/html'))) {
        event.respondWith(
          fetch(event.request.url).catch(error => {
              // Return the offline page
              return caches.match(offlineUrl);
        })
     );
  }
  else{
        event.respondWith(caches.match(event.request)
                        .then(function (response) {
                        return response || fetch(event.request);
                    })
            );
      }
});

二、CND

CDN工作原理 - SegmentFault 思否

传统网络访问形式：

CDN网络是在用户和服务器之间增加Cache层，通过接管DNS将用户的请求引导到Cache上获得源服务器的数据。

对于CDN客户来说，不需要改动网站架构，只需要修改自己的DNS解析，设置一个CNAME指向CDN服务商即可。

使用了CDN缓存后的网站的访问过程变为：

1. 用户向浏览器提供要访问的域名；
2. 浏览器调用域名解析库对域名进行解析，由于CDN对域名解析过程进行了调整，所以解析函数库得到的是该域名对应的CNAME记录（由于现在已经是使用了CDN服务，CNAME为CDN服务商域名），为了得到实际IP地址，浏览器需要再次对获得的CNAME域名进行解析以得到实际的IP地址；在此过程中，使用的全局负载均衡DNS解析，如根据地理位置信息解析对应的IP地址，使得用户能就近访问。（CDN服务来提供最近的机器）
3. 此次解析得到CDN缓存服务器的IP地址，浏览器在得到实际的IP地址以后，向缓存服务器发出访问请求；
4. 缓存服务器根据浏览器提供的要访问的域名，通过Cache内部专用DNS解析得到此域名的实际IP地址，再由缓存服务器向此实际IP地址提交访问请求；
5. 缓存服务器从实际IP地址得得到内容以后，一方面在本地进行保存，以备以后使用，二方面把获取的数据返回给客户端，完成数据服务过程；
6. 客户端得到由缓存服务器返回的数据以后显示出来并完成整个浏览的数据请求过程。

 CNAME(Canonical Name)指别名记录也被称为规范名字,CNAME可以理解为对域名设置别名。比如一个域名www.domain.com,设置一个CNAME指向它，由于www.domain.com与一个ip进行绑定，如果设置多个CNAME指向它，以后修改CNAME指向的服务器时，只需要修改一个www.domain.com对应的ip即可。