[[399853]]

前言

我始終覺得博客不是想什么就寫什么的，一定是有某一個契機，使得我們對某一個點或者方向有深度探索繼續學習或者加深印象的過程，并有體系的將這個過程記錄下來，昨天其實就在寫博客了，寫的點是關于XMLHttpRequest的，是因為之前跟一個同學談及到了它，以及相關的網絡請求標準AJAX、Fetch、axios等，最近，因為在等待論文盲審的過程中，有了寫書的想法，于是便匆匆開始了寫書之旅，一本關于Node的原理及實踐應用的書，暫取名《Node雜談》，目前已經寫了61頁了，但我是個善變的人，說不定過幾天我就不想寫了😄，但希望自己能堅持用半年到一年的時間完成這本可能沒啥用的書。接下來開始自己的博客，先談談自己對XHR及相關標準，然后談談操作系統的I/0及Node的異步I/0。

網絡請求

XHR背景

網絡請求的這幾個標準和庫，其實沒有必要開一片博客來記錄下自己的想法和理解的，偶然和和同學說道這些網絡交互的標準或者是庫，有些歧義，我又去網上看看了一些人的博客想著是否可以糾正自己可能會是錯誤的理解，然后我就在網上不斷翻閱，按照我自己對自己寫的博客的標準來定義，我查閱到的這些博客都是一些不能入眼的內容，只是互聯網沒有自動垃圾回收的機制，無可厚非，我的理解或者我的博客一樣也會被別人理解為www的設計缺陷，但至少我愿意把一件事講清楚，給自己講清楚。最近開始籌劃并著手寫一本自己對于Node的理解及相關實戰項目的書，談及ajax時候，我寫了這樣一段話：

我在這段話中大肆吐槽了所謂的模塊或者框架用的很六的使用者。如果你沒有看過fetch的源碼實現，或者說你并沒有看過axios的源碼實現，你連攔截器是怎么定義的都不知道，你用的再六又能怎么樣尼?希望這段話在勉勵我自己的同時，也能觸及到看見我博客的志同道合的朋友。接下來我談一談我自己對于ajax、fetch、axios的個人理解。

ajax

ajax全稱是啥，看到這你能在腦海中反應出來么?異步的javascript和xml，英文：Asynchronous JavaScript and XML，是利用瀏覽器已有標準重新組合后的新技術標準，應該可以說ajax是web1.0到web2.0跨越的重大功臣之一。為什么這么說，ajax最直觀的特點就是通過請求與響應來局部刷新頁面，而不是說之前的必須通過表單進行一次整體的請求與響應，刷新整個頁面，浪費網絡資源，用戶體驗也極差。ajax有缺點么?或者說有哪些在以前全局刷新情況下能夠很容易實現的功能但是使用ajax后就變得比較繁雜尼?以下4點是我在網上尋到并深有同感的幾點，如下：

a. AJAX干掉了Back和History功能，即對瀏覽器機制的破壞

b. AJAX的安全問題

c. 對搜索引擎支持較弱

d. 違背URL和資源定位的初衷

現代瀏覽器的實現主要依靠XMLHttpRequest對象，因為瀏覽器的版本不同，帶來不對于XHR的兼容問題，那，看到這里，你可以立馬動手實現一個最原始的AJAX么?

function loadXMLDoc() 
{ 
 var xmlhttp; 
 if (window.XMLHttpRequest) 
 { 
  //  IE7+, Firefox, Chrome, Opera, Safari 瀏覽器執行代碼 
  xmlhttp=new XMLHttpRequest(); 
 } 
 else 
 { 
  // IE6, IE5 瀏覽器執行代碼 
  xmlhttp=new ActiveXObject("Microsoft.XMLHTTP"); 
 } 
 xmlhttp.onreadystatechange=function() 
 { 
  if (xmlhttp.readyState==4 && xmlhttp.status==200) 
  { 
   // 返回數據處理 
   document.getElementById("myDiv").innerHTML=xmlhttp.responseText; 
  } 
 } 
 
 // 請求發送 true 異步，肯定異步啊，你要同步？？？ 
 xmlhttp.open("GET","/try/ajax/ajax_info.txt",true); 
 xmlhttp.send(); 
} 

代碼我肯定不會一行一行講解的，這沒啥，就很簡單，但是onreadystatechange中的readyState以及status是值得關注的，其記錄著ajax的運行狀態以及響應狀態。onreadystatechange：每當 readyState 屬性改變時，就會調用該函數。readyState：存有XMLHttpRequest的狀態。從 0 到 4 發生變化，值對應的狀態如下：

0: 請求未初始化

1: 服務器連接已建立

2: 請求已接收

3: 請求處理中

4: 請求已完成，且響應已就緒

status：記錄著響應的狀態 200: "OK"、404: 未找到頁面等等

promise

接下來談談promise這個對象，用來干啥的，簡單說就是對JS異步編程的一種能力加持，讓異步代碼的編寫及閱讀不再那么的惡心人。我寫一段惡心人的簡單實例：

setTimeout(()=>{ 
 setTimeout(()=>{ 
  setTimroiut(()=>{ 
   ...... 
  },1000) 
    },1000) 
},1000) 

你可能會說，啊這還好呀，這有啥。這只是我的一個簡單舉例，當在真實場景下無論前后端，不斷的異步嵌套的時候，你定會抓狂。那么，Promise是如何改善這種問題的尼?

將Promise理解為狀態扭轉機，類似于我們在學習編譯原理里面的有限狀態自動機，會由一個狀態過渡到另一個狀態，并且狀態是會結束的，有終點的。promise具有三種狀態，pending、resolve、reject。狀態的扭轉跟隨著兩過程：

pending ----> resolve

pending ----> reject

也就是從處理開始等待到成功處理或者從處理開始等待待處理失敗的過程。來看我直接markdown手擼把上面的嵌套promise化，讓代碼看起來更加直觀，流程更加清晰，讓其順序執行

console.time(); 
new Promise((resolve,reject)=>{ 
 setTimeout(()=>{ 
  if(Math.random() > 0.5){ 
   resolve("timer1"); 
  }else{ 
   reject("timer1 error"); 
  } 
   
 },1000) 
}).then((data)=>{ 
 console.log(data); 
 return new Promise((resolve, reject)=>{ 
  setTimeout(()=>{ 
   if(Math.random() > 0.5){ 
    resolve("timer2"); 
   }else{ 
    reject("timer2 error"); 
   } 
  },2000) 
 }) 
  
}).then((data)=>{ 
 console.log(data); 
 return new Promise((resolve, reject)=>{ 
  setTimeout(()=>{ 
   if(Math.random() > 0.5){ 
    resolve("timer3"); 
   }else{ 
    reject("timer3 error"); 
   } 
  },2000) 
 }) 
}).catch((err)=>{ 
 console.log(err); 
}) 
console.timeEnd() 

如果你的運氣夠好，每次都能random在0.5以下，那你就能看到 timer1，timer2，運氣不好直接就timer1 error了。為什么我在每個then里面都new了promise???感到奇怪?那就去看看mdn，then需要返回一個peomise對象。

promise還提供了race、all等靜態方法，用于串行或者并行執行，需要的自己下來看看，你也可以試試手擼一個promise，那你就很牛了。

fetch

講到了fetch，我說fetch其實就是ajax加一層promise的封裝，你贊同么?如果你贊同并且說這是一種polyfill，那我覺得你是完全懂fetch的使用方法并且明了其實現過程的，與其說fetch是promise對ajax進行了封裝，說的更準確一些的就是fetch是和ajax一樣同樣使用XMLHTTPRequest對象實現的各種http請求，然后使用promise進行了包裝使用.then.catch實現調用，但是其又與ajax稍有不同，為什么尼?因為其有屬于自己的實現方案，fetch的源碼，一共500多行，重點在其實現的幾個對象：Headers, Body, Request, Response，根據這幾個對象的命名就可以知道是對http結構及請求響應過程中的數據及方法的封裝，最后進行fetch方法的封裝。網上看到一個博主放了一段簡化的代碼，如下：

(function (self) { 
  'use strict'; 
  if (self.fetch) { 
     return 
  } 
  
  // 封裝的 Headers，支持的方法參考https://developer.mozilla.org/en-US/docs/Web/API/Headers 
  function Headers(headers) { 
    ...... 
  }   
  
  //方法參考：https://developer.mozilla.org/en-US/docs/Web/API/Body 
  function Body() { 
    ...... 
  } 
  
  // 請求的Request對象 ，https://developer.mozilla.org/en-US/docs/Web/API/Request 
  // cache,context,integrity,redirect,referrerPolicy 在MDN定義中是存在的 
  function Request(input, options) { 
     ...... 
  } 
  
  Body.call(Request.prototype)  //把Body方法屬性綁到 Reques.prototype 
  
  function Response(bodyInit, options) { 
  } 
  
  Body.call(Response.prototype) //把Body方法屬性綁到 Reques.prototype 
  
  self.Headers = Headers  //暴露Headers 
  self.Request = Request //暴露Request 
  self.Response = Response //暴露Response 
  
  self.fetch = function (input, init) { 
    return new Promise(function (resolve, reject) { 
      var request = new Request(input, init)  //初始化request對象 
      var xhr = new XMLHttpRequest()  // 初始化 xhr 
  
      xhr.onload = function () { //請求成功，構建Response，并resolve進入下一階段 
        var options = { 
          status: xhr.status, 
          statusText: xhr.statusText, 
          headers: parseHeaders(xhr.getAllResponseHeaders() || '') 
        } 
        options.url = 'responseURL' in xhr ? xhr.responseURL : options.headers.get('X-Request-URL') 
        var body = 'response' in xhr ? xhr.response : xhr.responseText 
        resolve(new Response(body, options)) 
      } 
  
      //請求失敗，構建Error，并reject進入下一階段 
      xhr.onerror = function () { 
        reject(new TypeError('Network request failed')) 
      } 
  
      //請求超時，構建Error，并reject進入下一階段 
      xhr.ontimeout = function () { 
        reject(new TypeError('Network request failed')) 
      } 
  
      // 設置xhr參數 
      xhr.open(request.method, request.url, true) 
  
      // 設置 credentials 
      if (request.credentials === 'include') { 
        xhr.withCredentials = true 
      } else if (request.credentials === 'omit') { 
        xhr.withCredentials = false 
      } 
  
      // 設置 responseType 
      if ('responseType' in xhr && support.blob) { 
        xhr.responseType = 'blob' 
      } 
  
      // 設置Header 
      request.headers.forEach(function (value, name) { 
        xhr.setRequestHeader(name, value) 
      }) 
      // 發送請求 
      xhr.send(typeof request._bodyInit === 'undefined' ? null : request._bodyInit) 
    }) 
  } 
  //標記是fetch是polyfill的，而不是原生的 
  self.fetch.polyfill = true 
})(typeof self !== 'undefined' ? self : this); // IIFE函數的參數，不用window，web worker, service worker里面也可以使用 

fetch本質意義上還是對XMLHttpRequest的請求封裝。

axios

談到axios時，這是我們經常會使用的一個網絡請求工具，易用且強大，提供了多種框架的版本，真是好，我還是貼一下axios的特性

1.從瀏覽器中創建XMLHttpRequests

2.從node.js創建http請求

3.支持PromiseAPI

4.攔截請求和響應

5.轉換請求數據和響應數據

6.取消請求

7.自動轉換JSON數據

8.客戶端支持防御XSRF

axios的源碼我還沒看完，沒有資格評論源碼級別的實現，但其就是promise對ajax的封裝，利用promise的能力來實現并行與串行的請求等，攔截器是一個很好的特性，允許我們在請求開始之前或者響應開始之前做一些我們想做的操作，這給業務層面的實現又多了其他的實現方案，說實話，我一開始一直覺得axios攔截器的實現是通過捕捉ajax的幾種狀態值并做響應的方法處理實現的，但是在閱讀部分源碼后我發現不是，原理是axios維護了一個攔截器方法數組，其實就是自定義方法，并使用use方法依次將攔截器數組里面的自定方法放在請求之前，利用promise形成鏈式調用，也就是順序調用來實現的。

I/O

I/O 背景

為啥又要講I/O了，事情是這樣的，上午時候跟一個自己尊敬的老師好友對一款桌面軟件的實現方案進行了討論，大致就是一款圖形處理兼AI推理的windows桌面應用，業務方要求必須使用c++完成所有的前后端開發工作，并且算子服務必須函數化在本地，于是我就開始了思考，給出了兩個實現方案，如下：

方案的思考過程中，我比較關注的兩個點是實現成本及軟件性能，之前寫過一篇對于端側性能的思考，尤其是這類需要做圖像處理，AI推理的應用，性能要求是極高的，當然，畢竟跑在windows上，而不是一些手機等終端上，GPU的調用十分的方便，性能也不會差到哪兒去，然后又基于實現方案的成本及可維護性做了思考，才給出了以上的兩種方案，談及到了I/O，這激起了我對異步I/O的思考。

異步I/O

說到異步編程，我相信這對于除開javascript以外的眾多語言都是比較陌生的，而且在絕大多數高級編程語言中，異步貌似不太被采納，大多數都喜歡利用從頭到腳同步阻塞的方式來執行，例如：PHP(哈哈哈，天下最好的語言)，當然這樣利于邏輯的理解與實現，但是在復雜的應用中，阻塞那是不能想象的，可能你會說，我多線程啊，再進行線程通信不就好了，繼續看，看到這篇博客的人，一定是用過nginx的，為什么nginx會有如此高的性能表現，這得益于事件驅動，異步I/O的架構設計，在進行I/O的過程中，不用等待著上一個I/O執行完成才進行下一個步驟的執行。而Node的設計就與Nginx的事件驅動、異步I/O架構不能說一模一樣，但也90%一樣了。

前面我在吐槽PHP沒有異步I/O不能承載高并發應用時，PHPer會說，我為什么不能多線程并行執行來提高并發的能力，為什么非要異步I/O尼，無可厚非，如果創建多線程的開銷小于并行執行的開銷，那肯定多線程是首選，但是多線程就意味著你需要創建多個線程并且在多個線程之間來回切換會帶來巨大的開銷，通常來說，遇見比較復雜的應用，你還需要做到鎖的應用，以及狀態同步等問題，那么，異步I/O就能很好的解決這樣的問題，利用單線程，遠離多線層死鎖、狀態同步等問題，遠離阻塞，更好的利用CPU等。

異步I/O的執行過程

畫了張圖如下：

如上圖，異步I/O的精髓在于，單線程進行I/O處理時，并不會阻塞其它指令的執行，在完成處理后，通過callback完成數據返回。雖然上文一直在說異步與同步，但是對于操作系統內核來說，處理I/O只有阻塞與非阻塞之分，阻塞I/O就是調用I/O處理之后一定要等到系統內核層面完成操作后，調用才結束，才能往下執行，這就會造成CPU等待I/O執行完成，造成CPU使用空余，效率低下，而操作系統利用輪詢實現的非阻塞I/O能夠通過一系列機制來改善阻塞I/O，提升CPU使用效率及性能，這里我畫圖總結一下。應該來的更明顯直觀：

操作系統通過輪詢實現的非阻塞調用，能夠在貌似異步的情況下取的完整的I/O數據，但是對于應用程序而言，依然是同步的，因為CPU還是需要等待I/O的完全返回。理想的非阻塞異步I/O應該是應用程序發起非阻塞調用，而不是通過一些輪詢，遍歷機制來實現一種偽異步，現實中，實現真正的應用程序調用異步，使用了線層池方案，通過讓部分線程進行阻塞I/O或者非阻塞I/O加輪詢完成數據的獲取，讓一個線程來進行計算處理，通過線程間通信將I/O線程獲取的數據進行傳遞，實現異步I/O。這也是Node實現的異步I/O的底層方案。

Node 異步I/O

當然，Node實現了跨平臺的異步I/O，開發者在*nix及windwos異步I/O之上實現了Libuv來實現跨平臺，linux平臺自己實現了異步I/O，windows則采用了iocp實現，所以，我總說Node是機制創新，底層還是得益于C++的線程池異步I/O帶來的高性能

本文轉載自公眾號【QC的黑板報】，如需轉載請聯系作者！