從輸入 URL 到頁面加載完的過程當中都發生了什麼事情

 本身總結：

0.瀏覽器優化

  0.1 智能匹配，DNS預取：輸入w時已經把weibo.com的DNS預取了

1. 瀏覽器查找域名的ip

  1.1 查看緩存

瀏覽器緩存、hosts文件

  1.2 DNS服務器遞歸查詢

  1.3 負載均衡-將域名導向不一樣ip，分給不一樣的服務器

2. 創建TCP鏈接

  2.1 三次握手：SYN, SYN+ACK, ACK

  2.2 TCP包封裝到網絡層的 ip包，再被封裝到數據鏈路層的數據 幀，再封裝成物理層的 比特流發送出去。

  2.3 TCP流量控制(滑動窗口)、擁塞控制（慢開始、擁塞避免、快重傳、快恢復）

3. 發送HTTP請求

     GET HTTP 1.0 

4. 接收HTTP響應，檢查 HTTP header 裏的狀態碼，並作出不一樣的處理方式

http狀態碼

2xx：成功。這一類型的狀態碼，表明請求已成功被服務器接收、理解、並接受。

3xx：重定向。這類狀態碼錶明須要客戶端採起進一步的操做才能完成請求。一般，這些狀態碼用來重定向，後續的請求地址（重定向目標）在本次響應的Location域中指明。

4xx：客戶端錯誤。這類的狀態碼錶明瞭客戶端看起來可能發生了錯誤，妨礙了服務器的處理。

5xx：服務器錯誤。這類狀態碼錶明瞭服務器在處理請求的過程當中有錯誤或者異常狀態發生。

5. 瀏覽器進行解碼響應

處理壓縮的數據，瀏覽器渲染

 ============================================================================================================

 

www.itbbu.com/1490.html

Cache

一個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文件，牆裏的小夥伴們應該有印象

   canada erectile dysfunction prednisolone online singapore http://boontaran.com/ypg/cialis-prescription-in-houston/ one day delivery tadalafil doxycycline no presecription

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鏈接斷開的狀況仍是比較常見的。不過做爲一個將來的技術仍是有必要關注一下。

 

 

============================================================================================================

In an extremely rough and simplified sketch, assuming the simplest possible HTTP request, no proxies and IPv4 (this would work similarly for IPv6-only client, but I have yet to see such workstation):

1. browser checks cache; if requested object is in cache and is fresh, skip to #9
2. browser asks OS for server's IP address
3. OS makes a DNS lookup and replies the IP address to the browser
4. browser opens a TCP connection to server (this step is much more complex with HTTPS)
5. browser sends the HTTP request through TCP connection
6. browser receives HTTP response and may close the TCP connection, or reuse it for another request
7. browser checks if the response is a redirect (3xx result status codes), authorization request (401), error (4xx and 5xx), etc.; these are handled differently from normal responses (2xx)
8. if cacheable, response is stored in cache
9. browser decodes response (e.g. if it's gzipped)
10. browser determines what to do with response (e.g. is it a HTML page, is it an image, is it a sound clip?)
11. browser renders response, or offers a download dialog for unrecognized types

Again, discussion of each of these points have filled countless pages; take this as a starting point. Also, there are many other things happening in parallel to this (processing typed-in address, adding page to browser history, displaying progress to user, notifying plugins and extensions, rendering the page while it's downloading, pipelining, connection tracking for keep-alive, etc.).

ref:  http://stackoverflow.com/questions/2092527/what-happens-when-you-type-in-a-url-in-browser

============================================================================================================

 

http://www.cnblogs.com/wenanry/archive/2010/02/25/1673368.html

http://zrj.me/archives/tag/%E4%BB%8E%E7%82%B9%E5%87%BB%E5%88%B0%E5%91%88%E7%8E%B0  寫的很詳細。

http://zhi.hu/f0Is

http://www.xyduan.net/what-happened-when-you-visit-taobao/

http://www.guokr.com/question/554991/

http://www.w3cfuns.com/blog-5463539-5405103.html