[譯]從輸入URL到頁面呈現的超詳細過程——第一步:獲取資源

原文連接：From URL to Interactive
原文做者：agustafson
譯者：wangds

這是一個系列文章，分爲四個部分介紹了從輸入URL到頁面呈現的詳細過程

• 客戶端從服務器獲取資源（Server to Client）
• 標籤轉化成DOM的過程（tags to DOM）
• CSS解析的過程（braces to pixels）
• 編譯執行javascript的過程（var to JIT）

本篇翻譯的是第一部分：Server to Client

每當咱們在地址欄中輸入URL或者點擊一個連接的時候，實質就是對瀏覽器（客戶端）下達一道指令去指定的位置（服務器）得到咱們想要的資源。獲取資源是瀏覽器展現web頁面的第一步工做。

獲取資源是一個過程，這個過程能夠拆解成以下幾個步驟。

1.瀏覽器修正傳輸協議（CHECK FOR HSTS）

當瀏覽器接收到URL後，瀏覽器首先要修正URL的傳輸協議（http or https)。之因此採用修正這個詞，是由於瀏覽器中有兩個列表：預加載 HSTS列表和瀏覽器曾經訪問過的HSTS列表，凡是在這兩個列表內的地址，瀏覽器都會將傳輸協議改爲HTTPS。舉個例子，即便你在瀏覽器裏輸入了http://www.bing.com這個地址，最後訪問的都是https://www.bing.com。

2.瀏覽器檢查服務工做線程（CHECK FOR SERVICE WORKERS）

接下來，瀏覽器要確認Service Worker是否能處理這個請求。Service Worker本質上充當了Web應用程序與瀏覽器之間的代理服務器，也能夠在網絡可用時做爲瀏覽器和網絡間的代理。Service Worker經過攔截並代理請求的方式，從腳本控制的緩存內得到資源。

用戶首次訪問具備Service Worker功能的網站時，Service Worker會馬上被下載（以後每24小時它至少會被下載一次）。下載完成後Service Worker將依次進行安裝和激活。若是網站有一個Service Worker處於激活狀態，新下載的Service Worker在安裝完成後不會當即激活而是處於等待狀態。只有當網站不依賴舊的Service Worker後，新的Service Worker纔會激活。Service Worker是徹底異步的。

若是沒有Service Worker，瀏覽器將會訪問網絡層，直接進行下一步工做。

3.瀏覽器檢查網絡緩存（CHECK THE NETWORK CACHE）

在這一步中，瀏覽器首先肯定本次請求的資源是否已經存在於本身的緩存中。若是瀏覽器是第一訪問這個網站，確定沒有緩存，而後瀏覽器將發送請求至服務器，在請求頭中添加Cache-Control這個字段用來制定本次請求關於緩存的規則。Cache-Control常見的取值有max-age（緩存內容失效時限）、no-store（是否開啓緩存）、no-cache（使用緩存時是否須要與服務器驗證）等。每次從瀏覽器的緩存中使用設置了no-cache資源前，都要發送一個驗證請求到服務器，驗證緩存中的資源是不是最新的。這個驗證緩存的請求頭中包含If-Modified-Since（時間斷定）或者包含If-None-Match（資源版本號），服務器接收到請求後根據修改時間或者最新版本號來判定瀏覽器中的資源是否是最新的，若是瀏覽器中的資源是最新的則響應HTTP 304,告知瀏覽器繼續使用以前的緩存；不是最新的則返回HTTP 200，同時響應最新的資源給瀏覽器，更新緩存。

4.瀏覽器檢測鏈接（CHECK FOR CONNECTION）

這一步的工做是解析DNS獲取正確的IP地址，解析域名的第一步是瀏覽器查找本機硬盤HOST文件是否有對應的IP地址，若是本機硬盤HOST文件內沒有，瀏覽器會發送一個DNS請求到本地DNS服務器（Internet服務提供商託管，中國的電信聯通等），本地DNS服務器會首先查找本身的緩存記錄，若是沒有將繼續發送請求至DNS根服務器，逐級查找到正確的IP地址。

有些時候，瀏覽器能夠預先知道將要訪問哪些資源，提早與這些資源進行鏈接。方法就是在頁面的link標籤內添加Resource Hint來告知瀏覽器哪些資源須要預先鏈接加載。Resource Hint有DNS Prefetch、Preconnect、Prefetch和Prerender四種。舉個應用例子，當咱們在搜索引擎中搜索東西的時候，結果頁面上會展現大量的相關連接。瀏覽器可使用Resource Hint將最靠前的搜索結果進行預鏈接和預下載，這樣當咱們點擊這些靠前連接的時候，打開速度將更快。

5.瀏覽器與服務器創建連接（ESTABLISH CONNECTION）

到了這一步，客戶端（也就是瀏覽器）已經正式與服務器創建了鏈接。若是咱們使用TLS，則須要執行TLS握手來驗證服務器提供的證書。

6.瀏覽器發送請求到服務器（SEND THE REQUEST TO THE SERVER）

一般來講，瀏覽器發給服務器的第一個請求是最基礎的頁面請求。服務器會將一個HTML文件發送給瀏覽器。

7.瀏覽器處理響應（HANDLE THE RESPONSE）

瀏覽器接收到來自服務器的響應資源後，將對這些響應資源進行分析。首先，瀏覽器將查看Response header。若是瀏覽器查看Response header表示須要重定向（例如採用 Location header的方法），瀏覽器拿到重定向的地址後，將從新從第一步修正傳輸協議（CHECK FOR HSTS）開始工做。

若是服務器的響應資源進行了壓縮，瀏覽器還須要對這些資源進行解壓。

另外，瀏覽器開始解析響應資源的時候，同時開始對這些資源進行緩存。

接下來，瀏覽器經過判斷響應內資源的MIME類型肯定用什麼樣的方式來加載資源。例如，在瀏覽器解析HTML的時候，碰到圖像文件就以image對象的方式加載。另外瀏覽器在解析HTML時（未生成render樹），還會繼續下載響應內的資源。這一部分的知識將在下篇文章內詳細講解。

至此，瀏覽器將會把此次訪問的URL放入瀏覽器的歷史記錄裏，咱們能夠經過瀏覽器的前進和後退功能訪問他們。

下面的流程圖的展現了1-7的步驟內容：

正如咱們所知道的，還有不少後續須要請求的資源，例如圖片資源、css資源、JavaScript資源。以及css資源內又包含的圖片或者使用import()，AJAX引用的其餘資源等等。這些所有的資源才構造了具備交互性的頁面。咱們全部請求的資源都遵循上面的流程圖，固然也遵循瀏覽器的緩存策略。

細聊瀏覽器緩存（Caching）

前文已經提到，瀏覽器管理着HTTP緩存,緩存中的資源用來快速展現咱們曾經訪問過的網站。緩存中儲藏着相似於網站圖標、基礎JavaScript文件等不常常變更的資源。合理的使用緩存既能夠減小網絡請求的數量又能夠加快頁面的載入速度。

另外，HTTP緩存也是有限度的。瀏覽器經過Response header頭內的Cache-Control來判斷須要緩存哪些資源和緩存資源的時限。好比瀏覽器能夠經過Cache-Control: no-store來判斷本次請求的資源是不須要緩存的，這種不緩存的內容通常是指須要頻繁變更的資源。又好比Cache-Control: immutable用來判定本次請求的資源是永久不變的。在使用Cache-Control: immutable的時候，做者建議用不一樣的URL來對應同一資源的不一樣版本，以便瀏覽器緩存的資源不受影響。

固然，瀏覽器中不只僅有HTTP緩存這一種緩存。咱們能夠經過JavaScript進行程序化緩存。這就是咱們第二步中提到的Service Worker,Service Worker能夠攔截請求並返回Service Worker緩存的資源。Service Worker程使網站的緩存更具備靈活性。另外，每一個網站的程序化緩存都是獨立，這些緩存與網站是一一對應的關係。

源的概念（Origin model）

同源指的是通訊協議、域名、端口徹底相同。舉個例子，https://www.bing.com:443中https是通訊協議，www.bing.com是域名，443是端口。https://www.bing.com:443和 http://www.bing.com:80就是不一樣源的。

同源是瀏覽器中很是重要的一個概念，隔離開來的數據變得更加安全。在大多數狀況下，瀏覽器爲了安全考慮都採用同源策略。在上面的兩個例子中https://www.bing.com:443和 http://www.bing.com:80都沒法查看對方的緩存。

假如bing.com想調用一個microsoft.com的JavaScript資源，正常狀況下瀏覽器會由於同源策略而不容許。這個時候能夠採用CORS(Cross-Origin Resource Sharing)方法來進行跨域訪問。microsoft.com服務器將進行一個聲明表示bing.com能夠訪問哪些資源。

結束語

以上就包含了資源從服務器到客戶端的所有內容。下一篇文章咱們將聊聊HTML標籤是如何轉化成DOM的。

限於本人水平有限，文中若有錯誤感謝您指正。