Web頁面的解析過程

博文轉自：http://hi.baidu.com/moniteryao/item/e851425177262ba8adc8577f

http://sd.csdn.net/a/20110212/291687.html

頁面的解析過程，這裏說的過程不是咱們常說的ASP.NET頁面的生命週期的過程，並且瀏覽器請求一個頁面，而後瀏覽器呈現頁面的過程。

在本篇的文章中，我會先闡述頁面的解析過程，顯示從總體上闡述，而後在每個點上提出優化的方法。先總體，後局部。

當瀏覽器在請求一個Web頁面是從URL開始的。下面就是過程描述：

1． 輸入URL地址或者點擊URL的一個連接。

2． 瀏覽器根據URL地址，結合DNS，解析出URL對應的IP地址。

3． 發送HTTP請求。

4． 開始鏈接請求的服務器而且請求相關的內容（至於請求時怎麼被處理的，咱們這裏暫時不討論，只是後面的文章要討論的問題）。

5． 瀏覽器解析從服務器端返回的內容，而且把頁面顯現出來，同時也繼續進行其餘的請求。

上面基本上就是一個頁面被請求到現實的過程。下面咱們就開始剖析這個過程。

當輸入URL以後，瀏覽器就要知道這個URL對應的IP是什麼，只有知道了IP地址，瀏覽器才能準備的把請求發送到指定的服務器的具體IP和端口號上面。

瀏 覽器的DNS解析器負責把URL解析爲正確的IP地址。這個解析的工做是要花時間的，並且這個解析的時間段內，瀏覽器不是能從服務器那裏下載到任何的東西 的。可是這個解析的過程是能夠優化的。試想，若是每次瀏覽器每次請求一個URL都須要解析，那麼每次的請求都有一點的時間消耗，可能這個時間消耗很短，但 是性能的提高就是一點點的「調」出來的。若是把對應URL和IP地址緩存起來，那麼當再次請求相同的URL時，瀏覽器就不用去解析，而是直接讀取緩存，這 樣勢必會快一點。

其實瀏覽器和操縱系統是提供了這樣的支持的。

當得到了IP地址以後，那麼瀏覽器就向服務器發送HTTP的請求，下面咱們就稍微看下這個發送請求是怎麼樣被髮送的：

1．    瀏覽器經過發送一個TCP的包，要求服務器打開鏈接。

2．    服務器也經過發送一個包來應答客戶端的瀏覽器，告訴瀏覽器鏈接開了。

3．    瀏覽器發送一個HTTP的GET請求，這個請求包含了不少的東西了，例如咱們常見的cookie和其餘的head頭信息。

這樣，一個請求就算是發過去了。

請求發送去以後，以後就是服務器的事情了，服務器端的程序，例如，瀏覽器清楚的文件是一個ASP.NET的頁面，那麼服務器端就把請求經過IIS交給ASP.NET 運行時，最後進行一系列的活動以後，把最後的結果，固然，通常是以是以html的形式發送到客戶端。

其 實首先到達瀏覽器的就是html的那些文檔，所謂的html的文檔，就是純粹的html代碼，不包含什麼圖片，腳本，css等的。也就是頁面的html結 構。由於此時返回的只是頁面的html結構。這個html文檔的發送到瀏覽器的時間是很短的，通常是佔整個響應時間的10%左右。

這樣以後，那麼頁面的基本的骨架就在瀏覽器中了，下一步就是瀏覽器解析頁面的過程，也就是一步步從上到下的解析html的骨架了。

若是此時在html文檔中，遇到了img標籤，那麼瀏覽器就會發送HTTP請求到這個img響應的URL地址去獲取圖片，而後呈現出來。若是在html文檔中有不少的圖片，flash，那麼瀏覽器就會一個個的請求，而後呈現。

到 這裏，你們也許感受到這種方式有點慢了。確實這個圖片等資源文件的請求的部分也是能夠優化的。暫不說別的，若是每一個圖片都要請求，那麼就要進行以前說的那 些步驟：解析url，打開tcp鏈接等等。開鏈接也是要消耗資源的，就像咱們在進行數據庫訪問同樣，咱們也是儘量的少開數據庫鏈接，多用鏈接池中的連 接。道理同樣，tcp鏈接也是能夠重用的。