系列文章：構建高性能.NET應用之配置高可用IIS服務器-第二篇 IIS請求處理模型
今天的文章的比較的容易，主要講述IIS中三個比較重要的組件：協議監聽者(Protocol Listeners)，WWW服務(World Wide Web Publishing Service)和WAS(Windows Process Activation Service)，理解這三個組件的功能，是理解IIS的必須的知識。
下面，我們首先來看第一個。
協議監聽者(Protocol Listeners)
我們知道，很多不同類型的應用程序都需要它們的客戶端以不同的協議與它們進行通信，我們稍微簡單的來舉幾個例子讓大家明白：
- Web應用程序採用Http來通信。Web應用程序通過接受Http請求和發送Http響應給客戶端的方式來進行通信。
- WCF應用程序可以採用很多的協議來進行通信，包括：HTTP, NET.TCP, NET.PIPE, 和 NET.MSMQ
在這裏各種不同類型的應用中，協議監聽者就是一個負責監聽特定協議的請求，然後把請求傳遞給IIS的組件。每一個協議都有它自己的監聽者。IIS7中包括了四個協議的監聽者：HTTP.SYS，NET.TCP，NET.PIPE和NET.MSMQ。如果要對其他的協議進行監聽，那麼可以採用PlugIn的方式寫新協議的監聽者組件，然後插入到IIS7中（就是採用所謂的“插件式”方式）。
IIS 7中採用了HTTP.SYS來對HTTP請求進行監聽，同時在安全性方面也有了改進，因爲它也可以對SSL的請求進行監聽。另外，對於HTTP.SYS，在IIS6和IIS7中都支持一下功能：
- HTTP.SYS被實現成爲內核模式中的一個組件
- HTTP.SYS直接將接受到的HTTP請求傳遞給請求的處理工作進程，並且在中途不會出現任何的進程間通信的開銷。在IIS6的之前的版本中，HTTP請求首先被用戶模式中的進程inetinfo.exe接受，這個進程再把請求轉發給IIS中的工作進程，這個過程就涉及到了工作進程與IIS之前跨進程通信了。
- 每一個應用程序池都有自己的基於內核模式的請求隊列。當沒有足夠的工作進程來處理HTTP請求的時候，HTTP.SYS就把新來的請求放在隊列中。之後，工作進程會直接從隊列中拿出請求進行處理，在過程中不會涉及到進程間通信的開銷。
- HTTP.SYS會把請求的輸出的響應緩存在內核緩存中，方便對後續的請求進行快速的響應。
下面，我們來看第二個組件。
WAS(Windows Process Activation Service)
WAS的主要的職責就是去讀取applicationHost.config配置文件中的配置項。有些配置項是用來配置協議監聽者的。在之前我們討論過，每一個協議都有一個監聽者（在IIS6中，可以支持的協議只有HTTP協議，在IIS7中因爲引入了插件式的協議監聽者的方式，所以可以處理很多的協議，如果大家還記得話，要把WCF部署在IIS6中，那麼就只能通過HTTP協議）。
如果WAS直接與每個特定的協議監聽者交互，那麼WAS就與這些協議的監聽者僅僅的耦合在了一起，不能與其他的協議監聽者交互（因爲我們無法修改WAS的代碼，除非微軟發佈新的版本）。所以在IIS7中，在這裏就引入了協議監聽適配器，其實就是採用了adapter模式了。讓WAS依賴抽象，而不是依賴具體的實現。
協議監聽適配器將WAS與具體的協議的監聽者隔離。那麼每一個協議都有一個協議的適配者。例如HTTP協議的適配者知道如何去適配HTTP.SYS，如果對設計模式比較熟悉的朋友，應該非常清楚這一點了。
WAS讀取applicationHost.config配置文件中的配置信息，然後把這些信息用在協議監聽適配者上。協議監聽適配者採用這些配置的信息來監聽特定通道的請求。
WAS除了讀取配置信息以外，它還負責其他一些比較重要的職責：
- 使用applicationHost.config配置文件的配置信息來配置和啓動應用程序池，來處理請求。
- 根據applicationHost.config配置文件的配置信息來監控，重啓，關閉和管理應用程序池以及相關的工作進程。
理解了上面的內容之後，那麼現在應該就非常清楚IIS中請求的處理流程了：
- 當請求達到的時候，協議監聽程序開始運行。
- 特定的協議監聽適配者被創建，並且通知特定的應用程序池請求到達。
- WAS檢查是否已經有一個工作進程在應用程序池中運行，如果沒有，WAS就在應用程序池中創建一個新的工作進程，然後把請求交給這個工作進程來處理，並且這個進程也隨後去處理應用程序池的請求隊列中的請求。
系列文章鏈接：