ASP.NET的本質(zhì)之IIS以及進(jìn)程模式

2019-11-18 16:28:11

字體：大中小

供稿：網(wǎng)友

　　asp.net對于編寫WEB應(yīng)用程序以及組件來說是一個很好的框架，但是由于他的龐大性對于很多人來說要了解他的每一個細(xì)節(jié)好象是否不太可能，我一直認(rèn)為有必要了解一下基層結(jié)構(gòu)的工作原理以便在設(shè)計時獲取更高的性能，在接下來的一系列文章中，我將要描敘一下WEB的生命周期，從當(dāng)請求被服務(wù)器接受開始，傳送到ASP.net管道處理一直到生成回送信息(如：HTML)在管道處理后期。

　　介紹

　　Microsoft Active Server Pages(微軟動態(tài)網(wǎng)頁服務(wù))，同樣也被大家稱為ASP，首先是在1996年末年發(fā)布的，為程序員提供一個用來建立WEB應(yīng)用程序豐富復(fù)雜的框架。幾年后，他的基礎(chǔ)構(gòu)造發(fā)展改進(jìn)了很多，也就是大家現(xiàn)在所了解的ASP.net.ASP.net是一個用來構(gòu)件WEB應(yīng)用程序的框架，也就是說，他必須運(yùn)行在WEB服務(wù)上，用客服端-服務(wù)端模型了表述的話通常是瀏覽器發(fā)送不同類型的資源請求到WEB服務(wù)器。在出現(xiàn)動態(tài)服務(wù)器資源生成技術(shù)(如CGI，php，jsp以及ASP)，所有的WEB服務(wù)只能接受客服端的靜態(tài)資源請求并把他們回送到客服端。

　　表面上看起來,這樣在服務(wù)端和客戶端的交互是非常的簡單。會話通過HTTP協(xié)議進(jìn)行，他是一個建立在TCP和ip協(xié)議(用來在2個連接到不同類型的網(wǎng)絡(luò)端點(diǎn)交換數(shù)據(jù)，如我們所知道的WWW萬維網(wǎng))上的應(yīng)用程序級協(xié)議。

　　本質(zhì)上任何動態(tài)服務(wù)器技術(shù)需要運(yùn)行在特定WEB服務(wù)上，同樣ASP.net緊密地和微軟因特網(wǎng)信息服務(wù)，也叫做IIS。

　　不同的服務(wù)選擇不同的方式去生成動態(tài)資源等等。。。我們將要解析一下IIS是怎么做到的當(dāng)一個請求信息一旦到達(dá)服務(wù)端以及最后回送到客戶端。

　　IIS and ISAPI 擴(kuò)展

　　如上面提到的，靜態(tài)資源不需要被服務(wù)器處理;一旦這樣的資源請求到達(dá)服務(wù)器，服務(wù)器只需要從文件系統(tǒng)中找到他的內(nèi)容并且以字節(jié)流形式發(fā)送到客戶端通過HTTP協(xié)議。靜態(tài)資源可以是圖片，javascript,CSS或者普通HTML頁面。很顯然服務(wù)器需要知道怎樣去區(qū)分靜態(tài)和動態(tài)資源，動態(tài)資源需要如何被處理而不是直接發(fā)送回客戶端。因此出現(xiàn)了ISAPI擴(kuò)展，ISAPI是因特網(wǎng)服務(wù)應(yīng)用程序編程的接口。ISAPI作為模塊被執(zhí)行如早期的Win32.dll.IIS依靠ISAPI來處理特定的資源。通過IIS映射ISAPI擴(kuò)展和文件的方式，把每種文件擴(kuò)展類型關(guān)聯(lián)到特定的ISAPI擴(kuò)展，也就是說，當(dāng)一個請求某種文件的請求到達(dá)，IIS處理并轉(zhuǎn)到相應(yīng)的ISAPI擴(kuò)展，以確認(rèn)這種請求能被處理。

　　圖表1：在IIS5.0中配置ISAPI擴(kuò)展映射

　　ISAPI擴(kuò)展明顯需要符合一個通用接口，這樣他們才能被IIS調(diào)用并提供必要的數(shù)據(jù)用來處理請求和生成回送。

　　如圖1，.ASP擴(kuò)展名被映射到asp.dll ISAPI擴(kuò)展;在ASP處理時段，這個組件負(fù)責(zé)執(zhí)行所有需要的任務(wù)去生成回送，也就是說，通過收集請求信息，并使得他能夠在ASP頁面可用，其他ASP內(nèi)部對象，解析并執(zhí)行ASP頁面最后以HTML形式返回結(jié)果。

　　盡管，這樣相對于CGI技術(shù)來說已經(jīng)是很大的進(jìn)步了，但是ASP.net更強(qiáng)大。

　　在安裝ASP.net后，ASP.net配置IIS 把ASP.net指定的文件請求重定向到一個新的ISAPI擴(kuò)展aspnet_isapi.dll.這個擴(kuò)展有些不同于以前的asp.dll擴(kuò)展。

　　表格I：aspnet_isapi.dll在IIS應(yīng)用程序中的映射

　　ExtensionResource Type

　　.asaxASP.NET 應(yīng)用程序文件. 常用的有 global.asax.

　　.ascxASP.NET 用戶控件文件.

　　.ashxHTTP handlers, the managed counterpart of ISAPI extensions.

　　.asmxASP.NET web services.

　　.aspxASP.NET web pages.

　　.axdASP.NET internal HTTP handlers.

　　除了表格1所列出的文件擴(kuò)展名，ASP.net ISAPI擴(kuò)展也管理其他一些通常不提供給瀏覽器訪問的文件擴(kuò)展類型，如Visual Studio工程文件，資源文件以及配置文件。

　　ASP.NET處理模型

　　到目前為止，我們已經(jīng)明白當(dāng)請求一個asp.net文件的請求傳到IIS后，他被轉(zhuǎn)遞到aspnet_isapi.dll,他是asp.net相關(guān)處理的主要入口點(diǎn)。實際上，這個擴(kuò)展明顯依賴于系統(tǒng)上IIS的版本，因此處理模型是通過asp.net運(yùn)行時通過有序的操作執(zhí)行來處理請求并生成回送，也許有那么一點(diǎn)改變。

　　在IIS5.X，所有asp.net相關(guān)請求通過ISAPI擴(kuò)展被分配到外部工作進(jìn)程叫做aspnet_wp.exe.ISAPI擴(kuò)展，在IIS進(jìn)程(inetinfo.exe)中運(yùn)行,再傳遞控制權(quán)連同所有關(guān)于當(dāng)前傳入請求的信息到aspnet_wp.exe。2個進(jìn)程間的通信通過命名管道(眾所周知IPC[內(nèi)部進(jìn)程通信]機(jī)制建立。ASP.NET工作進(jìn)程執(zhí)行ISAPI擴(kuò)展的大部分任務(wù)。注意一下每個WEB應(yīng)用程序的實質(zhì)，以及與IIS下不同虛擬目錄的通訊，他們在asp.net工作進(jìn)程同一個進(jìn)程的上下文中被執(zhí)行。為了實現(xiàn)讀取各自執(zhí)行中上下文ASP.net引入了應(yīng)用程序域的概念，縮寫AppDomains.他們可以被認(rèn)為是一個輕量級的進(jìn)程。更多的將在后面介紹。

　　如果運(yùn)行在IIS6上，aspnet_wp.exe進(jìn)程沒有被使用，選擇一個更優(yōu)的進(jìn)程叫做w3wp.exe.同時，inetinfo.exe也不再用來傳遞HTTP請求到ISAPI擴(kuò)展，盡管這樣他還是保持為其他協(xié)議的請求提供服務(wù)。雖然IIS6能夠運(yùn)行在兼容模式下并且模擬之前的行為，但是相對于先前的IIS5處理模型有了很多的變化。相對早期最大改變，當(dāng)處理模型運(yùn)行在IIS5上，傳入進(jìn)來的請求以lower-kernel-level形式然后傳遞到正確的ISAPI擴(kuò)展，從而避免在內(nèi)部信息處理方面花費(fèi)過多的操作。在下面的段落中，我們將進(jìn)行更深入的研究。

　　IIS5.0 處理模型

　　在windows2000以及XP系統(tǒng)上這是默認(rèn)的處理模型。如上所說他有IIS inetinfo.exe進(jìn)程默認(rèn)在TCP端口80監(jiān)聽傳入的HTTP請求并且把他們推送進(jìn)隊列等待處理。如果請求類型是asp.net,處理將委托給asp.net isapi擴(kuò)展 aspnet_isapi.dll.這樣輪流通過命名管道與asp.net工作進(jìn)程通信，最終工作進(jìn)程處理并傳遞請求到asp.net HTTP運(yùn)行時環(huán)境。圖表2將具體描敘這個過程。

　　圖表2：IIS5.0處理模型

　　圖表2顯示一個我們尚未提到過的元素—ASP.NET HTTP運(yùn)行時環(huán)境。目前他并不是我們這編文章的主題，他將在接下來的文章中被解析。HTTP運(yùn)行時可以被看作一個黑色盒子，所有ASP.NET指定處理在這里發(fā)生，所有的受管制代碼運(yùn)行場所，從HTTP運(yùn)行時一直到httphandler最終處理請求并生成回送都在這里被處理。這里還涉及到asp.net管道或http運(yùn)行時管道。

　　就這個模型有一個有趣的地方就是所有請求，一旦被ISAPI擴(kuò)展處理，就被傳遞到asp.net工作進(jìn)程。每次活動時間有且僅有一個進(jìn)行實例，一個例外，后面討論。因此所運(yùn)行在IIS上的asp.net web應(yīng)用程序?qū)嶋H上也運(yùn)行在工作進(jìn)程上。盡管如此，這并不意味著所有應(yīng)用運(yùn)行在同一個上下文上并共享他們所有的數(shù)據(jù)。值得一提，asp.net引入APPDomain概念，本質(zhì)上是一種提供獨(dú)立和安全邊界的受管制輕量級進(jìn)程。每個IIS虛擬目錄在一個APPDomain里執(zhí)行，他將自動加載到工作進(jìn)程只要資源是屬于第一次請求的應(yīng)用程序。一旦appdomain被加載，換句話說，當(dāng)前請求所有需要的程序集被加載到appdomain–實際上是傳遞到asp.net管道處理。若干appdomains能夠這樣運(yùn)行在同樣的進(jìn)程中，當(dāng)多個請求對于同樣的appdomain能夠在多個線程出來。盡管如此，一個線程并不屬于一個appdomain，他能為多個不同的appdomians處理多個請求,但是同一個給定的時間一個線程屬于一個APPdomain.

　　處于性能目的，工作線程能夠根據(jù)一些標(biāo)準(zhǔn)(通過MACHINCE.CONFIG文件配置)被回收。這些標(biāo)準(zhǔn)包括進(jìn)程生命周期，請求以及隊列數(shù)量，空閑時間，內(nèi)存分配。一旦達(dá)到這些參數(shù)中一項臨界值，ISAPI擴(kuò)展將生成一個新的工作進(jìn)程實例用來處理請求。實際上，先前的進(jìn)程實例并沒有被關(guān)閉，但是他被終止服務(wù)等待的請求。

　　IIS6.0處理模型

　　IIS6是WINDOWS2003系統(tǒng)默認(rèn)的。在IIS5處理模型的上他有幾個改變和改進(jìn)。其中之一最大改變就是應(yīng)用程序池概念。在IIS5系列應(yīng)用程序上，即所有的appDomains—運(yùn)行在asp.net工作進(jìn)程上。為了在安全以及特性上完成一個出色的界定，IIS6處理模型允許應(yīng)用程序運(yùn)行在同一個工作進(jìn)程的不同拷貝上。每個應(yīng)用程序池能夠包含多個appdomains(運(yùn)行在單獨(dú)一個工作進(jìn)程拷貝上).換而言之，這個變化是從單一進(jìn)程運(yùn)行所有程序到多個進(jìn)程運(yùn)行每一個應(yīng)用池。這個模型也叫做工作過程隔離模式。

　　例外一個大變化相對先前的模型在IIS監(jiān)聽所有傳入數(shù)據(jù)方面。在IIS5里，由IIS進(jìn)程,inetinfo.exe監(jiān)聽指定的TCP端口。在IIS6中，傳入請求被處理并隊列在核心級別來替換先前通過核心驅(qū)動調(diào)用http.sys的用戶模式;這種方法有幾個優(yōu)勢相對于先前的模式被叫作 kernel-level 請求隊列。

　　圖表3 IIS6處理模型