乙個http請求的過程
●dns lookup 先獲得url對應的ip位址
●socket connect 瀏覽器和伺服器建立tcp連線
●send request 傳送http請求
●content download 伺服器傳送響應
如果下到物理層去講就有點耍流氓了，如果這些你還認可這幾個步驟的話，我們就來講一下這裡面存在的效能問題。
●如果你對dns的查詢還有印象的話現在反思一下，dns lookup就是為了獲取一串ip位址要和無數個dns伺服器進行通訊，這要消耗多少時間？別忘了你查詢完了的時候你還沒和那邊的伺服器通訊呢。
●tcp連線要三次握手，如果伺服器很遠的話這三次握手要花多少時間？別忘了建立連線之後你還沒發請求呢。（通常到這裡0.5秒就出去了）
●傳送http請求的時候你要知道一點就是我們的網路頻寬上行和下行通常是不一樣的，通常上行的頻寬會小一些，乙個的話還好，但是現在的網頁通常都會後續請求很多資源，頻寬小的時候上行擁塞怎麼辦？別忘了已經到第三步了，伺服器還沒給你發響應呢，現在你的瀏覽器還什麼都畫不出來。
●終於到了伺服器發響應了，不巧你訪問的這個伺服器比較忙，好幾萬個人都要這個資源，伺服器的上行頻寬也是有限的，怎麼辦？
我覺得我出了幾道還不錯的面試題。順便提一下，前兩步的延遲和網路頻寬的影響不大；後兩步加頻寬是能一定程度緩解，不過你要有錢，而且很貴。雖說博主做過webkit本地渲染的優化，但是深知網頁載入的主要時間還是浪費在網路通訊上，所以在這些步驟上的優化會比你在瀏覽器核心的優化省力且效果明顯。
網路方面的主要優化手段，博主總結一下不外乎快取，預取，壓縮，並行。以後如果再有面試問效能優化之類的問題，大家都可以照著這個思路去考慮，下面就分階段介紹一下現有的優化手段。
dns 優化
對於dns優化，快取無疑是最簡單粗暴且效果明顯的了。說到快取就一定要提到快取層級：
●瀏覽器dns快取，chrome可以看 chrome://net-internals/#dns
●系統dns快取
●hosts檔案，牆裡的小夥伴們應該有印象
●各個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傳輸就不一樣了如果你所有鏈結都去預取的話你的頻寬很快就被佔滿了，這樣你正常的請求無法得到滿足，效能反而會嚴重下降。
快取就又出現了，提快取必提層次結構。
●pagecache 這個是最快的了，直接在記憶體中快取了現有網頁的dom結構和渲染結果，這就是你為什麼在點前進後退的時候會這麼快。
●http cache 檔案級別的cache存在本地的檔案系統上按照rfc2616實現。
●**cache 如果是通過**伺服器上網的話，**伺服器通常也會按照快取標準
●cdn 乙個地理上離你很近的內容伺服器，比如說你在北京請求杭州**的乙個，結果在北京的乙個cdn上有這個，那麼就不用去杭州了。
●dmoc（distributed memory object caching system）cdn主要存放的是靜態資料，但是網頁中通常有很多動態的資料需要查資料庫，流量多了壓力就會很大，通常伺服器外圍還會有一層記憶體快取伺服器，專門快取這些資料庫中的物件，據《**技術這10年》稱可以減少99.5%的資料庫訪問。
●server 其實真正落在伺服器上的請求已經不多了。
大家看到這裡有沒有想到能在什麼地方再加一層快取呢？其實可以在2和3之間加，也就是在路由器上加快取。小公尺的路由器和搜狗合作的預取引擎其實就相當於是在路由器上加一層緩存款順便智慧型預取一下。博主為什麼在這裡另起一段專門談小公尺呢，難不成是小公尺的水軍？才不是呢，是因為博主看到這個訊息的時候心都涼了，和博主的畢設撞車了有木有。去年在360剛出隨身wifi的時候博主想到了這麼個點子，還想著把這個東西做出來之後用這個創業和360談合作。結果最近剛做完，**也投出去了，幻想著開啟人生巔峰，顛覆行業結果就發現小公尺和搜狗出了這麼個一樣的東西還都商業化了。說好的人生巔峰就這樣沒有了，早知道去年就先申請個專利了。
另乙個http常用的優化就是壓縮了，網路傳輸時間 = 訊息大小/網速 既然網速比較貴那麼就壓縮一下吧，大部分伺服器都會對http訊息進行gzip壓縮。可以在http header中看到，具體的就不細說了。
未來協議 spdy
上面的都是傳統做法，下面講乙個未來的技術。由於http協議是上個世紀制定的協議了，已經不能很好的適應現在web的發展，所以google提出了spdy協議目前是指定中的http2.0標準的乙個底版。spdy主要有下面的特點：
●乙個tcp連線上並行多個http連線，減少連線的建立時間
●請求優先順序（目前還沒看到具體實現）
●http頭部壓縮，上文提到的http壓縮是對http body的壓縮，並沒有對頭部壓縮。對於小的http訊息，頭部的比重還是很大的，而現在的web中存在大量小訊息。
●server push/hint 伺服器主動推送物件（可以想象成伺服器幫客戶端預取）
業界目前對spdy是有讚有彈，博主也持謹慎的態度。主要在1和4上，4其實和之前提到的http直接預取的矛盾點一樣，萬一推送的不需要又佔據了頻寬怎麼辦，hint到底該如何實現都有困難。第一條潛在的風險就是tcp連線中途斷開，那麼所有的連線就全部停掉了，pc網際網路這種情況可能會少一些，但是移動網際網路中tcp連線斷開的情況還是比較常見的。不過作為乙個未來的技術還是有必要關注一下。
來自：安度部落格
從輸入URL到頁面載入的過程
1.從瀏覽器接收url到開啟網路請求執行緒 這一部分可以展開瀏覽器的機制以及程序與執行緒之間的關係 2.開啟網路執行緒到發出乙個完整的http請求 這一部分涉及到dns查詢，tcp ip請求，五層網際網路協議棧等知識 3.從伺服器接收到請求到對應後台接收到請求 這一部分可能涉及到負載均衡，安全攔截以...
從輸入url到載入完頁面發生了什麼？
我願稱之為絕殺面試題，計算機網路方面的知識甚至瀏覽器的渲染機制，同時考察知識面的廣度和深度，面試官問這乙個題就足以探清你這方面知識的掌握情況。另一方面了解這其中的細節，對於前端優化來說也至關重要，本文也只能盡自己所了解到的進行總結。從輸入url到載入完頁面主要發生了以下過程 不考慮cdn和資源的強快...
從輸入URL到頁面載入完成
例如 協議部分 http www.guokr.com 資源路徑 question 554991 2 如果位址不是乙個ip位址，通過dns 網域名稱系統 將該位址解析成ip位址。ip位址對應著網路上一台計算機，dns伺服器本身也有ip，你的網路設定包含dns伺服器的ip。例如 www.guokr.co...