IIS的運行機制

一，VS自帶的IIS（IIS Express）和真實的IIS有什麼區別？

1，VS帶的IIS是IIS的真實精簡版本，叫IIS Express，和IIS徹底同樣，不一樣於Development Server，IIS Express支持包括ISAPI等等插件，除了在鏈接數上的限制之外，IIS Express也沒有圖形化的管理界面，並且也不是以服務的形式運行，IIS Express的功能和行爲幾乎和IIS同樣。

2，能夠理解爲：VS自帶的那個是虛擬機

3，IIS配置的網站能夠被外網訪問，VS只是本地調試

4，IIS是一個系統服務，IIS Express則只是一個臨時進程。

5，IIS Express至關於一個IIS的精簡版本，它擁有IIS幾乎全部的功能，但它沒有可視化的管理界面

二，IIS是如何處理基於ASP.NET資源（.aspx .asmx）的請求的？

IIS5x

1>IIS5X運行在進程InetInfo.exe中，該進程寄宿着一個名爲World Wide Web Publishing Server(簡稱W3SVC)的Windows服務。W3SVC的主要功能包括HTTP請求的監聽、工做進程和配置管理（經過從MetaBase中加載相關的配置信息）等

2>當檢測到某個HTTP 請求時，先根據擴展名判斷請求的是不是靜態資源(好比.html 、.img 、.txt 、.xml 等)，若是是，則直接將文件內容以HTTP 回覆的形式返回:若是是動態資源(好比.aspx 、.asp 、.php 等) ，則經過擴展名從IIS 的腳本映射C Script Map) 中找到相應的ISAPI 動態鏈接庫CDynamic Link Library, DLL) 。

3>ISAPI C Intemet Server Application Programming Interface) 是一套本地的CNative) Win32API，是IIS 和其餘動態Web 應用或平臺之間的紐帶。ISAPI 定義在一個動態鏈接庫CDLL)文件中， ASP.NET ISAPI 對應的DLL 文件名稱爲aspnet_isapi. dll ，咱們能夠在目錄"%windir% \Microsoft.NET\Framework\ {version no} \"中找到它。ISAPI 支持ISAPI 擴展CISAPIExtension) 和ISAPI 篩選C ISAPI Filter) ，前者是真正處理HTTP 請求的接口，後者則能夠在HTTP 請求真正被處理以前查看、修改、轉發或拒絕請求，好比IIS 能夠利用ISAPI 篩選進行請求的驗證。

4>若是咱們請求的是一個基於ASPNET 的資源類型，好比.aspx 、.asmx 和.svc 等，aspnet isapi. dll 會被加載，而AS衛NETISAPI 擴展會建立ASP.NET 的工做進程(若是該進程還沒有啓動)。對於IIS 5.x 來講，該工做進程爲aspnet. exeo IIS 進程與工做進程之間經過命名管道CNamed Pipes) 進行通訊。

5>在工做進程初始化過程當中， .NET 運行時(CLR) 被加載進而構建了一個託管的環境。對於某個Web 應用的初次請求， CLR 會爲其建立一個應用程序域C Application Domain) 。在應用程序域中， HTTP 運行時C HTTP Runtime) 被加載並用以建立相應的應用。寄宿於IIS 5.x 的全部Web 應用都運行在同一個進程(工做進程aspnet_wp.exe) 的不一樣應用程序域中。

IIS6x

1>經過上面的介紹，咱們能夠看出IIS 5.x 至少存在着以下兩個方面的不足。ISAPI 動態鏈接庫被加載到Inetlnfo.exe 進程中，它和工做進程之間是一種典型的跨進程通訊方式，儘管採用命名管道，可是仍然會帶來性能的瓶頸。全部的ASP.NET 應用運行在相同進程C aspnet_ wp.exe) 中的不一樣的應用程序域中，基於應用程序域的隔離不能從根本上解決一個應用程序對另外一個程序的影響。在更多的時候，咱們須要不一樣的Web 應用運行在不一樣的進程中。

2>爲了解決第一個問題， IIS 6.0 將ISAPI 動態鏈接庫直接加載到工做進程中:爲了解決第二個問題，引入了應用程序池C Application Pool )的機制。咱們能夠爲一個或多個Web 應用建立應用程序池，因爲每個應用程序池對應一個獨立的工做進程，從而爲運行在不一樣應用程序池中的Web 應用提供基於進程的隔離級別。IIS 6.0 的工做進程名稱爲w3wp.exe 。

3>除了上面兩點改進以外， IIS 6.0 還有其餘一些值得稱道的地方。其中最重要的一點就是建立了一個名爲HTTP.SYS 的HTTP 監聽器。HTTP.SYS 以驅動程序的形式運行在Windows的內核模式C Kemel Mode) 下，它是Windows 2003 的TCP/IP 網絡子系統的一部分，從結構上看它屬於TCP 之上的一個網絡驅動程序。

4>嚴格地說， HTTP.SYS 已經不屬於IIS 的範疇了，因此HTTP.SYS 的配置信息也沒有保存在IIS 的元數據庫CMetabase) 中，而是定義在註冊表中。HTTP.SYS 的註冊表項的路徑爲HKEY LOCAL MACHINE/SYSTEMlCurrentControlSetlServices/HTTP 0 HTTP.SYS 可以帶來以下的好處。

    持續監昕:因爲HTTP.SYS 是一個網絡驅動程序，始終處於運行狀態，對於用戶的HTTP請求可以及時做出反應。

    更好的穩定性: HTTP.SYS 運行在操做系統內核模式下，並不執行任何用戶代碼，因此其自己不會受到Web 應用、工做進程和IIS 進程的影響。內核模式下數據緩存:若是某個資源被頻繁請求， HTTP.SYS 會把響應的內容進行緩存，緩存的內容能夠直接響應後續的請求。因爲這是基於內核模式的緩存，不存在內核模式和用戶模式的切換，響應速度將獲得極大的改進。

5>下圖，體現了IIS 的結構和處理HTTP 請求的流程。與IIS 5.x 不一樣， W3SVC 從InetInfo.exe 進程脫離出來(對於IIS 6.0 來講， InetInfo.exe 基本上能夠看做單純的IIS 管理進程) ，運行在另外一個進程SvcHost. exe 中。不過W3SVC 的基本功能並無發生變化，只是在功能的實現上做了相應的改進。與IIS 5.x 同樣，元數據庫CMetabase) 依然存在於Inetlnfo.exe 進程中。

6>當HTTP.SYS 監聽到用戶的HTTP 請求時將其分發給W3SVC ， W3SVC 解析出請求的URL ，並根據從Metabase 獲取的URL 與Web 應用之間的映射關係獲得目標應用，並進一步獲得目標應用運行的應用程序池或工做進程。若是工做進程不存在(還沒有建立或被回收) ,則爲該請求建立新的工做進程。咱們將工做進程的這種建立方式稱爲請求式建立。在工做進程的初始化過程當中，相應的ISAPI 動態鏈接庫被加載。對於ASP.NET 應用來講，被加載的ISAPI. dll 爲aspnet_isap i. dllo AS衛NETISAPI 再負責進行CLR 的加載、應用程序域的建立和Web 應用的初始化等操做。

IIS7x

1>IIS 7在請求的監聽和分發機制上又進行了革新性的改進，主要體如今對於Windows進程激活服務C Windows Process Activation Service, WAS) 的引入，將原來CIIS 6.0) W3SVC承載的部分功能分流給了WAS 。經過上面的介紹，咱們知道對於IIS 6.0 來講W3SVC 主要承載着3 大功能。

    HTTP 請求接收:接收HTTP.SYS 監聽到的HTTP 請求。

    配置管理:從元數據庫CMetabase) 中加載配置信息對相關組件進行配置。   

進程管理:建立、回收、監控工做進程。

2>IIS 7.0 將後兩組功能實現到了WAS 中，接收HTTP 請求的任務依然落在W3SVC 頭上。WAS 的引入爲IIS 7.0 提供了對非HTTP 協議的支持。WAS 經過監聽器適配器接口CListenerAdapter Interface) 抽象出不一樣協議監聽器。具體來講，除了基於網絡驅動的HTTP.SYS 提供HTTP 請求監聽功能外還提供了TCP 監聽器、命名管道監聽器和MSMQ 監昕器以提供基於TCP、命名管道和MSMQ 傳輸協議的監聽支持。

3>與此3 種監聽器相對的是3 種監聽適配器，它們提供監昕器與WAS 中的監聽器適配器接口之間的適配。從這個意義上講， IIS 7.0 中的W3SVC 更多地爲HTTP.SYS 起着監昕適配器的做用。這3 種非HTTP 監聽器和監昕適配器定義在程序集SMHost. exe 中，咱們能夠在目錄%windir%\Microsoft.NET飛Framework\v3.0\Windows Communication Foundation \中找到它們。

4>WCF 提供的這3 種監昕器和監昕適配器最終以Windows 服務的形式體現。雖然它們定義在一個程序集中，咱們依然能夠經過服務工做管理器對其進行單獨的啓動、終止和配置。SMHost. exe 提供了4 個重要的Windows Service 。NetTcpPortSharing: 爲WCF 提供TCP 端口共享。關於端口共享在WCF 中的應用，本人拙著<<WCF 全面解析)) C 上冊)對此有詳細的介紹。NetTcpActivator: 爲WAS 提供基於TCP 的激活請求，包含TCP 監昕器和對應的監聽適配器。

    NetPipeActivator: 爲WAS 提供基於命名管道的激活請求，包含命名管道監昕器和對應的監聽適配器。

    NetMsmqActivator: 爲WAS 提供基於MSMQ 的激活請求，包含MSMQ 監昕器和對應的監聽適配器。

5>揭示了IIS 7.0 的總體構架及整個請求處理流程。不管是從W3SVC 接收到的HTTP 請求，仍是經過WCF 提供的監聽適配器接收到的請求，最終都會傳遞到WAS 。若是相應的工做進程(或者應用程序池)還沒有建立，則建立它，不然將請求分發給對應的工做進程進行後續的處理。WAS 在進行請求處理過程當中，經過內置的配置管理模塊加載相關的配置信息，並對相關的組件進行配置。與IIS 5.x 和IIS 6.0 基於Metabase 的配置信息存儲不一樣的是， IIS 7.0 大都將配置信息存放於XML 形式的配置文件中，基本的配置存放在applicationHost. config 中。

 三，代碼請求