摘要：不是使用前面提到的網(wǎng)絡(luò)棧，而是直接利用系統(tǒng)的域名解析機(jī)制，不會(huì)阻礙當(dāng)前網(wǎng)絡(luò)棧的工作，針對(duì)多個(gè)域名采取并行處理的方式，每個(gè)域名的解析由一個(gè)新線(xiàn)程處理，結(jié)束后退出。更多技術(shù)內(nèi)幕知識(shí)提煉架構(gòu)和模塊

WebKit 資源加載機(jī)制

資源

HTML 支持的資源主要包括：HTML、JavaScript、CSS、圖片、SVG、CSS Shader、視頻、音頻、字幕、字體、XSL樣式表等

這些資源在 WebKit 中都有不同的類(lèi)表示，公共基類(lèi)是 CachedResource。其中 HTML文本的類(lèi)型為 MainResource，對(duì)應(yīng)的資源類(lèi)型叫 CachedRawResource類(lèi)。

資源緩存

基本思想是建立一個(gè)緩存池，優(yōu)先從緩存池中讀取數(shù)據(jù)。這里的所說(shuō)的緩存池是內(nèi)存緩存。WebKit 從資源池中查找資源的關(guān)鍵詞是URL，只要URL不同，就被認(rèn)為是兩個(gè)不同的資源

資源加載器

分為三種：

針對(duì)每種資源類(lèi)型的特定加載器，僅加載某一種資源，并且沒(méi)有公共基類(lèi)，加載器屬于它的調(diào)用者。如 ImageLoader 屬于 HTMLImageElement

緩存機(jī)制加載器 CachedResourceLoader 所有特定加載器都共享它來(lái)查找并插入緩存資源，屬于 HTML 文檔的對(duì)象

通用資源加載器 ResourceLoader類(lèi)，WebKit 需要從網(wǎng)絡(luò)或者文件中獲取資源的時(shí)候使用，只負(fù)責(zé)獲取資源數(shù)據(jù)

過(guò)程

例子：有一個(gè) “img” 元素，“src”是一個(gè)有效 URL 地址，當(dāng) HTML 解釋器解析到該元素的該屬性，WebKit 會(huì)創(chuàng)建一個(gè) ImageLoader 對(duì)象來(lái)加載該資源，ImageLoader創(chuàng)建一個(gè)緩存資源請(qǐng)求CachedResourceRequest，并調(diào)用CachedResourceLoader 查找緩存資源，如果命中緩存則返回給調(diào)用者，如果沒(méi)有命中則創(chuàng)建一個(gè)資源請(qǐng)求ResourceRequest ,并且調(diào)用通用資源加載器加載資源，具體到下面的 ResourceHandleInternal ，依賴(lài)于每個(gè) WebKit 移植的實(shí)現(xiàn)策略。

存在默寫(xiě)資源會(huì)阻塞主線(xiàn)程渲染過(guò)程，當(dāng)前的主線(xiàn)程渲染被阻塞時(shí)，WebKit 會(huì)啟動(dòng)另外一個(gè)線(xiàn)程去遍歷后面的 HTML 網(wǎng)頁(yè)，收集需要的資源 URL，并可以并發(fā)下載這些資源。

資源的生命周期

資源池使用 LRU（Least Recently Used 最近最少使用）算法，并且在這個(gè)基礎(chǔ)上添加了協(xié)商緩存。如果命中緩存，那么發(fā)送一個(gè) HTTP 請(qǐng)求給服務(wù)器，說(shuō)明資源在本地的一些信息，如資源更新時(shí)間，服務(wù)器根據(jù)信息判斷，如果沒(méi)有更新，則返回狀態(tài)碼 304，那么直接使用原資源；否則下載最新資源。

Renderer 進(jìn)程在網(wǎng)頁(yè)的加載過(guò)程中需要獲取資源，但由于安全性（沙箱模型打開(kāi)的時(shí)候，Renderer進(jìn)程是沒(méi)有權(quán)限獲取資源的）和效率上（資源可以共享），Renderer 進(jìn)程的資源獲取實(shí)際上是通過(guò)進(jìn)程間通信將任務(wù)交給 Browser 進(jìn)程來(lái)完成。

網(wǎng)絡(luò)棧

WebKit 的資源加載的優(yōu)化其實(shí)是交由各個(gè)移植來(lái)實(shí)現(xiàn)的，WebCore 沒(méi)有什么也別的基礎(chǔ)設(shè)施，每個(gè)移植的網(wǎng)絡(luò)實(shí)現(xiàn)是非常不一樣的。

網(wǎng)絡(luò)棧的基本組成

除了 HTTP 協(xié)議、DNS 解析等，還包含了 Chromium 為了減少網(wǎng)絡(luò)時(shí)間而引入的新技術(shù)，例如 SPDY，QUIC

網(wǎng)絡(luò)棧結(jié)構(gòu)

URLRequest 類(lèi)被調(diào)用時(shí)，會(huì)根據(jù) URL 的 “scheme”（協(xié)議類(lèi)型，如：“http://”，“file://”等） 來(lái)決定要?jiǎng)?chuàng)建什么類(lèi)型的請(qǐng)求，Chromium 使用工廠模式處理不同類(lèi)型的請(qǐng)求，例如 “http://” 類(lèi)型則會(huì)使用 URLRequestJobManager 創(chuàng)建一個(gè) URLRequestJob 類(lèi)，具體使用哪個(gè)工廠則是一個(gè)責(zé)任鏈模式，優(yōu)先判斷是否是用戶(hù)自定義的 “scheme” 。

當(dāng) URLRequestJob 被創(chuàng)建后，先從 Cookie 管理器中獲取與該 URL 相關(guān)的信息，之后使用 HttpTransactionFactory 對(duì)象創(chuàng)建 HttpTransaction 對(duì)象開(kāi)啟一個(gè) Http 連接的事務(wù)。如果請(qǐng)求對(duì)應(yīng)的回復(fù)已經(jīng)在磁盤(pán)緩存中，那么 Chromium 無(wú)需再建立 HttpTransaction

HttpNetworkTransaction 使用 HttpNetworkSession 類(lèi)來(lái)管理會(huì)話(huà)。通過(guò) HttpStreamFactory 對(duì)象來(lái)建立 TCP Socket 連接。之后 HttpStreamFactory 創(chuàng)建 HttpStream 對(duì)象，來(lái)處理對(duì)象和網(wǎng)絡(luò)之間數(shù)據(jù)的讀寫(xiě)。

Chromium 中與服務(wù)器建立連接的套接字是 SteamSocket 類(lèi)，它是一個(gè)抽象類(lèi)，再 POSIX 系統(tǒng)和 Windows 系統(tǒng)上有不同實(shí)現(xiàn)。

域名解析（DNS）

Chromium 使用 HostResolverImpl 類(lèi)來(lái)解析域名，具體調(diào)用的是 “getaddrinfo()”，是一個(gè)阻塞式函數(shù)，所以使用多帶帶的線(xiàn)程處理。為了考慮效率，使用 HostCache 類(lèi)來(lái)保存解析后的域名，還有 DNS 預(yù)解析機(jī)制。

磁盤(pán)本地緩存

要求：

要有相應(yīng)的機(jī)制來(lái)移除合適的緩存資源

瀏覽器崩潰時(shí)不破壞磁盤(pán)文件

可以通過(guò)同步或異步的方式高效快速的訪問(wèn)

避免同時(shí)存儲(chǔ)相同的資源

操作一個(gè)項(xiàng)的時(shí)候不受其他請(qǐng)求影響

磁盤(pán)不支持多線(xiàn)程訪問(wèn)，磁盤(pán)的緩存操作要放到多帶帶的線(xiàn)程

支持老版結(jié)構(gòu)

實(shí)現(xiàn)上主要有兩個(gè)類(lèi)，Backend（整個(gè)磁盤(pán)緩存） 和 Entry（表中的表項(xiàng)）。至少需要一個(gè)索引文件和四個(gè)數(shù)據(jù)文件。索引文件用來(lái)索引，數(shù)據(jù)文件又稱(chēng)塊文件。

索引文件： 包括一個(gè)索引頭部和索引地址；頭部用來(lái)表示該索引文件的信息（索引文件版本號(hào)、索引項(xiàng)數(shù)量、文件大小等信息）；索引地址表保存各個(gè)表項(xiàng)對(duì)應(yīng)的索引地址，直接將文件映射到內(nèi)存地址。從內(nèi)存地址可以找到數(shù)據(jù)文件，數(shù)據(jù)文件也是一個(gè)文件頭加上后面的塊文件，每個(gè)塊的大小是固定的，當(dāng)超過(guò) 512 字節(jié)的時(shí)候會(huì)為其分配多個(gè)塊。但最多不超過(guò)四個(gè)，超過(guò)通常會(huì)用多帶帶的文件存儲(chǔ)。如果一個(gè)表項(xiàng)要分配四個(gè)塊，那么是和塊索引位置是對(duì)齊的（起始?jí)K的位置是4的倍數(shù)）

表項(xiàng)結(jié)構(gòu) 分為兩個(gè)部分，第一部分標(biāo)記自己，包括元數(shù)據(jù)信息和自身內(nèi)容。另一部分經(jīng)常發(fā)生變動(dòng)，主要為表項(xiàng)的回收算法服務(wù)，保存了回收算法所需的信息（LRU回收算法）。

高性能網(wǎng)絡(luò)棧

DNS 預(yù)取和 TCP 預(yù)連接

一次 DNS 查詢(xún)約 60~120ms，而 TCP 的三次握手也大約幾十毫秒

DNS 預(yù)取：利用現(xiàn)有的 DNS 機(jī)制，提前解析網(wǎng)頁(yè)中可能的連接。不是使用前面提到的 Chromium 網(wǎng)絡(luò)棧，而是直接利用系統(tǒng)的域名解析機(jī)制，不會(huì)阻礙當(dāng)前網(wǎng)絡(luò)棧的工作，針對(duì)多個(gè)域名采取并行處理的方式，每個(gè)域名的解析由一個(gè)新線(xiàn)程處理，結(jié)束后退出。網(wǎng)頁(yè)開(kāi)發(fā)者可以顯示指定哪些域名來(lái)讓 Chromium 解析，使用方法：。 用戶(hù)地址欄也同理。

TCP 預(yù)鏈接：使用追蹤技術(shù)獲取用戶(hù)從什么網(wǎng)頁(yè)跳轉(zhuǎn)到另一個(gè)網(wǎng)頁(yè)，利用這些數(shù)據(jù)、和一些啟發(fā)規(guī)則來(lái) DNS 預(yù)取和 TCP 預(yù)鏈接，這對(duì)用戶(hù)隱私是一個(gè)巨大挑戰(zhàn)。

HTTP 管線(xiàn)化

HTTP1.1 開(kāi)始增加了管線(xiàn)化技術(shù)，可以將多個(gè) HTTP 請(qǐng)求一次性提交給服務(wù)器，無(wú)需等待服務(wù)器回復(fù)，因?yàn)樗赡軐⒍鄠€(gè)HTTP 請(qǐng)求填充在一個(gè) TCP 數(shù)據(jù)包內(nèi)。能在高延遲的鏈接環(huán)境下有明顯的性能提升。

局限性：需要通過(guò)永久連接完成，并且只有 GET 和 HEAD 等請(qǐng)求可以進(jìn)行管線(xiàn)化。

SPDY

為了解決網(wǎng)絡(luò)延遲和安全問(wèn)題，根據(jù) Google 官方數(shù)據(jù)，可以將網(wǎng)絡(luò)加載時(shí)間減少 64%，HTTP2.0 將引入 SPDY 協(xié)議，將其作為基礎(chǔ)來(lái)編寫(xiě)。

SPDY 協(xié)議是一種新的會(huì)話(huà)層協(xié)議，是一種棧式結(jié)構(gòu)，被定義在 HTTP 協(xié)議和 TCP 協(xié)議之間，核心是多路復(fù)用，僅使用一個(gè)連接來(lái)傳輸一個(gè)網(wǎng)頁(yè)中的眾多資源。本質(zhì)上并沒(méi)有改變 HTTP 協(xié)議，只是將 HTTP 協(xié)議頭通過(guò) SPDY 來(lái)封裝傳輸，數(shù)據(jù)傳輸方式也沒(méi)有發(fā)生變化。所以比較容易部署，服務(wù)器只需要插入 SPDY 協(xié)議的解釋層，從 SPDY 的消息頭中獲取各個(gè)資源的 HTTP 頭即可。但 SPDY 必須建立在 SSL 層之上。

特征：

利用一個(gè) TCP 連接來(lái)傳輸不限個(gè)數(shù)的資源請(qǐng)求的讀寫(xiě)數(shù)據(jù)流，提高 TCP 連接的利用率，減少 TCP 連接的維護(hù)成本

可以調(diào)整這些資源請(qǐng)求的優(yōu)先級(jí)

對(duì)請(qǐng)求使用壓縮技術(shù)

可以嘗試發(fā)送一些信息給瀏覽器，告訴瀏覽器后面可能需要哪些資源，更極端可以主動(dòng)發(fā)送資源給瀏覽器。

QUIC

QUIC 是一種新的網(wǎng)絡(luò)傳輸協(xié)議，目標(biāo)是改進(jìn) UDP 數(shù)據(jù)協(xié)議的能力，解決傳輸層的傳輸效率，并提供數(shù)據(jù)的加密，SPDY 可以在 QUIC 上工作。

《WebKit技術(shù)內(nèi)幕》知識(shí)提煉 —— WebKit 架構(gòu)和模塊