【轉載】ASP.NET之旅--深刻淺出解讀IIS架構

在學習Asp.net時，發現大多數做者都是站在一個比較高的層次上講解Asp.Net。 他們耐心、 細緻地告訴你如何一步步拖放控件、 設置控件屬性、編寫 CodeBehind代碼，以實現某個特定的功能。這種作法，其實是回答了「如何去作」的問題，卻沒有回答「爲何能夠這樣作」的問題。這樣有它的好處， 就是能夠快速開發。 但建議多掌握一點底層知識，對一些問題會有更好的理解。但願經過這篇文章的，可讓你更好的理解IIS和 Asp.Net的運做原理。

    思考「爲何在地址欄輸入 www.baidu.com就能夠看到百度主頁？」相似於思考「爲何蘋果是往地上掉不是往天上飄？」。 對於普通訪問者來講， 這就像天天太陽東邊升起西邊落下同樣是理所固然的。 對於不少程序員來講， 認爲這個與己無關，不過是系統管理員或者網管員的責任。畢竟，IIS 是Windows的一個組件，又不是Asp.Net的一個組成部分。而實際上，從你輕拍回車到頁面呈如今你眼前的十分之一秒內，IIS 和.Net Framework已經作了大量的幕後工做，而且在IIS7.0之後的版本中Asp.net已經成爲IIS的核心。

1、初識IIS

    IIS全稱爲Internet Information Server（網絡信息服務管理器），它是微軟公司主推的Web服務器。也就是說在理解IIS時首先咱們應該把咱們的電腦看作是一個網絡服務器，而IIS就是管理網絡信息的服務器管理程序。

    IIS有了基本的理解後咱們再來看一個完整的網絡請求，以下圖：

    客戶端在請求網頁時首先要在網頁中輸入靜態的IP地址或者網站域名，通過域名解析後若是請求的地址存在且合法則請求的內容會發送到服務器上。當服務器接收到一個  Http 請求的時候，IIS  首先須要決定如何去處理這個請求（如：服務器處理一個.htm 頁面和一個.aspx頁面確定是不同的麼）。那 IIS 依據什麼去處理呢？答案是：根據文件的後綴名。

    服務器獲取所請求的頁面（也能夠是文件，如：sun.jpg）的後綴名之後，接下來會在服務器端尋找能夠處理這類後綴名的應用程序， 若是 IIS找不到能夠處理此類文件的應用程序，而且這個文件也沒有受到服務器端的保護（如：一個受保護的例子就是App_Code中的文件， 一個不受保護的例子就是你的js腳本），那麼 IIS 將直接把這個文件返還給客戶端，若是IIS找到可處理的此類文件的應用程序後會使用託管代碼對它進行編譯，而後在返回到管道繼續執行，最後返還回客戶端。

    可以處理各類後綴名的應用程序，一般被稱爲ISAPI（在下面咱們會講到）應用程序。雖然這ISAPI聽上去還挺氣派，也算是「應用程序」呢，但仔細看看它的全稱就明白了，它實際上只是一個接口，起到一個代理的做用，它的主要工做是映射所請求的頁面(文件)和與此後綴名相對應的實際的處理程序。

    如今咱們對網絡請求有了初步的認識，可是還有不少疑問。IIS在收到HTTP請求後是如何對信息進行解析處理的，它內部的工做原理又是什麼樣的。不要着急，接下來咱們立刻說明。

2、再看IIS

    首先來看下IIS的基本構成。

    在向下解析IIS前咱們要先認識些專有名字，這些名詞都是IIS內重要的組成部分。

  一、何爲請求管道

    對於IIS的初級開發人員來講，請求管道是一個很新的名詞，它的做用和咱們日常生活中所看到的管道是相同的，IIS在運行時會在應用程序池中建立一個運行管道，這個管道把HTTP的請求服務集成到了一塊兒。

    那麼這個請求管道就是集成了HTTP請求所須要的全部步驟的內容。ASP.NET使用的就是管道模式來處理的HTTP請求。

  二、何爲託管代碼

    託管是NET的一個專門概念，它是一種編程理念，使用託管實現了對程序語言的相互轉化，能夠說它是一種中間語言，等同於咱們現實生活中的翻譯器，實現了編程語言的通用轉換，所以徹底能夠把「託管」視爲「.NET」。

    託管代碼也是如此，簡單點說，託管代碼是微軟的中間語言，他主要的做用是在.NET的CLR執行代碼前去編譯源代碼，也就是說託管代碼充當着翻譯的做用，源代碼在運行時分爲兩個階段：

      ① 源代碼編譯爲託管代碼；（因此源代碼能夠有不少種，如VB,C#)；

      ② 託管代碼編譯爲微軟系統的.net平臺專用文件(如類庫、可執行文件等)。

    它就好像是咱們現實生活中的翻譯人員，兩個國家之間的語言每每是不一樣的，可是爲了實現交流就必須由翻譯人員實現語言託管。

三、何爲ISAPI

    ISAPI是網絡服務應用程序接口，全稱是Internet Server Application Programming Interface。仔細看看它的全稱就能夠明白，它實際上只是一個接口，起到一個代理的做用。

    ISAPI主要分爲ISA和ISAPIFilter兩部分。ISA方法相對而言要傳統一些，利用一些特殊的連接，指向服務器的做業，供程序開發人員設計一些擴展功能；而ISAPI過濾器則傾向於構造服務器直接調用的模塊，提供一種無縫連接部件用於監測直接來自於服務器的HTTP請求。

    簡單的講，ISAPI咱們能夠理解爲一種語言編譯器。asp.net或其它程序語言文件，如：PHP、JSP等傳輸到ISAPI後，根據文件擴展名的不一樣映射所請求的頁面(文件)，讓與此後綴名相對應的實際的處理程序來接管。由應用程序接管的，擴展名爲.exe；由應用程序擴展接管的，擴展名爲.dll。這種託管須要獲取指定語言的映射機制，通常爲DLL文件，例如:ASP對應的ISAPI映射爲:"%SYSTEMROOT%\inetsrv\asp.dll"。

    在咱們平常生活中這種請求機制隨意可見，公司的部門的分配就是很好的實例典範。當一項業務分配到該公司後，公司老闆會根據業務的不一樣來指定部門處理請求，老闆分配業務就是一種映射關係，各個部門收到指令後去處理業務就是一種代碼的託管機制。

3、解讀IIS內部運行機制

    IIS7.0提供了兩種管道的託管模式，它們分別是：經典管道模式和集成管道模式。經典管道模式是IIS7.0之前的請求模式，這種模式擴展繁瑣，運行效率也比較低下。IIS7.0發生了翻天覆地的變化，就連底層的代碼庫也是從新進行編寫的，可是微軟爲了IIS的兼容性，仍然爲用戶保存了經典的託管模式。

     以下圖爲IIS兩種託管模式的運行機制：

一、經典管道託管模式

    圖1中採用的是經典管道託管模式，HTTP進入請求管道後首先要進行身份驗證，驗證方式有多種，驗證完成後要肯定執行處理程序，若是這個文件是一個ASP.NET文件，將執行託管，退出請求管道轉入ASP.NET ISAPI過濾器。經過ISAPI的處理後，這個請求還將返回管道，而後在向下請求管道，執行發送響應，寫入請求日誌，並將請求信息發送給客戶端。

    圖1中，ASP.NET扮演了一個ISAPI過濾器的角色（ASP.NET只是ISAPI的一個插件），也就是說，請求退出管道後，由aspnet.dll進行處理，而後返回到管道進行進一步處理，最終將響應返回給客戶端。

    這種經典的託管模式有不少缺點，其一，擴展繁瑣，開發人員要本身編寫程序運行所須要的ISAPI過濾器，但對於通常的程序猿來講這是很困難的時；其二，執行效率低，在執行ISAPI過濾時要退出請求管道運行應用程序實現過濾，增長了應用程序個數，浪費了內存空間；其三，安全性差。其中最主要的是安全問題，它在運行時要退出管道，查找映射，若是被影射的DLL文件不存在，則不能向下執行，致使執行出錯（常見的錯誤如：映射出錯）。雖然這種託管模式已被修改，可是IIS 7.0繼續提供了這種模式，主要是考慮到程序兼容性問題，若是在集成模式下不能使用，能夠遷移到經典模式中。

  二、集成管道託管模式             

    要想深刻理解集成管道模式的好處，首先咱們要了解集成的概念，集成是說把某一模塊可以做爲處理的一個步驟加入其中，並且這種集成是很是靈活的，開發人員能夠任意指定要集成的託管代碼，如：ASP.NET、PHP等。

    此時在看集成的優點就會發現，集成模式不只加強了IIS的靈活性，並且使得HTTP請求模式更加安全。其一，集成模塊的託管代碼能夠由開發人員自行制定，而且模塊能夠成爲管道的組成部分；其二，它去除了複雜的ISAPI的映射託管過程，在請求時能夠 直接由相應的編譯環境來執行請求，使得編譯過程更加安全。ASP.NET的性能之因此可以獲得改善，也是由於ASP.NET應用程序集成到管道中，在請求時再也不須要退出管道並加載ISAPI進程來處理ASP.NET代碼，而後再返回到管道爲客戶提供響應信息。        

    若是咱們把ASP.NET集成到IIS管道中，那麼此時ASP.NET就成爲IIS7.0的核心。能夠在管道中處理ASP.NET文件，這樣能夠在處理過程的任意一個步驟使用ASP.NET代碼。由於ASP.NET已經成爲管道的一部分了。因此，諸如身份驗證之類的ASP.NET功能也能夠用於處理非ASP.NET內容（如：StaticFile、Image、HTML等）。每一個請求均可以由IIS和ASP.NET進行處理，而沒必要考慮其所屬類型。

4、應用程序池、應用程序和虛擬目錄

    管道模式是針對應用程序池的，IIS在工做時會在應用程序池中建立請求管道，簡單的講應用程序池是用來存放請求管道的。在建立網站時會建立一個應用程序咱們稱之爲根應用程序，使用（/）表示，同時也默認建立該網站的應用程序池，可是咱們也能夠爲請求管道隨意指定應用程序池，同時也修改了應用程序所在的應用程序池。也就是說應用程序的執行是基於HTTP請求管道的。

    虛擬目錄是一個指針，它指向了本地物理地址或者遠程服務器上的某個地址。在建立應用程序時會默認建立一個虛擬目錄，那就是應用程序所指的根虛擬目錄，也用（/）表示。

    應用程序是由一些文件和文件夾組成的集合，這些文件和文件夾能夠經過諸如HTTP或HTTPS等協議爲外界提供服務。一個應用程序下能夠指向多個本地物理地址，也就是能夠建立多個虛擬目錄。

    一個應用程序池中能夠包括多個應用程序。每一個網站至少包括一個應用程序（一個網站就是一個應用程序），即根應用程序，可是在必要狀況下，一個網站能夠包括多個應用程序。

    它們之間的關係以下圖：

    因此它們四者的關係就很明顯了應用程序池-->HTTP管道-->應用程序-->虛擬目錄。

    這種關係就至關於Windows系統中的文件夾和快捷方式之間的關係，咱們能夠把磁盤看作一個應用程序池，文件夾看作一個應用程序，而虛擬目錄就至關於文件夾內的快捷方式。若是咱們想要在文件夾中訪問一個文件但又不想讓文件保存在文件夾下，這時咱們能夠經過快捷方式來實現。咱們經過快捷方式可以實現快捷訪問文件夾中的內容，且不用指定安全級別。

5、思想昇華

    學習就好像VS中的錯誤處理機制同樣，遇到問題時就向上拋，拋的越高咱們看的東西越廣，一樣的道理站得高才能看得遠。在學習時咱們能夠嘗試多問爲何，只知道「如何去作」，不知道「爲何這樣作」，那咱們永遠學不到知識的精髓。

   （本文只對IIS架構進行了一些初步的解讀，若是想進一步研究IIS架構，爲你們推薦一本書《IIS7開發與管理徹底參考手冊》，這本書深刻研究了IIS7.0的架構及其新特性，在此基礎上深刻介紹瞭如何高效地管理IIS7.0。對IIS架構的熟知也是Web服務器管理員的必備課程。該書有翻譯版本的，看了後感受翻譯的不錯，幫助很大，若是不想買的話爲你們提供個看書的連接：http://book.51cto.com/art/200908/146040.htm。）

 

【轉自】http://blog.csdn.net/zhang_xinxiu/article/details/10312787