• <noscript id="eom2a"><optgroup id="eom2a"></optgroup></noscript>
    <tt id="eom2a"><small id="eom2a"></small></tt>
    <input id="eom2a"></input>
  • <div id="eom2a"><small id="eom2a"></small></div>
    <td id="eom2a"><small id="eom2a"></small></td>
  • 您的位置:知識庫 ? .NET技術

    IIS 內部運行機制

    作者: ※森林小居※  來源: 博客園  發布時間: 2012-07-25 16:34  閱讀: 27909 次  推薦: 96   原文鏈接   [收藏]  

      ASP.NET是一個非常強大的構建Web應用的平臺,它提供了極大的靈活性和能力以致于可以用它來構建所有類型的Web應用。

      絕大多數的人只熟悉高層的框架如: WebForms 和 WebServices — 這些都在ASP.NET層次結構的最高層。

      這篇文章的資料收集整理自各種微軟公開的文檔,通過比較 IIS5、IIS6、IIS7 這三代 IIS 對請求的處理過程, 讓我們熟悉 ASP.NET的底層機制并對請求(request)是怎么從Web服務器傳送到ASP.NET運行時有所了解。通過對底層機制的了解,可以讓我們對 ASP.net 有更深的理解。

      IIS 5 的 ASP.net 請求處理過程

      對圖的解釋:

      IIS 5.x 一個顯著的特征就是 Web Server 和真正的 ASP.NET Application 的分離。作為 Web Server 的IIS運行在一個名為 InetInfo.exe 的進程上,InetInfo.exe 是一個Native Executive,并不是一個托管的程序,而我們真正的 ASP.NET Application 則是運行在一個叫做 aspnet_wp 的 Worker Process 上面,在該進程初始化的時候會加載CLR,所以這是一個托管的環境。

      ISAPI: 指能夠處理各種后綴名的應用程序。 ISAPI 是下面單詞的簡寫 :Internet Server Application Programe Interface,互聯網服務器應用程序接口。

      IIS 5 模式的特點:

      1、首先,同一臺主機上在同一時間只能運行一個 aspnet_wp 進程,每個基于虛擬目錄的 ASP.NET Application 對應一個 Application Domain ,也就是說每個 Application 都運行在同一個 Worker Process 中,Application之間的隔離是基于 Application Domain 的,而不是基于Process的。

      2、其次,ASP.NET  ISAPI 不但負責創建 aspnet_wp Worker Process,而且負責監控該進程,如果檢測到 aspnet_wp 的 Performance 降低到某個設定的下限,ASP.NET  ISAPI 會負責結束掉該進程。當 aspnet_wp 結束掉之后,后續的 Request 會導致 ASP.NET ISAPI 重新創建新的 aspnet_wp Worker Process。

      3、最后,由于 IIS 和 Application 運行在他們各自的進程中,他們之間的通信必須采用特定的通信機制。本質上 IIS 所在的 InetInfo 進程和 Worker Process 之間的通信是同一臺機器不同進程的通信(local interprocess communications),處于 Performance 的考慮,他們之間采用基于 Named pipe 的通信機制。ASP.NET ISAPI 和 Worker Process 之間的通信通過他們之間的一組 Pipe 實現。同樣處于 Performance 的原因,ASP.NET ISAPI 通過異步的方式將 Request 傳到 Worker Process 并獲得 Response,但是 Worker Process 則是通過同步的方式向 ASP.NET ISAPI 獲得一些基于 Server 的變量。

      IIS6 的 ASP.net 請求處理過程

      對圖的解釋:

      IIS 5.x 是通過 InetInfo.exe 監聽 Request 并把 Request 分發到Work Process。換句話說,在 IIS 5.x 中對 Request 的監聽和分發是在 User Mode 中進行,在IIS 6中,這種工作被移植到 Kernel Mode中 進行,所有的這一切都是通過一個新的組件 — http.sys 來負責。

      注:為了避免用戶應用程序訪問或者修改關鍵的操作系統數據,Windows 提供了兩種處理器訪問模式:用戶模式(User Mode)和內核模式(Kernel Mode)。一般地,用戶程序運行在 User mode 下,而操作系統代碼運行在 Kernel Mode 下。Kernel Mode 的代碼允許訪問所有系統內存和所有CPU指令。

      在 User Mode 下,http.sys 接收到一個基于 aspx 的 http request,然后它會根據 IIS 中的 Metabase 查看基于該 Request 的 Application 屬于哪個 Application Pool, 如果該 Application Pool 不存在,則創建之。否則直接將 request 發到對應 Application Pool 的 Queue中。

      每個 Application Pool 對應著一個 Worker Process — w3wp.exe,毫無疑問他是運行在 User Mode 下的。在 IIS Metabase 中維護著 Application Pool 和 Worker Process 的Mapping。WAS(Web Administrative Service)根據這樣一個 mapping,將存在于某個 Application Pool Queue 的 request 傳遞到對應的 Worker Process (如果沒有,就創建這樣一個進程)。在 Worker Process 初始化的時候,加載 ASP.NET ISAPI,ASP.NET ISAPI 進而加載 CLR。最后的流程就和 IIS 5.x 一樣了:通過 AppManagerAppDomainFactory 的 Create 方法為 Application 創建一個 Application Domain;通過 ISAPIRuntime 的  ProcessRequest 處理 Request,進而將流程進入到 ASP.NET Http Runtime Pipeline。

      IIS 7  的 ASP.net 請求處理過程

      IIS7 站點啟動并處理請求的步驟如下圖:  

      步驟 1 到 6 ,是處理應用啟動,啟動好后,以后就不需要再走這個步驟了。

      上圖的8個步驟分別如下:

      1、當客戶端瀏覽器開始 HTTP 請求一個WEB 服務器的資源時,HTTP.sys 攔截到這個請求。

      2、HTTP.sys 聯系 WAS 獲取配置信息。

      3、WAS 向配置存儲中心(applicationHost.config)請求配置信息。

      4、WWW 服務接收到配置信息,配置信息指類似應用程序池配置信息,站點配置信息等等。

      5、WWW 服務使用配置信息去配置 HTTP.sys 處理策略。

      6、WAS starts a worker process for the application pool to which the request was made.

      7、The worker process processes the request and returns a response to HTTP.sys.

      8、客戶端接受到處理結果信息。

      W3WP.exe 進程中又是如果處理的呢? IIS 7 的應用程序池的托管管道模式分兩種: 經典和集成。這兩種模式下處理策略各不相同。

      IIS 6 以及 IIS7 經典模式的托管管道的架構

      在 IIS7 之前,ASP.NET 是以 IIS ISAPI extension 的方式外加到 IIS,其實包括 ASP 以及 PHP,也都以相同的方式配置(PHP 在 IIS 采用了兩種配置方式,除了 IIS ISAPI extension 的方式,也包括了 CGI 的方式,系統管理者能選擇 PHP 程序的執行方式),因此客戶端對 IIS 的 HTTP 請求會先經由 IIS 處理,然后 IIS 根據要求的內容類型,如果是 HTML 靜態網頁就由 IIS 自行處理,如果不是,就根據要求的內容類型,分派給各自的 IIS ISAPI extension;如果要求的內容類型是 ASP.NET,就分派給負責處理 ASP.NET 的 IIS ISAPI extension,也就是 aspnet_isapi.dll。下圖是這個架構的示意圖。

      IIS 7 應用程序池的托管管道模式“經典”模式也是這樣的工作原理。這種模式是兼容 IIS 6 的方式, 以減少升級的成本。

      IIS6 的執行架構圖,以及 IIS7  應用程序池配置成經典模式的執行架構圖

      IIS  7 應用程序池的托管管道模式 — 集成模式

      而 IIS 7 完全整合 .NET 之后,架構的處理順序有了很大的不同(如下圖),最主要的原因就是 ASP.NET 從 IIS 插件(ISAPI extension)的角色,進入了 IIS 核心,而且也能以 ASP.NET 模塊負責處理 IIS 7 的諸多類型要求。這些 ASP.NET 模塊不只能處理 ASP.NET 網頁程序,也能處理其他如 ASP 程序、PHP 程序或靜態 HTML 網頁,也因為 ASP.NET 的諸多功能已經成為 IIS 7 的一部份,因此 ASP 程序、PHP 程序或靜態 HTML 網頁等類型的要求,也能使用像是 Forms 認證(Forms Authentication)或輸出緩存(Output Cache)等 ASP.NET 2.0 的功能(但須修改 IIS 7 的設定值)。也因為 IIS 7 允許自行以 ASP.NET API 開發并加入模塊,因此 ASP.NET 網頁開發人員將更容易擴充 IIS 7 和網站應用程序的功能,甚至能自行以 .NET 編寫管理 IIS 7 的程序(例如以程序控制 IIS 7 建置網站或虛擬目錄)。

    IIS 7 的執行架構圖(集成托管信道模式下的架構)

      小結

      IIS5 到 IIS6 的改進,主要是 HTTP.sys 的改進。

      IIS6 到 IIS7 的改進,主要是 ISAPI 的改進。

      參考資料:

      ASP.NET Process Model之一:IIS 和 ASP.NET ISAPI

      http://www.cnblogs.com/artech/archive/2007/09/09/887528.html

      ASP.NET Internals – IIS and the Process Model

      http://dotnetslackers.com/articles/iis/ASPNETInternalsIISAndTheProcessModel.aspx

      模組化的IIS 7 與.NET 能力整合

      http://www.microsoft.com/taiwan/technet/columns/profwin/33-iis7-componentization-integration.mspx

      Introduction to IIS 7.0 Architecture

      http://learn.iis.net/page.aspx/101/introduction-to-iis7-architecture/

    96
    0
    標簽:IIS ASP.NET

    .NET技術熱門文章

      .NET技術最新文章

        最新新聞

          熱門新聞

            黄色网_免费在线黄色电影_黄色成人快播电影_伦理电影_黄色片