【原創】構建高效能ASP.NET網站之一 剖析頁面的處理過程（前端）

構建高效能ASP.NET網站之一 剖析頁面的處理過程（前端）

　　前言：在對ASP.NET網站進行最佳化的時候，往往不是只是懂得ASP.NET就足夠了的。 在最佳化的過程中，一般先是找出問題可能存在的地方，然後證明找出的問題就是要解決的問題，確認之後，在進行一些措施。系列文章在結構上的安排是這樣的：先講述前端的調優，我會在文章的標題後面標上”前端”，如果是後台代碼的調優，我會在標題上標上”後端”，如果是資料庫設計的調優，我會在標題上標上”資料庫”，希望大家多多提建議。

 

 

　　系列文章連結：

　　構建高效能ASP.NET網站 開篇

　　構建高效能ASP.NET網站之一 剖析頁面的處理過程（前端）

　　構建高效能ASP.NET網站之二 最佳化HTTP請求(前端)

　　構建高效能ASP.NET網站之三 細節決定成敗

　　構建高效能ASP.NET網站 第五章—效能調優綜述（前篇）

　　大型高效能ASP.NET系統架構設計  

　　構建高效能ASP.NET網站 第五章—效能調優綜述（中篇）

　　構建高效能ASP.NET網站 第五章—效能調優綜述（後篇）  

　　構建高效能ASP.NET網站 第六章—效能瓶頸診斷與初步調優（上篇）—識別效能瓶頸

　　構建高效能ASP.NET網站 第六章—效能瓶頸診斷與初步調優（下前篇）—簡單的最佳化措施

　　構建高效能ASP.NET網站 第六章—效能瓶頸診斷與初步調優（下後篇）—減少不必要的請求  

　　構建高效能ASP.NET網站 第七章 如何解決記憶體的問題(前篇)—託管資源最佳化—記憶體回收機制深度剖析

　　構建高效能ASP.NET網站 第七章 如何解決記憶體的問題(前中篇)—託管資源最佳化—監測CLR效能

 

 

 

 

 

　　本篇主要剖析過程，讓大家有個全面的瞭解，下一篇就開始分步剖析了。

 

　　本篇的議題如下：

剖析頁面的解析過程

分析出可能存在的最佳化點

 

　　剖析頁面的解析過程

　　頁面的解析過程，這裡說的過程不是我們常說的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串連也是可以重用的。但是重用也有問題：如果兩個圖片它們的url地址如下：

 

 

代碼

<img src="q1.gif" height="16" width="16" />

<img src="q2.gif" height="16" width="16" />

<img src="q3.gif" height="16" width="16" />

<img src="q4.gif" height="16" width="16" />

<img src="q5.gif" height="16" width="16" />

<img src="q6.gif" height="16" width="16" />

<img src="q7.gif" height="16" width="16" />

<img src="q8.gif" height="16" width="16" />

<img src="q9.gif" height="16" width="16" />

<img src="q10.gif" height="16" width="16" />

 

 

請求這些圖片的時間消耗如：

 

 

 

　　大家首先看到最上面的黃線的部分，這個黃線就代表了瀏覽器開啟串連，黃線的後半部分為藍色，就表示瀏覽器請求到了html的文檔。

 

　　最上面的第二條藍線就表示第一個圖片已經請求到了，此時請求這個圖片使用還是之前的一個tcp的串連。

 

　　大家在看到第三條線，前部分是黃色的，表示請求第二個圖片的時候又開了一個tcp的串連，這條線的後半部分為藍色，表示圖片已經請求到了。

 

　　剩下的要請求的一些圖片都使用上一個tcp串連。

 

　　確實，tcp的串連時充分的被使用了，但是圖片下載的速度確實慢了，看出，圖片是一個個的順序的下載下來的。整個頁面的回應時間可想而知。

 

　　如果採用下一種方式，如：

 

 

 

　　可以看出串連時多了，但是圖片的幾乎都是並行下載下來的，相比而言就快多了。

 

 

　　其實這就是一個權衡的問題了。

 

　　實際上瀏覽器也是內建了以一些最佳化方式的，例如緩衝圖片，指令碼等。或者採用並行下載圖片的方式，談到並行下載，就如所看到的，勢必會消耗更多的串連資源。 

 

　　今天主要對頁面的過程進行了初步的剖析，是的大家有個總體的把握，下一篇我們就開始逐步最佳化，敬請關注，也希望大家多多提出意見和反饋。先謝過了啊！ ：）

 

 

著作權為小洋和部落格園所有，歡迎轉載，轉載請標明出處給作者。

　　 http://www.cnblogs.com/yanyangtian