ASP.NET的本質:IIS以及進程模式__.net

來源:互聯網
上載者:User
  ASP.net對於編寫WEB應用程式以及組件來說是一個很好的架構,但是由於他的龐大性對於很多人來說要瞭解他的每一個細節好象是否不太可能,我一直認為有必要瞭解一下基層結構的工作原理以便在設計時擷取更高的效能,在接下來的一系列文章中,我將要描敘一下WEB的生命週期,從當請求被伺服器接受開始,傳送到ASP.net管道處理一直到產生回送資訊(如:HTML)在管道處理後期。

介紹

  Microsoft Active Server Pages(微軟動態網頁服務),同樣也被大家稱為ASP,首先是在1996年末年發布的,為程式員提供一個用來建立WEB應用程式豐富複雜的架構。幾年後,他的基礎構造發展改進了很多,也就是大家現在所瞭解的ASP.net.ASP.net是一個用來構件WEB應用程式的架構,也就是說,他必須運行在WEB服務上,用客服端-服務端模型了表述的話通常是瀏覽器發送不同類型的資源請求到WEB伺服器。在出現動態伺服器資源產生技術(如CGI,PHP,JSP以及ASP),所有的WEB服務只能接受客服端的靜態資源請求並把他們回送到客服端。

  表面上看起來,這樣在服務端和用戶端的互動是非常的簡單。會話通過HTTP協議進行,他是一個建立在TCP和IP協議(用來在2個串連到不同類型的網路端點交換資料,如我們所知道的WWW全球資訊網)上的應用程式級協議。

  本質上任何動態伺服器技術需要運行在特定WEB服務上,同樣ASP.net緊密地和微軟網際網路資訊服務,也叫做IIS。

  不同的服務選擇不同的方式去產生動態資源等等。。。我們將要解析一下IIS是怎麼做到的當一個請求資訊一旦到達服務端以及最後回送到用戶端。

IIS and ISAPI 擴充

  如上面提到的,靜態資源不需要被伺服器處理;一旦這樣的資源請求到達伺服器,伺服器只需要從檔案系統中找到他的內容並且以位元組流形式發送到用戶端通過HTTP協議。靜態資源可以是圖片,javascript,CSS或者普通HTML頁面。很顯然伺服器需要知道怎樣去區分靜態和動態資源,動態資源需要如何被處理而不是直接發送回用戶端。因此出現了ISAPI擴充,ISAPI是網際網路服務應用程式編程的介面。ISAPI作為模組被執行如早期的Win32.dll.IIS依靠ISAPI來處理特定的資源。通過IIS映射ISAPI擴充和檔案的方式,把每種檔案擴充類型關聯到特定的ISAPI擴充,也就是說,當一個請求某種檔案的請求到達,IIS處理並轉到相應的ISAPI擴充,以確認這種請求能被處理。

  ISAPI擴充明顯需要符合一個通用介面,這樣他們才能被IIS調用並提供必要的資料用來處理請求和產生回送。

  .ASP副檔名被映射到asp.dll ISAPI擴充;在ASP處理時段,這個組件負責執行所有需要的任務去產生回送,也就是說,通過收集請求資訊,並使得他能夠在ASP頁面可用,其他ASP內部對象,解析並執行ASP頁面最後以HTML形式返回結果。

  儘管,這樣相對於CGI技術來說已經是很大的進步了,但是ASP.net更強大。

  在安裝ASP.net後,ASP.net配置IIS 把ASP.net指定的檔案請求重新導向到一個新的ISAPI擴充aspnet_isapi.dll.這個擴充有些不同於以前的asp.dll擴充。

表格I:aspnet_isapi.dll在IIS應用程式中的映射

Extension Resource Type
.asax ASP.NET 應用程式檔案. 常用的有 global.asax.
.ascx ASP.NET 使用者控制項檔案.
.ashx HTTP handlers, the managed counterpart of ISAPI extensions.
.asmx ASP.NET web services.
.aspx ASP.NET web pages.
.axd ASP.NET internal HTTP handlers.

除了表格1所列出的副檔名,ASP.net ISAPI擴充也管理其他一些通常不提供給瀏覽器訪問的檔案擴充類型,如Visual Studio工程檔案,資源檔以及設定檔。

  ASP.NET處理模型

  到目前為止,我們已經明白當請求一個asp.net檔案的請求傳到IIS後,他被轉遞到aspnet_isapi.dll,他是asp.net相關處理的主要進入點。實際上,這個擴充明顯依賴於系統上IIS的版本,因此處理模型是通過asp.net運行時通過有序的操作執行來處理請求並產生回送,也許有那麼一點改變。

  在IIS5.X,所有asp.net相關請求通過ISAPI擴充被分配到外部背景工作處理序叫做aspnet_wp.exe.ISAPI擴充,在IIS進程(inetinfo.exe)中運行,再傳遞控制權連同所有關於當前傳入請求的資訊到aspnet_wp.exe。2個進程間的通訊通過具名管道(眾所周知IPC[內部進程通訊]機制建立。ASP.NET背景工作處理序執行ISAPI擴充的大部分任務。注意一下每個WEB應用程式的實質,以及與IIS下不同虛擬目錄的通訊,他們在asp.net背景工作處理序同一個進程的上下文中被執行。為了實現讀取各自執行中上下文ASP.net引入了應用程式定義域的概念,縮寫AppDomains.他們可以被認為是一個輕量級的進程。更多的將在後面介紹。

  如果運行在IIS6上,aspnet_wp.exe進程沒有被使用,選擇一個更優的進程叫做w3wp.exe.同時,inetinfo.exe也不再用來傳遞HTTP請求到ISAPI擴充,儘管這樣他還是保持為其他協議的請求提供服務。雖然IIS6能夠運行在相容模式下並且類比之前的行為,但是相對於先前的IIS5處理模型有了很多的變化。相對早期最大改變,當處理模型運行在IIS5上,傳入進來的請求以lower-kernel-level形式然後傳遞到正確的ISAPI擴充,從而避免在內部資訊處理方面花費過多的操作。在下面的段落中,我們將進行更深入的研究。

  IIS5.0 處理模型

  在windows2000以及XP系統上這是預設的處理模型。如上所說他有IIS inetinfo.exe進程預設在TCP連接埠80監聽傳入的HTTP請求並且把他們推送進隊列等待處理。如果請求類型是asp.net,處理將委託給asp.net isapi擴充 aspnet_isapi.dll.這樣輪流通過具名管道與asp.net背景工作處理序通訊,最終背景工作處理序處理並傳遞請求到asp.net HTTP運行時環境。

  我們未提到過的元素—ASP.NET HTTP運行環境。目前他並不是我們這編文章的主題,他將在接下來的文章中被解析。HTTP運行時可以被看作一個黑色盒子,所有ASP.NET指定處理在這裡發生,所有的受管制代碼運行場所,從HTTP運行時一直到httphandler最終處理請求並產生回送都在這裡被處理。這裡還涉及到asp.net管道或http運行時管道。

  就這個模型有一個有趣的地方就是所有請求,一旦被ISAPI擴充處理,就被傳遞到asp.net背景工作處理序。每次啟用時間有且僅有一個進行執行個體,一個例外,後面討論。因此所運行在IIS上的asp.net web應用程式實際上也運行在背景工作處理序上。儘管如此,這並不意味著所有應用運行在同一個上下文上並共用他們所有的資料。值得一提,asp.net引入APPDomain概念,本質上是一種提供獨立和安全邊界的受管制輕量級進程。每個IIS虛擬目錄在一個APPDomain裡執行,他將自動載入到背景工作處理序只要資源是屬於第一次請求的應用程式。一旦appdomain被載入,換句話說,當前請求所有需要的程式集被載入到appdomain–實際上是傳遞到asp.net管道處理。若干appdomains能夠這樣運行在同樣的進程中,當多個請求對於同樣的appdomain能夠在多個線程出來。儘管如此,一個線程並不屬於一個appdomain,他能為多個不同的appdomians處理多個請求,但是同一個給定的時間一個線程屬於一個APPdomain.

  處於效能目的,背景工作執行緒能夠根據一些標準(通過MACHINCE.CONFIG檔案配置)被回收。這些標準包括進程生命週期,請求以及隊列數量,空閑時間,記憶體配置。一旦達到這些參數中一項臨界值,ISAPI擴充將產生一個新的背景工作處理序執行個體用來處理請求。實際上,先前的進程執行個體並沒有被關閉,但是他被終止服務等待的請求。

IIS6.0處理模型

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

  例外一個大變化相對先前的模型在IIS監聽所有傳入資料方面。在IIS5裡,由IIS進程,inetinfo.exe監聽指定的TCP連接埠。在IIS6中,傳入請求被處理並隊列在核心層級來替換先前通過核心驅動調用http.sys的使用者模式;這種方法有幾個優勢相對於先前的模式被叫作 kernel-level 請求隊列。


  一旦一個請求到達核心層級裝置驅動http.sys,然後發送到相應的應用程式集區隊列,每個隊列屬於一個指定的應用程式集區。

  背景工作處理序負責載入asp.net ISAPI擴充,依次載入 CRL 委派所有工作到HTTP運行時。

  W3WP.exe進程與IIS5下面的aspnet_wp.exe不同,他不是asp.net特有的,能夠用來處理任何類型的請求。什麼樣的ISAPI模組被載入類型根據需要的服務資源類型。 
相關文章

聯繫我們

該頁面正文內容均來源於網絡整理,並不代表阿里雲官方的觀點,該頁面所提到的產品和服務也與阿里云無關,如果該頁面內容對您造成了困擾,歡迎寫郵件給我們,收到郵件我們將在5個工作日內處理。

如果您發現本社區中有涉嫌抄襲的內容,歡迎發送郵件至: info-contact@alibabacloud.com 進行舉報並提供相關證據,工作人員會在 5 個工作天內聯絡您,一經查實,本站將立刻刪除涉嫌侵權內容。

A Free Trial That Lets You Build Big!

Start building with 50+ products and up to 12 months usage for Elastic Compute Service

  • Sales Support

    1 on 1 presale consultation

  • After-Sales Support

    24/7 Technical Support 6 Free Tickets per Quarter Faster Response

  • Alibaba Cloud offers highly flexible support services tailored to meet your exact needs.