Event Loop

Event Loop即事件循环，是指浏览器或者Nodejs解决javascript单线程运行时异步逻辑不会阻塞的一种机制。

Event Loop是一个执行模型，不同的运行环境有不同的实现，浏览器和nodejs基于不同的技术实现自己的event loop。

• 浏览器的Event Loop是在HTML5规范中明确定义。
• Nodejs的Event Loop是libuv实现的。
• libuv已经对Event Loop作出了实现，HTML5规范中只是定义的浏览器中Event Loop的模型，具体的实现交给了浏览器厂商。

宏队列和微队列

在javascript中，任务被分为两种，一种为宏任务(macrotask)，也称为task，一种为微任务(microtask)，也称为jobs。

宏任务主要包括:

• script全部代码
• setTimeout
• setInterval
• setImmediate (Nodejs独有，浏览器暂时不支持，只有IE10支持)
• requestAnimationFrame (浏览器独有)
• I/O
• UI rendering (浏览器独有)

微任务主要包括:

• process.nextTick (Nodejs独有)
• Promise
• Object.observe (废弃)
• MutationObserver

浏览器中的Event Loop

Javascript 有一个主线程 main thread 和 一个调用栈(执行栈) call-stack，所有任务都会被放到调用栈等待主线程的执行。

JS调用栈采用的是后进先出的规则，当函数执行时，会被添加到调用栈的顶部，当执行栈执行完后，就会从栈顶移除，直到栈内被清空。

Javascript单线程任务可以分为同步任务和异步任务，同步任务会在调用栈内按照顺序依次被主线程执行，异步任务会在异步任务有了结果后，将注册的回调函数放入任务队列中等待主线程空闲的时候（调用栈被清空的时候），被读取到调用栈内等待主线程的执行

任务队列 Task Queue, 是先进先出的数据结构。

浏览器Event Loop的具体流程:

1. 执行全局Javascript的同步代码，可能包含一些同步语句，也可以是异步语句(setTimeout语句不执行回调函数里面的，Promise中.then之前的语句)
2. 全局Javascript执行完毕后，调用栈call-stack会被清空
3. 从微队列microtask queue中取出位于首部的回调函数，放入到调用栈call-stack中执行，执行完毕后从调用栈中删除，microtask queue的长度减1。
4. 继续从微队列microtask queue的队首取出任务，放到调用栈中执行，依次循环往复，直至微任务队列microtask queue中的任务都被调用栈执行完毕。特别注意，如果在执行微任务microtask过程中，又产生了微任务microtask，新产生的微任务也会追加到微任务队列microtask queue的尾部，新生成的微任务也会在当前周期中被执行完毕。
5. microtask queue中的任务都被执行完毕后，microtask queue为空队列，调用栈也处于空闲阶段
6. 执行UI rendering
7. 从宏队列macrotask queue的队首取出宏任务，放入调用栈中执行。
8. 执行完后，调用栈为空闲状态
9. 重复 3 - 8 的步骤，直至宏任务队列的任务都被执行完毕。
   …

浏览器Event Loop的3个重点:

1. 宏队列macrotask queue每次只从中取出一个任务放到调用栈中执行，执行完后去执行微任务队列中的所有任务
2. 微任务队列中的所有任务都会依次取出来执行，只是微任务队列中的任务清空
3. UI rendering 的执行节点在微任务队列执行完毕后，宏任务队列中取出任务执行之前执行

NodeJs中的Event Loop

libuv结构

NodeJs中的宏任务队列和微任务队列

NodeJs的Event Loop中，执行宏任务队列的回调有6个阶段

Node的Event Loop可以分为6个阶段，各个阶段执行的任务如下所示:

• timers: 执行setTimeout和setInterval中到期的callback。
• I/O callbacks: 执行几乎所有的回调，除了close callbacks以及timers调度的回调和setImmediate()调度的回调。
• idle, prepare: 仅在内部使用。
• poll: 最重要的阶段，检索新的I/O事件，在适当的情况下回阻塞在该阶段。
• check: 执行setImmediate的callback(setImmediate()会将事件回调插入到事件队列的尾部，主线程和事件队列的任务执行完毕后会立即执行setImmediate中传入的回调函数)。
• close callbacks: 执行close事件的callback，例如socket.on(‘close’, fn)或则http.server.on(‘close’, fn)等。

NodeJs中的宏任务队列可以分为下列4个:

1. Timers Queue
2. I/O Callbacks Queue
3. Check Queue
4. Close Callbacks Queue

在浏览器中只有一个宏任务队列，所有宏任务都会放入到宏任务队列中等待放入执行栈中被主线程执行，NodeJs中有4个宏任务队列，不同类型的宏任务会被放入到不同的宏任务队列中。

NodeJs中的微任务队列可以分为下列2个:

1. Next Tick Queue: 放置process.nextTick(callback)的回调函数
2. Other Micro Queue: 其他microtask，例如Promise等

在浏览器中只有一个微任务队列，所有微任务都会放入到微任务队列中等待放入执行栈中被主线程执行，NodeJs中有2个微任务队列，不同类型的微任务会被放入到不同的微任务队列中。

NodeJs的Event Loop的具体流程:

1. 执行全局Javascript的同步代码，可能包含一些同步语句，也可以是异步语句(setTimeout语句不执行回调函数里面的，Promise中.then之前的语句)。
2. 执行微任务队列中的微任务，先执行Next Tick Queue队列中的所有的所有任务，再执行Other Micro Queue队列中的所有任务。
3. 开始执行宏任务队列中的任务，共6个阶段，从第1个阶段开始执行每个阶段对应宏任务队列中的所有任务，注意，这里执行的是该阶段宏任务队列中的所有的任务，浏览器Event Loop每次只会中宏任务队列中取出队首的任务执行，执行完后开始执行微任务队列中的任务，NodeJs的Event Loop会执行完该阶段中宏任务队列中的所有任务后，才开始执行微任务队列中的任务，也就是步骤2。
4. Timers Queue -> 步骤2 -> I/O Callbacks Queue -> 步骤2 -> Check Queue -> 步骤2 -> Close Callback Queue -> 步骤2 -> Timers Queue -> ……

特别注意:

• 上述的第三步，当 NodeJs 版本小于11时，NodeJs的Event Loop会执行完该阶段中宏任务队列中的所有任务
• 当 NodeJS 版本大于等于11时，在timer阶段的setTimeout,setInterval…和在check阶段的setImmediate都在node11里面都修改为一旦执行一个阶段里的一个任务就立刻执行微任务队列。为了和浏览器更加趋同。

NodeJs的Event Loop的microtask queue和macrotask queue的执行顺序详情

当setTimeout(fn, 0)和setImmediate(fn)放在同一同步代码中执行时，可能会出现下面两种情况：

1. 第一种情况: 同步代码执行完后，timer还没到期，setImmediate中注册的回调函数先放入到Check Queue的宏任务队列中，先执行微任务队列，然后开始执行宏任务队列，先从Timers Queue开始，由于在Timer Queue中未发现任何的回调函数，往下阶段走，直到Check Queue中发现setImmediate中注册的回调函数，先执行，然后timer到期，setTimeout注册的回调函数会放入到Timers Queue的宏任务队列中，下一轮后再次执行到Timers Queue阶段时，才会再Timers Queue中发现了setTimeout注册的回调函数，于是执行该timer的回调，所以，setImmediate(fn)注册的回调函数会早于setTimeout(fn, 0)注册的回调函数执行。

2. 第二种情况: 同步代码执行完之前，timer已经到期，setTimeout注册的回调函数会放入到Timers Queue的宏任务队列中，执行同步代码到setImmediate时，将其回调函数注册到Check Queue中，同步代码执行完后，先执行微任务队列，然后开始执行宏任务队列，先从Timers Queue开始，在Timers Queue发现了timer中注册的回调函数，取出执行，往下阶段走，到Check Queue中发现setImmediate中注册的回调函数，又执行，所以这种情况时，setTimeout(fn, 0)注册的回调函数会早于setImmediate(fn)注册的回调函数执行。

3. 在同步代码中同时调setTimeout(fn, 0)和setImmediate执行顺序情况是不确定的，但是如果把他们放在一个IO的回调，比如readFile(‘xx’, function () {// ….})回调中，那么IO回调是在I/O Callbacks Queue中，setTimeout到期回调注册到Timers Queue，setImmediate回调注册到Check Queue，I/O Callbacks Queue执行完到Check Queue，Timers Queue得到下个循环周期，所以setImmediate回调这种情况下肯定比setTimeout(fn, 0)回调先执行。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19

setImmediate(function A() {
  console.log(1);
  setImmediate(function B(){console.log(2);});
});

setTimeout(function timeout() {
  console.log('TIMEOUT FIRED');
}, 0);

// 执行结果: 会存在下面两种情况
// 第一种情况:
// 1
// TIMEOUT FIRED
// 2

// 第二种情况:
// TIMEOUT FIRED
// 1
// 2

注:

• setImmediate中如果又存在setImmediate语句，内部的setImmediate语句注册的回调函数会在下一个check阶段来执行，并不在当前的check阶段来执行。

poll 阶段详解:

poll 阶段主要又两个功能:

1. 当timers到达指定的时间后，执行指定的timer的回调(Executing scripts for timers whose threshold has elapsed, then)。
2. 处理poll队列的事件(Processing events in the poll queue)。

当进入到poll阶段，并且没有timers被调用的时候，会出现下面的情况:

• 如果poll队列不为空，Event Loop将同步执行poll queue中的任务，直到poll queue队列为空或者执行的callback达到上限。
• 如果poll队列为空，会发生下面的情况:
  • 如果脚本执行过setImmediate代码，Event Loop会结束poll阶段，直接进入check阶段，执行Check Queue中调用setImmediate注册的回调函数。
  • 如果脚本没有执行过setImmediate代码，poll阶段将等待callback被添加到队列中，然后立即执行。

当进入到poll阶段，并且调用了timers的话，会发生下面的情况:

• 一旦poll queue为空，Event Loop会检测Timers Queue中是否存在任务，如果存在任务的话，Event Loop会回到timer阶段并执行Timers Queue中timers注册的回调函数。执行完后是进入check阶段，还是又重新进入I/O callbacks阶段?

setTimeout 对比 setImmediate

• setTimeout(fn, 0)在timers阶段执行，并且是在poll阶段进行判断是否达到指定的timer时间才会执行
• setImmediate(fn)在check阶段执行

两者的执行顺序要根据当前的执行环境才能确定：

• 如果两者都在主模块(main module)调用，那么执行先后取决于进程性能，顺序随机
• 如果两者都不在主模块调用，即在一个I/O Circle中调用，那么setImmediate的回调永远先执行，因为会先到Check阶段

setImmediate 对比 process.nextTick

• setImmediate(fn)的回调任务会插入到宏队列Check Queue中
• process.nextTick(fn)的回调任务会插入到微队列Next Tick Queue中
• process.nextTick(fn)调用深度有限制，上限是1000，而setImmediate则没有

Fetch API使用的常见问题及其解决办法

XMLHttpRequest在发送web请求时需要开发者配置相关请求信息和成功后的回调，尽管开发者只关心请求成功后的业务处理，但是也要配置其他繁琐内容，导致配置和调用比较混乱，也不符合关注分离的原则；fetch的出现正是为了解决XHR存在的这些问题。

fetch是基于Promise设计的，让开发者只关注请求成功后的业务逻辑处理，其他的不用关心，相当简单，FetchAPI的优点如下:

• 语法简单，更加语义化
• 基于标准的Promise实现，支持async/await
• 使用isomorphic-fetch可以方便同构

使用fetch来进行项目开发时，也是有一些常见问题的，下面就来说说fetch使用的常见问题。

Fetch 兼容性问题

fetch是相对较新的技术，当然就会存在浏览器兼容性的问题，借用上面应用文章的一幅图加以说明fetch在各种浏览器的原生支持情况：

从上图可以看出各个浏览器的低版本都不支持fetch技术。

如何在所有浏览器中通用fetch呢，当然就要考虑fetch的polyfill了。

fetch是基于Promise来实现的，所以在低版本浏览器中Promise可能也未被原生支持，所以还需要Promise的polyfill；大多数情况下，实现fetch的polyfill需要涉及到的：

• promise的polyfill，例如es6-promise、babel-polyfill提供的promise实现。
• fetch的polyfill实现，例如isomorphic-fetch和whatwg-fetch

IE浏览器中IE8/9还比较特殊：IE8它使用的是ES3，而IE9则对ES5部分支持。这种情况下还需要ES5的polyfill es5-shim支持了。

上述有关promise的polyfill实现，需要说明的是：

babel-runtime是不能作为Promise的polyfill的实现的，否则在IE8/9下使用fetch会报Promise未定义。为什么？我想大家猜到了，因为babel-runtime实现的polyfill是局部实现而不是全局实现，fetch底层实现用到Promise就是从全局中去取的，拿不到这报上述错误。

fetch的polyfill实现思路:

首先判断浏览器是否原生支持fetch，否则结合Promise使用XMLHttpRequest的方式来实现；这正是whatwg-fetch的实现思路，而同构应用中使用的isomorphic-fetch，其客户端fetch的实现是直接require(“whatwg-fetch”)来实现的。

fetch默认不携带cookie

fetch发送请求默认是不发送cookie的，不管是同域还是跨域；

对于那些需要权限验证的请求就可能无法正常获取数据，可以配置其credentials项，其有3个值：

• omit: 默认值，忽略cookie的发送
• same-origin: 表示cookie只能同域发送，不能跨域发送
• include: cookie既可以同域发送，也可以跨域发送

credentials所表达的含义，其实与XHR2中的withCredentials属性类似，表示请求是否携带cookie；

若要fetch请求携带cookie信息，只需设置一下credentials选项即可，例如fetch(url, {credentials: ‘include’});

fetch默认对服务端通过Set-Cookie头设置的cookie也会忽略，若想选择接受来自服务端的cookie信息，也必须要配置credentials选项；

fetch请求对某些错误http状态不会reject

主要是由fetch返回promise导致的，因为fetch返回的promise在某些错误的http状态下如400、500等不会reject，相反它会被resolve；只有网络错误会导致请求不能完成时，fetch 才会被 reject；所以一般会对fetch请求做一层封装。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20

function checkStatus(response) {
  if (response.status >= 200 && response.status < 300) {
    return response;
  }
  const error = new Error(response.statusText);
  error.response = response;
  throw error;
}

function parseJSON(response) {
  return response.json();
}

export default function request(url, options = {}) {
  return fetch(url, { credentials: 'include', ...options })
    .then(checkStatus)
    .then(parseJSON)
    .then((data) => data)
    .catch((err) => err);
}

fetch不支持超时timeout处理

fetch不像大多数ajax库那样对请求设置超时timeout，它没有有关请求超时的功能，所以在fetch标准添加超时功能之前，都需要polyfill该特性。

实际上，我们真正需要的是abort()， timeout可以通过timeout+abort方式来实现，起到真正超时丢弃当前的请求。

目前的fetch指导规范中，fetch并不是一个具体实例，而只是一个方法；其返回的promise实例根据Promise指导规范标准是不能abort的，也不能手动改变promise实例的状态，只能由内部来根据请求结果来改变promise的状态。

实现fetch的timeout功能，其思想就是新创建一个可以手动控制promise状态的实例，根据不同情况来对新promise实例进行resolve或者reject，从而达到实现timeout的功能；

根据github上timeout handling上的讨论，目前可以有两种不同的解决方法：

方法一: 单纯setTimeout方法

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19

var fetchOrigin = fetch;
window.fetch = function(url, options) {
  return new Promise(function(resolve, reject) {
    var timerId;
    if (options.timeout) {
      timerId = setTimeout(function() {
        reject(new Error('fetch timeout'));
      }, options.timeout);
    }

    fetchOrigin(url, option).then(function(response) {
      timerId && clearTimeout(timerId);
      resolve(response);
    }, function(error) {
      timerId && clearTimeout(timerId);
      reject(error);
    });
  });
}

使用这种方式还可模拟XHR的abort方法

1
2
3
4
5
6
7
8
9
10
11
12
13

var fetchOrigin = fetch;
window.fetch = function(url, options) {
  return new Promise(function(resolve, reject) {
    var abort = function() {
      reject(new Error('fetch abort'));
    };

    const p = fetchOrigin(url, option).then(resolve, reject);
    p.abort = abort;

    return p;
  });
}

方法二: 利用Promise.race方法

Promise.race方法接受一个promise实例数组参数，表示多个promise实例中任何一个最先改变状态，那么race方法返回的promise实例状态就跟着改变

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33

var fetchOrigin = fetch;
window.fetch = function(url, options) {
  var abortFn = null;
  var timeoutFn = null;

  var timeoutPromise = new Promise(function(resolve, reject) {
    timeoutFn = function () {
      reject(new Error('fetch timeout'));
    }
  });

  var abortPromise = new Promise(function(resolve, reject) {
    abortFn = function () {
      reject(new Error('fetch abort'));
    }
  });

  const fetchPromise = fetchOrigin(url, option);

  if (option.timeout) {
    setTimeout(timeoutFn, option.timeout);
  }

  const promise = Promise.race(
    timeoutPromise,
    abortPromise,
    fetchPromise,
  );

  promise.abort = abortFn;

  return promise;
}

对fetch的timeout的上述实现方式补充几点：

• timeout不是请求连接超时的含义，它表示发送请求到接收响应的时间，包括请求的连接、服务器处理及服务器响应回来的时间。
• fetch的timeout即使超时发生了，本次请求也不会被abort丢弃掉，它在后台仍然会发送到服务器端，只是本次请求的响应内容被丢弃而已。

fetch不支持JSONP

fetch是与服务器端进行异步交互的，而JSONP是外链一个javascript资源，是JSON的一种“使用模式”，可用于解决主流浏览器的跨域数据访问的问题，并不是真正ajax，所以fetch与JSONP没有什么直接关联，当然至少目前是不支持JSONP的。

这里我们把JSONP与fetch关联在一起有点差强人意，fetch只是一个ajax库，我们不可能使fetch支持JSONP；只是我们要实现一个JSONP，只不过这个JSONP的实现要与fetch的实现类似，即基于Promise来实现一个JSONP；而其外在表现给人感觉是fetch支持JSONP一样；

目前比较成熟的开源JSONP实现fetch-jsonp给我们提供了解决方案，想了解可以自行前往。不过再次想唠叨一下其JSONP的实现步骤，因为在本人面试的前端候选人中大部分人对JSONP的实现语焉不详；

使用它非常简单，首先需要用npm安装fetch-jsonp

1

npm install fetch-jsonp --save-dev

fetch-jsonp源码如下所示:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89

const defaultOptions = {
  timeout: 5000,
  jsonpCallback: 'callback',
  jsonpCallbackFunction: null,
};

function generateCallbackFunction() {
  return `jsonp_${Date.now()}_${Math.ceil(Math.random() * 100000)}`;
}

function clearFunction(functionName) {
  // IE8 throws an exception when you try to delete a property on window
  // http://stackoverflow.com/a/1824228/751089
  try {
    delete window[functionName];
  } catch (e) {
    window[functionName] = undefined;
  }
}

function removeScript(scriptId) {
  const script = document.getElementById(scriptId);
  if (script) {
    document.getElementsByTagName('head')[0].removeChild(script);
  }
}

function fetchJsonp(_url, options = {}) {
  // to avoid param reassign
  let url = _url;
  const timeout = options.timeout || defaultOptions.timeout;
  const jsonpCallback = options.jsonpCallback || defaultOptions.jsonpCallback;

  let timeoutId;

  return new Promise((resolve, reject) => {
    const callbackFunction = options.jsonpCallbackFunction || generateCallbackFunction();
    const scriptId = `${jsonpCallback}_${callbackFunction}`;

    window[callbackFunction] = (response) => {
      resolve({
        ok: true,
        // keep consistent with fetch API
        json: () => Promise.resolve(response),
      });

      if (timeoutId) clearTimeout(timeoutId);

      removeScript(scriptId);

      clearFunction(callbackFunction);
    };

    // Check if the user set their own params, and if not add a ? to start a list of params
    url += (url.indexOf('?') === -1) ? '?' : '&';

    const jsonpScript = document.createElement('script');
    jsonpScript.setAttribute('src', `${url}${jsonpCallback}=${callbackFunction}`);
    if (options.charset) {
      jsonpScript.setAttribute('charset', options.charset);
    }
    jsonpScript.id = scriptId;
    document.getElementsByTagName('head')[0].appendChild(jsonpScript);

    timeoutId = setTimeout(() => {
      reject(new Error(`JSONP request to ${_url} timed out`));

      removeScript(scriptId);

      clearFunction(callbackFunction);

      // 当前超时，请求并没有丢弃，请求完成的时候还是会调用该方法，如果直接干掉，会报错，修改函数体，回调过来时删除从全局上删除该函数
      window[callbackFunction] = () => {
        clearFunction(callbackFunction);
      };
    }, timeout);

    // Caught if got 404/500
    jsonpScript.onerror = () => {
      reject(new Error(`JSONP request to ${_url} failed`));

      clearFunction(callbackFunction);
      removeScript(scriptId);
      if (timeoutId) clearTimeout(timeoutId);
    };
  });
}

export default fetchJsonp;

具体的使用方式:

1
2
3
4
5
6
7
8
9

fetchJsonp('/users.jsonp', {
  timeout: 3000,
  jsonpCallback: 'custom_callback'
})
.then(function(response) {
  return response.json()
}).catch(function(ex) {
  console.log('parsing failed', ex)
});

fetch不支持progress事件

XHR是原生支持progress事件的，例如下面代码这样：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

var xhr = new XMLHttpRequest();
xhr.open('POST', '/uploads');
xhr.onload = function() {}
xhr.onerror = function() {}
var uploadProgress = function(event) {
  if (event.lengthComputable) {
    var percent = Math.round((event.loaded / event.total) * 100);
    console.log(percent);
  }
};

// 上传的progress事件
xhr.upload.onprogress = uploadProgress;
// 下载的progress事件
xhr.onprogress = uploadProgress;

但是fetch是不支持有关progress事件的；不过可喜的是，根据fetch的指导规范标准，其内部设计实现了Request和Response类；其中Response封装一些方法和属性，通过Response实例可以访问这些方法和属性，例如response.json()、response.body等等；

值得关注的地方是，response.body是一个可读字节流对象，其实现了一个getRender()方法，其具体作用是：

getRender()方法用于读取响应的原始字节流，该字节流是可以循环读取的，直至body内容传输完成；

因此，利用到这点可以模拟出fetch的progress。

代码实现如下:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25

// fetch() returns a promise that resolves once headers have been received
fetch(url).then(response => {
  // response.body is a readable stream.
  // Calling getReader() gives us exclusive access to the stream's content
  var reader = response.body.getReader();
  var bytesReceived = 0;

  // read() returns a promise that resolves when a value has been received
  reader.read().then(function processResult(result) {
    // Result objects contain two properties:
    // done  - true if the stream has already given you all its data.
    // value - some data. Always undefined when done is true.
    if (result.done) {
      console.log("Fetch complete");
      return;
    }

    // result.value for fetch streams is a Uint8Array
    bytesReceived += result.value.length;
    console.log('Received', bytesReceived, 'bytes of data so far');

    // Read some more, and call this function again
    return reader.read().then(processResult);
  });
});

github上也有使用Promise+XHR结合的方式实现类fetch的progress效果(当然这跟fetch完全不搭边）可以参考这里，具体代码如下：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24

function fetchProgress(url, opts={}, onProgress) {
  return new Promise((resolve, reject)=>{
    var xhr = new XMLHttpRequest();
    xhr.open(opts.method || 'get', url);

    for (var key in opts.headers||{}) {
      xhr.setRequestHeader(key, opts.headers[key]);
    }

    xhr.onload = function(event) {
      resolve(e.target.responseText)
    };

    xhr.onerror = reject;

    if (xhr.upload && onProgress) {
      xhr.upload.onprogress = onProgress; // event.loaded / event.total * 100 ; //event.lengthComputable
    }

    xhr.send(opts.body);
  });
}

fetchProgress('/').then(console.log)

fetch跨域问题

既然是ajax库，就不可避免与跨域扯上关系；XHR2是支持跨域请求的，只不过要满足浏览器端支持CORS，服务器通过Access-Control-Allow-Origin来允许指定的源进行跨域，仅此一种方式。

与XHR2一样，fetch也是支持跨域请求的，只不过其跨域请求做法与XHR2一样，需要客户端与服务端支持；另外，fetch还支持一种跨域，不需要服务器支持的形式，具体可以通过其mode的配置项来说明。

fetch的mode配置项有3个值，如下：

• same-origin：该模式是不允许跨域的，它需要遵守同源策略，否则浏览器会返回一个error告知不能跨域；其对应的response type为basic。
• cors: 该模式支持跨域请求，顾名思义它是以CORS的形式跨域；当然该模式也可以同域请求不需要后端额外的CORS支持；其对应的response type为cors。
• no-cors: 该模式用于跨域请求但是服务器不带CORS响应头，也就是服务端不支持CORS；这也是fetch的特殊跨域请求方式；其对应的response type为opaque。

针对跨域请求，cors模式是常见跨域请求实现，但是fetch自带的no-cors跨域请求模式则较为陌生，该模式有一个比较明显的特点：

该模式允许浏览器发送本次跨域请求，但是不能访问响应返回的内容，这也是其response type为opaque不透明的原因。

这与<img />发送的请求类似，只是该模式不能访问响应的内容信息；但是它可以被其他APIs进行处理，例如ServiceWorker。另外，该模式返回的response可以在Cache API中被存储起来以便后续的对它的使用，这点对script、css和图片的CDN资源是非常合适的，因为这些资源响应头中都没有CORS头。

总的来说，fetch的跨域请求是使用CORS方式，需要浏览器和服务端的支持。

原型链和继承

JavaScript是一门面向对象的设计语言，在JS里除了null和undefined，其余一切皆为对象。其中Array/Function/Date/RegExp是Object对象的特殊实例实现，Boolean/Number/String也都有对应的基本包装类型的对象（具有内置的方法）。传统语言是依靠class类来完成面向对象的继承和多态等特性，而JS使用原型链和构造器来实现继承，依靠参数arguments.length来实现多态。并且在ES6里也引入了class关键字来实现类。

函数与对象的关系

有时我们会好奇为什么能给一个函数添加属性，函数难道不应该就是一个执行过程的作用域吗？

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

var name = 'Hank';
function Person(name) {
    this.name = name;
    this.sayName = function() {
        alert(this.name);
    }
}
Person.age = 10;
console.log(Person.age);    // 10
console.log(Person);
/* 输出函数体：
ƒ Person(name) {
    this.name = name;
}
*/

我们能够给函数赋一个属性值，当我们输出这个函数时这个属性却无影无踪了，这到底是怎么回事，这个属性又保存在哪里了呢？

其实，在JS里，函数就是一个对象，这些属性自然就跟对象的属性一样被保存起来，函数名称指向这个对象的存储空间。

函数调用过程没查到资料，个人理解为：这个对象内部拥有一个内部属性[[function]]保存有该函数体的字符串形式，当使用()来调用的时候，就会实时对其进行动态解析和执行，如同**eval()**一样。

上图是JS的具体内存分配方式，JS中分为值类型和引用类型，值类型的数据大小固定，我们将其分配在栈里，直接保存其数据。而引用类型是对象，会动态的增删属性，大小不固定，我们把它分配到内存堆里，并用一个指针指向这片地址，也就是Person其实保存的是一个指向这片地址的指针。这里的Person对象是个函数实例，所以拥有特殊的内部属性[[function]]用于调用。同时它也拥有内部属性arguments/this/name，因为不相关，这里我们没有绘出，而展示了我们为其添加的属性age。

函数与原型的关系

同时在JS里，我们创建的每一个函数都有一个prototype（原型）属性，这个属性是一个指针，指向一个用于包含该函数所有实例的共享属性和方法的对象。而这个对象同时包含一个指针指向这个这个函数，这个指针就是constructor，这个函数也被成为构造函数。这样我们就完成了构造函数和原型对象的双向引用。

而上面的代码实质也就是当我们创建了Person构造函数之后，同步开辟了一片空间创建了一个对象作为Person的原型对象，可以通过Person.prototype来访问这个对象，也可以通过Person.prototype.constructor来访问Person该构造函数。通过构造函数我们可以往实例对象里添加属性，如上面的例子里的name属性和sayName()方法。我们也可以通过prototype来添加原型属性，如：

要注意属性和原型属性不是同一个东西，也并不保存在同一个空间里：

1
2

Person.age; // 10
Person.prototype.age; // 24

原型和实例的关系

现在有了构造函数和原型对象，那我们接下来new一个实例出来，这样才能真正体现面向对象编程的思想，也就是继承：

1
2

var person1 = new Person('Lee');
var person2 = new Person('Lucy');

我们新建了两个实例person1和person2，这些实例的内部都会包含一个指向其构造函数的原型对象的指针（内部属性），这个指针叫[[Prototype]]，在ES5的标准上没有规定访问这个属性，但是大部分浏览器实现了**proto**的属性来访问它，成为了实际的通用属性，于是在ES6的附录里写进了该属性。__proto__前后的双下划线说明其本质上是一个内部属性，而不是对外访问的API，因此官方建议新的代码应当避免使用该属性，转而使用Object.setPrototypeOf()（写操作）、Object.getPrototypeOf()（读操作）、Object.create()（生成操作）代替。

这里的prototype我们称为显示原型，__proto__我们称为隐式原型。

1

Object.getPrototypeOf({}) === Object.prototype; // true

同时由于现代 JavaScript 引擎优化属性访问所带来的特性的关系，更改对象的 [[Prototype]]在各个浏览器和 JavaScript 引擎上都是一个很慢的操作。其在更改继承的性能上的影响是微妙而又广泛的，这不仅仅限于 obj.proto = … 语句上的时间花费，而且可能会延伸到任何代码，那些可以访问任何[[Prototype]]已被更改的对象的代码。如果你关心性能，你应该避免设置一个对象的 [[Prototype]]。相反，你应该使用 Object.create()来创建带有你想要的[[Prototype]]的新对象。

此时它们的关系是（为了清晰，忽略函数属性的指向，用(function)代指）：

在这里我们可以看到两个实例指向了同一个原型对象，而在new的过程中调用了Person()方法，对每个实例分别初始化了name属性和sayName方法，属性值分别被保存，而方法作为引用对象也指向了不同的内存空间。

我们可以用几种方法来验证实例的原型指针到底指向的是不是构造函数的原型对象：

1
2
3
4

person1.__proto__ === Person.prototype // true
Person.prototype.isPrototypeOf(person1); // true
Object.getPrototypeOf(person2) === Person.prototype; // true
person1 instanceof Person; // true

原型链

现在我们访问实例person1的属性和方法了：

1
2
3

person1.name; // Lee
person1.age; // 24
person1.toString(); // [object Object]

想下这个问题，我们的name值来自于person1的属性，那么age值来自于哪？toString( )方法又在哪定义的呢？

这就是我们要说的原型链，原型链是实现继承的主要方法，其思想是利用原型让一个引用类型继承另一个引用类型的属性和方法。如果我们让一个原型对象等于另一个类型的实例，那么该原型对象就会包含一个指向另一个原型的指针，而如果另一个原型对象又是另一个原型的实例，那么上述关系依然成立，层层递进，就构成了实例与原型的链条，这就是原型链的概念。

上面代码的name来自于自身属性，age来自于原型属性，toString( )方法来自于Person原型对象的原型Object。当我们访问一个实例属性的时候，如果没有找到，我们就会继续搜索实例的原型，如果还没有找到，就递归搜索原型链直到原型链末端。我们可以来验证一下原型链的关系：

1

Person.prototype.__proto__ === Object.prototype // true

同时让我们更加深入的验证一些东西：

1
2

Person.__proto__ === Function.prototype // true
Function.prototype.__proto__ === Object.prototype // true

我们会发现Person是Function对象的实例，Function是Object对象的实例，Person原型是Object对象的实例。这证明了我们开篇的观点：JavaScript是一门面向对象的设计语言，在JS里除了null和undefined，其余一切皆为对象。

下面祭出我们的原型链图：

根据我们上面讲述的关于prototype/constructor/__proto__的内容，我相信你可以完全看懂这张图的内容。需要注意两点：

1. 构造函数和对象原型一一对应，他们与实例一起作为三要素构成了三面这幅图。最左侧是实例，中间是构造函数，最右侧是对象原型。
2. 最最右侧的null告诉我们：Object.prototype.proto = null，也就是Object.prototype是JS中一切对象的根源。其余的对象继承于它，并拥有自己的方法和属性。

6种继承方法

第一种: 原型链继承

利用原型链的特点进行继承

1
2
3
4
5
6
7
8
9
10
11
12

function Super(){
  this.name = 'web前端';
  this.type = ['JS','HTML','CSS'];
}
Super.prototype.sayName=function(){
  return this.name;
}
function Sub(){};
Sub.prototype = new Super();
Sub.prototype.constructor = Sub;
var sub1 = new Sub();
sub1.sayName();

优点：

• 可以实现继承。

缺点:

• 子类的原型属性集成了父类实例化对象，所有子类的实例化对象都共享原型对象的属性和方法

1
2
3
4
5

var sub1 = new Son();
var sub2 = new Son();
sub1.type.push('VUE');
console.log(sub1.type); // ['JS','HTML','CSS','VUE']
console.log(sub2.type); // ['JS','HTML','CSS','VUE']

• 子类构造函数实例化对象时，无法传递参数给父类

第二种: 构造函数继承

通过构造函数call方法实现继承。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

function Super(){
  this.name = 'web前端';
  this.type = ['JS','HTML','CSS'];

  this.sayName = function() {
    return this.name;
  }
}
function Sub(){
  Super.call(this);
}
var sub1 = new Sub();
sub1.type.push('VUE');
console.log(sub1.type); // ['JS','HTML','CSS','VUE']
var sub2 = new Sub();
console.log(sub2.type); // ['JS','HTML','CSS']

优点:

• 实现父类实例化对象的独立性

• 还可以给父类实例化对象添加参数

缺点:

• 方法都在构造函数中定义，每次实例化对象都得创建一遍方法，基本无法实现函数复用

• call方法仅仅调用了父级构造函数的属性及方法，没有办法访问父级构造函数原型对象的属性和方法

第三种: 组合继承

利用原型链继承和构造函数继承的各自优势进行组合使用

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23

function Super(name){
  this.name = name;
  this.type = ['JS','HTML','CSS'];
}

Super.prototype.sayName=function(){
  return this.name;
}

function Sub(name){
  Super.call(this, name);
}

Sub.prototype = new Super();
sub1 = new Sub('张三');
sub2 = new Sub('李四');
sub1.type.push('VUE');
sub2.type.push('PHP');
console.log(sub1.type); // ['JS','HTML','CSS','VUE']
console.log(sub2.type); // ['JS','HTML','CSS','PHP']
sub1.sayName(); // 张三
sub2.sayName(); // 李四

优点:

• 利用原型链继承，实现原型对象方法的继承，允许访问父级构造函数原型对象属性和方法，实现方法复用

• 利用构造函数继承，实现属性的继承，而且可以传递参数

缺点:

• 创建子类实例对象时，无论什么情况下，都会调用两次父级构造函数：一次是在创建子级原型的时候，另一次是在子级构造函数内部(call)

第四种: 原型式继承

创建一个函数，将参数作为一个对象的原型对象。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17

function create(obj) {
  function Sub(){};
  Sub.prototype = obj;
  Sub.prototype.constructor = Sub;
  return new Sub();
}

var parent = {
  name: '张三',
  type: ['JS','HTML','CSS'],
};

var sub1 = create(parent);
var sub2 = create(parent);

console.log(sub1.name); // 张三
console.log(sub2.name); // 张三

ES5规范化了这个原型继承，新增了Object.create()方法，接收两个参数，第一个为原型对象，第二个为要混合进新对象的属性，格式与Object.defineProperties()相同。

1
2
3
4
5
6
7
8
9
10
11
12
13

Object.create(null, {name: {value: 'Greg', enumerable: true}});

// 相当于
var parent = {
  name: '张三',
  type: ['JS','HTML','CSS'],
};

var sub1 = Object.create(parent);
var sub2 = Object.create(parent);

console.log(sub1.name); // 张三
console.log(sub2.name); // 张三

优缺点：

• 跟原型链类似

第五种: 寄生继承

在原型式继承的基础上，在函数内部丰富对象

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26

function create(obj) {
  function Sub() {};
  Sub.prototype = obj;
  Sub.prototype.constructor = Sub;

  return new Sub();
}

function Parasitic(obj) {
  var clone = create(obj);
  clone.sayHi = function() {
    console.log('hi');
  };
  return clone;
}

var parent = {
  name: '张三',
  type: ['JS','HTML','CSS'],
};

var sub1 = Parasitic(parent);
var sub2 = Parasitic(parent);

console.log(sub1.name); // 张三
console.log(sub2.name); // 张三

如果使用ES5Object.create来代替create函数的话，可以简化成如下所示:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20

function Parasitic(obj) {
  var clone = Object.create(obj);
  clone.sayHi = function() {
    console.log('hi');
  };
  return clone;
}

var parent = {
  name: '张三',
  type: ['JS','HTML','CSS'];
};

var son1 = Parasitic(parent);
var son2 = Parasitic(parent);

console.log(son1.name); // 张三
console.log(son2.name); // 张三
son1.sayHi();
son2.sayHi();

优缺点:

• 跟构造函数继承类似，调用一次函数就得创建一遍方法，无法实现函数复用，效率较低

第六种: 寄生组合继承

利用组合继承和寄生继承各自优势

组合继承方法我们已经说了，它的缺点是两次调用父级构造函数，一次是在创建子级原型的时候，另一次是在子级构造函数内部，那么我们只需要优化这个问题就行了，即减少一次调用父级构造函数，正好利用寄生继承的特性，继承父级构造函数的原型来创建子级原型。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32

function Super(name) {
  this.name = name;
  this.type = ['JS','HTML','CSS'];
};

Super.prototype.sayName = function () {
  return this.name;
};

function Sub(name, age) {
  Super.call(this, name);
  this.age = age;
}

// 我们封装其继承过程
function inheritPrototype(Sub, Super) {
  // 以该对象为原型创建一个新对象
  var prototype = Object.create(Super.prototype);
  prototype.constructor = Sub;
  Sub.prototype = prototype;
}

inheritPrototype(Sub, Super);

// 必须定义在inheritPrototype方法之后
Sub.prototype.sayAge = function () {
  return this.age;
}

var instance = new Sub('张三', 40);
instance.sayName(); // 张三
instance.sayAge(); // 40

这种方式只调用了一次父类构造函数，只在子类上创建一次对象，同时保持原型链，还可以使用instanceof和isPrototypeOf()来判断原型，是我们最理想的继承方式。

第七种: ES6 Class类和extends关键字

ES6引进了class关键字，用于创建类，这里的类是作为ES5构造函数和原型对象的语法糖存在的，其功能大部分都可以被ES5实现，不过在语言层面上ES6也提供了部分支持。新的写法不过让对象原型看起来更加清晰，更像面向对象的语法而已。

1
2
3
4
5
6
7
8
9
10
11
12
13

//定义类
class Point {
  constructor(x, y) {
    this.x = x;
    this.y = y;
  }

  toString() {
    return '(' + this.x + ', ' + this.y + ')';
  }
}

var point = new Point(10, 10);

我们看到其中的constructor方法就是之前的构造函数，this就是之前的原型对象，toString()就是定义在原型上的方法，只能使用new关键字来新建实例。语法差别在于我们不需要function关键字和逗号分割符。其中，所有的方法都直接定义在原型上，注意所有的方法都不可枚举。类的内部使用严格模式，并且不存在变量提升，其中的this指向类的实例。

new是从构造函数生成实例的命令。ES6 为new命令引入了一个new.target属性，该属性一般用在构造函数之中，返回new命令作用于的那个构造函数。如果构造函数不是通过new命令调用的，new.target会返回undefined，因此这个属性可以用来确定构造函数是怎么调用的。

类存在静态方法，使用static关键字表示，其只能类和继承的子类来进行调用，不能被实例调用，也就是不能被实例继承，所以我们称它为静态方法。类不存在内部方法和内部属性。

1
2
3
4
5
6
7
8
9
10
11

class Foo {
  static classMethod() {
    return 'hello';
  }
}

Foo.classMethod() // 'hello'

var foo = new Foo();
foo.classMethod()
// TypeError: foo.classMethod is not a function

类通过extends关键字来实现继承，在继承的子类的构造函数里我们使用super关键字来表示对父类构造函数的引用；在静态方法里，super指向父类；在其它函数体内，super表示对父类原型属性的引用。其中super必须在子类的构造函数体内调用一次，因为我们需要调用时来绑定子类的元素对象，否则会报错。

1
2
3
4
5
6
7
8
9
10

class ColorPoint extends Point {
  constructor(x, y, color) {
    super(x, y); // 调用父类的constructor(x, y)
    this.color = color;
  }

  toString() {
    return this.color + ' ' + super.toString(); // 调用父类的toString()
  }
}

前端性能优化

性能优化是把双刃剑，有好的一面也有坏的一面。好的一面就是能提升网站性能，坏的一面就是配置麻烦，或者要遵守的规则太多。并且某些性能优化规则并不适用所有场景，需要谨慎使用。

下面列出来了前端性能的24条建议:

1. 减少 HTTP 请求

一个完整的 HTTP 请求需要经历 DNS 查找，TCP 握手，浏览器发出 HTTP 请求，服务器接收请求，服务器处理请求并发回响应，浏览器接收响应等过程。

接下来看一个具体的例子帮助理解 HTTP ：

这是一个 HTTP 请求，请求的文件大小为 28.4KB。

名词解释：

• Queueing: 在请求队列中的时间。
• Stalled: 从TCP 连接建立完成，到真正可以传输数据之间的时间差，此时间包括代理协商时间。
• Proxy negotiation: 与代理服务器连接进行协商所花费的时间。
• DNS Lookup: 执行DNS查找所花费的时间，页面上的每个不同的域都需要进行DNS查找。
• Initial Connection / Connecting: 建立连接所花费的时间，包括TCP握手，重试和协商SSL。
• SSL: 完成SSL握手所花费的时间。
• Request sent: 发出网络请求所花费的时间，通常为一毫秒的时间。
• Waiting(TFFB): TFFB 是发出页面请求到接收到应答数据第一个字节的时间。
• Content Download: 接收响应数据所花费的时间。

从这个例子可以看出，真正下载数据的时间占比为 13.05 / 204.16 = 6.39%，文件越小，这个比例越小，文件越大，比例就越高。这就是为什么要建议将多个小文件合并为一个大文件，从而减少 HTTP 请求次数的原因。

2. 使用 HTTP2

HTTP2 相比 HTTP1.1 有如下几个优点：

解析速度快

服务器解析 HTTP1.1 的请求时，必须不断地读入字节，直到遇到分隔符 CRLF 为止。而解析 HTTP2 的请求就不用这么麻烦，因为 HTTP2 是基于帧的协议，每个帧都有表示帧长度的字段。

多路复用

HTTP1.1 如果要同时发起多个请求，就得建立多个 TCP 连接，因为一个 TCP 连接同时只能处理一个 HTTP1.1 的请求。

在 HTTP2 上，多个请求可以共用一个 TCP 连接，这称为多路复用。同一个请求和响应用一个流来表示，并有唯一的流 ID 来标识。 多个请求和响应在 TCP 连接中可以乱序发送，到达目的地后再通过流 ID 重新组建。

首部压缩

HTTP2 提供了首部压缩功能。

例如有如下两个请求：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31

// 请求1
:authority: unpkg.zhimg.com
:method: GET
:path: /za-js-sdk@2.16.0/dist/zap.js
:scheme: https
accept: */*
accept-encoding: gzip, deflate, br
accept-language: zh-CN,zh;q=0.9
cache-control: no-cache
pragma: no-cache
referer: https://www.zhihu.com/
sec-fetch-dest: script
sec-fetch-mode: no-cors
sec-fetch-site: cross-site
user-agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/80.0.3987.122 Safari/537.36

// 请求2
:authority: zz.bdstatic.com
:method: GET
:path: /linksubmit/push.js
:scheme: https
accept: */*
accept-encoding: gzip, deflate, br
accept-language: zh-CN,zh;q=0.9
cache-control: no-cache
pragma: no-cache
referer: https://www.zhihu.com/
sec-fetch-dest: script
sec-fetch-mode: no-cors
sec-fetch-site: cross-site
user-agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/80.0.3987.122 Safari/537.36

从上面两个请求可以看出来，有很多数据都是重复的。如果可以把相同的首部存储起来，仅发送它们之间不同的部分，就可以节省不少的流量，加快请求的时间。

HTTP/2 在客户端和服务器端使用“首部表”来跟踪和存储之前发送的键－值对，对于相同的数据，不再通过每次请求和响应发送。

下面再来看一个简化的例子，假设客户端按顺序发送如下请求首部：

1
2
3

Header1:foo
Header2:bar
Header3:bat

当客户端发送请求时，它会根据首部值创建一张表：

如果服务器收到了请求，它会照样创建一张表。 当客户端发送下一个请求的时候，如果首部相同，它可以直接发送这样的首部块：

1

62 63 64

服务器会查找先前建立的表格，并把这些数字还原成索引对应的完整首部。

优先级

HTTP2 可以对比较紧急的请求设置一个较高的优先级，服务器在收到这样的请求后，可以优先处理。

流量控制

由于一个 TCP 连接流量带宽（根据客户端到服务器的网络带宽而定）是固定的，当有多个请求并发时，一个请求占的流量多，另一个请求占的流量就会少。流量控制可以对不同的流的流量进行精确控制。

服务器推送

HTTP2 新增的一个强大的新功能，就是服务器可以对一个客户端请求发送多个响应。换句话说，除了对最初请求的响应外，服务器还可以额外向客户端推送资源，而无需客户端明确地请求。

例如当浏览器请求一个网站时，除了返回 HTML 页面外，服务器还可以根据 HTML 页面中的资源的 URL，来提前推送资源。

现在有很多网站已经开始使用 HTTP2 了，例如知乎：

其中 h2 是指 HTTP2 协议，http/1.1 则是指 HTTP1.1 协议。

参考资料：

• 半小时搞懂 HTTP、HTTPS和HTTP2

3. 使用服务端渲染

客户端渲染: 获取 HTML 文件，根据需要下载 JavaScript 文件，运行文件，生成 DOM，再渲染。

服务端渲染：服务端返回 HTML 文件，客户端只需解析 HTML。

• 优点：首屏渲染快，SEO 好。
• 缺点：配置麻烦，增加了服务器的计算压力。

下面我用 Vue SSR 做示例，简单的描述一下 SSR 过程。

客户端渲染过程

1. 访问客户端渲染的网站。
2. 服务器返回一个包含了引入资源语句和 <div id=”app”></div> 的 HTML 文件。
3. 客户端通过 HTTP 向服务器请求资源，当必要的资源都加载完毕后，执行 new Vue() 开始实例化并渲染页面。

服务端渲染过程

1. 访问服务端渲染的网站。
2. 服务器会查看当前路由组件需要哪些资源文件，然后将这些文件的内容填充到 HTML 文件。如果有 ajax 请求，就会执行它进行数据预取并填充到 HTML 文件里，最后返回这个 HTML 页面。
3. 当客户端接收到这个 HTML 页面时，可以马上就开始渲染页面。与此同时，页面也会加载资源，当必要的资源都加载完毕后，开始执行 new Vue() 开始实例化并接管页面。

从上述两个过程中可以看出，区别就在于第二步。客户端渲染的网站会直接返回 HTML 文件，而服务端渲染的网站则会渲染完页面再返回这个 HTML 文件。

这样做的好处是什么？是更快的内容到达时间 (time-to-content)。

假设你的网站需要加载完 abcd 四个文件才能渲染完毕。并且每个文件大小为 1 M。

这样一算：客户端渲染的网站需要加载 4 个文件和 HTML 文件才能完成首页渲染，总计大小为 4M（忽略 HTML 文件大小）。而服务端渲染的网站只需要加载一个渲染完毕的 HTML 文件就能完成首页渲染，总计大小为已经渲染完毕的 HTML 文件（这种文件不会太大，一般为几百K，我的个人博客网站（SSR）加载的 HTML 文件为 400K）。这就是服务端渲染更快的原因。

参考资料：

• vue-ssr-demo
• Vue.js 服务器端渲染指南

4. 静态资源使用 CDN

内容分发网络（CDN）是一组分布在多个不同地理位置的 Web 服务器。我们都知道，当服务器离用户越远时，延迟越高。CDN 就是为了解决这一问题，在多个位置部署服务器，让用户离服务器更近，从而缩短请求时间。

CDN 原理

当用户访问一个网站时，如果没有 CDN，过程是这样的：

1. 浏览器要将域名解析为 IP 地址，所以需要向本地 DNS 发出请求。
2. 本地 DNS 依次向根服务器、顶级域名服务器、权限服务器发出请求，得到网站服务器的 IP 地址。
3. 本地 DNS 将 IP 地址发回给浏览器，浏览器向网站服务器 IP 地址发出请求并得到资源。

如果用户访问的网站部署了 CDN，过程是这样的：

1. 浏览器要将域名解析为 IP 地址，所以需要向本地 DNS 发出请求。
2. 本地 DNS 依次向根服务器、顶级域名服务器、权限服务器发出请求，得到全局负载均衡系统（GSLB）的 IP 地址。
3. 本地 DNS 再向 GSLB 发出请求，GSLB 的主要功能是根据本地 DNS 的 IP 地址判断用户的位置，筛选出距离用户较近的本地负载均衡系统（SLB），并将该 SLB 的 IP 地址作为结果返回给本地 DNS。
4. 本地 DNS 将 SLB 的 IP 地址发回给浏览器，浏览器向 SLB 发出请求。
5. SLB 根据浏览器请求的资源和地址，选出最优的缓存服务器发回给浏览器。
6. 浏览器再根据 SLB 发回的地址重定向到缓存服务器。
7. 如果缓存服务器有浏览器需要的资源，就将资源发回给浏览器。如果没有，就向源服务器请求资源，再发给浏览器并缓存在本地。

参考资料：

• CDN是什么？使用CDN有什么优势？
• CDN原理简析

5. 将 CSS 放在文件头部，JavaScript 文件放在底部

所有放在 head 标签里的 CSS 和 JS 文件都会堵塞渲染。如果这些 CSS 和 JS 需要加载和解析很久的话，那么页面就空白了。所以 JS 文件要放在底部，等 HTML 解析完了再加载 JS 文件。

那为什么 CSS 文件还要放在头部呢？

因为先加载 HTML 再加载 CSS，会让用户第一时间看到的页面是没有样式的、“丑陋”的，为了避免这种情况发生，就要将 CSS 文件放在头部了。

另外，JS 文件也不是不可以放在头部，只要给 script 标签加上 defer 属性就可以了，异步下载，延迟执行。

6. 使用字体图标 iconfont 代替图片图标

字体图标就是将图标制作成一个字体，使用时就跟字体一样，可以设置属性，例如 font-size、color 等等，非常方便。并且字体图标是矢量图，不会失真。还有一个优点是生成的文件特别小。

压缩字体文件

使用 fontmin-webpack 插件对字体文件进行压缩。

参考资料：

• fontmin-webpack
• Iconfont-阿里巴巴矢量图标库

7. 善用缓存，不重复加载相同的资源

为了避免用户每次访问网站都得请求文件，我们可以通过添加 Expires 或 max-age 来控制这一行为。Expires 设置了一个时间，只要在这个时间之前，浏览器都不会请求文件，而是直接使用缓存。而 max-age 是一个相对时间，建议使用 max-age 代替 Expires 。

不过这样会产生一个问题，当文件更新了怎么办？怎么通知浏览器重新请求文件？

可以通过更新页面中引用的资源链接地址，让浏览器主动放弃缓存，加载新资源。

具体做法是把资源地址 URL 的修改与文件内容关联起来，也就是说，只有文件内容变化，才会导致相应 URL 的变更，从而实现文件级别的精确缓存控制。什么东西与文件内容相关呢？我们会很自然的联想到利用数据摘要要算法对文件求摘要信息，摘要信息与文件内容一一对应，就有了一种可以精确到单个文件粒度的缓存控制依据了。

参考资料：

• webpack + express 实现文件精确缓存
• webpack-缓存
• 张云龙–大公司里怎样开发和部署前端代码？

8. 压缩文件

压缩文件可以减少文件下载时间，让用户体验性更好。

得益于 webpack 和 node 的发展，现在压缩文件已经非常方便了。

在 webpack 可以使用如下插件进行压缩：

• JavaScript：UglifyPlugin
• CSS ：MiniCssExtractPlugin
• HTML：HtmlWebpackPlugin

其实，我们还可以做得更好。那就是使用 gzip 压缩。可以通过向 HTTP 请求头中的 Accept-Encoding 头添加 gzip 标识来开启这一功能。当然，服务器也得支持这一功能。

gzip 是目前最流行和最有效的压缩方法。举个例子，我用 Vue 开发的项目构建后生成的 app.js 文件大小为 1.4MB，使用 gzip 压缩后只有 573KB，体积减少了将近 60%。

附上 webpack 和 node 配置 gzip 的使用方法。

下载插件

1
2

npm install compression-webpack-plugin --save-dev
npm install compression

webpack 配置

1
2
3
4
5

const CompressionPlugin = require('compression-webpack-plugin');

module.exports = {
  plugins: [new CompressionPlugin()],
}

node 配置

1
2
3

const compression = require('compression')
// 在其他中间件前使用
app.use(compression())

9. 图片优化

(1). 图片延迟加载

在页面中，先不给图片设置路径，只有当图片出现在浏览器的可视区域时，才去加载真正的图片，这就是延迟加载。对于图片很多的网站来说，一次性加载全部图片，会对用户体验造成很大的影响，所以需要使用图片延迟加载。

首先可以将图片这样设置，在页面不可见时图片不会加载：

1

<img data-src="https://avatars0.githubusercontent.com/u/22117876?s=460&u=7bd8f32788df6988833da6bd155c3cfbebc68006&v=4">

等页面可见时，使用 JS 加载图片：

1
2

const img = document.querySelector('img')
img.src = img.dataset.src

这样图片就加载出来了，完整的代码可以看一下参考资料。

参考资料：

• web 前端图片懒加载实现原理

(2). 响应式图片

响应式图片的优点是浏览器能够根据屏幕大小自动加载合适的图片。

通过 picture 实现

1
2
3
4
5

<picture>
  <source srcset="banner_w1000.jpg" media="(min-width: 801px)">
  <source srcset="banner_w800.jpg" media="(max-width: 800px)">
  <img src="banner_w800.jpg" alt="">
</picture>

通过 @media 实现

1
2
3
4
5
6
7
8
9
10

@media (min-width: 769px) {
  .bg {
    background-image: url(bg1080.jpg);
  }
}
@media (max-width: 768px) {
  .bg {
    background-image: url(bg768.jpg);
  }
}

(3). 调整图片大小

例如，你有一个 1920 * 1080 大小的图片，用缩略图的方式展示给用户，并且当用户鼠标悬停在上面时才展示全图。如果用户从未真正将鼠标悬停在缩略图上，则浪费了下载图片的时间。

所以，我们可以用两张图片来实行优化。一开始，只加载缩略图，当用户悬停在图片上时，才加载大图。还有一种办法，即对大图进行延迟加载，在所有元素都加载完成后手动更改大图的 src 进行下载。

(4). 降低图片质量

例如 JPG 格式的图片，100% 的质量和 90% 质量的通常看不出来区别，尤其是用来当背景图的时候。我经常用 PS 切背景图时， 将图片切成 JPG 格式，并且将它压缩到 60% 的质量，基本上看不出来区别。

压缩方法有两种，一是通过 webpack 插件 image-webpack-loader，二是通过在线网站进行压缩。

以下附上 webpack 插件 image-webpack-loader 的用法。

1

npm install --save-dev image-webpack-loader

webpack 配置

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19

{
  test: /\.(png|jpe?g|gif|svg)(\?.*)?$/,
  use:[
    {
    loader: 'url-loader',
    options: {
      limit: 10000, /* 图片大小小于1000字节限制时会自动转成 base64 码引用*/
      name: utils.assetsPath('img/[name].[hash:7].[ext]')
      }
    },
    /*对图片进行压缩*/
    {
      loader: 'image-webpack-loader',
      options: {
        bypassOnDebug: true,
      }
    }
  ]
}

参考资料：

• img图片在webpack中使用

(5). 尽可能利用 CSS3 效果代替图片

有很多图片使用 CSS 效果（渐变、阴影等）就能画出来，这种情况选择 CSS3 效果更好。因为代码大小通常是图片大小的几分之一甚至几十分之一。

(6). 使用 webp 格式的图片

WebP 的优势体现在它具有更优的图像数据压缩算法，能带来更小的图片体积，而且拥有肉眼识别无差异的图像质量；同时具备了无损和有损的压缩模式、Alpha 透明以及动画的特性，在 JPEG 和 PNG 上的转化效果都相当优秀、稳定和统一。

参考资料：

• WebP 相对于 PNG、JPG 有什么优势？

10. 通过 webpack 按需加载代码，提取第三库代码，减少 ES6 转为 ES5 的冗余代码

懒加载或者按需加载，是一种很好的优化网页或应用的方式。这种方式实际上是先把你的代码在一些逻辑断点处分离开，然后在一些代码块中完成某些操作后，立即引用或即将引用另外一些新的代码块。这样加快了应用的初始加载速度，减轻了它的总体体积，因为某些代码块可能永远不会被加载。

根据文件内容生成文件名，结合 import 动态引入组件实现按需加载

通过配置 output 的 filename 属性可以实现这个需求。filename 属性的值选项中有一个 [contenthash]，它将根据文件内容创建出唯一 hash。当文件内容发生变化时，[contenthash] 也会发生变化。

1
2
3
4
5
6
7

{
  output: {
    filename: '[name].[contenthash].js',
    chunkFilename: '[name].[contenthash].js',
    path: path.resolve(__dirname, '../dist'),
  },
}

提取第三方库

由于引入的第三方库一般都比较稳定，不会经常改变。所以将它们单独提取出来，作为长期缓存是一个更好的选择。 这里需要使用 webpack4 的 splitChunk 插件 cacheGroups 选项。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22

optimization: {
  runtimeChunk: {
    name: 'manifest' // 将 webpack 的 runtime 代码拆分为一个单独的 chunk。
  },
  splitChunks: {
    cacheGroups: {
      vendor: {
        name: 'chunk-vendors',
        test: /[\\/]node_modules[\\/]/,
        priority: -10,
        chunks: 'initial'
      },
      common: {
        name: 'chunk-common',
        minChunks: 2,
        priority: -20,
        chunks: 'initial',
        reuseExistingChunk: true
      }
    },
  }
},

• test: 过滤 modules，默认为所有的 modules，可匹配模块路径或 chunk 名字，当匹配到某个 chunk 的名字时，这个 chunk 里面引入的所有 module 都会选中。可以传递的值类型：RegExp、String和Function。
• priority: 权重，数字越大表示优先级越高。一个 module 可能会满足多个 cacheGroups 的正则匹配，到底将哪个缓存组应用于这个 module，取决于优先级。
• reuseExistingChunk: 表示是否使用已有的 chunk，true 则表示如果当前的 chunk 包含的模块已经被抽取出去了，那么将不会重新生成新的，即几个 chunk 复用被拆分出去的一个 module。
• minChunks(默认是1): 在分割之前，这个代码块最小应该被引用的次数（译注：保证代码块复用性，默认配置的策略是不需要多次引用也可以被分割）
• chunks(默认是async): initial、async和all。chunks改为all，表示同时对静态加载(initial)和动态加载(async)起作用。
• name(打包的chunks的名字): 字符串或者函数(函数可以根据条件自定义名字)

减少 ES6 转为 ES5 的冗余代码

Babel 转化后的代码想要实现和原来代码一样的功能需要借助一些帮助函数，比如

1

class Person {}

会被转换为：

1
2
3
4
5
6
7
8
9
10
11

"use strict";

function _classCallCheck(instance, Constructor) {
  if (!(instance instanceof Constructor)) {
    throw new TypeError("Cannot call a class as a function");
  }
}

var Person = function Person() {
  _classCallCheck(this, Person);
};

这里 _classCallCheck 就是一个 helper 函数，如果在很多文件里都声明了类，那么就会产生很多个这样的 helper 函数。

这里的 @babel/runtime 包就声明了所有需要用到的帮助函数，而 @babel/plugin-transform-runtime 的作用就是将所有需要 helper 函数的文件，从 @babel/runtime包引进来：

1
2
3
4
5
6
7
8
9
10
11
12
13

"use strict";

var _classCallCheck2 = require("@babel/runtime/helpers/classCallCheck");

var _classCallCheck3 = _interopRequireDefault(_classCallCheck2);

function _interopRequireDefault(obj) {
  return obj && obj.__esModule ? obj : { default: obj };
}

var Person = function Person() {
  (0, _classCallCheck3.default)(this, Person);
};

这里就没有再编译出 helper 函数 classCallCheck 了，而是直接引用了 @babel/runtime 中的 helpers/classCallCheck。

安装

1

npm install --save-dev @babel/plugin-transform-runtime @babel/runtime

使用 在 .babelrc 文件中

1
2
3
4
5

{
  "plugins": [
    "@babel/plugin-transform-runtime"
  ]
}

参考资料：

• Babel 7.1介绍 transform-runtime polyfill env
• webpack 懒加载
• Vue 路由懒加载
• webpack 缓存
• 一步一步的了解webpack4的splitChunk插件

11. 减少重绘重排

浏览器渲染过程

1. 解析HTML生成DOM树。
2. 解析CSS生成CSSOM规则树。
3. 将DOM树与CSSOM规则树合并在一起生成渲染树。
4. 遍历渲染树开始布局，计算每个节点的位置大小信息。
5. 将渲染树每个节点绘制到屏幕。

重排

当改变 DOM 元素位置或大小时，会导致浏览器重新生成渲染树，这个过程叫重排。

重绘

当重新生成渲染树后，就要将渲染树每个节点绘制到屏幕，这个过程叫重绘。不是所有的动作都会导致重排，例如改变字体颜色，只会导致重绘。记住，重排会导致重绘，重绘不会导致重排。

重排和重绘这两个操作都是非常昂贵的，因为 JavaScript 引擎线程与 GUI 渲染线程是互斥，它们同时只能一个在工作。

什么操作会导致重排？

• 添加或删除可见的 DOM 元素
• 元素位置改变
• 元素尺寸改变
• 内容改变
• 浏览器窗口尺寸改变

如何减少重排重绘？

• 用 JavaScript 修改样式时，最好不要直接写样式，而是替换 class 来改变样式。
• 如果要对 DOM 元素执行一系列操作，可以将 DOM 元素脱离文档流，修改完成后，再将它带回文档。推荐使用隐藏元素（display:none）或文档碎片（DocumentFragment），都能很好的实现这个方案。

12. 使用事件委托

事件委托利用了事件冒泡，只指定一个事件处理程序，就可以管理某一类型的所有事件。所有用到按钮的事件（多数鼠标事件和键盘事件）都适合采用事件委托技术， 使用事件委托可以节省内存。

1
2
3
4
5

<ul>
  <li>苹果</li>
  <li>香蕉</li>
  <li>凤梨</li>
</ul>

1
2
3
4
5
6
7
8
9
10
11
12
13
14

// good
document.querySelector('ul').onclick = (event) => {
  const target = event.target;
  if (target.nodeName === 'LI') {
    console.log(target.innerHTML);
  }
}

// bad
document.querySelectorAll('li').forEach((e) => {
  e.onclick = function() {
    console.log(this.innerHTML);
  }
})

13. 注意程序的局部性

一个编写良好的计算机程序常常具有良好的局部性，它们倾向于引用最近引用过的数据项附近的数据项，或者最近引用过的数据项本身，这种倾向性，被称为局部性原理。有良好局部性的程序比局部性差的程序运行得更快。

局部性通常有两种不同的形式：

• 时间局部性: 在一个具有良好时间局部性的程序中，被引用过一次的内存位置很可能在不远的将来被多次引用。
• 空间局部性: 在一个具有良好空间局部性的程序中，如果一个内存位置被引用了一次，那么程序很可能在不远的将来引用附近的一个内存位置。

时间局部性示例

1
2
3
4
5
6
7
8
9
10

function sum(arry) {
  let i, sum = 0;
  let len = arry.length;

  for (i = 0; i < len; i++) {
    sum += arry[i];
  }

  return sum;
}

在这个例子中，变量sum在每次循环迭代中被引用一次，因此，对于sum来说，具有良好的时间局部性

空间局部性示例

具有良好空间局部性的程序

1
2
3
4
5
6
7
8
9
10
11
12

// 二维数组
function sum1(arry, rows, cols) {
  let i, j, sum = 0;

  for (i = 0; i < rows; i++) {
    for (j = 0; j < cols; j++) {
      sum += arry[i][j];
    }
  }

  return sum;
}

空间局部性差的程序

1
2
3
4
5
6
7
8
9
10
11
12

// 二维数组
function sum2(arry, rows, cols) {
  let i, j, sum = 0;

  for (j = 0; j < cols; j++) {
    for (i = 0; i < rows; i++) {
      sum += arry[i][j];
    }
  }

  return sum;
}

看一下上面的两个空间局部性示例，像示例中从每行开始按顺序访问数组每个元素的方式，称为具有步长为1的引用模式。 如果在数组中，每隔k个元素进行访问，就称为步长为k的引用模式。 一般而言，随着步长的增加，空间局部性下降。

这两个例子有什么区别？区别在于第一个示例是按行扫描数组，每扫描完一行再去扫下一行；第二个示例是按列来扫描数组，扫完一行中的一个元素，马上就去扫下一行中的同一列元素。

数组在内存中是按照行顺序来存放的，结果就是逐行扫描数组的示例得到了步长为 1 引用模式，具有良好的空间局部性；而另一个示例步长为 rows，空间局部性极差。

性能测试

运行环境：

• cpu: i7-10510U
• 浏览器: 83.0.4103.61

对一个长度为9000的二维数组（子数组长度也为9000）进行10次空间局部性测试，时间（毫秒）取平均值，结果如下：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44

function sum2(arry, rows, cols) {
  let i, j, sum = 0;

  for (j = 0; j < cols; j++) {
    for (i = 0; i < rows; i++) {
      sum += arry[i][j];
    }
  }

  return sum;
}

// 二维数组
function sum1(arry, rows, cols) {
  let i, j, sum = 0;

  for (i = 0; i < rows; i++) {
    for (j = 0; j < cols; j++) {
      sum += arry[i][j];
    }
  }

  return sum;
}

var arry = new Array(9000).fill(new Array(9000).fill(1));

let ts = 0;
for (let i = 0; i < 10; i++) {
  const startTime = new Date().valueOf();
  sum1(arry, 9000, 9000);
  ts += (new Date().valueOf() - startTime);
}

console.log('sum1: ' + (ts / 10)); // 81.5ms

let ts2 = 0;
for (let i = 0; i < 10; i++) {
  const startTime = new Date().valueOf();
  sum2(arry, 9000, 9000);
  ts2 += (new Date().valueOf() - startTime);
}

console.log('sum2: ' + (ts2 / 10)); // 167.3ms

所用示例为上述两个空间局部性示例

从以上测试结果来看，步长为 1 的数组执行时间比步长为 9000 的数组快了一个数量级。

总结：

• 重复引用相同变量的程序具有良好的时间局部性
• 对于具有步长为 k 的引用模式的程序，步长越小，空间局部性越好；而在内存中以大步长跳来跳去的程序空间局部性会很差

参考资料：

• 深入理解计算机系统

14. if-else 对比 switch

当判断条件数量越来越多时，越倾向于使用 switch 而不是 if-else。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39

if (color == 'blue') {

} else if (color == 'yellow') {

} else if (color == 'white') {

} else if (color == 'black') {

} else if (color == 'green') {

} else if (color == 'orange') {

} else if (color == 'pink') {

}

switch (color) {
  case 'blue':

    break;
  case 'yellow':

    break;
  case 'white':

    break;
  case 'black':

    break;
  case 'green':

    break;
  case 'orange':

    break;
  case 'pink':

    break;
}

像以上这种情况，使用 switch 是最好的。假设 color 的值为 pink，则 if-else 语句要进行 7 次判断，switch 只需要进行一次判断。 从可读性来说，switch 语句也更好。

从使用时机来说，当条件值大于两个的时候，使用 switch 更好。不过 if-else 也有 switch 无法做到的事情，例如有多个判断条件的情况下，无法使用 switch。

15. 查找表

当条件语句特别多时，使用 switch 和 if-else 不是最佳的选择，这时不妨试一下查找表。查找表可以使用数组和对象来构建。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26

switch (index) {
  case '0':
    return result0;
  case '1':
    return result1;
  case '2':
    return result2;
  case '3':
    return result3;
  case '4':
    return result4;
  case '5':
    return result5;
  case '6':
    return result6;
  case '7':
    return result7;
  case '8':
    return result8;
  case '9':
    return result9;
  case '10':
    return result10;
  case '11':
    return result11;
}

可以将这个 switch 语句转换为查找表

1
2
3

const results = [result0,result1,result2,result3,result4,result5,result6,result7,result8,result9,result10,result11];

return results[index];

如果条件语句不是数值而是字符串，可以用对象来建立查找表

1
2
3
4
5
6

const map = {
  red: result0,
  green: result1,
};

return map[color];

16. 避免页面卡顿

60fps 与设备刷新率

目前大多数设备的屏幕刷新率为 60 次/秒。因此，如果在页面中有一个动画或渐变效果，或者用户正在滚动页面，那么浏览器渲染动画或页面的每一帧的速率也需要跟设备屏幕的刷新率保持一致。 其中每个帧的预算时间仅比 16 毫秒多一点 (1 秒/ 60 = 16.66 毫秒)。但实际上，浏览器有整理工作要做，因此您的所有工作需要在 10 毫秒内完成。如果无法符合此预算，帧率将下降，并且内容会在屏幕上抖动。 此现象通常称为卡顿，会对用户体验产生负面影响。

假如你用 JavaScript 修改了 DOM，并触发样式修改，经历重排重绘最后画到屏幕上。如果这其中任意一项的执行时间过长，都会导致渲染这一帧的时间过长，平均帧率就会下降。假设这一帧花了 50 ms，那么此时的帧率为 1s / 50ms = 20fps，页面看起来就像卡顿了一样。

对于一些长时间运行的 JavaScript，我们可以使用定时器进行切分，延迟执行。

1
2
3

for (let i = 0, len = arry.length; i < len; i++) {
  process(arry[i]);
}

假设上面的循环结构由于 process() 复杂度过高或数组元素太多，甚至两者都有，可以尝试一下切分。

1
2
3
4
5
6
7
8
9

const todo = arry.concat();
setTimeout(function(){
  process(todo.shift());
  if (todo.length) {
    setTimeout(arguments.callee, 25);
  } else {
    callback(arry);
  }
}, 25);

如果有兴趣了解更多，可以查看一下高性能JavaScript第 6 章和高效前端：Web高效编程与优化实践第 3 章。

17. 使用 requestAnimationFrame 来实现视觉变化

从第 16 点我们可以知道，大多数设备屏幕刷新率为 60 次/秒，也就是说每一帧的平均时间为 16.66 毫秒。在使用 JavaScript 实现动画效果的时候，最好的情况就是每次代码都是在帧的开头开始执行。而保证 JavaScript 在帧开始时运行的唯一方式是使用 requestAnimationFrame。

1
2
3
4
5
6
7
8
9

/**
 * If run as a requestAnimationFrame callback, this
 * will be run at the start of the frame.
 */
function updateScreen(time) {
  // Make visual updates here.
}

requestAnimationFrame(updateScreen);

如果采取 setTimeout 或 setInterval 来实现动画的话，回调函数将在帧中的某个时点运行，可能刚好在末尾，而这可能经常会使我们丢失帧，导致卡顿。

18. 使用 Web Workers

Web Worker 使用其他工作线程从而独立于主线程之外，它可以执行任务而不干扰用户界面。一个 worker 可以将消息发送到创建它的 JavaScript 代码, 通过将消息发送到该代码指定的事件处理程序（反之亦然）。

Web Worker 适用于那些处理纯数据，或者与浏览器 UI 无关的长时间运行脚本。

创建一个新的 worker 很简单，指定一个脚本的 URI 来执行 worker 线程（main.js）：

1
2
3
4
5
6
7
8
9
10
11

var myWorker = new Worker('worker.js');
// 你可以通过postMessage() 方法和onmessage事件向worker发送消息。
first.onchange = function() {
  myWorker.postMessage([first.value,second.value]);
  console.log('Message posted to worker');
}

second.onchange = function() {
  myWorker.postMessage([first.value,second.value]);
  console.log('Message posted to worker');
}

在 worker 中接收到消息后，我们可以写一个事件处理函数代码作为响应（worker.js）：

1
2
3
4
5
6

onmessage = function(e) {
  console.log('Message received from main script');
  var workerResult = 'Result: ' + (e.data[0] * e.data[1]);
  console.log('Posting message back to main script');
  postMessage(workerResult);
}

onmessage处理函数在接收到消息后马上执行，代码中消息本身作为事件的data属性进行使用。这里我们简单的对这2个数字作乘法处理并再次使用postMessage()方法，将结果回传给主线程。

回到主线程，我们再次使用onmessage以响应worker回传的消息：

1
2
3
4

myWorker.onmessage = function(e) {
  result.textContent = e.data;
  console.log('Message received from worker');
}

在这里我们获取消息事件的data，并且将它设置为result的textContent，所以用户可以直接看到运算的结果。

不过在worker内，不能直接操作DOM节点，也不能使用window对象的默认方法和属性。然而你可以使用大量window对象之下的东西，包括WebSockets，IndexedDB以及FireFox OS专用的Data Store API等数据存储机制。

参考资料：

• Web Workers

19. 使用位操作

JavaScript 中的数字都使用 IEEE-754 标准以 64 位格式存储。但是在位操作中，数字被转换为有符号的 32 位格式。即使需要转换，位操作也比其他数学运算和布尔操作快得多。

取模

由于偶数的最低位为 0，奇数为 1，所以取模运算可以用位操作来代替。

1
2
3
4
5
6
7
8
9
10
11

if (value % 2) {
    // 奇数
} else {
    // 偶数
}
// 位操作
if (value & 1) {
    // 奇数
} else {
    // 偶数
}

取整

1
2
3
4
5

~~10.12 // 10
~~10 // 10
~~'1.5' // 1
~~undefined // 0
~~null // 0

位掩码

1
2
3
4

const a = 1
const b = 2
const c = 4
const options = a | b | c

通过定义这些选项，可以用按位与操作来判断 a/b/c 是否在 options 中。

1
2
3
4

// 选项 b 是否在选项中
if (b & options) {
  // ...
}

20. 不要覆盖原生方法

无论你的 JavaScript 代码如何优化，都比不上原生方法。因为原生方法是用低级语言写的（C/C++），并且被编译成机器码，成为浏览器的一部分。当原生方法可用时，尽量使用它们，特别是数学运算和 DOM 操作。

21. 降低 CSS 选择器的复杂性

(1). 浏览器读取选择器，遵循的原则是从选择器的右边到左边读取

看个示例

1
2
3

#block .text p {
    color: red;
}

1. 查找所有 P 元素。
2. 查找结果 1 中的元素是否有类名为 text 的父元素
3. 查找结果 2 中的元素是否有 id 为 block 的父元素

(2). CSS 选择器优先级

1

内联 > ID选择器 > 类选择器 > 标签选择器

根据以上两个信息可以得出结论。

1. 选择器越短越好。
2. 尽量使用高优先级的选择器，例如 ID 和类选择器。
3. 避免使用通配符 *。

最后要说一句，据我查找的资料所得，CSS 选择器没有优化的必要，因为最慢和慢快的选择器性能差别非常小。

22. 使用 flexbox 而不是较早的布局模型

在早期的 CSS 布局方式中我们能对元素实行绝对定位、相对定位或浮动定位。而现在，我们有了新的布局方式 flexbox，它比起早期的布局方式来说有个优势，那就是性能比较好。

下面的截图显示了在 1300 个框上使用浮动的布局开销：

然后我们用 flexbox 来重现这个例子：

现在，对于相同数量的元素和相同的视觉外观，布局的时间要少得多（本例中为分别 3.5 毫秒和 14 毫秒）。

不过 flexbox 兼容性还是有点问题，不是所有浏览器都支持它，所以要谨慎使用。

各浏览器兼容性：

• Chrome 29+
• Firefox 28+
• Internet Explorer 11
• Opera 17+
• Safari 6.1+ (prefixed with -webkit-)
• Android 4.4+
• iOS 7.1+ (prefixed with -webkit-)

但是在可能的情况下，至少应研究布局模型对网站性能的影响，并且采用最大程度减少网页执行开销的模型。

在任何情况下，不管是否选择 Flexbox，都应当在应用的高压力点期间尝试完全避免触发布局！

23. 使用 transform 和 opacity 属性更改来实现动画

在 CSS 中，transforms 和 opacity 这两个属性更改不会触发重排与重绘，它们是可以由合成器（composite）单独处理的属性。

24. 合理使用规则，避免过度优化

性能优化主要分为两类：

1. 加载时优化
2. 运行时优化

上述 23 条建议中，属于加载时优化的是前面 10 条建议，属于运行时优化的是后面 13 条建议。通常来说，没有必要 23 条性能优化规则都用上，根据网站用户群体来做针对性的调整是最好的，节省精力，节省时间。

在解决问题之前，得先找出问题，否则无从下手。所以在做性能优化之前，最好先调查一下网站的加载性能和运行性能。

检查加载性能

一个网站加载性能如何主要看白屏时间和首屏时间。

• 白屏时间：指从输入网址，到页面开始显示内容的时间。
• 首屏时间：指从输入网址，到页面完全渲染的时间。

将以下脚本放在 </head> 前面就能获取白屏时间。

1
2
3

<script>
  new Date() - performance.timing.navigationStart
</script>

在 window.onload 事件里执行 new Date() - performance.timing.navigationStart 即可获取首屏时间。

检查运行性能

配合 chrome 的开发者工具，我们可以查看网站在运行时的性能。

打开网站，按 F12 选择 performance，点击左上角的灰色圆点，变成红色就代表开始记录了。这时可以模仿用户使用网站，在使用完毕后，点击 stop，然后你就能看到网站运行期间的性能报告。如果有红色的块，代表有掉帧的情况；如果是绿色，则代表 FPS 很好。performance 的具体使用方法请用搜索引擎搜索一下，毕竟篇幅有限。

通过检查加载和运行性能，相信你对网站性能已经有了大概了解。所以这时候要做的事情，就是使用上述 23 条建议尽情地去优化你的网站，加油！

参考资料：

• performance.timing.navigationStart

其他参考资料

• 高性能网站建设指南
• Web性能权威指南
• 高性能JavaScript
• 高效前端：Web高效编程与优化实践

如何进行网站性能优化

雅虎 Best Practices for Speeding Up Your Web Site：

• content 方面

  1. 减少 HTTP 请求：合并文件、CSS 精灵、inline Image
  2. 减少 DNS 查询：DNS 查询完成之前浏览器不能从这个主机下载任何任何文件。方法：DNS 缓存、将资源分布到恰当数量的主机名，平衡并行下载和 DNS 查询
  3. 避免重定向：多余的中间访问
  4. 使 Ajax 可缓存
  5. 非必须组件延迟加载
  6. 未来所需组件预加载
  7. 减少 DOM 元素数量
  8. 将资源放到不同的域下：浏览器同时从一个域下载资源的数目有限，增加域可以提高并行下载量
  9. 减少 iframe 数量
  10. 不要 404

• Server 方面

  1. 使用 CDN
  2. 添加 Expires 或者 Cache-Control 响应头
  3. 对组件使用 Gzip 压缩
  4. 配置 ETag
  5. Flush Buffer Early
  6. Ajax 使用 GET 进行请求
  7. 避免空 src 的 img 标签

• Cookie 方面

  1. 减小 cookie 大小
  2. 引入资源的域名不要包含 cookie

• css 方面

  1. 将样式表放到页面顶部
  2. 不使用 CSS 表达式
  3. 使用<link>不使用@import
  4. 不使用 IE 的 Filter

• Javascript 方面

  1. 将脚本放到页面底部
  2. 将 javascript 和 css 从外部引入
  3. 压缩 javascript 和 css
  4. 删除不需要的脚本
  5. 减少 DOM 访问
  6. 合理设计事件监听器

• 图片方面

  1. 优化图片：根据实际颜色需要选择色深、压缩
  2. 优化 css 精灵
  3. 不要在 HTML 中拉伸图片
  4. 保证 favicon.ico 小并且可缓存

• 移动方面

  1. 保证组件小于 25k
  2. Pack Components into a Multipart Document

强缓存与协商缓存

浏览器缓存

当浏览器去请求某个文件的时候，服务端就在response header里面对该文件做了缓存配置。缓存的时间、缓存类型都由服务端控制

缓存优点

1. 减少不必要的数据传输，节省带宽
2. 减少服务器的负担，提升网站性能
3. 加快了客户端加载网页的速度，用户体验友好

缓存缺点

资源如果有更改,会导致客户端不及时更新就会造成用户获取信息滞后

缓存流程

浏览器第一次请求时

浏览器后续在进行请求时

从上图可以知道,浏览器缓存包括两种类型,即强缓存(本地缓存)和协商缓存,浏览器在第一次请求发生后,再次请求时

• 浏览器在请求某一资源时，会先获取该资源缓存的header信息，判断是否命中强缓存（cache-control和expires信息），若命中直接从缓存中获取资源信息，包括缓存header信息；本次请求根本就不会与服务器进行通信。

请求头信息

1
2
3
4
5
6
7

Accept: xxx
Accept-Encoding: gzip,deflate
Accept-Language: zh-cn
Connection: keep-alive
Host: xxx
Referer: xxx
User-Agent: xxx

来自缓存的响应头的信息

1
2
3
4
5
6
7
8
9

Accept-Ranges: bytes
Cache-Control: max-age= xxxx
Content-Encoding: gzip
Content-length: 3333
Content-Type: application/javascript
Date: xxx
Expires: xxx
Last-Modified: xxx
Server: 服务器

• 如果没有命中强缓存，浏览器会发送请求到服务器，请求会携带第一次请求返回的有关缓存的header字段信息（Last-Modified/If-Modified-Since和Etag/If-None-Match），由服务器根据请求中的相关header信息来比对结果是否协商缓存命中；若命中，则服务器返回新的响应header信息更新缓存中的对应header信息，但是并不返回资源内容，它会告知浏览器可以直接从缓存获取；否则返回最新的资源内容。

强缓存与协商缓存的区别，可以用下表来进行描述：

强缓存相关的header字段

强缓存上面已经介绍了，直接从缓存中获取资源而不经过服务器；与强缓存相关的header字段有两个：

1. expires: 这是http1.0时的规范；它的值为一个绝对时间的GMT格式的时间字符串，如Mon, 10 Jun 2015 21:31:12 GMT，如果发送请求的时间在expires之前，那么本地缓存始终有效，否则就会发送请求到服务器来获取资源。
2. cache-control：max-age=number: 这是http1.1时出现的header信息，主要是利用该字段的max-age值来进行判断，它是一个相对值；资源第一次的请求时间和Cache-Control设定的有效期，计算出一个资源过期时间，再拿这个过期时间跟当前的请求时间比较，如果请求时间在过期时间之前，就能命中缓存，否则就不行；cache-control除了该字段外，还有下面几个比较常用的设置值：

• no-cache: 不使用本地缓存。需要使用缓存协商，先与服务器确认返回的响应是否被更改，如果之前的响应中存在ETag，那么请求的时候会与服务端验证，如果资源未被更改，则可以避免重新下载。
• no-store: 直接禁止游览器缓存数据，每次用户请求该资源，都会向服务器发送一个请求，每次都会下载完整的资源。
• public: 可以被所有的用户缓存，包括终端用户和CDN等中间代理服务器。
• private: 只能被终端用户的浏览器缓存，不允许CDN等中继缓存服务器对其缓存。

注意：如果cache-control与expires同时存在的话，cache-control的优先级高于expires。

协商缓存相关的header字段

协商缓存都是由服务器来确定缓存资源是否可用的，所以客户端与服务器端要通过某种标识来进行通信，从而让服务器判断请求资源是否可以缓存访问，这主要涉及到下面两组header字段，这两组搭档都是成对出现的，即第一次请求的响应头带上某个字段（Last-Modified或者Etag），则后续请求则会带上对应的请求字段（If-Modified-Since或者If-None-Match），若响应头没有Last-Modified或者Etag字段，则请求头也不会有对应的字段。

1. Last-Modified/If-Modified-Since

二者的值都是GMT格式的时间字符串，具体过程：

• 浏览器第一次跟服务器请求一个资源，服务器在返回这个资源的同时，在response的header加上Last-Modified的header，这个header表示这个资源在服务器上的最后修改时间

• 浏览器再次跟服务器请求这个资源时，在request的header上加上If-Modified-Since的header，这个header的值就是上一次请求时返回的Last-Modified的值

• 服务器再次收到资源请求时，根据浏览器传过来If-Modified-Since和资源在服务器上的最后修改时间判断资源是否有变化，如果没有变化则返回304 Not Modified，但是不会返回资源内容；如果有变化，就正常返回资源内容。当服务器返回304 Not Modified的响应时，response header中不会再添加Last-Modified的header，因为既然资源没有变化，那么Last-Modified也就不会改变，这是服务器返回304时的response header

• 浏览器收到304的响应后，就会从缓存中加载资源

• 如果协商缓存没有命中，浏览器直接从服务器加载资源时，Last-Modified的Header在重新加载的时候会被更新，下次请求时，If-Modified-Since会启用上次返回的Last-Modified值

2. Etag/If-None-Match

这两个值是由服务器生成的每个资源的唯一标识字符串，只要资源有变化就这个值就会改变；其判断过程与Last-Modified/If-Modified-Since类似，与Last-Modified不一样的是，当服务器返回304 Not Modified的响应时，由于ETag重新生成过，response header中还会把这个ETag返回，即使这个ETag跟之前的没有变化。

既生Last-Modified何生Etag

你可能会觉得使用Last-Modified已经足以让浏览器知道本地的缓存副本是否足够新，为什么还需要Etag呢？HTTP1.1中Etag的出现主要是为了解决几个Last-Modified比较难解决的问题：

• 一些文件也许会周期性的更改，但是他的内容并不改变(仅仅改变的修改时间)，这个时候我们并不希望客户端认为这个文件被修改了，而重新GET；

• 某些文件修改非常频繁，比如在秒以下的时间内进行修改，(比方说1s内修改了N次)，If-Modified-Since能检查到的粒度是s级的，这种修改无法判断(或者说UNIX记录MTIME只能精确到秒)；

• 某些服务器不能精确的得到文件的最后修改时间。

这时，利用Etag能够更加准确的控制缓存，因为Etag是服务器自动生成或者由开发者生成的对应资源在服务器端的唯一标识符。

注意: Last-Modified与ETag是可以一起使用的，服务器会优先验证ETag，一致的情况下，才会继续比对Last-Modified，最后才决定是否返回304。

用户的行为对缓存的影响

强缓存如何重新加载缓存缓存过的资源

使用强缓存时，浏览器不会发送请求到服务端，根据设置的缓存时间浏览器一直从缓存中获取资源，在这期间若资源产生了变化，浏览器就在缓存期内就一直得不到最新的资源，那么如何防止这种事情发生呢？

通过更新页面中引用的资源路径，让浏览器主动放弃缓存，加载新资源。

1
2
3

<link rel="stylesheet" href="a.css?a=1.0" />
...
<div class="app">app</div>

这样每次文件改变后就会生成新的query值，这样query值不同，也就是页面引用的资源路径不同了，之前缓存过的资源就被浏览器忽略了，因为资源请求的路径变了。

HTTP 各版本特点与区别

HTTP协议到现在为止总共经历了3个版本的演化，第一个HTTP协议诞生于1989年3月。

1、HTTP 0.9

HTTP 0.9是第一个版本的HTTP协议，已过时。它的组成极其简单，只允许客户端发送GET这一种请求，且不支持请求头。由于没有协议头，造成了HTTP 0.9协议只支持一种内容，即纯文本。不过网页仍然支持用HTML语言格式化，同时无法插入图片。

HTTP 0.9具有典型的无状态性，每个事务独立进行处理，事务结束时就释放这个连接。由此可见，HTTP协议的无状态特点在其第一个版本0.9中已经成型。一次HTTP 0.9的传输首先要建立一个由客户端到Web服务器的TCP连接，由客户端发起一个请求，然后由Web服务器返回页面内容，然后连接会关闭。如果请求的页面不存在，也不会返回任何错误码。

2、HTTP 1.0

HTTP协议的第二个版本，第一个在通讯中指定版本号的HTTP协议版本，至今仍被广泛采用。相对于HTTP 0.9 增加了如下主要特性：

• 请求与响应支持头域
• 响应对象以一个响应状态行开始
• 响应对象不只限于超文本
• 开始支持客户端通过POST方法向Web服务器提交数据，支持GET、HEAD、POST方法
• （短连接）每一个请求建立一个TCP连接，请求完成后立马断开连接。这将会导致2个问题：连接无法复用，队头阻塞(head of line blocking)。连接无法复用会导致每次请求都经历三次握手和慢启动。三次握手在高延迟的场景下影响较明显，慢启动则对文件类请求影响较大。队头阻塞(head of line blocking)

3、HTTP 1.1

HTTP协议的第三个版本是HTTP 1.1，是目前使用最广泛的协议版本 。HTTP 1.1是目前主流的HTTP协议版本，因此这里就多花一些笔墨介绍一下HTTP 1.1的特性。

HTTP 1.1引入了许多关键性能优化：keepalive连接，chunked编码传输，字节范围请求，请求流水线等

Persistent Connection（keepalive连接）

允许HTTP设备在事务处理结束之后将TCP连接保持在打开的状态，以便未来的HTTP请求重用现在的连接，直到客户端或服务器端决定将其关闭为止。在HTTP1.0中使用长连接需要添加请求头 Connection: Keep-Alive，而在HTTP 1.1 所有的连接默认都是长连接，除非特殊声明不支持（ HTTP请求报文首部加上Connection: close ）。服务器端按照FIFO原则来处理不同的Request。

chunked编码传输

该编码将实体分块传送并逐块标明长度，直到长度为0块表示传输结束，这在实体长度未知时特别有用(比如由数据库动态产生的数据)

字节范围请求

HTTP1.1支持传送内容的一部分。比方说，当客户端已经有内容的一部分，为了节省带宽，可以只向服务器请求一部分。该功能通过在请求消息中引入了range头域来实现，它允许只请求资源的某个部分。在响应消息中Content-Range头域声明了返回的这部分对象的偏移值和长度。如果服务器相应地返回了对象所请求范围的内容，则响应码206（Partial Content）

断点续传

Header 字段

服务端

Accept-Ranges:表示服务器支持断点续传，并且数据传输以字节为单位

Etag:资源的唯一 tag 后端自定义，验证文件是否修改过。修改过就重新重头传输

Last-Modified:文件上次修改时间

Content-Range:返回数据范围

客户端

If-Range:服务器给的 Etag 值

Range:请求的数据范围

If-Modified-Since: 将服务器响应的 Last-Modified 保存， 下次发送可以携带，后台接受判断文件是否修改，没有可以返回 304状态码，叫客户端使用缓存数据，避免重复发出资源。

流程

注意：断点续传后台返回状态码为 206。

Pipelining（请求流水线）

其他特性

另外，HTTP 1.1还新增了如下特性：

• 请求消息和响应消息都支持Host头域：在HTTP1.0中认为每台服务器都绑定一个唯一的IP地址，因此，请求消息中的URL并没有传递主机名（hostname）。但随着虚拟主机技术的发展，在一台物理服务器上可以存在多个虚拟主机（Multi-homed Web Servers），并且它们共享一个IP地址。因此，Host头的引入就很有必要了。

• 新增了一批Request method：HTTP1.1增加了OPTIONS, PUT, DELETE, TRACE, CONNECT方法

• 缓存处理：HTTP/1.1在1.0的基础上加入了一些cache的新特性，引入了实体标签，一般被称为e-tags，新增更为强大的Cache-Control头。

4、HTTP 2.0

HTTP 2.0是下一代HTTP协议。主要特点有：

二进制分帧

HTTP 2.0最大的特点：不会改动HTTP 的语义，HTTP 方法、状态码、URI 及首部字段，等等这些核心概念上一如往常，却能致力于突破上一代标准的性能限制，改进传输性能，实现低延迟和高吞吐量。而之所以叫2.0，是在于新增的二进制分帧层。在二进制分帧层上， HTTP 2.0 会将所有传输的信息分割为更小的消息和帧，并对它们采用二进制格式的编码 ，其中HTTP1.x的首部信息会被封装到Headers帧，而我们的request body则封装到Data帧里面。

多路复用

HTTP 2.0 通信都在一个连接上完成，这个连接可以承载任意数量的双向数据流。

通过单一的 HTTP2.0连接连续发起多重请求-响应消息，即客户端和服务器可以同时发送多个请求和响应，而不用顺序一一对应。

每个数据流以HTTP消息的形式发送，HTTP消息被分为独立的帧，然后由一或多个帧组成，这些帧可以乱序发送，接收端根据这些帧的标识符号和首部将信息重新组装起来。

默认什么情况下使用同一个连接

• 同一个域名下的资源
• 不同域名但是满足两个条件：1）解析到同一个 IP；2）使用同一个证书

头部压缩

当一个客户端向相同服务器请求许多资源时，像来自同一个网页的图像，将会有大量的请求看上去几乎同样的，这就需要压缩技术对付这种几乎相同的信息。

由于头信息使用文本，没有压缩，请求时候会来回重复传递，造成流量浪费。

参考HTTP2头部压缩技术介绍

头部压缩需要支持 HTTP2的浏览器和服务器之间：

• 维护一份相同的静态字典（包含常见的头部名称，以及常见的头部名称与值的组合）
• 维护一份相同的动态字典，动态添加内容（即实际的 Header 值）
• 支持基于静态哈夫曼码表的哈夫曼编码（uffman Coding）

原理图：

总结： 通过映射表，传递对应编码和值来达到压缩。

随时复位

HTTP1.1一个缺点是当HTTP信息有一定长度大小数据传输时，你不能方便地随时停止它，中断TCP连接的代价是昂贵的。使用HTTP2的RST_STREAM将能方便停止一个信息传输，启动新的信息，在不中断连接的情况下提高带宽利用效率。

服务器端推流

Server Push。客户端请求一个资源X，服务器端判断也许客户端还需要资源Z，在无需事先询问客户端情况下将资源Z推送到客户端，客户端接受到后，可以缓存起来以备后用。

优先权和依赖

每个流都有自己的优先级别，会表明哪个流是最重要的，客户端会指定哪个流是最重要的，有一些依赖参数，这样一个流可以依赖另外一个流。优先级别可以在运行时动态改变，当用户滚动页面时，可以告诉浏览器哪个图像是最重要的，你也可以在一组流中进行优先筛选，能够突然抓住重点流。

队头阻塞以及解决办法

前言

通常我们提到队头阻塞，指的可能是TCP协议中的队头阻塞，但是HTTP1.1中也有一个类似TCP队头阻塞的问题，下面各自介绍一下。

TCP队头阻塞

队头阻塞（head-of-line blocking）发生在一个TCP分节丢失，导致其后续分节不按序到达接收端的时候。该后续分节将被接收端一直保持直到丢失的第一个分节被发送端重传并到达接收端为止。该后续分节的延迟递送确保接收应用进程能够按照发送端的发送顺序接收数据。这种为了达到完全有序而引入的延迟机制，非常有用，但也有不利之处。

假设在单个TCP连接上发送语义独立的消息，比如说服务器可能发送3幅不同的图像供Web浏览器显示。为了营造这几幅图像在用户屏幕上并行显示的效果，服务器先发送第一幅图像的一个断片，再发送第二幅图像的一个断片，然后再发送第三幅图像的一个断片；服务器重复这个过程，直到这3幅图像全部成功地发送到浏览器为止。

要是第一幅图像的某个断片内容的TCP分节丢失了，客户端将保持已到达的不按序的所有数据，直到丢失的分节重传成功。这样不仅延缓了第一幅图像数据的递送，也延缓了第二幅和第三幅图像数据的递送。

HTTP队头阻塞

上面用浏览器请求图片资源举例子，但实际上HTTP自身也有类似TCP队头阻塞的情况。要介绍HTTP队头阻塞，就需要先讲讲HTTP的管道化（pipelining）。

HTTP管道化是什么

HTTP1.1 允许在持久连接上可选的使用请求管道。这是相对于keep-alive连接的又一性能优化。在响应到达之前，可以将多条请求放入队列，当第一条请求发往服务器的时候，第二第三条请求也可以开始发送了，在高延时网络条件下，这样做可以降低网络的环回时间，提高性能。

非管道化与管道化的区别示意图

HTTP管道化产生的背景

在一般情况下，HTTP遵守“请求-响应”的模式，也就是客户端每次发送一个请求到服务端，服务端返回响应。这种模式非常容易理解，但是效率并不是那么高，为了提高速度和效率，人们做了很多尝试：

• 最简单的情况下，服务端一旦返回响应后就会把对应的连接关闭，客户端的多个请求实际上是串行发送的。
• 除此之外，客户端可以选择同时创建多个连接，在多个连接上并行的发送不同请求。但是创建更多连接也带来了更多的消耗，当前大部分浏览器都会限制对同一个域名的连接数。
• 从HTTP1.0开始增加了持久连接的概念（HTTP1.0的Keep-Alive和HTTP1.1的persistent），可以使HTTP能够复用已经创建好的连接。客户端在收到服务端响应后，可以复用上次的连接发送下一个请求，而不用重新建立连接。
• 现代浏览器大多采用并行连接与持久连接共用的方式提高访问速度，对每个域名建立并行地少量持久连接。
• 而在持久连接的基础上，HTTP1.1进一步地支持在持久连接上使用管道化（pipelining）特性。管道化允许客户端在已发送的请求收到服务端的响应之前发送下一个请求，借此来减少等待时间提高吞吐；如果多个请求能在同一个TCP分节发送的话，还能提高网络利用率。但是因为HTTP管道化本身可能会导致队头阻塞的问题，以及一些其他的原因，现代浏览器默认都关闭了管道化。

HTTP管道化的限制

1. 管道化要求服务端按照请求发送的顺序返回响应（FIFO），原因很简单，HTTP请求和响应并没有序号标识，无法将乱序的响应与请求关联起来。
2. 客户端需要保持未收到响应的请求，当连接意外中断时，需要重新发送这部分请求。
3. 只有幂等的请求才能进行管道化，也就是只有GET和HEAD请求才能管道化，否则可能会出现意料之外的结果

HTTP管道化引起的请求队头阻塞

前面提到HTTP管道化要求服务端必须按照请求发送的顺序返回响应，那如果一个响应返回延迟了，那么其后续的响应都会被延迟，直到队头的响应送达。

如何解决队头阻塞

如何解决HTTP队头阻塞

对于HTTP1.1中管道化导致的请求/响应级别的队头阻塞，可以使用HTTP2解决。HTTP2不使用管道化的方式，而是引入了帧、消息和数据流等概念，每个请求/响应被称为消息，每个消息都被拆分成若干个帧进行传输，每个帧都分配一个序号。每个帧在传输是属于一个数据流，而一个连接上可以存在多个流，各个帧在流和连接上独立传输，到达之后在组装成消息，这样就避免了请求/响应阻塞。

当然，即使使用HTTP2，如果HTTP2底层使用的是TCP协议，仍可能出现TCP队头阻塞。

如何解决TCP队头阻塞

TCP中的队头阻塞的产生是由TCP自身的实现机制决定的，无法避免。想要在应用程序当中避免TCP队头阻塞带来的影响，只有舍弃TCP协议。

比如google推出的QUIC协议，在某种程度上可以说避免了TCP中的队头阻塞，因为它根本不使用TCP协议，而是在UDP协议的基础上实现了可靠传输。而UDP是面向数据报的协议，数据报之间不会有阻塞约束。

此外还有一个SCTP（流控制传输协议），它是和TCP、UDP在同一层次的传输协议。SCTP的多流特性也可以尽可能的避免队头阻塞的情况。

总结

从TCP队头阻塞和HTTP队头阻塞的原因我们可以看到，出现队头阻塞的原因有两个：

1. 独立的消息数据都在一个链路上传输，也就是有一个“队列”。比如TCP只有一个流，多个HTTP请求共用一个TCP连接
2. 队列上传输的数据有严格的顺序约束。比如TCP要求数据严格按照序号顺序，HTTP管道化要求响应严格按照请求顺序返回

所以要避免队头阻塞，就需要从以上两个方面出发，比如quic协议不使用TCP协议而是使用UDP协议，SCTP协议支持一个连接上存在多个数据流等等。

QUIC

QUIC（Quick UDP Internet Connection）是谷歌制定的一种互联网传输层协议，它基于UDP传输层协议，同时兼具TCP、TLS、HTTP/2等协议的可靠性与安全性，可以有效减少连接与传输延迟，更好地应对当前传输层与应用层的挑战。

QUIC的由来：为什么是UDP而非TCP？

UDP和TCP都属于传输层协议。TCP是面向连接的，更强调的是传输的可靠性，通过TCP连接传送的数据，无差错，不丢失，不重复，按序到达，但是因为TCP在传递数据之前会有三次握手来建立连接，所以效率低、占用系统的CPU、内存等硬件资源较高；而UDP的无连接的（即发送数据之前不需要建立连接），只需要知道对方地址即可发送数据，具有较好的实时性，工作效率比TCP高，占用系统资源比TCP少，但是在数据传递时，如果网络质量不好，就会很容易丢包。

我们知道，大部分Web平台的数据传输都基于TCP协议。实际上，TCP在设计之初，网络环境复杂、丢包率高、网速差，所以TCP可以完美解决可靠性的问题。而如今的网络环境和网速都已经取得了巨大的改善，网络传输可靠性已经不再是棘手的问题。另外，TCP还有一个很大的问题是更新非常困难。这是因为：TCP网络协议栈的实现依赖于系统内核更新，一旦系统内核更新，终端设备、中间设备的系统更新都会非常缓慢，迭代需要花费几年甚至十几年的时间，这显然跟不上当今互联网的发展速度。所以现在解法就是，抛弃TCP而使用UDP，来实现低延迟的传输需求。

为了结合两者优点，谷歌公司推出了QUIC，它的升级不依赖于系统内核，只需要Client和Server端更新到指定版本。如此一来，基于UDP的QUIC就能月更甚至周更，很好的解决了TCP部署和更新的困难，更灵活地实现部署和更新。

为什么要用QUIC？

1. 建连延迟低

网民传统TCP三次握手+TLS1~2RTT握手+http数据，基于TCP的HTTPS一次建连至少需要2~3个RTT，而QUIC基于UDP，完整握手只需要1RTT乃至0RTT，可以显著降低延迟。

2. 安全又可靠

QUIC具备TCP、TLS、HTTPS/2等协议的安全、可靠性的特点，通过提供安全功能（如身份验证和加密）来实现加密传输，这些功能由传输协议本身的更高层协议（如TLS）来实现。

3. 改造灵活

QUIC在应用程序层面就能实现不同的拥塞控制算法，不需要操作系统和内核支持，这相比于传统的TCP协议改造灵活性更好。

4. 改进的拥塞控制

QUIC主要实现了TCP的慢启动、拥塞避免、快重传、快恢复。在这些拥塞控制算法的基础上改进，例如单调递增的 Packet Number，解决了重传的二义性，确保RTT准确性，减少重传次数。

5. 无队头阻塞的多路复用

HTTP2实现了多路复用，可以在一条TCP流上并发多个HTTP请求，但基于TCP的HTTP2在传输层却有个问题，TCP无法识别不同的HTTP2流，实际收数据仍是一个队列，当后发的流先收到时，会因前面的流未到达而被阻塞。QUIC一个connection可以复用传输多个stream，每个stream之间都是独立的，一个stream的丢包不会影响到其他stream的接收和处理。

综上所述，QUIC具有众多优点，它融合了UDP协议的速度、性能与TCP的安全与可靠，大大优化了互联网传输体验。

作为提升终端用户访问效率的CDN服务，其节点之间存在大量数据互通，节点之间的网络连接、传输架构等因素都会对CDN服务质量产生影响。而将QUIC应用在CDN系统中，CDN用户开启QUIC功能后，系统将遵循QUIC协议进行用户IP请求处理，既能满足安全传输的需求，也能提升传输效率。

QUIC对客户端的要求

• 如果您使用Chrome浏览器，则只支持QUIC协议Q43版本。当前阿里云CDN的QUIC协议是Q39版本，不支持直接对阿里云CDN发起QUIC请求。
• 如果您使用自研App，则App必须集成支持QUIC协议的网络库，例如：lsquic-client或cronet网络库。

QUIC应用场景

1. 图片小文件：明显降低文件下载总耗时，提升效率
2. 视频点播：提升首屏秒开率，降低卡顿率，提升用户观看体验
3. 动态请求：适用于动态请求，提升访问速度，如网页登录、交易等交互体验提升
4. 弱网环境：在丢包和网络延迟严重的情况下仍可提供可用的服务，并优化卡顿率、请求失败率、秒开率、提高连接成功率等传输指标
5. 大并发连接：连接可靠性强，支持页面资源数较多、并发连接数较多情况下的访问速率提升
6. 加密连接：具备安全、可靠的传输性能

HTTP协议

一面中，如果有笔试，考HTTP协议的可能性较大。

1. 前言

一面要讲的内容：

• HTTP协议的主要特点
• HTTP报文的组成部分
• HTTP方法
• get 和 post的区别
• HTTP状态码
• 什么是持久连接
• 什么是管线化

二面要讲的内容；

• 缓存
• CSRF攻击
• TSL 协商

2. HTTP协议的主要特点

• 简单快速
• 灵活
• 无连接
• 无状态

通常我们要答出以上四个内容。如果实在记不住，一定要记得后面的两个：无连接、无状态。

我们分别来解释一下。

2.1 简单快速

简单：每个资源（比如图片、页面）都通过 url 来定位。这都是固定的，在http协议中，处理起来也比较简单，想访问什么资源，直接输入url即可。

2.2 灵活

http协议的头部有一个数据类型，通过http协议，就可以完成不同数据类型的传输。

2.3 无连接

连接一次，就会断开，不会继续保持连接。

2.4 无状态

客户端和服务器端是两种身份。第一次请求结束后，就断开了，第二次请求时，服务器端并没有记住之前的状态，也就是说，服务器端无法区分客户端是否为同一个人、同一个身份。

有的时候，我们访问网站时，网站能记住我们的账号，这个是通过其他的手段（比如 session）做到的，并不是http协议能做到的。

3 HTTP报文的组成部分

在回答此问题时，我们要按照顺序回答：

• 先回答的是，http报文包括：请求报文和响应报文。
• 再回答的是，每个报文包含什么部分。
• 最后回答，每个部分的内容是什么

3.1 请求报文包括：

• 请求行：包括请求方法、请求的url、http协议及版本。
• 请求头：一大堆的键值对。
• 空行指的是：当服务器在解析请求头的时候，如果遇到了空行，则表明，后面的内容是请求体
• 请求体：数据部分。

3.2 响应报文包括：

• 状态行：http协议及版本、状态码及状态描述。
• 响应头
• 空行
• 响应体

4 HTTP方法

包括：

• GET：获取资源
• POST：传输资源
• put：更新资源
• DELETE：删除资源
• HEAD：获得报文首部

HTTP方法有很多，但是上面这五个方法，要求在面试时全部说出来，不要漏掉。

• get 和 post` 比较常见。
• put 和 delete 在实际应用中用的很少。况且，业务中，一般不删除服务器端的资源。
• head 可能偶尔用的到。

5 get 和 post的区别

• 区别有很多，如果记不住，面试时，至少要任意答出其中的三四条。
• 有一点要强调，get是相对不隐私的，而post是相对隐私的。

我们大概要记住以下几点：

1. 浏览器在回退时，get 不会重新请求，但是post会重新请求。【重要】
2. get请求会被浏览器主动缓存，而post不会。【重要】
3. get请求的参数，会报保留在浏览器的历史记录里，而post不会。做业务时要注意。为了防止CSRF攻击，很多公司把get统一改成了post。
4. get请求在url中传递的参数有大小限制，基本是2kb`，不同的浏览器略有不同。而post没有注意。
5. get的参数是直接暴露在url上的，相对不安全。而post是放在请求体中的。

6 http状态码

http状态码分类：

常见的http状态码：

部分解释：

• 206的应用：range指的是请求的范围，客户端只请求某个大文件里的一部分内容。比如说，如果播放视频地址或音频地址的前面一部分，可以用到206。
• 301：重定向（永久）。
• 302：重定向（临时）。
• 304：我这个服务器告诉客户端，你已经有缓存了，不需要从我这里取了。

• 400和401用的不多,未授权。403指的是请求被拒绝。404指的是资源不存在。

7 持久链接/http长连接

如果你能答出持久链接，这是面试官很想知道的一个点。

• 轮询：http1.0中，客户端每隔很短的时间，都会对服务器发出请求，查看是否有新的消息，只要轮询速度足够快，例如1秒，就能给人造成交互是实时进行的印象。这种做法是无奈之举，实际上对服务器、客户端双方都造成了大量的性能浪费。
• 长连接：HTTP1.1中，通过使用Connection:keep-alive进行长连接，。客户端只请求一次，但是服务器会将继续保持连接，当再次请求时，避免了重新建立连接。

注意，HTTP 1.1默认进行持久连接。在一次 TCP 连接中可以完成多个 HTTP 请求，但是对每个请求仍然要单独发 header，Keep-Alive不会永久保持连接，它有一个保持时间，可以在不同的服务器软件（如Apache）中设定这个时间。

8 长连接中的管线化

如果能答出管线化，则属于加分项。

8.1 管线化的原理

长连接时，默认的请求这样的：

1

请求1 --> 响应1 -->请求2 --> 响应2 --> 请求3 --> 响应3

管线化就是，我把现在的请求打包，一次性发过去，你也给我一次响应回来。

8.2 管线化的注意事项

面试时，不会深究管线化。如果真要问你，就回答：“我没怎么研究过，准备回去看看~”

9 TLS 协商

Transport Layer Security (TLS) 是一个为计算机网络提供通信安全的加密协议。它广泛应用于大量应用程序，其中之一即浏览网页。网站可以使用 TLS 来保证服务器和网页浏览器之间的所有通信安全。

整个 TLS 握手过程包含以下几个步骤：

• 客户端向服务器发送 『Client hello』 信息，附带着客户端随机值(random_C)和支持的加密算法组合。
• 服务器返回给客户端 『Server hello』信息，附带着服务器随机值(random_S)，以及选择一个客户端发送过来加密算法。
• 服务器返回给客户端认证证书及或许要求客户端返回一个类似的证书，认证证书里面携带服务端的公钥信息。
• 服务器返回『Server hello done』信息。
• 如果服务器要求客户端发送一个证书，客户端进行发送。
• 客户端创建一个随机的 Pre-Master 密钥然后使用服务器证书中的公钥来进行加密，向服务器发送加密过的 Pre-Master 密钥。
• 服务器收到 Pre-Master 密钥。服务器和客户端各自生成基于 Pre-Master 密钥的主密钥和会话密钥。两个明文随机数 random_C 和 random_S 与自己计算产生的 pre-master，计算得到协商密钥enc_key=Fuc(random_C, random_S, pre-master)
• 客户端给服务器发送一个 『Change cipher spec』的通知，表明客户端将会开始使用协商密钥和加密算法进行加密通信。
• 客户端也发送了一个 『Client finished』的消息。
• 服务器接收到『Change cipher spec』的通知然后使用协商密钥和加密算法进行加密通信。
• 服务器返回客户端一个 『Server finished』消息。
• 客户端和服务器现在可以通过建立的安全通道来交换程序数据。所有客户端和服务器之间发送的信息都会使用会话密钥进行加密。

每当发生任何验证失败的时候，用户会收到警告。比如服务器使用自签名的证书。

WebRTC的优缺点

WebRTC，即网页即时通信（Web Real-Time Communication），是一个支持网页浏览器进行实时语音对话或视频对话的API。

目前几乎所有主流浏览器都支持了 WebRTC，越来越多的公司正在使用 WebRTC 并且将其加到自己的应用程序中。在浏览器端，依赖于浏览器获取音视频的能力，以及强大的网页上的渲染能力，就能够为高清的通信体验打下基础。同时，相比移动端来说，屏幕比较大，视窗选择也比较灵活。

优点

1. 方便。对于用户来说，在WebRTC出现之前想要进行实时通信就需要安装插件和客户端，但是对于很多用户来说，插件的下载、软件的安装和更新这些操作是复杂而且容易出现问题的，现在WebRTC技术内置于浏览器中，用户不需要使用任何插件或者软件就能通过浏览器来实现实时通信。对于开发者来说，在Google将WebRTC开源之前，浏览器之间实现通信的技术是掌握在大企业手中，这项技术的开发是一个很困难的任务，现在开发者使用简单的HTML标签和JavaScript API就能够实现Web音/视频通信的功能。

2. 免费。虽然WebRTC技术已经较为成熟，其集成了最佳的音/视频引擎，十分先进的codec，但是Google对于这些技术不收取任何费用。

3. 强大的打洞能力。WebRTC技术包含了使用STUN、ICE、TURN、RTP-over-TCP的关键NAT和防火墙穿透技术，并支持代理。

缺点

1. 缺乏服务器方案的设计和部署。

2. 传输质量难以保证。WebRTC的传输设计基于P2P，难以保障传输质量，优化手段也有限，只能做一些端到端的优化，难以应对复杂的互联网环境。比如对跨地区、跨运营商、低带宽、高丢包等场景下的传输质量基本是靠天吃饭，而这恰恰是国内互联网应用的典型场景。

3. WebRTC比较适合一对一的单聊，虽然功能上可以扩展实现群聊，但是没有针对群聊，特别是超大群聊进行任何优化。

4. 设备端适配，如回声、录音失败等问题层出不穷。这一点在安卓设备上尤为突出。由于安卓设备厂商众多，每个厂商都会在标准的安卓框架上进行定制化，导致很多可用性问题（访问麦克风失败）和质量问题（如回声、啸叫）。

5. 对Native开发支持不够。WebRTC顾名思义，主要面向Web应用，虽然也可以用于Native开发，但是由于涉及到的领域知识（音视频采集、处理、编解码、实时传输等）较多，整个框架设计比较复杂，API粒度也比较细，导致连工程项目的编译都不是一件容易的事。

EventSource和轮询的优缺点

EventSource

简介

EventSource 是服务器推送的一个网络事件接口。一个EventSource实例会对HTTP服务开启一个持久化的连接，以text/event-stream 格式发送事件, 会一直保持开启直到被要求关闭。

一旦连接开启，来自服务端传入的消息会以事件的形式分发至你代码中。如果接收消息中有一个事件字段，触发的事件与事件字段的值相同。如果没有事件字段存在，则将触发通用事件。

与 WebSockets,不同的是，服务端推送是单向的。数据信息被单向从服务端到客户端分发. 当不需要以消息形式将数据从客户端发送到服务器时，这使它们成为绝佳的选择。例如，对于处理社交媒体状态更新，新闻提要或将数据传递到客户端存储机制（如IndexedDB或Web存储）之类的，EventSource无疑是一个有效方案。

• EventSource（Server-sent events）简称SSE用于向服务端发送事件，它是基于http协议的单向通讯技术，以text/event-stream格式接受事件，如果不关闭会一直处于连接状态，直到调用EventSource.close()方法才能关闭连接；

• EvenSource本质上也就是XHR-streaming只不过浏览器给它提供了标准的API封装和协议。

• 由于EventSource是单向通讯，所以只能用来实现像股票报价、新闻推送、实时天气这些只需要服务器发送消息给客户端场景中。

• EventSource虽然不支持双向通讯，但是在功能设计上他也有一些优点比如可以自动重连接,event IDs,以及发送随机事件的等功能

EventSource案例浏览器端代码如下所示:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20

// 实例化 EventSource 参数是服务端监听的路由
var source = new EventSource('http://localhost:3000');

source.onopen = function (event) { // 与服务器连接成功回调
  console.log('成功与服务器连接');
}

// 监听从服务器发送来的所有没有指定事件类型的消息(没有event字段的消息)
source.onmessage = function (event) { // 监听未命名事件
  console.log('未命名事件', event.data);
}

source.onerror = function (error) { // 监听错误
  console.log('错误');
}

// 监听指定类型的事件（可以监听多个）
source.addEventListener("ping", function (event) {
  console.log("ping", event.data)
})

服务器端

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23

const http = require('http');

http.createServer((req, res) => {
  res.writeHead(200, {
    'Content-Type' :'text/event-stream',
    'Access-Control-Allow-Origin':'*'
  });

  let i = 0;
  const timer = setInterval(()=>{
    const date = {date:new Date()}
    var content ='event: ping\n'+"data:"+JSON.stringify(date)+"" +"\n\n";
    res.write(content);
  },1000)

  res.connection.on("close", function(){
    res.end();
    clearInterval(timer);
    console.log("Client closed connection. Aborting.");
  });

}).listen(3000);
console.log('server is run http://localhost:3000');

EventSource规范字段

• event: 事件类型，如果指定了该字段，则在客户端接收到该条消息时，会在当前的EventSource对象上触发一个事件，事件类型就是该字段的字段值，你可以使用addEventListener()方法在当前EventSource对象上监听任意类型的命名事件，如果该条消息没有event字段，则会触发onmessage属性上的事件处理函数。
• data: 消息的数据字段，如果该消息包含多个data字段，则客户端会用换行符把他们连接成一个字符串来处理
• id: 事件ID，会成为当前EventSource对象的内部属性“最后一个事件ID”的属性值；
• retry: 一个整数值，指定了重新连接的时间（单位为毫秒），如果该字段不是整数，则会被忽略。

EventSource属性

• EventSource.onerror: 是一个 EventHandler，当发生错误时被调用，并且在此对象上派发 error 事件。
• EventSource.onmessage: 是一个 EventHandler，当收到一个 message事件，即消息来自源头时被调用。
• EventSource.onopen: 是一个 EventHandler，当收到一个 open 事件，即连接刚打开时被调用。
• EventSource.readyState(只读): 一个 unsigned short 值，代表连接状态。可能值是CONNECTING (0), OPEN (1), 或者 CLOSED (2)。
• EventSource.url(只读): 一个DOMString，代表源头的URL。

EventSource 通讯过程

缺点

1. 因为是服务器->客户端的，所以它不能处理客户端请求流
2. 因为是明确指定用于传输UTF-8数据的，所以对于传输二进制流是低效率的，即使你转为base64的话，反而增加带宽的负载，得不偿失。

轮询

短轮询(Polling)

是一种简单粗暴，同样也是一种效率低下的实现“实时”通讯方案，这种方案的原理就是定期向服务器发送请求，主动拉取最新的消息队列。

客户端代码：

1
2
3
4
5
6
7
8
9
10

function Polling() {
  fetch(url).then(data => {
    // somthing
  }).catch(err => {
    console.error(err);
  });
}

//每5s执行一次
setInterval(polling, 5000);

这种轮询方式比较适合服务器信息定期更新的场景，如天气预报股票行情等，每隔一段时间会进行更新，且轮询间隔的服务器更新频率保持一致是比较理想的方式，但很多多时候会因网络或者服务器出现阻塞早场事件间隔不一致。

优点：

• 可以看到实现非常简单，它的兼容性也比较好的只要支持http协议就可以用这种方式实现

缺点：

• 资源浪费: 比如轮询的间隔小于服务器信息跟新频率，会浪费很多HTTP请求，消耗宝贵的CPU时间和带宽。

• 容易导致请求轰炸: 例如当服务器负载比较高时，第一个请求还没有处理完，这时第三、第四个请求接踵而来，无用的额外请求对服务器端进行了轰炸。

长轮询(Long Polling)

这是一种优化的轮询方式，称为长轮询，sockjs就是使用的这种轮询方式，长轮询值的是浏览器发送一个请求到服务器，服务器只有在有可用的新数据时才会响应。

客户端代码:

1
2
3
4
5
6
7
8
9

function LongPolling() {
    fetch(url).then(data => {
        LongPolling();
    }).catch(err => {
        LongPolling();
        console.log(err);
    });
}
LongPolling();

客户端向服务器发送一个消息获取请求时，服务器会将当前的消息队列返回给客户端，然后关闭连接。当消息队列为空的时，服务器不会立即关闭连接，而是等待指定的时间间隔，如果在这个时间间隔内没有新的消息，则由客户端主动超时关闭连接。

相比Polling，客户端的轮询请求只有在上一个请求连接关闭后才会重新发起。这就解决了Polling的请求轰炸问题。服务器可以控制的请求时序，因为在服务器未响应之前，客户端不会发送额为的请求。

优点:

• 长轮询和短轮询比起来，明显减少了很多不必要的http请求次数，相比之下节约了资源。

缺点:

• 连接挂起也会导致资源的浪费。

EventSource VS 轮询

总结

通过对上面两种对通讯技术比较，可以从不同的角度考虑；

• 兼容性: 短轮询 > 长轮询 > EventSource
• 性能: EvenSource > 长轮询 > 短轮询
• 服务端推送: EventSource > 长连接 （短轮询基本不考虑）

WebSocket 是什么原理？为什么可以实现持久连接？

WebSocket 机制

以下简要介绍一下WebSocket的原理及运行机制。

WebSocket是HTML5下一种新的协议。它实现了浏览器与服务器全双工通信，能更好的节省服务器资源和带宽并达到实时通讯的目的。它与HTTP一样通过已建立的TCP连接来传输数据，但是它和HTTP最大不同是：

• WebSocket是一种双向通信协议。在建立连接后，WebSocket服务器端和客户端都能主动向对方发送或接收数据，就像Socket一样；
• WebSocket需要像TCP一样，先建立连接，连接成功后才能相互通信。

传统HTTP客户端与服务器请求响应模式如下图所示：

WebSocket模式客户端与服务器请求响应模式如下图：

上图对比可以看出，相对于传统HTTP每次请求-响应都需要客户端与服务端建立连接的模式，WebSocket是类似Socket的TCP长连接通讯模式。一旦WebSocket连接建立后，后续数据都以帧序列的形式传输。在客户端断开WebSocket连接或Server端中断连接前，不需要客户端和服务端重新发起连接请求。在海量并发及客户端与服务器交互负载流量大的情况下，极大的节省了网络带宽资源的消耗，有明显的性能优势，且客户端发送和接受消息是在同一个持久连接上发起，实时性优势明显。

相比HTTP长连接，WebSocket有以下特点：

• 是真正的全双工方式，建立连接后客户端与服务器端是完全平等的，可以互相主动请求。而HTTP长连接基于HTTP，是传统的客户端对服务器发起请求的模式。
• HTTP长连接中，每次数据交换除了真正的数据部分外，服务器和客户端还要大量交换HTTP header，信息交换效率很低。Websocket协议通过第一个request建立了TCP连接之后，之后交换的数据都不需要发送 HTTP header就能交换数据，这显然和原有的HTTP协议有区别所以它需要对服务器和客户端都进行升级才能实现（主流浏览器都已支持HTML5）。此外还有 multiplexing、不同的URL可以复用同一个WebSocket连接等功能。这些都是HTTP长连接不能做到的。

WebSocket协议的原理

与http协议一样，WebSocket协议也需要通过已建立的TCP连接来传输数据。具体实现上是通过http协议建立通道，然后在此基础上用真正的WebSocket协议进行通信，所以WebSocket协议和http协议是有一定的交叉关系的。

下面是WebSocket协议请求头：

其中请求头中重要的字段：

1
2
3
4
5
6
7
8
9

Connection:Upgrade

Upgrade:websocket

Sec-WebSocket-Extensions:permessage-deflate; client_max_window_bits

Sec-WebSocket-Key:mg8LvEqrB2vLpyCNnCJV3Q==

Sec-WebSocket-Version:13

1. Connection和Upgrade字段告诉服务器，客户端发起的是WebSocket协议请求
2. Sec-WebSocket-Extensions表示客户端想要表达的协议级的扩展
3. Sec-WebSocket-Key是一个Base64编码值，由浏览器随机生成
4. Sec-WebSocket-Version表明客户端所使用的协议版本

而得到的响应头中重要的字段：

1
2
3
4
5

Connection:Upgrade

Upgrade:websocket

Sec-WebSocket-Accept:AYtwtwampsFjE0lu3kFQrmOCzLQ=

1. Connection和Upgrade字段与请求头中的作用相同

2. Sec-WebSocket-Accept表明服务器接受了客户端的请求

1

Status Code:101 Switching Protocols

并且http请求完成后响应的状态码为101，表示切换了协议，说明WebSocket协议通过http协议来建立运输层的TCP连接，之后便与http协议无关了。

WebSocket协议的优缺点

优点：

• WebSocket协议一旦建议后，互相沟通所消耗的请求头是很小的
• 服务器可以向客户端推送消息了

缺点：

• 少部分浏览器不支持，浏览器支持的程度与方式有区别

WebSocket协议的应用场景

• 即时聊天通信
• 多玩家游戏
• 在线协同编辑/编辑
• 实时数据流的拉取与推送
• 体育/游戏实况
• 实时地图位置

一个使用WebSocket应用于视频的业务思路如下：

• 使用心跳维护websocket链路，探测客户端端的网红/主播是否在线
• 设置负载均衡7层的proxy_read_timeout默认为60s
• 设置心跳为50s，即可长期保持Websocket不断开

网络相关

1.1 DNS 预解析

• DNS 解析也是需要时间的，可以通过预解析的方式来预先获得域名所对应的 IP