IIS架構

1.   概述

爲了提高IIS的可靠性，安全性以及可用性，與IIS5.0和以前更早的版本不同，IIS6.0提供了一個全新的IIS架構。這個架構的詳細情況如下圖所示：

  
 
                                       （圖 1） IIS 6.0整體架構

由上可以看出，IIS 6.0的內核體系主要由如下三個組件構成：HTTP.SYS，W3SVC以及W3Core。作爲一個全新的架構，IIS6.0有如下讓人值得關注的新特點：
 

Ø      HTTP.SYS。全新的內核監聽模式。

Ø      IIS6.0新的應用程序隔離模式-工作進程隔離模式。

Ø      應用程序池。

Ø      工作進程。

Ø      Web管理服務（W3SVC）。

作爲一個平臺，IIS上面運行着很多web應用程序，並且提供了一系列的相關服務。在系統啓動階段，IIS以及IIS所包含的服務的啓動過程如下圖所示：

           （圖 2） IIS的啓動過程
 

2.   HTTP.SYS

2.1. 概述

HTTP.SYS 運行在windows 的內核模式下，作爲驅動程序而存在。它是Windows 2003的TCP/IP網絡子系統的一部分，從結構上說，它是TCP之上的一個網絡驅動程序，因此，HTTP.SYS不再屬於IIS，它已經從IIS中獨立了出來。在TCP/IP的基礎之上，HTTP.SYS的主要功能是：偵聽用戶的http請求（這個請求來自於TCPIP.sys驅動程序），並將請求轉發給相關的web應用程序處理，最後，HTTP.SYS將處理結果返回給用戶（返回到TCPIP.sys驅動程序）。

在HTTP.SYS的內部，它由如下的功能模塊組成：

ü    偵聽模塊。

ü    應答緩存模塊。

ü    請求隊列。

ü    響應發送模塊。

HTTP.SYS的內部組成結構圖如下圖：
    

              （圖 3）HTTP.SYS的內部結構
 

2.2. HTTP.SYS的可靠性

作爲在內核模式下運行的操作系統的驅動程序，HTTP.SYS擁有高度的可靠性和穩定性。它始終處於運行狀態，能夠對用戶的http請求作出快速的響應。

   在內核模式下，HTTP.SYS不執行任何用戶代碼，它只是監聽用戶的http請求。這些http請求中包含了IIS上運行的web站點所使用的IP地址和端口。因爲在HTTP.SYS中不運行任何的用戶代碼，所以即使用戶的web應用程序發生了故障，也不會影響到HTTP.SYS本身，它仍然能夠對用戶的http請求進行監聽，並及時作出反應。

在IIS 5.0或以前更早的版本中，對用戶的http請求進行監聽的功能是集成在Inetinfo.exe進程之中的。同時，有一部分用戶代碼也是運行在Inetinfo.exe進程之中的。在這種情況下，如果用戶代碼不穩定，或者由於其他原因導致了用戶代碼的崩潰，那麼Inetinfo.exe也會崩潰，這就導致了IIS的不穩定性。

    在IIS 6.0 中，引入了HTTP.SYS模塊，它運行在內核模式下，與Inetinfo.exe進程隔離開來，作爲操作系統的驅動程序運行。因此，HTTP.SYS不會受到用戶代碼的影響，它始終處於穩定運行狀態，對用戶的http請求進行監聽，並及時作出反應。IIS 6.0就是通過這種方式保證了它的穩定性和可靠性。

2.3. HTTP.SYS對請求的響應過程

HTTP.SYS監聽並接收用戶的http請求，之後對用戶的http請求做出迴應。它的具體操作流程如下圖所示：
     

                      （圖 4）數據請求
 

首先，用戶通過瀏覽器對部署在IIS中的web應用程序發出http請求。經過各種處理，這個http請求最終會到達TCPIP.SYS驅動程序，TCPIP.SYS將這個請求轉發給HTTP.SYS網絡驅動程序。在HTTP.SYS中，它的監聽模塊始終在監聽着網絡上是否有對它的http請求，當一個http請求到達以後，監聽模塊會對這個http請求進行分析，並根據請求的類型的不同，將這些請求進行排隊，等候應用程序池中的web應用程序對隊列中的請求進行處理。

在HTTP.SYS中，它維護着一張數據配置表，在這個表中記錄着URL與應用程序池之間的對應關係，HTTP.SYS會對http請求中的URL進行跟蹤。也就是說，HTTP.SYS註冊了所有IIS 6.0應用，並給每個工作進程賦予一個句柄，IIS內部利用這些句柄來標識、註冊應用程序要用到的一個或多個名稱空間。因此，當HTTP.SYS接收到一個 HTTP請求的時候，它能夠很快地將請求數據包從內核模式下的HTTP.SYS傳遞到正確的用戶模式下的Web應用。

如果在一個http數據請求包到達之後，相關的應用程序池還沒有啓動，那麼HTTP.SYS負責將這個應用程序池啓動。這種處理方式也叫做請求式啓動。

當一個http請求被處理完畢之後，處理的結果會返回到HTTP.SYS中，由HTTP.SYS中的響應發送模塊將這個處理結果返回到TCPIP.SYS中,並最終返回給用戶。
 

2.4.HTTP.SYS對數據的緩存

如果用戶對web網站上的某部分資源進行頻繁的http請求的話，HTTP.SYS會把對這個請求的響應結果進行緩存。當用戶下次對這部分資源進行請求的時候，HTTP.SYS會直接把在緩存中保存的響應結果直接發送給用戶。從用戶發送http請求到系統返回響應結果的這一過程都是HTTP.SYS在內核模式下完成的。不需要在內核模式和用戶模式下進行切換，這樣就極大地節省了系統資源，提高了請求的響應速度。有關HTTP.SYS數據緩存的過程如下圖所示：
     
                (圖 5)HTTP.SYS的緩存處理
 

2.5.HTTP.SYS的配置信息

HTTP.SYS作爲網絡驅動程序，它已經從IIS中分離了出來，它不再屬於IIS的一部分，因此HTTP.SYS的配置數據是存儲在註冊表中的，而不是IIS的配置數據庫中。在註冊表中，HTTP.SYS的註冊信息位於如下路徑下面：

HKEY_LOCAL_MACHINE/SYSTEM/CurrentControlSet/Services/HTTP。

 

2.26.HTTP.SYS的其他功能

管理TCP的連接

驗證HTTP請求

記錄IIS中的Web網站的日誌信息

實施帶寬限制策略以及支持TCP/IP級的管理

    實現客戶證書請求服務

3.   W3SVC

 

3.1.概述

   與IIS 5.0不同，W3SVC已經從Inetinfo.exe進程中分離了出來，在IIS中，它將作爲一個獨立的進程運行。根據配置數據的設置，W3SVC負責創建工作進程(W3Core)。在工作進程的運行過程中，W3SVC還負責監視它的運行狀態。

   作爲一個獨立運行的進程，W3SVC不包含任何第三方用戶代碼。所以，它不會受到web網站故障的影響，始終處於穩定的運行狀態。在此前提下，W3SVC能夠穩定地對web網站的運行情況進行監視，並在必要的時候採取行動。基於這一策略，服務器能夠根據用戶指定的參數監視和重新啓動應用程序。

3.2.IIS 5.0簡介

 在IIS 5.0中，web服務器進程(Inetinfo.exe)負責管理如下四個服務：

Ø      WWW服務

Ø      SMTP服務

Ø      FTP服務

Ø      NNTP服務

   其中，WWW服務負責創建，管理web應用程序的進程。同時，它還負責調度工作，即將用戶的http請求轉發給web應用程序，當web應用程序對用戶的 http請求處理完畢後，WWW服務還負責將處理結果返回給用戶。

   在web服務器進程（Inetinfo.exe）中，除了運行上面所說的四個服務外，它還可以運行第三方代碼，也就是web應用程序。

   IIS 5.0中，它的架構以及各個進程之間的關係如下圖所示：

  (圖6)IIS 5.0簡單架構圖
 

在IIS 5.0中，它提供了三個不同級別的應用程序保護，他們分別是：

Ø      低級別。IIS進程內，與IIS 1.0、IIS 2.0、IIS 3.0的單一結構一樣，web應用程序作爲web服務器進程（Intetinfo.exe）的一部分，它在web服務器進程內部運行。這樣做的好處是：提高了web應用程序的性能，能夠快速的對用戶的請求作出響應。但是，同時也降低了IIS的穩定性，一旦web應用程序崩潰，IIS也就同時崩潰了。

Ø      中級別。實現一個單獨的緩衝池進程（名爲DLLHost.exe的COM+宿主進程），這個緩衝池進程運行在Inetinfo.exe進程之外，多個web應用程序運行在緩衝池進程中。這樣就實現了web應用程序與Inetinfo.exe進程的隔離。Web應用程序出現故障也不會影響到Inetinfo.exe進程。在一定程度上保證了IIS的穩定性。但是，在緩衝池進程中，一旦有一個web應用程序崩潰，那麼整個緩衝池也就崩潰了，所有運行在緩衝池中的web應用程序都將停止工作。

Ø      高級別。實現一個單獨的緩衝池進程（名爲DLLHost.exe的COM+宿主進程），這個緩衝池進程運行在Inetinfo.exe進程之外，並且，有且僅有一個web應用程序運行在緩衝池中。這種高級別的保護，在IIS的穩定性方面，要比前兩種好的多。一個web應用程序的崩潰不會影響到其他web應用程序和IIS的運行。

   在IIS信息服務管理器中，通過如下方式設置應用程序的保護級別，如下圖：
    
              （圖 9）性能配置
 

路徑：開始菜單->管理工具->Internet信息服務管理器->應用程序池->屬性。

 

在這裏IIS提供了四種性能監控功能：

ü       對空閒超時的監控。如果工作進程一直處於空閒狀態，那麼當空閒時間達到設定的值後，W3SVC會關閉工作進程。

ü       請求隊列限制。如果用戶對工作進程的請求達到設定的上限後，W3SVC將會對用戶的請求進行限制。

ü       CPU監視。如果工作進程對CPU的佔用率超過設定的上限後，W3SVC會根據IIS的配置信息採取相應的措施。

ü       Web園。關於web園將會在後面的章節詳細介紹。

 

3.4.1.2應用程序運行狀況監控

在Internet信息服務管理器中，關於應用程序運行狀況監控的配置如下圖：

       
           （圖 10）運行狀況配置
     
 

路徑：開始菜單->管理工具->Internet信息服務管理器->應用程序池->屬性。

 

在這裏，IIS對應用程序池運行狀況的監控提供了四種功能：

ü       Ping。W3SVC會在設定的時間間隔內對工作線程執行Ping操作，以獲取工作線程的狀態信息。

ü       快速失敗保護。如果在指定的時間段內，一定數目的工作進程發生失敗，則W3SVC會禁用應用程序池。

ü       啓動時間限制。工作進程必須在設定的時間內開始。

ü      關閉時間限制。工作進程必須在設定的時間內關閉。

3.4.2.    應用程序池回收

在Internet信息服務管理器中，關於應用程序池回收的配置如下圖：
 
         （圖 11）回收
 

路徑：開始菜單->管理工具->Internet信息服務管理器->應用程序池->屬性。

在這裏，IIS提供了四種回收的方式：

ü       可以設定回收工作進程的時間間隔。

ü       可以根據對工作進程的請求數量進行回收，一但對工作進程的用戶請求數量超過設定值，系統就會執行對應用程序池的回收工作。

ü       定時回收。

ü       根據內存消耗進行回收。

應用程序發生故障，它通知W3SVC執行進程回收工作。

                （圖 13）

W3SVC啓動一個新的工作進程。舊的工作進程繼續執行未完成的用戶請求，但不接收新的用戶請求。
      
                    （圖 14）

新、舊工作進程之間通信，同步應用程序的狀態信息。當新工作進程完全獲得了舊工作進程中的應用程序狀態信息後，它通知W3SVC，表示它已經準備好了，可以接收用戶的http請求。
    
               （圖 15）

舊的進程完成其未決的請求，然後正常關閉，或者如果在達到了配置的時間限制、請求數、設置的時間計劃，或當達到指定的內存用量限制後仍沒有關閉，則明確地終止進程。新工作進程開始正式工作，接收用戶的http請求。

 

 

4.   W3Core

4.1.概述

W3Core又稱爲工作進程(Worker Process)或W3WP.exe。在默認情況下，IIS 6.0是在工作進程隔離模式下運行的。對於每一個web應用程序，IIS6.0都有一個或多個工作進程實例來運行它。

在W3SVC的管理和監控下，W3Core負責對用戶的web應用程序進行管理。它的主要功能是在一個名爲W3Core.dll的動態聯接庫中實現的。在IIS5.0隔離模式下，這個DLL可以被加載到Inetinfo.exe進程中；在應用程序隔離模式下，這個DLL可以被加載到W3WP.exe進程中。

4.2.用戶web應用程序（web Application）,應用程序池(Application Pools)與工作進程（Worker Process）之間的關係

ü      在IIS6.0中，每一個用戶web應用程序都會運行在一個應用程序池中。這個應用程序池可以是IIS默認的應用程序池，也可以是用戶自定義的應用程序池。

ü      作爲一個宿主程序，每個應用程序池中都會運行着一個或者多個用戶web應用程序。

ü      在應用程序池中，存在着一個或者多個工作進程。每個工作進程只能屬於一個特定的應用程序池，由這些工作進程來負責管理應用程序池中的用戶web應用程序。

他們的結構關係如下圖所示：
      
           （圖 16）應用程序池

如果，我們將應用程序池比喻成爲一座公寓，那麼在公寓裏面的那些住戶就是一個個web應用程序，而公寓的物業的管理人員就是工作進程。如果公寓比較大，住戶比較多，那麼就可能需要有多個物業管理人員。也就是說，每個應用程序池裏面可以有多個工作進程在工作。

4.3.W3Core在IIS安全性方面的考慮

在IIS6.0或更早的版本中，用戶的web應用程序是允許運行在進程內的。他們使用系統（System）帳戶運行。這個系統帳戶是：IWAM_計算機名。因爲是在系統帳戶下運行，所以這些web應用程序有比較高的權限。

在IIS6.0中，默認情況下，w3wp.exe的所有實例都在一個權限有限的“網絡服務”帳戶下運行。如下圖所示：
      
                （圖 17）網絡帳戶的配置

當然，用戶可以在需要的情況下爲W3WP.exe配置新的運行帳戶。

這樣做的好處是：一旦一個web應用被攻擊成功，攻擊者只能訪問當時運行的工作進程的帳戶有權訪問的資源，默認的網絡服務帳戶不能寫入Inetpub文件夾，執行權限也極其有限，所以在一定程度上提高了IIS的安全性。
 

4.4.W3Core在IIS性能方面的考慮

在IIS5.0中，由WWW服務負責將用戶的http請求轉發給web應用程序處理，並負責將web應用程序處理的結果返回給用戶。

這一處理的流程如下圖所示：

      
     （圖18）用戶請求的處理過程

在這個過程中，數據需要經過多次傳遞和轉化，這些傳遞和轉換主要包括：

ü       內核模式到用戶模式的轉化。TCPIP.sys運行在內核模式下，IIS運行在用戶模式下。這個轉化一項系統開銷很大的操作。

ü       IIS負責對用戶的http請求進行監聽。

ü       用戶http請求的需址過程。即，確定由哪個web應用程序來處理用戶的請求。這一工作需要IIS來完成。

因此，IIS5.0的這種對用戶的http請求的處理過程對IIS的性能有很大的影響。

在IIS6.0中，除了將WWW服務從Inetinfo.exe進程中獨立了出來，作爲一個單獨的組件（W3SVC）來處理外，還將接收用戶http請求的功能從W3SVC中分離了出來。接收用戶http請求的功能現在由W3Core來實現。W3SVC僅負責對W3Core進行創建和監控，不再負責對用戶http請求進行處理。因此，在處理用戶的http請求的時候，內核模式下的HTTP.SYS直接監聽用戶的http請求，並將用戶的http請求直接轉發給W3Core。並由W3Core所管理的web應用程序來處理用戶的http請求。

這一操作過程如下圖所示：
      
                   （圖 19）用戶請求的處理過程

通過這種方式,IIS6.0中處於內核模式下的HTTP.SYS直接與用戶應用程序通信。這就縮短了數據的請求、轉發過程，提高了IIS的性能。

5.   應用程序池

5.1.概述

作爲宿主程序，在應用程序池中存在着一個或者多個web應用程序，並且由一個或者多個工作進程來管理這些web應用程序。在W3SVC的監控和管理下，應用程序池主要負責如下四方面的工作。

Ø      回收

Ø      性能

Ø      運行狀況

Ø      標識

關於對這四方面的配置，可以在應用程序池的屬性頁對話框中進行。具體路徑如下：開始菜單->管理工具->Internet信息服務管理器->應用程序池->屬性。

5.2.應用程序池的回收功能

在工作進程隔離模式中，通過配置，IIS可以定期重新啓動應用程序池中的工作進程。通過這種機制IIS可以更好地管理那些有錯誤的工作進程。在默認情況下，當IIS回收一個應用程序池的時候，它會使用一種稱爲overlapped recycle的回收技術。

在這種回收模式下，失敗的工作進程將不會接收新的http請求，當它處理完存儲在請求隊列中的所有剩餘的http請求後，這個進程則正常關閉；或者如果在達到了配置的時間限制、請求數、設置的時間計劃，或當達到指定的內存用量限制後仍沒有關閉，則明確地終止進程。默認情況下，應用程序池每隔1740分鐘（29小時）回收一次。

爲了防止服務中斷，在失敗的工作進程繼續處理存儲在請求隊列中的剩餘的請求的時候，IIS啓動了新的工作進程，所有新的http請求都會由給這個新的工作進程處理。在此期間，TCP/IP連接不會丟失。

關於應用程序池在他方面的功能在前面的章節中已有詳細的介紹，這裏就不再過多介紹了。

6.   應用程序隔離模式

6.1.概述

如果你的服務器是從windows2000升級到windows2003，那麼IIS 5.0也會被升級到IIS6.0，這種情況下，IIS是運行在IIS5.0隔離模式下的；如果你的服務器是新安裝的windows2003，那麼IIS是運行在工作進程隔離模式下的。因此，在IIS6.0中有兩種應用程序隔離模式：IIS5隔離模式和工作進程隔離模式。
 

6.2.應用程序隔離的目的

作爲一個web應用程序運行的平臺，在IIS中將會運行着很多個web應用程序，每個web應用程序的穩定性也各不相同。爲了保證IIS的高度穩定性和可靠性，要求在IIS中運行的各個web應用程序彼此相互獨立，互不影響。也就是說某一個web應用程序的崩潰不會導致其他web應用程序的崩潰或者整個IIS的崩潰。因此，在IIS中提出了應用程序隔離的概念。

6.3.在IIS5.0中的做法

在IIS5.0中，對應用程序的隔離主要有如下幾個要點：

Ø       還不存在HTTP.SYS驅動程序，對用戶http請求的監聽功能由Inetinfo.exe進程實現。

Ø       WWW服務位於Inetinfoexe進程之中。所以WWW服務的穩定性也會影響到整個IIS的穩定性。

Ø       提供了三個不同級別的應用程序保護，即低級別，中級別，高級別。關於應用程序保護級別的詳細情況，請見。。。。節。

Ø       存在進程之間互相通信的問題，加大了系統開銷。

IIS5.0中，對應用程序進行隔離的結構如下圖所示：

        （圖 20）IIS 5.0的應用程序隔離情況

當一個http請求到底以後，首先由TCPIP.SYS將請求傳遞給Inetinfo.exe中的WWW服務，然後再由WWW服務轉發給DLLHost.exe進程中的web應用程序處理。在這裏就存在了一個進程之間通信的問題，必然會引起一些大的系統開銷。

WWW服務僅僅負責對DLLHost.exe宿主進程地創建。當這些宿主進程創建完畢後，WWW服務就不會再對它進行管理。

根據應用程序保護級別的不同，web應用程序的隔離程度也各不相同。在低級別的隔離模式中，web應用程序的運行效率最高，但是，由於它直接運行在WWW服務的進程之中，所以它對整個IIS的穩定性的影響也最大。在高級別的隔離模式中，每一個web應用程序都運行於一個屬於它的宿主進程（DLLHost.exe）中，雖然這個web應用程序的運行效率降低了，但是，由於它被隔離在一個特定的宿主進程之中運行，所以它對整個IIS系統的穩定性的影響也減小了，一個web應用 

程序的崩潰不會影響到其他web應用程序以及整個IIS系統的運行。

6.4.IIS5.0隔離模式

在IIS6.0中，爲了考慮應用程序的兼容性，因爲某些web應用程序可能依賴於IIS5.0的架構。比如，某些Web應用，特別是有些Internet Server API（ISAPI）篩選器，在進程外運行時可能會遇到問題。在IIS 5.0和IIS 4.0中，ISAPI篩選器總是運行在進程Inetinfo.exe之內的，它們的設計目標本來就不是運行在進程之外的，正是由於這些原因，某些篩選器在IIS 6.0的工作進程隔離模式中運行時可能會出現問題。因此，IIS6.0提供了另一種應用程序隔離模式：IIS5.0隔離模式。IIS5.0隔離模式的結構圖如下圖所示：

      
                    （圖 21）IIS5.0隔離模式

在IIS6.0中，IIS5.0隔離模式主要有如下幾個要點：

Ø       在內核模式中實現了HTTP.SYS驅動程序，由它負責對http請求的監聽。

Ø       WWW服務從Inetinfo.exe進程之中獨立了出來。並且由WWW服務負責對宿主進程（DLLHost.exe）的創建和管理。與IIS5.0不同，WWW服務創建了宿主進程DLLHost.exe之後還負責對它進行管理，比如監聽它的狀態，運行情況等。

Ø       WWW服務負責對http請求進行轉發。當用戶的http請求從HTTP.SYS驅動程序傳遞過來以後，由WWW服務負責將這個請求傳遞個相關的web應用程序處理，並將處理結果返回。

Web應用程序允許運行在Inetinfo.exe進程之中，也可以運行在DLLHost.exe宿主進程之中。

6.5.工作進程隔離模式

工作進程隔離模式是IIS6.0所提供的全新的應用程序隔離模式。它的組成結構如下圖所示：
       
                   （圖 22）工作進程隔離模式

在IIS6.0中，工作進程隔離模式主要有如下幾個要點：

Ø       在內核模式中實現了HTTP.SYS驅動程序，由它負責對http請求的監聽。

Ø       WWW服務從Inetinfo.exe進程之中獨立了出來，它運行在了新的進程SVCHost.exe之中。

Ø       WWW服務只負責對應用程序池的創建和管理。

Ø       HTTP.SYS驅動程序直接與應用程序池中的工作進程（Worker Process）通信。

Ø       一個應用程序池中可以運行一個或者多個web應用程序，並且由一個或者多個工作進程來管理它們。

Ø       工作進程（Worker Process）之中實現了原來WWW服務的功能：接收HTTP.SYS轉發過來的用戶http請求。WWW服務將不再負責這部分工作。

7.   Web園

在一個應用程序池中存在着一個或者多個web應用程序，並且由這個應用程序池中一個或者多個工作進程來管理這些web應用程序。如果在一個應用程序池中存在着多個工作進程的話，那麼就形成了一個web園（Web Gardens）。

關於Web園的配置，如下圖所示，只需要將“最大工作進程數”的值設置爲大於1的值就可以了。

        
                  （圖 23）配置Web園

這樣做的好處是：提高了處理用戶http請求的效率；當一個工作進程壞掉之後，其他的工作進程仍然能夠處理用戶的請求，保證了系統的穩定性和可靠性。

轉自：http://www.cnblogs.com/arbin98/archive/2010/09/03/1816847.html