前言：在對(duì)ASP.NET網(wǎng)站進(jìn)行優(yōu)化的時(shí)候，往往不是只是懂得ASP.NET就足夠了的。 在優(yōu)化的過程中，一般先是找出問題可能存在的地方，然后證明找出的問題就是要解決的問題，確認(rèn)之后，在進(jìn)行一些措施。系列文章在結(jié)構(gòu)上的安排是這樣的：先講述前端的調(diào)優(yōu)，我會(huì)在文章的標(biāo)題后面標(biāo)上”前端”，如果是后臺(tái)代碼的調(diào)優(yōu)，我會(huì)在標(biāo)題上標(biāo)上”后端”，如果是數(shù)據(jù)庫設(shè)計(jì)的調(diào)優(yōu)，我會(huì)在標(biāo)題上標(biāo)上”數(shù)據(jù)庫”，希望大家多多提建議。

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

本篇的議題如下：

剖析頁面的解析過程

分析出可能存在的優(yōu)化點(diǎn)

剖析頁面的解析過程

頁面的解析過程，這里說的過程不是我們常說的ASP.NET頁面的生命周期的過程，而且瀏覽器請求一個(gè)頁面，然后瀏覽器呈現(xiàn)頁面的過程。

在本篇的文章中，我會(huì)先闡述頁面的解析過程，顯示從整體上闡述，然后在每一個(gè)點(diǎn)上提出優(yōu)化的方法。先整體，后局部。

當(dāng)瀏覽器在請求一個(gè)Web頁面是從URL開始的。下面就是過程描述：

1． 輸入U(xiǎn)RL地址或者點(diǎn)擊URL的一個(gè)鏈接

2． 瀏覽器根據(jù)URL地址，結(jié)合DNS，解析出URL對(duì)應(yīng)的IP地址

3． 發(fā)送HTTP請求

4． 開始連接請求的服務(wù)器并且請求相關(guān)的內(nèi)容（至于請求時(shí)怎么被處理的，我們這里暫時(shí)不討論，只是后面的文章要討論的問題）

5． 瀏覽器解析從服務(wù)器端返回的內(nèi)容，并且把頁面顯現(xiàn)出來，同時(shí)也繼續(xù)進(jìn)行其他的請求。

上面基本上就是一個(gè)頁面被請求到現(xiàn)實(shí)的過程。下面我們就開始剖析這個(gè)過程。

當(dāng)輸入U(xiǎn)RL之后，瀏覽器就要知道這個(gè)URL對(duì)應(yīng)的IP是什么，只有知道了IP地址，瀏覽器才能準(zhǔn)備的把請求發(fā)送到指定的服務(wù)器的具體IP和端口號(hào)上面。

瀏覽器的DNS解析器負(fù)責(zé)把URL解析為正確的IP地址。這個(gè)解析的工作是要花時(shí)間的，而且這個(gè)解析的時(shí)間段內(nèi)，瀏覽器不是能從服務(wù)器那里下載到任何的東西的。但是這個(gè)解析的過程是可以優(yōu)化的。試想，如果每次瀏覽器每次請求一個(gè)URL都需要解析，那么每次的請求都有一點(diǎn)的時(shí)間消耗，可能這個(gè)時(shí)間消耗很短，但是性能的提升就是一點(diǎn)點(diǎn)的“調(diào)”出來的。如果把對(duì)應(yīng)URL和IP地址緩存起來，那么當(dāng)再次請求相同的URL時(shí)，瀏覽器就不用去解析，而是直接讀取緩存，這樣勢必會(huì)快一點(diǎn)。

其實(shí)瀏覽器和操縱系統(tǒng)是提供了這樣的支持的。

當(dāng)獲得了IP地址之后，那么瀏覽器就向服務(wù)器發(fā)送HTTP的請求，下面我們就稍微看下這個(gè)發(fā)送請求是怎么樣被發(fā)送的：

1．    瀏覽器通過發(fā)送一個(gè)TCP的包，要求服務(wù)器打開連接

2．    服務(wù)器也通過發(fā)送一個(gè)包來應(yīng)答客戶端的瀏覽器，告訴瀏覽器連接開了。

3．    瀏覽器發(fā)送一個(gè)HTTP的GET請求，這個(gè)請求包含了很多的東西了，例如我們常見的cookie和其他的head頭信息。

這樣，一個(gè)請求就算是發(fā)過去了。

請求發(fā)送去之后，之后就是服務(wù)器的事情了，服務(wù)器端的程序，例如，瀏覽器清楚的文件是一個(gè)ASP.NET的頁面，那么服務(wù)器端就把請求通過IIS交給ASP.NET 運(yùn)行時(shí)，最后進(jìn)行一系列的活動(dòng)之后，把最后的結(jié)果，當(dāng)然，一般是以是以html的形式發(fā)送到客戶端。

其實(shí)首先到達(dá)瀏覽器的就是html的那些文檔，所謂的html的文檔，就是純粹的html代碼，不包含什么圖片，腳本，css等的。也就是頁面的html結(jié)構(gòu)。因?yàn)榇藭r(shí)返回的只是頁面的html結(jié)構(gòu)。這個(gè)html文檔的發(fā)送到瀏覽器的時(shí)間是很短的，一般是占整個(gè)響應(yīng)時(shí)間的10%左右。

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

如果此時(shí)在html文檔中，遇到了img標(biāo)簽，那么瀏覽器就會(huì)發(fā)送HTTP請求到這個(gè)img響應(yīng)的URL地址去獲取圖片，然后呈現(xiàn)出來。如果在html文檔中有很多的圖片，flash，那么瀏覽器就會(huì)一個(gè)個(gè)的請求，然后呈現(xiàn)。

到這里，大家也許感覺到這種方式有點(diǎn)慢了。確實(shí)這個(gè)圖片等資源文件的請求的部分也是可以優(yōu)化的。暫不說別的，如果每個(gè)圖片都要請求，那么就要進(jìn)行之前說的那些步驟：解析url，打開tcp連接等等。開連接也是要消耗資源的，就像我們在進(jìn)行數(shù)據(jù)庫訪問一樣，我們也是盡可能的少開數(shù)據(jù)庫連接，多用連接池中的連接。道理一樣，tcp連接也是可以重用的。但是重用也有問題：如果兩個(gè)圖片它們的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" /> 

請求這些圖片的時(shí)間消耗如下圖：

大家首先看到最上面的黃線的部分，這個(gè)黃線就代表了瀏覽器打開連接，黃線的后半部分為藍(lán)色，就表示瀏覽器請求到了html的文檔。

最上面的第二條藍(lán)線就表示第一個(gè)圖片已經(jīng)請求到了，此時(shí)請求這個(gè)圖片使用還是之前的一個(gè)tcp的連接。

大家在看到第三條線，前部分是黃色的，表示請求第二個(gè)圖片的時(shí)候又開了一個(gè)tcp的連接，這條線的后半部分為藍(lán)色，表示圖片已經(jīng)請求到了。

剩下的要請求的一些圖片都使用上一個(gè)tcp連接。

確實(shí)，tcp的連接時(shí)充分的被使用了，但是圖片下載的速度確實(shí)慢了，從圖中看出，圖片是一個(gè)個(gè)的順序的下載下來的。整個(gè)頁面的響應(yīng)時(shí)間可想而知。

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

其實(shí)這就是一個(gè)權(quán)衡的問題了。

實(shí)際上瀏覽器也是內(nèi)置了以一些優(yōu)化方式的，例如緩存圖片，腳本等?；蛘卟捎貌⑿邢螺d圖片的方式，談到并行下載，就如上圖所看到的，勢必會(huì)消耗更多的連接資源。 

原文標(biāo)題：【原創(chuàng)】構(gòu)建高性能ASP.NET站點(diǎn)之一 剖析頁面的處理過程（前端）

鏈接：http://www.cnblogs.com/yanyangtian/archive/2010/07/22/1782670.html 

【編輯推薦】

1. 添加設(shè)置ASP.NET Web時(shí)出現(xiàn)問題
2. 詳細(xì)說明ASP.NET 2.0功能支持
3. 強(qiáng)化部署ASP.Net 2.0配置應(yīng)用程序
4. 微軟PDC2009直擊：改進(jìn)ASP.NET 4運(yùn)行時(shí)
5. 詳解ASP.NET MVC 2自定義驗(yàn)證