? ? ? ? ?在IIS 中，Http監聽者(http.sys)和請求處理者由兩個系統服務在控制著。一個是WWW 服務，另外一個就是Windows Process Activation。

??對于WWW服務，它主要是監控IIS的配置文件，將新的配置信息用到HTTP.sys和WAS上。同時它也維持一些性能計數器，把一些數據反應到計數器中，所以，很多的時候，我們可以查看性能計數器來獲取一些與IIS性能相關的信息。

? 對于Windows ProcessActivation，這個服務的作用就是激活和喚起進程來處理請求，同時它也對正在運行的處理進程進行管理，例如資源的回收，以及控制著性能相關的一些限制。

? ? ? ? ?在IIS6中，上面的講述的功能都是包含在WWW服務中的，在IIS 7中，就將上面的功能分開了。到了這里，我感覺再講下去，大家可能要犯糊涂了，為了使得后文的講述更加的方便和大家的理解更加的深入，這里很有必要把IIS 的架構講講，也非常有必要把IIS 6和IIS 7進行比較。

???????? 首先，我們就來看看IIS6的請求的處理模型，如下圖所示：

? ?

???????? 在上圖中，我們可以看到：

1.??????IIS6的請求處理模型中包含了兩個管道：一個是IIS6的處理管道，一個是ASP.NET的處理管道。

2.??????每一個請求的處理都要經過兩個管道。當請求經過IIS的管道的時候，IIS6就是根據它的metabase里面的配置信息來決定把請求給那個來處理。如果是請求與ASP.NET相關的內容的，那么請求就會被交個aspnet_isapi.dll來處理，然后aspnet_isapi.dll就加載CLR運行時，并且開啟ASP.NET的處理管道。

3.??????在兩個管道中，有一些相同的處理流程，例如身份驗證。

?

另外，ASP.NET允許我們在處理管道中注冊自己的module或者handler，這一點朋友們都應該很清楚了。我們一般在ASP.NET的應用程序級別的事件中注冊我們自己的邏輯，當ASP.NET觸發這些事件的時候，我們的代碼就運行了。

IIS6中引入了兩個不同的處理管道，引發了下面的問題：

1.??????導致了一定程度的重復處理。例如，兩個管道中都有身份驗證的組件，那么一個請求就要被驗證兩次。

2.??????因為ASP.NET的管道在IIS的管道之后，所以對于每個請求的處理決定完全是由aspnet_isapi.dll這個組件來控制的，也就是說ASP.NET的處理管道無法在早期對請求如何進行處理下決定。

3.??????一旦把請求交給了ASP.NET的處理管道之后，IIS 的處理管道要等到ASP.NET處理完畢之后才能接著處理，而且，一旦ASP.NET管道處理完之后，ASP.NET的處理管道無法影響后續的IIS6的處理管道。

4.??????只有把請求交給了aspnet_isapi.dll之后，ASP.NET處理管道才開始啟動，并且請求的內容只能是與ASP.NET相關的，例如aspx頁面等。ASP.NET處理管道無法處理對非ASP.NET內容的請求，例如圖片，腳本等。也就是說：程序在一定的程度上無法對非ASP.NET的資源進行驗證與授權的保護。

既然IIS6有上面的一些問題，IIS7的出現就解決了上述的問題。IIS 7移除了對aspnet_isapi，并且將IIS和ASP.NET的進行了集成，成為一個管道，如下：

一個請求的處理流程變的簡單了，效率應該會提高。事實也確實如何，并且一個請求的線程切換次數也變少了，這極大的提升了性能（不用把請求從IIS的線程切換到ASP.NET的處理線程）。

通過改進，IIS 7解決了上述我們提到的幾個問題：

1.??????集成管道中不會包含重復的組件。

2.??????ASP.NET的module和handler可以在管道的如何地方發揮作用，從而使得我們可以對請求的處理流程進行完全的控制。

3.??????可以處理對非ASP.NET內容的請求。

相關內容

• 構建高性能.NET應用之配置高可用IIS服務器-第一篇：IIS必須掌握的知識

作者介紹：汪洋，哪合伙CEO，曾大漢電子商務有限公司首席技術官，副總裁，負責公司產品、技術、運營，參與商業模式設計。華康移動醫療前CTO，副總裁，首席架構師。微軟MVP

---

.NET社區新聞，深度好文，微信中搜索dotNET跨平臺或掃描二維碼關注

贊賞

人贊賞

創作挑戰賽新人創作獎勵來咯，堅持創作打卡瓜分現金大獎

總結

以上是生活随笔為你收集整理的构建高性能.NET应用之配置高可用IIS服务器-第二篇 IIS请求处理模型的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。