從輸入 URL 到頁面加載完的過程當中都發生了什麼事情 —— 網絡優化篇

http://oilbeater.com/技術相關/2014/05/09/from-url-to-webpage.html  -- 原博文，表示感謝！

話說這些年來我最喜歡問的面試題是『從輸入 URL 到頁面加載完的過程當中都發生了什麼事情？』，我的以爲這道題很是很是難，既考深度又考廣度，至今尚未人的回答讓我滿意，因此我想本身挑戰一下，整理出一篇文章，有哪位大牛也想來一塊兒挑戰麼？ @JS小組 @前端交流

想到這不就是我這兩年來研究的東西麼，因而就接受一下挑戰。網上已經有不少版本的答案了好比這裏和這裏。這道題能夠從瀏覽器端，網絡傳輸和服務器端詳細展開，每一部分均可以說上好幾天，每一個人都能說上幾句又不可能說全，因此說的方向和角度就很重要了。其中客戶端和服務器端的工做已經有太多的人說了，本文來說一下中間部分的網絡傳輸。但是網絡傳輸部分相對來講是比較簡單的，有成文的規範和協議基本和背課文同樣，本文就講點帶花的，講一下現有針對網絡的優化部分，以防止和別人雷同。

一個HTTP請求的過程

爲了簡化咱們先從一個HTTP請求開始，簡要介紹一下一個HTTP求情的網絡傳輸過程，也就是所謂的「從輸入 URL 到頁面下載完的過程當中都發生了什麼事情」

1. DNS Lookup 先得到URL對應的IP地址

2. Socket Connect 瀏覽器和服務器創建TCP鏈接

3. Send Request 發送HTTP請求

4. Content Download 服務器發送響應

若是下到物理層去講就有點耍流氓了，若是這些你還承認這幾個步驟的話，咱們就來說一下這裏面存在的性能問題。

1. 若是你對DNS的查詢還有印象的話如今反思一下，DNS Lookup就是爲了獲取一串IP地址要和無數個DNS服務器進行通訊，這要消耗多少時間？別忘了你查詢完了的時候你還沒和那邊的服務器通訊呢。

2. TCP鏈接要三次握手，若是服務器很遠的話這三次握手要花多少時間？別忘了創建鏈接以後你還沒發請求呢。（一般到這裏0.5秒就出去了）

3. 發送HTTP請求的時候你要知道一點就是咱們的網絡帶寬上行和下行一般是不同的，一般上行的帶寬會小一些，一個的話還好，可是如今的網頁一般都會後續請求不少資源，帶寬小的時候上行擁塞怎麼辦？別忘了已經到第三步了，服務器還沒給你發響應呢，如今你的瀏覽器還什麼都畫不出來。

4. 終於到了服務器發響應了，不巧你訪問的這個服務器比較忙，好幾萬我的都要這個資源，服務器的上行帶寬也是有限的，怎麼辦？

我以爲我出了幾道還不錯的面試題。順便提一下，前兩步的延遲和網絡帶寬的影響不大；後兩步加帶寬是能必定程度緩解，不過你要有錢，並且很貴。雖然說博主作過Webkit本地渲染的優化，可是深知網頁加載的主要時間仍是浪費在網絡通訊上，因此在這些步驟上的優化會比你在瀏覽器內核的優化省力且效果明顯。

網絡方面的主要優化手段，博主總結一下不外乎緩存，預取，壓縮，並行。之後若是再有面試問性能優化之類的問題，你們均可以照着這個思路去考慮，下面就分階段介紹一下現有的優化手段。

DNS 優化

對於DNS優化，緩存無疑是最簡單粗暴且效果明顯的了。說到緩存就必定要提到緩存層級：

1. 瀏覽器DNS緩存，chrome能夠看 chrome://net-internals/#dns

2. 系統DNS緩存

3. hosts文件，牆裏的小夥伴們應該有印象

4. 各個DNS服務器上的緩存

固然DNS緩存失效期一般都比較短，不少狀況下都要再去查找，爲了下降用戶體驗到的延遲（注意這裏不是網絡延時）預取是一個不錯的方法。好比說你敲網址的時候尚未敲完，可是瀏覽器根據你的歷史發現你頗有可能去訪問哪一個網站就提早給你作dns預取了，好比你打了一個「w」的時候，chrome已經幫你去找weibo.com的ip地址了。chrome用戶能夠看一下 chrome://predictors/ 你就知道了。

此外瀏覽器還會記錄你過去的歷史知道每一個域名下一般還會有哪些其餘的連接創建起網站的拓撲結構，當你訪問這個域名下的網站他就會預先對其餘連接的域名進行DNS解析能夠參照 chrome://dns/。

TCP 優化

看到前面的DNS的具體優化這麼繁雜，知道這簡單的一步沒那麼簡單了吧。結果到TCP這一步優化反而簡單了，由於剛纔dns已經把ip都預先弄到了那麼咱們順着剛纔的步驟再創建鏈接就行了。因此在你敲第一個字母的時候dns解析完了就去創建鏈接了，這時候你可能網址還沒敲完。當你剛訪問一個網站的時候瀏覽器刷刷刷的幫你把到別的服務器的TCP鏈接給你建好。

HTTP傳輸優化

寫到這裏可能有人會想，既然已經把TCP鏈接創建好了，那我乾脆預取更進一步，把全部的連接內容直接預取下來不就行了，這樣我網址還沒敲完網頁就已經加載完成了。這個想法是好的，但現實倒是殘酷的。由於要記住咱們的帶寬是有限的，DNS和TCP鏈接量級都比較輕，對網絡帶寬不會佔據太多，可是HTTP傳輸就不同了若是你全部連接都去預取的話你的帶寬很快就被佔滿了，這樣你正常的請求沒法獲得知足，性能反而會嚴重降低。

緩存就又出現了，提緩存必提層次結構。

1. PageCache 這個是最快的了，直接在內存中緩存了現有網頁的dom結構和渲染結果，這就是你爲何在點前進後退的時候會這麼快。

2. HTTP Cache 文件級別的Cache存在本地的文件系統上按照RFC2616實現。

3. 代理Cache 若是是經過代理服務器上網的話，代理服務器一般也會按照緩存標準

4. CDN 一個地理上離你很近的內容服務器，好比說你在北京請求杭州淘寶的一個圖片，結果在北京的一個CDN上有這個圖片，那麼就不用去杭州了。

5. DMOC（distributed memory object caching system）CDN主要存放的是靜態數據，可是網頁中一般有不少動態的數據須要查數據庫，流量多了壓力就會很大，一般服務器外圍還會有一層內存緩存服務器，專門緩存這些數據庫中的對象，據《淘寶技術這10年》稱能夠減小99.5%的數據庫訪問。

6. Server 其實真正落在服務器上的請求已經很少了。

你們看到這裏有沒有想到能在什麼地方再加一層緩存呢？其實能夠在2和3之間加，也就是在路由器上加緩存。小米的路由器和搜狗合做的預取引擎其實就至關因而在路由器上加一層緩存款順便智能預取一下。博主爲何在這裏另起一段專門談小米呢，難不成是小米的水軍？纔不是呢，是由於博主看到這個消息的時候心都涼了，和博主的畢設撞車了有木有。去年在360剛出隨身WiFi的時候博主想到了這麼個點子，還想着把這個東西作出來以後用這個創業和360談合做。結果最近剛作完，論文也投出去了，幻想着開啓人生巔峯，顛覆行業結果就發現小米和搜狗出了這麼個同樣的東西還都商業化了。說好的人生巔峯就這樣沒有了，早知道去年就先申請個專利了。

另外一個HTTP經常使用的優化就是壓縮了，網絡傳輸時間 = 消息大小/網速 既然網速比較貴那麼就壓縮一下吧，大部分服務器都會對HTTP消息進行gzip壓縮。能夠在Http Header中看到，具體的就不細說了。

將來協議 SPDY

上面的都是傳統作法，下面講一個將來的技術。因爲HTTP協議是上個世紀制定的協議了，已經不能很好的適應如今Web的發展，因此Google提出了SPDY協議目前是指定中的HTTP2.0標準的一個底版。SPDY主要有下面的特色：

1. 一個TCP鏈接上並行多個HTTP鏈接，減小鏈接的創建時間

2. 請求優先級（目前還沒看到具體實現）

3. HTTP頭部壓縮，上文提到的HTTP壓縮是對HTTP body的壓縮，並無對頭部壓縮。對於小的HTTP消息，頭部的比重仍是很大的，而如今的web中存在大量小消息。

4. Server push/hint 服務器主動推送對象（能夠想象成服務器幫客戶端預取）

業界目前對SPDY是有贊有彈，博主也持謹慎的態度。主要在1和4上，4其實和以前提到的HTTP直接預取的矛盾點同樣，萬一推送的不須要又佔據了帶寬怎麼辦，hint到底該如何實現都有困難。第一條潛在的風險就是TCP鏈接中途斷開，那麼全部的鏈接就所有停掉了，PC互聯網這種狀況可能會少一些，可是移動互聯網中TCP鏈接斷開的狀況仍是比較常見的。不過做爲一個將來的技術仍是有必要關注一下。

總結

上面就是博主對」從輸入 URL 到頁面加載完的過程當中都發生了什麼事情「兩端之間網絡鏈接這塊所知道的事情還有優化措施，歡迎你們來拍磚。對於瀏覽器端到底作了些什麼博主其實也很熟，只是這一塊已經有不少成熟的資料了好比這裏，這裏和這裏想寫點不同的東西太難了。服務器端的事情博主就不是太清楚了，還請你們多多指教。