摘要：大多數(shù)情況，為了安全考慮，瀏覽器會(huì)強(qiáng)制使用同源策略，意味著一個(gè)源無法訪問另一個(gè)源的數(shù)據(jù)。如果想要從加載一個(gè)文件，它就需要在實(shí)行同源策略的瀏覽中發(fā)起一個(gè)跨域資源請求。

原文：https://alistapart.com/articl...

最近發(fā)現(xiàn)國外有一個(gè)系列，專門探究從輸入U(xiǎn)RL到頁面可交互的詳細(xì)過程，是一份干貨十足的好資料。筆者決定分為四篇文章對其進(jìn)行有刪減地翻譯，只希望能對大家有所幫助，畢竟這是前端必備的知識點(diǎn)，也是容易忽略掉某些細(xì)節(jié)的知識點(diǎn)。事先聲明，這個(gè)系列完全由筆者手翻，如有翻譯不當(dāng)?shù)牡胤?，懇請讀者給出改進(jìn)意見！

接下來開始第一篇——《從服務(wù)端到客戶端》

在瀏覽器執(zhí)行任何工作之前，它需要先知道訪問的是哪里。有幾種方法可以實(shí)現(xiàn)訪問：在地址欄中輸入U(xiǎn)RL、點(diǎn)擊(或觸碰)一個(gè)頁面上或其他app中的超鏈接、或者點(diǎn)擊你的收藏。無論是哪種情況，都會(huì)觸發(fā)一個(gè)動(dòng)作——導(dǎo)航。導(dǎo)航永遠(yuǎn)是網(wǎng)頁中交互的第一步，因?yàn)樗|發(fā)了如下一系列事件的連鎖反應(yīng)直至網(wǎng)頁被加載。

一旦URL被提供給瀏覽器去加載，以下這些事情就會(huì)悄悄在背后發(fā)生：

首先，瀏覽器需要判斷這個(gè)URL是否明確為HTTP(不安全)協(xié)議。如果它是一個(gè)HTTP的請求，那么瀏覽器則需要檢查這個(gè)域名是否在HSTS的清單中(HTTP Strict Transport Security——嚴(yán)格安全傳輸)。這個(gè)清單包含了一個(gè)預(yù)加載好的名單以及你之前訪問過的使用HSTS的網(wǎng)站名單，它們都是存放在瀏覽器中的。如果你請求的HTTP開頭的host處于在HSTS清單中，那這個(gè)請求會(huì)被強(qiáng)制轉(zhuǎn)為HTTPS開頭的URL而非HTTP。這就是為什么你會(huì)發(fā)現(xiàn)當(dāng)你試圖在一個(gè)現(xiàn)代瀏覽器中輸入http://www.bing.com 會(huì)被轉(zhuǎn)為https://www.bing.com。

接著，瀏覽器需要判斷service worker是否可以用來處理請求——這對于那些離線的沒有網(wǎng)絡(luò)連接的用戶來說至關(guān)重要。Service workers相對來講是比較新的瀏覽器特性。它通過對網(wǎng)絡(luò)請求的攔截來提供離線應(yīng)用的能力，這些請求都可以被保留在腳本控制的緩存中。這是很有用的，因?yàn)樗咕W(wǎng)站能夠更好地控制何時(shí)使用緩存的項(xiàng)目。這些緩存是跟域名綁定的，這意味著每個(gè)域都可以有自己的緩存黑盒，并與其他域的緩存隔離開。

當(dāng)一個(gè)頁面被訪問時(shí)，可以注冊一個(gè)Service worker，這個(gè)動(dòng)作是由一個(gè)工作線程來完成的，它可以把service worker的注冊和URL映射記錄在本地?cái)?shù)據(jù)庫中。要判斷一個(gè)service worker是否被安裝，只需在這個(gè)本地?cái)?shù)據(jù)中查找是否有對應(yīng)的URL。如果為service worker查到了對應(yīng)的URL，它就會(huì)被允許處理請求的回應(yīng)。而如果瀏覽器支持Navigation Preload的新特性，且開發(fā)者使用了它，那么瀏覽器會(huì)同時(shí)去發(fā)起首次導(dǎo)航請求。這是有好處的，因?yàn)樗苊饬藶g覽器因?yàn)閟ervice worker啟動(dòng)過慢而對頁面渲染的影響。

當(dāng)瀏覽器發(fā)現(xiàn)沒有service worker來處理初始化請求時(shí)，就會(huì)繼續(xù)網(wǎng)絡(luò)請求層。

瀏覽器會(huì)通過網(wǎng)絡(luò)請求層檢查緩存中是否存在全新的響應(yīng)。這經(jīng)常是由響應(yīng)頭中的Cache-Control字段決定的，字段中設(shè)置的max-age值可以決定緩存多久會(huì)刷新，而no-store字段可以表明是否應(yīng)該被緩存?？上攵绻麨g覽器在緩存中找不到任何東西，那么就需要進(jìn)行網(wǎng)絡(luò)請求了。而如果在緩存中有一個(gè)全新的響應(yīng)，它就會(huì)被立即返回以用于頁面加載。如果存在一個(gè)不夠“新”的資源，那么瀏覽器會(huì)把這個(gè)請求轉(zhuǎn)為一個(gè)附帶條件的校驗(yàn)請求，也就是請求頭帶上If-Modified-Since或者If-None-Match去告訴服務(wù)端當(dāng)前瀏覽器存的是哪個(gè)版本的緩存。服務(wù)端則可以返回HTTP 304狀態(tài)碼(沒有更改)告訴瀏覽器這個(gè)緩存是最新的，不帶響應(yīng)正文；或者返回HTTP 200狀態(tài)碼告訴瀏覽器這個(gè)緩存資源已經(jīng)過期了，并直接返回最新的資源

如果現(xiàn)在有一個(gè)和主機(jī)、端口建立起連接的請求，那么它會(huì)被瀏覽器復(fù)用而不是重新去建立一個(gè)，否則，瀏覽器會(huì)走網(wǎng)絡(luò)層以了解是否需要執(zhí)行DNS(域名系統(tǒng))查詢。這個(gè)動(dòng)作的具體流程是，先尋找本地的DNS緩存(存儲在你的設(shè)備上)，然后根據(jù)DNS緩存是否過期來決定是否訪問遠(yuǎn)程域名服務(wù)器(它們由互聯(lián)網(wǎng)服務(wù)提供商ISP分配主機(jī)地址)，域名服務(wù)器最終會(huì)返回準(zhǔn)確的IP地址給瀏覽器進(jìn)行連接。

某些情況下，瀏覽器能夠預(yù)先知道哪些域名會(huì)被訪問，從而先準(zhǔn)備好對這些域名的連接。一個(gè)網(wǎng)頁可以通過在link標(biāo)簽中使用資源提示(resource hints)，比如rel="preconnect" 來提示瀏覽器提前準(zhǔn)備好連接。在如下場景中，資源提示是很有用的，比如一個(gè)用戶在必應(yīng)的搜索結(jié)果頁，而通常的預(yù)期中，前幾條搜索結(jié)果是最有可能被用戶訪問的。此時(shí)，提前準(zhǔn)備好對那些域名的連接可以在那些網(wǎng)頁被點(diǎn)擊之后節(jié)省掉DNS查詢和域名連接的消耗。

瀏覽器現(xiàn)在可以與服務(wù)器建立起連接了，且服務(wù)端知道自己需要從客戶端接收和發(fā)送消息了。如果我們是使用TLS，我們需要執(zhí)行一次TLS握手流程以驗(yàn)證服務(wù)器提供的證書。

第一個(gè)通過這個(gè)連接發(fā)起的請求叫做頂級頁面請求。通常情況，這個(gè)請求的資源會(huì)是一個(gè)HTLML文件，從服務(wù)器返回到客戶端

當(dāng)響應(yīng)以數(shù)據(jù)流的形式到達(dá)客戶端后，客戶端就開始進(jìn)行解析了。首先，瀏覽器會(huì)檢查響應(yīng)頭。HTTP頭部是以鍵值對的形式作為HTTP響應(yīng)的一部分。如果響應(yīng)頭指示要進(jìn)行重定向(比如，通過Location字段)，瀏覽器就會(huì)再一次進(jìn)行導(dǎo)航并回到最初的那一步，檢查是否需要執(zhí)行HSTS的升級(為HTTPS)。

如果服務(wù)器的響應(yīng)數(shù)據(jù)被壓縮或分塊了，瀏覽器會(huì)嘗試對它進(jìn)行解壓和合并。

待響應(yīng)被解讀完成后，瀏覽器還會(huì)并行地將其寫入網(wǎng)絡(luò)緩存中。

接著，瀏覽器會(huì)搞清發(fā)送過來的文件的MIME類型，這樣它才能以適當(dāng)?shù)姆绞饺ゼ虞d這份文件。比如，一份圖片文件會(huì)原封不動(dòng)地被加載進(jìn)來，但HTML文件則會(huì)被執(zhí)行解析和渲染。如果HTML解析器被調(diào)用了，那么它會(huì)掃描出那些可能要下載的資源文件的URL，以便瀏覽器在頁面渲染之前就可以開始去下載。這一部分的更多細(xì)節(jié)會(huì)在系列文章的下一篇中具體展開。

截至目前，被請求的導(dǎo)航URL已經(jīng)輸入到了瀏覽器的歷史中，這樣它就可以被用于瀏覽器導(dǎo)航的前進(jìn)和后退功能了。

這里有一張更詳細(xì)的流程圖，它可以讓你對目前討論的內(nèi)容有個(gè)總體的概覽：

如你所知的，頁面會(huì)繼續(xù)發(fā)起請求，因?yàn)轫撁嫔线€有很多對整體體驗(yàn)很重要的子資源，比如圖片，腳本，和樣式表。另外，這些子資源中引用到的其他資源，比如背景圖片(CSS中引用的)，或者其他由fetch()，import()，AJAX請求發(fā)起的資源。如果沒有這些的話，我們將只能看到一個(gè)原始的無交互的空頁面。

剛剛已經(jīng)提到，瀏覽器會(huì)管理網(wǎng)絡(luò)緩存，以便在多種場景下能對下載好的資源的重復(fù)利用。這對那些長久不更新的資源尤其有用，比如logo和第三方的腳本文件。我們應(yīng)該盡可能地利用好這些緩存，因?yàn)檫@有利于減少對外的網(wǎng)絡(luò)請求數(shù)，取而代之的是本地的可復(fù)用的緩存資源。

響應(yīng)頭中的Cache-Control字段控制著瀏覽器的緩存邏輯。某些情況下，你可以謹(jǐn)慎地告訴瀏覽器完全不要進(jìn)行緩存，比如使用Cache-Control: no-store，因?yàn)檫@個(gè)資源在預(yù)期中是一直在變化的。另一種情況下，當(dāng)給定URL的響應(yīng)內(nèi)容永遠(yuǎn)不會(huì)變化時(shí)，我們可以設(shè)置Cache-Control: immutable以便瀏覽器可以永遠(yuǎn)地緩存它。實(shí)際應(yīng)用中，當(dāng)我們使用不同的URL來指向不同版本的同一份資源時(shí)，我們就可以采用這種做法，而非對同一個(gè)URL的資源進(jìn)行更改，因?yàn)楸痪彺娴陌姹緯?huì)一直被使用且不會(huì)去發(fā)送請求。

Origin是由協(xié)議，主機(jī)名和端口共同組成的。例如，https://www.bing.com:443 這個(gè)origin是由https的協(xié)議， www.bing.com 的主機(jī)名和443的端口組成的。只要其中任何一個(gè)部分有差異，那么在兩者進(jìn)行比較時(shí)，都會(huì)被認(rèn)為是不同源的。比如https://images.bing.com:443 和 http://www.bing.com:80 就是不同源的。

Origin對于瀏覽器來說是很重要的概念，因?yàn)樗x了數(shù)據(jù)是如何被隔離和保護(hù)的。大多數(shù)情況，為了安全考慮，瀏覽器會(huì)強(qiáng)制使用同源策略，意味著一個(gè)源無法訪問另一個(gè)源的數(shù)據(jù)。就像上面提到的兩個(gè)源——https://images.bing.com:443 和 http://www.bing.com:80 ，它們互相都無法訪問對方的緩存(service worker的)。

如果bing.com想要從microsoft.com加載一個(gè)Javascript文件，它就需要在實(shí)行同源策略的瀏覽中發(fā)起一個(gè)跨域資源請求。想要允許這種操作的話，microsoft.com就需要與bing.com通過指定CORS(跨域資源共享)的頭部進(jìn)行合作。

既然你已經(jīng)明白了資源如何從服務(wù)器走到客戶端以及之間的所有細(xì)節(jié)，那么請繼續(xù)關(guān)注網(wǎng)頁加載的下一步：從HTML標(biāo)簽轉(zhuǎn)為DOM。