建構高性能.NET應用之配置高可用IIS伺服器-第三篇 IIS中三個核心元件的講解（上）

系列文章： 建構高性能.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就在應用程式池中建立一個新的工作程序，然後把請求交給這個工作程序來處理，并且這個程序也随後去處理應用程式池的請求隊列中的請求。

系列文章連結：

IIS負載均衡-Application Request Route詳解第一篇： ARR介紹  

IIS負載均衡-Application Request Route詳解第二篇：建立與配置Server Farm

 IIS負載均衡-Application Request Route詳解第三篇：使用ARR進行Http請求的負載均衡（上） 

IIS負載均衡-Application Request Route詳解第三篇：使用ARR進行Http請求的負載均衡（下） 

IIS負載均衡-Application Request Route詳解第四篇：使用ARR實作三層部署架構

負載均衡原理與實踐詳解 第一篇（重新整理）   

負載均衡原理與實踐詳解 第二篇（重新整理）   

負載均衡原理與實踐詳解 第三篇 伺服器負載均衡的基本概念-網絡基礎   

負載均衡原理與實踐詳解 第四篇 使用負載均衡器的伺服器群    

負載均衡原理與實踐詳解 第五篇 負載均衡時資料包流程詳解   

負載均衡原理與實踐詳解 第六篇 健康檢查機制詳解（上）   

負載均衡原理與實踐詳解 第七篇 健康檢查機制詳解（下）   

負載均衡原理與實踐詳解 第八篇 網絡位址轉換（上） 

負載均衡原理與實踐詳解 第八篇 網絡位址轉換(下) 

負載均衡原理與實踐詳解 第九篇 伺服器負載均衡技術進階-會話保持（上）

打賞

<b></b>贊

<b></b>收藏

<b></b>評論

分享

微網誌

QQ

微信

舉報

上一篇：如何提高Linq查詢的性能（上）

下一篇：建構高性能.NET應用之配置高可用IIS伺服器-第四篇 IIS常見問題之：工作程序回收機制（上）

建構高性能.NET應用之配置高可用IIS伺服器-第四篇 IIS常見問題之：工作程序回收機制（上）,在IIS上搭建WebSocket伺服器（三）,LEMP建構高性能WEB伺服器（第三版）,第三篇,IPsec入門篇講解（第三篇）,.net iis伺服器配置,hadoop三個元件,iis伺服器講解,iis第三方伺服器,java中三個斜杠