摘要：但對于很多資源，則可以利用協(xié)議減少網(wǎng)絡(luò)負載。采用的是多進程的資源加載機制。目前大多數(shù)瀏覽器都有磁盤緩存機制，因為緩存機制確實能夠提高網(wǎng)頁的加載速度。

微信公眾號：愛寫bugger的阿拉斯加
如有問題或建議，請后臺留言，我會盡力解決你的問題。

此文章是我最近在看的【W(wǎng)ebKit 技術(shù)內(nèi)幕】一書的一些理解和做的筆記。
而【W(wǎng)ebKit 技術(shù)內(nèi)幕】是基于 WebKit 的 Chromium 項目的講解。
書接上文 瀏覽器內(nèi)核之WebKit 架構(gòu)與模塊

網(wǎng)絡(luò)和資源加載是網(wǎng)頁的加載和渲染過程中的第一步，加載的資源包括以下內(nèi)容：

在資源類的前面加上 “Cached” 字樣，是因為效率問題而引入的緩存機制，所有對資源的請求都會先獲取緩存中的信息， 以決定是否向服務(wù)器提出資源請求。

資源的緩存機制是提高資源使用效率的有效方法。

它的基本思想是建立一個資源的緩存池。

當 WebKit 需要請求資源的時候，先從資源池中查找是否存在相應(yīng)的資源。如果有，WebKit 則取出以便使用；如果沒有，WebKit 創(chuàng)建一個新的 CachedResource 子類的對象，并發(fā)送真正的請求給服務(wù)器，WebKit 收到資源后將其設(shè)置到該資源類的對象中去，以便于緩存后下次使用。這里緩存指的是內(nèi)存緩存，而不同于后面在網(wǎng)絡(luò)棧部份的磁盤緩存。

WebKit 從資源池中查找資源的關(guān)鍵字是 URL, 因為標記資源唯一的特征就是資源的 URL 。這也意味著，假如兩個資源有不同的 URL ，但是它們的內(nèi)容完全一樣，也被認為是兩個不同的資源。其實，上面是個簡單的示意圖，真實的過程比這里要復(fù)雜，這其中涉及到了資源的生命周期和失效機制。

按照加載器的類型來分，WebKit 總共有三種類型的加載器。

由于從網(wǎng)絡(luò)獲取資源是一個非常耗時的過程，通常一些資源的加載是異步執(zhí)行的，也就是說網(wǎng)絡(luò)資源的獲取和加載不會阻礙當前 WebKit 的渲染過程，例如圖片、CSS 文件。

當然，網(wǎng)頁也存在某些特別的資源會阻礙主線程的渲染過程，例如 Javascript 代碼文件。這會嚴重影響 WebKit 下載資源的效率。因為主線程被阻礙了，后面的解析工作沒有辦法繼續(xù)往下進行，所以對于 HTML 網(wǎng)頁中后面使用的資源也沒有辦法知道并發(fā)送下載請求。

這時候，WebKit 會這樣：當前的主線程被阻礙時，WebKit 會啟動另外一個線程去遍歷后面的 HTMl 網(wǎng)頁，收集需要的資源 URL，然后發(fā)送請求，這樣就可以避免被阻礙。與此同時，WebKit 能夠并發(fā)下載這些資源，甚至并發(fā)下載 JavaScript 代碼資源。這種機制對于網(wǎng)頁的加載提速很是明顯。

資源池中的生命周期是什么呢？資源池不能無限大，必須要用相應(yīng)的機制來替換其中的資源，從而加入新的資源。資源池使用的機制其實很簡單，就是采用 LRU（Lease Recent Used 最近最少使用）算法。

另外一方面，當一個資源加載后，通常它會被放入資源池，以便之后使用。問題是，WebKit 如何判斷下次使用的時候是否需要更新該資源從而對服務(wù)器重新請求？因為服務(wù)器可能在某段時間之后更新了該資源。

考慮這樣的場景，當用戶打開網(wǎng)頁后，他想刷新當前的頁面。這種情況下，資源池會出現(xiàn)怎樣的情況呢？是清除所有的資源，重新獲得？還是直接利用當前的資源？都不是。對于某些資源，WebKit 需要直接重新發(fā)送請求，要求服務(wù)器將內(nèi)容重新發(fā)送過來。但對于很多資源，WebKit 則可以利用 HTTP 協(xié)議減少網(wǎng)絡(luò)負載。在 HTTP 協(xié)議的規(guī)范中對此有規(guī)定，瀏覽器可以發(fā)送消息確認是否需要更新，如果有，瀏覽器則重新獲取該資源；否則就需要利用該資源。

WebKit 的做法是，首先判斷資源是否在資源池中，如果是，那么發(fā)送一個 HTTP 請求給服務(wù)器，說明該資源在本地的一些信息，例如該資源什么時間修改的，服務(wù)器則根據(jù)該信息作判斷，如果沒有更新，服務(wù)器則發(fā)送回狀態(tài)碼 304 ，表明無需更新，那么直接利用資源池中原來的資源；否則。WebKit 申請下載最新的資源內(nèi)容。

資源的實際加載在各個 WebKit 移植中有不同的實現(xiàn)。Chromium 采用的是多進程的資源加載機制。

圖4-11 描述了關(guān)于 Chromium 如何利用多進程架構(gòu)來完成資源的加載，主要是多個 Render 進程和 Browser 進程之間的調(diào)用棧涉及的主要類。

Render 進程在網(wǎng)頁的加載過程中需要獲取資源，但是由于安全性（實際上，當沙箱模型打開的時候，Render 進程是沒有權(quán)限去獲取資源的）和效率上（資源共享等問題）的考慮，Render 進程的資源獲取實際上是通過進程間通信將任務(wù)交給 Browser 進程來完成，Browser 進程有權(quán)限從網(wǎng)絡(luò)或者本地獲取資源。

在 Chromium 架構(gòu)的 Renderer 進程中，ResourceHandleInternal 類通過 IPCResource-LoaderBridge 類同 Browser 進程通信。IPCResourceLoaderBridge 類繼承自 ResourceLoaderBridge 類，其作用是負責(zé)發(fā)起請求的對象和回復(fù)結(jié)果的解釋工作，實際消息的接收和派發(fā)交給 ResourceDispatcher 類來處理。

資源統(tǒng)一交由 Browser 進程來處理，這使得資源在不同網(wǎng)頁間的共享變得很容易。因為每個 Renderer 進程某段時間內(nèi)可能有多個請求，同時還有多個 Renderer 進程，Browser 進程需要處理大量的資源請求，這就需要一個處理這些請求的調(diào)度器，這就是 Chromium 中的 ResourceScheduler。

上圖4-13 是 “ent” 所包括的主要子目錄，也是 Chromium 網(wǎng)絡(luò)棧的主要模塊。這里面除了一些基礎(chǔ)的部分，例如 HTTP 協(xié)議。NDS 解析等模塊，還包含了 Chromium 為了減少網(wǎng)絡(luò)時間 而引入的新技術(shù)，例如 SPDY 、QUIC 等

圖4-14 描述了從 URLRequest 類到 Socket 類之間的調(diào)用過程。以 HTTP 協(xié)議為例，圖中列出了建立 TCP 的 socket 連接過程中涉及的類。

首先是 URLRequest 類被上層調(diào)用并啟動請求的時候，它會根據(jù) URL 的 “scheme” 來決定需要創(chuàng)建什么類型的請求。“scheme” 也就是 URL 的協(xié)議類型，例如 “http://”、“file://” ，也可以是自定義的 scheme ，例如 Android 系統(tǒng)的 “file://android_asset/”。 URLRequest 對創(chuàng)建的是一個 URLRequestJob 子類的一個對象，例如圖中的 URLRequestJob 類。為了支持自定義的 scheme 處理方式， Chromium 使用工廠模式。

URLRequestJob 類和它的工廠類 URLRequestJobFactory 的管理工作都由 URLRequestJobManager 類負責(zé)?；舅悸肥?，用戶可以在該類中注冊多個工廠，當有 URLRquest 請求時，先由工廠檢查它是否需要處理該 “scheme” ,如果沒有，工廠管理類繼續(xù)交給下一個工廠類來處理。最后，如果沒有任何工廠能夠處理，Chromium 則交給內(nèi)置的工廠來檢查和處理是否為 “http://”、“ftp://”、或者 “file://” 等。

圖 4-15 就是描述這些類的關(guān)系。

當用戶設(shè)置代理時，用戶代理依賴以下類來處理。

圖 4-17 不僅描述上面這些類，同時也描述了 Chromium 中獲取網(wǎng)絡(luò)代理的過程。圖中數(shù)據(jù)表示獲取網(wǎng)絡(luò)代理的次序，其中的分支 3.1 和 4.1 分別表示簡單的代理設(shè)置和代理腳本設(shè)置的處理過程。

如果沒有磁盤緩存，當用戶訪問網(wǎng)頁的時候，每次瀏覽器都要需要從網(wǎng)站下載網(wǎng)頁，圖片、js 等資源，這其實費力又不討好。解決這一問題的方法就是將之前瀏覽器下載的資源保存下來，存到磁盤中，以備今后使用。當然，資源是有時效性的，也會變得不再有效，所以需要有相應(yīng)的退出機制來解決這一問題。目前大多數(shù)瀏覽器都有磁盤緩存機制，因為緩存機制確實能夠提高網(wǎng)頁的加載速度。

為了適應(yīng)網(wǎng)絡(luò)資源的本地緩存需求， Chromium 的本地磁盤緩存有幾個特性或者要求。

雖然需要緩存的資源可能很多，但磁盤空間不是無限大的，所以必須要有相應(yīng)的機制來移除合適的緩存資源，以便加入新的資源。

能夠確保在瀏覽器崩潰時不破壞文件，至少能夠保護原先在磁盤中的數(shù)據(jù)。

能夠高效和快速地訪問磁盤中現(xiàn)有的數(shù)據(jù)結(jié)構(gòu)，支持同步和異步兩種訪問方式。

能夠避免同時存儲兩個相同的資源。

能夠很方便地從磁盤中刪除一個項，同時可以在操作一個項的時候不受其他請求的影響。

磁盤不支持多線程訪問，所以需要把所有磁盤緩存的操作放入多帶帶的一個線程。

升級版本時，如果磁盤緩存的內(nèi)部存儲結(jié)構(gòu)發(fā)生改變， Chromium 仍然能夠支持老版本的結(jié)構(gòu)。

內(nèi)部結(jié)構(gòu)主要有個類：Backend 和 Entry 。 Backend 類表示整個磁盤緩存，是所有針對磁盤緩存操作的主入口，表示的是一個緩存表。Entry 類指的是表中的表項。緩存通常是一個表，對于整個表的操作作用在 Backend 類中，包括創(chuàng)建表中的一個個項，每個項由關(guān)鍵字來唯一確定，這個關(guān)鍵字注是資源的 URL。而對項目內(nèi)的操作包括讀寫等都是由 Entry 類來處理。

Cookie 格式就是一系列的 “關(guān)鍵字+值” 對，一個簡單的例子如下：

test1 = webkit; test2 = chromium, Expires = Sun, 30 Oct 2016 21:35:00 GMT; Domain = .myweb.cm;

例子中包括兩個自定義的關(guān)鍵字，分別是 “test1” 和 “test2” ,它們的值分別為 “webkit” 和 “chromium” 。后面的則是預(yù)定義的關(guān)鍵字 “Expires” 和 “Domain”,表示的是該 Cookie 的失敗時間和該 Cookie 對應(yīng)的域。基于安全性考慮，一個網(wǎng)頁的 Cookie 只能被該網(wǎng)頁（或者說是該域的網(wǎng)頁）訪問。

根據(jù) Cookie 的時效性可以將 Cookie 分成兩種類型，第一種是會話型 Cookie （Session Cookie）。如果 Cookie 沒有設(shè)置失效時間，就是會話型 Cookie。第二種是持續(xù)型 Cookie （Persistent Cookie），也就是當瀏覽器退出的時候，仍然保留 Cookie 的內(nèi)容。該類型的 Cookie 有一個有效期，在有效期內(nèi)，每次訪問該 Cookie 所屬域的時候，都需要將該 Cookie 發(fā)送給服務(wù)器，這樣服務(wù)器能夠有效追蹤用戶的行為。

Chromium 中支持 Cookie 的機制也較為簡單和清晰，如圖 4-23 所示的是 Chromium 所設(shè)計和使用的主要類及其關(guān)系。CookieMonster 是Cookie 機制中最重要的類，實際上相當于 Cookie 管理器。

它包括幾個作用：

第一是實現(xiàn) CookieStore 的接口，它是對外的接口，調(diào)用者可以設(shè)置和獲得 Cookie；

第二是報告各種 Cookie 的事件，例如更新信息等，主要使用 Delegate 類，

第三是 Cookie 對象的集合，也就是 CanonicalCookie 的集合，每個 CanonicalCookie 對象都是保存在內(nèi)存中的，當需要存儲到磁盤的時候使用 PersistentCookieStore 類，具體由 SQLitePersistentCookieStore 類負責(zé)實際的存儲動作。

HTTP 是一種使用明文來傳輸數(shù)據(jù)的應(yīng)用層協(xié)議。構(gòu)建在 SSL 之上的 HTTPS 提供了安全的網(wǎng)絡(luò)傳輸機制，現(xiàn)已被廣泛應(yīng)用于網(wǎng)絡(luò)上。典型的是電子商務(wù)、銀行支付方面的應(yīng)用?；旧纤械臑g覽器都支持該協(xié)議， Chromium 當然也不例外。

不僅如此，Chromium 也支持一種新的標準，這就是 HSTS (HTTP Strict TransportSecurity)。該協(xié)議能夠讓網(wǎng)絡(luò)服務(wù)器聲明它只支持 HTTPS 協(xié)議，所以瀏覽器能夠理解服務(wù)器的聲明，發(fā)送基于 HTTPS 的連接和請求。通常情況下，瀏覽器用戶不會輸入 “scheme（http://）”，瀏覽器的補充功能通常會加入該 “scheme” ,但是，服務(wù)器可能需要輸入 ”https://“ 。在這樣子的情況下，該協(xié)議就顯得非常有用。一般情況下，服務(wù)在返回的消息頭中加入以下信息表明它支持該標準：

Strict-Transport-Security: max-age=16070400; includeSubDomains

Chromium 的網(wǎng)絡(luò)模塊有兩個重要目標，其一是安全，其二是速度。為此，該項目引入了很多 WebKit 所沒有的新技術(shù)。

一次 DNS 查詢的平均時間大概是 60 ~ 120ms 之間或者更長，而 TCP 的三次握手時間大概也是幾十毫秒或者更長。為了有效減少這段時間，Chromium 引入了 DNS 預(yù)取和 TCP 預(yù)連接，它們都是由 Chromium 的 ”Predictor“ 機制來實現(xiàn)的。

首先是 DNS 預(yù)取技術(shù)。它的主要思想是利用現(xiàn)有的 DNS 機制，提前解析網(wǎng)頁中可能的網(wǎng)絡(luò)連接。具體來講，當用戶正在瀏覽當前網(wǎng)頁的時候，Chromium 提取網(wǎng)頁中的超鏈接，將域名抽取出來，利用比較少的 CPU 和網(wǎng)絡(luò)帶寬來解析這些域名或者 IP 地址，這樣一來，用戶根本感覺不到這一過程。當用戶單擊這些鏈接的時候，可以節(jié)省不少時間，特別在域名解析比較慢的時候，效果特別明顯。

DNS 預(yù)取技術(shù)是利用系統(tǒng)的域名解析機制，好處是它不會阻礙當前網(wǎng)絡(luò)棧的工作。DNS 預(yù)取技術(shù)針對多個域名采取并行處理的方式，每個域名的解析須由新開啟的一個線程來處理，結(jié)束后此線程即退出。

當然， DNS 預(yù)取技術(shù)不僅應(yīng)用于網(wǎng)頁中的超鏈接，當用戶在地址欄中輸入地址后，候選項同輸入的地址很匹配的時候，在用戶敲下回車鍵獲取網(wǎng)頁之前， Chromium 已經(jīng)開始使用 DNS 預(yù)取技術(shù)解析該域名了。

Chromium 使用追蹤技術(shù)來獲取用戶從什么網(wǎng)頁跳轉(zhuǎn)到另外一個網(wǎng)頁?？梢岳眠@些數(shù)據(jù)，一些啟發(fā)式規(guī)則和其他一些暗示來預(yù)測用戶下面會單擊什么超鏈接，當有足夠的把握時，它便先 DNS 預(yù)取，更進一步，還可以預(yù)先建立 TCP 連接。聽起來夠智能的吧，是的。但是這對用戶的隱私是一個極大的挑戰(zhàn)，它甚至能預(yù)測你單擊什么超鏈接。

同 DSN 預(yù)取技術(shù)一樣，追蹤技術(shù)不會應(yīng)用于網(wǎng)頁中的超鏈接，當用戶在地址欄中輸入地址，如候選項同輸入的地址很匹配，則在用戶敲擊下回車鍵獲取該網(wǎng)頁之前，Chromium 就已經(jīng)開始嘗試建立 TCP 連接了。

很多時候，服務(wù)器和瀏覽器通話是按順序來的，瀏覽器發(fā)送一個請求給服務(wù)器，等到服務(wù)器的回復(fù)后，才會發(fā)送另外一個請求。弊端是效率極差。

HTTP 1.1 開始增加了管線化技術(shù)，Chromium 也支持這一技術(shù)，但它需要服務(wù)器的支持兩者配合才能實現(xiàn) HTTP 管線化。HTTP 管線化技術(shù)是一項同時將多個 HTTP 請求一次性提交給服務(wù)器的技術(shù)，因此無需等待服務(wù)器的回復(fù)，因為它可能將多個 HTTP 請求填充在一個 TCP 數(shù)據(jù)包內(nèi)。HTTP 管線化需要在網(wǎng)絡(luò)上傳輸較少的 TCP 數(shù)據(jù)包，因此減少了網(wǎng)絡(luò)負載。

圖4-24 描述了 HTTP 管線化技術(shù)是如何傳送請求和回復(fù)的。

請求結(jié)果的管線化使得 HTML 網(wǎng)頁加載時間動態(tài)提升，特別是在具體有高延遲的連接環(huán)境下。在速度較快的網(wǎng)絡(luò)連接環(huán)境下，提速可能不是很明顯。因為這些請求還是有明顯的先后順序的。管線化機制需要通過永久連接（Persistent Connection）完成，并且只有 GET 和 HEAD 等請求可以進行管線化，使用場景有很大的限制。

SPDY 就是為了解決網(wǎng)絡(luò)延遲和安全性問題。根據(jù) Google 的官方數(shù)據(jù)，使用 SPDY 協(xié)議的服務(wù)器和客戶端可以將網(wǎng)絡(luò)加載的時間減少 64。

SPDY 協(xié)議是一種新的會話層協(xié)議，因為網(wǎng)絡(luò)協(xié)議 是一種棧式結(jié)構(gòu)，它被定義在 HTTP 協(xié)議和 TCP 協(xié)議之間，SPDY 協(xié)議的核心思想 是多數(shù)復(fù)用，僅使用一個連接來傳輸一個網(wǎng)頁中的眾多資源。

QUIC 是一種新的網(wǎng)絡(luò)傳輸協(xié)議，主要目標是改進 UDP 數(shù)據(jù)協(xié)議的能力。同 SPDY 建立在傳輸層之上不同，QUIC 所要解決的問題就是傳輸層的傳輸效率，并提供了數(shù)據(jù)的加密，所以，SPDY 可以在 QUIC 之上工作。

WebKit 和 Chromium 為了高效率地下載資源，設(shè)計出了各種各樣的策略和新技術(shù)。
## 12.1 DNS 和 TCP 連接

DNS 和 TCP 連接占用大量的時間，所以為了高效地加載網(wǎng)頁，網(wǎng)頁開發(fā)者可以從以下方面著手改變以減少這一部分的時間。

減少鏈接的重定向。有些網(wǎng)頁中使用了大量重定向，可能還會有很多次重定向，還不僅要求瀏覽器建立多次鏈接，同時還需要多次 DNS 解析，這會阻礙 DNS 預(yù)取技術(shù)的應(yīng)用，應(yīng)該盡量避免。

利用DNS預(yù)取機制。網(wǎng)頁的開發(fā)者當然知道需要鏈接的 URL,為了讓瀏覽器也知道這些鏈接，開發(fā)者可以指定需要預(yù)取的 URL。

搭建支持 SPDY 協(xié)議的服務(wù)器，當然指的是那些需要使用 HTTPS 協(xié)議的網(wǎng)站。

避免錯誤的鏈接請求。有些網(wǎng)頁中包含了一些失效的鏈接，當瀏覽器試圖獲取該鏈接對應(yīng)的資源的時候，就會占用網(wǎng)絡(luò)資源。

我們也可以通過減少網(wǎng)頁中所需的資源數(shù)量來改善網(wǎng)頁的加載：

在 HTML 網(wǎng)頁中內(nèi)嵌小型的資源，也就是當資源比較小的時候，可以將它們直接放在網(wǎng)頁中，可能的資源如 CSS、JavaScript 和圖片等。比如圖片 用 webpack 直接打包成 base64。

合并一些資源，例如 CSS、JavaScript 和圖片。常見的就是一些網(wǎng)頁中大量使用的小圖片，可以將它們合并成一張大的圖片以供使用。

對于每個資源而言，通過減少它的數(shù)據(jù)量來提高網(wǎng)頁的加載速度：

使用瀏覽器本地磁盤緩存機制。因為 HTTP 協(xié)議支持資源的失效機制，通過對資源設(shè)置適當?shù)氖趤頊p少瀏覽器對資源的重復(fù)獲取。

啟用資源的壓縮技術(shù)。例如，對于圖片而言，可以使用 zip 壓縮技術(shù)，然后在 HTTP 消息頭中說明該資源經(jīng)過壓縮，這樣可以有效減少網(wǎng)絡(luò)傳輸?shù)臄?shù)據(jù)量。

希望本文對你有點幫助。

下期分享 第五章 HTML解釋器與模型 敬請期待。

對 全棧開發(fā) 有興趣的朋友可以掃下方二維碼關(guān)注我的公眾號 —— 愛寫bugger的阿拉斯加

分享 web 開發(fā)相關(guān)的技術(shù)文章，熱點資源，全棧程序員的成長之路。

大家一起交流成長。

只要關(guān)注公眾號并回復(fù) 福利 便送你六套、并且每套價值 3999 元的視頻資源： Python、Java、Linux、Go、vue、react、javaScript