初識WEB：輸入URL以後的故事【轉】

　　轉載一篇文章，分析的是瀏覽器輸入url後所執行的一系列操做！寫得很是清晰易懂，分享給你們！

做者：Jesse 出處： http://jesse2013.cnblogs.com/

本文版權歸做者和博客園共有，歡迎轉載，但未經做者贊成必須保留此段聲明，且在文章頁面明顯位置給出原文鏈接，不然保留追究法律責任的權利。若是以爲還有幫助的話，能夠點一下右下角的【推薦】，但願可以持續的爲你們帶來好的技術文章！想跟我一塊兒進步麼？那就【關注】我吧。

 

原博文以下：

　　1. 概述
　　2. HTTP請求過程
　　3. 相關性能檢測及優化手段
　　4. 瀏覽器的呈現過程
　　5. 瀏覽器的呈現引擎
　　6. 引用及延伸閱讀

概述

　　爲何輸入www.cnblogs.com以後敲一個回車，瀏覽器就會顯示咱們所看到的內容？這傢伙在背後到底偷偷的幹了哪些事情？今天咱們就來挖掘一下這背後的故事。

HTTP請求過程

　　爲直觀明瞭，先上一張圖:

 　　　　

　　畫完以後，才發現原來個人字寫的這麼難看，別噴我，小夥伴們！

　　下面是詳細的步驟以及說明：

1. 輸入URL,敲回車。
2. 針對當前URL檢查是否存在本地緩存， 若是存在，則會加載本地緩存進行呈現。如圖，通過 (1)-> (2) ->(9) ->(10)。 ( 感謝「我是你的豬」的糾錯 :) )
3. 根據URL找到對應的IP地址。這一步一般被稱爲DNS輪詢，這裏面是有緩存機制的。緩存的順序依次爲：瀏覽器緩存->操做系統緩存->路由器緩存->DNS提供商緩存->DNS提供商輪詢。
4. 創建TCP鏈接到上一步找到的機器
5. 用上一步創建的鏈接發送http request
6. 等待並接收http response
7. 關閉TCP鏈接，視狀況而定，http1.1已經支持keep-alive。那麼這個TCP請求是能夠被後面的request利用的，這樣就能夠減小不斷創建鏈接而形成的損失。
8. 檢查狀態碼，若是response的狀態碼出現3XX(跳轉)，未受權（401），錯誤（4XX和5XX）會有不一樣的處理。
9. 準備呈現，若是response status 爲304（內容未更改）瀏覽器則會從原本緩存加載內容進行呈現。
10. 呈現

相關性能檢測及優化手段

　　在不少瀏覽器的輔助工具中，大都將上述步驟分爲了如下5 個：

1. DNS輪詢
2. 創建鏈接
3. 發送請求
4. 等待響應
5. 接受請求

 

　　咱們經過查看這個時間線，就能夠粗略知道咱們的網站是否有性能問題以及問題出在哪裏？而後咱們就能夠針對性的解決。

　　拿上圖舉例，第4步「等待響應」所花的時間爲3.03秒。所謂等待響應主要是頁面的處理時間，好比說查詢數據庫、業務邏輯處理計算等等直接最後把html代碼封裝成response返回。（關於IIS的請求處理過程咱們後面再探討）若是這一步的時間過長，那咱們就要考慮從後臺動態代碼處理邏輯，以及數據查詢方面下手去找問題了。另外須要監控併發量，是否服務器同時處理的請求過多致使處理時間過長等。

　　第3步和第5步若是時間過長，咱們能夠經過如下方式來解決。

1. Request會攜帶cookie傳輸，這就是除了安全性考慮之外爲何咱們建議限制cookie數據和大小的緣由。
2. Response 若是是html代碼咱們能夠考慮代碼壓縮和gzip壓縮。
3. 靜態資源能夠採用其它的方式直接壓縮。
4. 創建CDN網絡服務不一樣地域的用戶。

瀏覽器的呈現過程

　　這裏有一個略虛的問題，當咱們輸完www.cnblogs.com以後，究竟是一個http請求，仍是多個？

　　

　　咱們或許能夠說，只有一個請求是直接產生的，然後面一堆的請求是取絕於咱們所輸入的URL。咱們能夠看到第一個請求的Path就是咱們輸入的URL，當這個請求的類型爲text/html的時候，也就是說這個請求返回給咱們的是html代碼。那麼瀏覽器會去呈現這個頁面。

      可是若是咱們直接輸入：http://common.cnblogs.com/script/jquery.js 這個時候固然瀏覽器不會去發起其它請求（前提條件是這個JS裏面沒有主動去請求其它資源的狀況下）。而瀏覽器對於每一種請求類型的處理方式是不同的，像text/html、application/JavaScript、text/plain等等這些是能夠直接呈現的，而對於不能呈現的類型，瀏覽器會將該資源下載到本地。

 

　　總的來講，實際的請求數量是1+這個請求資源裏面所包含其它資源的數量。

　　接下來，咱們主要看一下，瀏覽器若是呈現text/html類型的請求。上面咱們講到的http的請求過程當中的第6步瀏覽器已經拿到了返回結果即response。

   

      那麼瀏覽器在確認這個response的狀態不是301（跳轉）或者401（未受權）或其它須要作特殊處理的狀態，以後開始進入呈現過程。

瀏覽器的呈現引擎

　　呈現引擎：負責顯示請求的內容。若是請求的內容是 HTML，它就負責解析 HTML 和 CSS 內容，並將解析後的內容顯示在屏幕上。默認狀況下，呈現引擎可顯示 HTML 和 XML 文檔與圖片。經過插件（或瀏覽器擴展程序），還能夠顯示其它類型的內容；例如，使用 PDF 查看器插件就能顯示 PDF 文檔。這裏咱們主要討論它的主要功能：顯示使用 CSS 格式化的 HTML 內容和圖片。

　　呈現引擎的處理步驟包括4個：

 

1. 解析html轉換成DOM樹。瀏覽器有一個內置組件叫HTML解析器，會遍歷HTML代碼去生成DOM樹。
2. 結合部分CSS樣式將DOM樹轉換成呈現樹（這裏面的樣式包括顏色尺碼等）。這裏有瀏覽器的另一個內置組件叫CSS解析器會遍歷全部的CSS內容行成一組樣式規則。這裏面的CSS解析器和上一步的HTML解析器是同時進行的，以後會將樣式規則附加到DOM樹上就造成了咱們的呈現樹。
3. 經過呈現樹構建佈局樹，主要是爲每個DOM元素分配了一個應出如今屏幕上的確切座標。
4. 遍歷呈現樹，繪製每個節點。

 

 

　　爲了縮短整個呈現的過程，瀏覽器不會等到全部的DOM樹和全部的樣式規則都準備好再進行顯示。而是一邊解析一邊顯示，若是後面有JavaScript改變了某一些元素的樣式屬性則會致使重流（Reflow）和重繪(Repaint)。關於什麼是重流和重繪這裏就不詳述了，網上有不少相關的資料，有興趣的同鞋能夠戳這裏：重流和重繪

    這是個人第一篇博客，主要是想對本身所掌握的知識有一個總結，也查看了不少網上的資料以及前輩們的博客J。固然也是想跟你們分享關於web方面的知識，個人側重點主要在於web的一些運行機制，後面還會繼續，下一篇將討論一下關於IIS以及ASP.NET的運行機制，歡迎你們拍磚。

 引用及延伸閱讀

1. 瀏覽器工做原理：http://ux.sohu.com/topics/50972d9ae7de3e752e0081ff
2. What happens when you navigate to a URL: http://igoro.com/archive/what-really-happens-when-you-navigate-to-a-url/　
3. 前端必讀之Best Practices for Speeding Up Your Web Site：http://developer.yahoo.com/performance/rules.html

------------------------------------------------

　　博主經營一家髮飾淘寶店，都是純手工製做哦，開業衝鑽，只爲信譽！須要的親們能夠光顧一下！謝謝你們的支持！
店名：
　　小魚尼莫手工飾品店
經營:
　　髮飾、頭花、髮夾、耳環等（手工製做）
網店：
　　http://shop117066935.taobao.com/

  ---------------------------------------------------------------------