構建高性能.NET應用之配置高可用IIS服務器-第三篇 IIS中三個核心組件的講解(上)


 

 

 

系列文章:

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

構建高性能.NET應用之配置高可用IIS服務器-第二篇 IIS請求處理模型
構建高性能.NET應用之配置高可用IIS服務器-第三篇 IIS中三個核心組件的講解(上) 
構建高性能.NET應用之配置高可用IIS服務器-第三篇 IIS中三個核心組件的講解(下) 

 

       今天的文章的比較的容易,主要講述IIS中三個比較重要的組件:協議監聽者(Protocol Listeners),WWW服務(World Wide Web Publishing Service)和WAS(Windows  Process Activation Service),理解這三個組件的功能,是理解IIS的必須的知識。

 

       下面,我們首先來看第一個。

 

協議監聽者(Protocol Listeners)

 

       我們知道,很多不同類型的應用程序都需要它們的客戶端以不同的協議與它們進行通信,我們稍微簡單的來舉幾個例子讓大家明白:

    1. Web應用程序采用Http來通信。Web應用程序通過接受Http請求和發送Http響應給客戶端的方式來進行通信。
    2. 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中都支持一下功能:

    1. HTTP.SYS被實現成為內核模式中的一個組件
    2. HTTP.SYS直接將接受到的HTTP請求傳遞給請求的處理工作進程,並且在中途不會出現任何的進程間通信的開銷。在IIS6的之前的版本中,HTTP請求首先被用戶模式中的進程inetinfo.exe接受,這個進程再把請求轉發給IIS中的工作進程,這個過程就涉及到了工作進程與IIS之前跨進程通信了。
    3. 每一個應用程序池都有自己的基於內核模式的請求隊列。當沒有足夠的工作進程來處理HTTP請求的時候,HTTP.SYS就把新來的請求放在隊列中。之后,工作進程會直接從隊列中拿出請求進行處理,在過程中不會涉及到進程間通信的開銷。
    4. 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除了讀取配置信息以外,它還負責其他一些比較重要的職責:

    1. 使用applicationHost.config配置文件的配置信息來配置和啟動應用程序池,來處理請求。
    2. 根據applicationHost.config配置文件的配置信息來監控,重啟,關閉和管理應用程序池以及相關的工作進程。

 

       理解了上面的內容之后,那么現在應該就非常清楚IIS中請求的處理流程了:

    1. 當請求達到的時候,協議監聽程序開始運行。
    2. 特定的協議監聽適配者被創建,並且通知特定的應用程序池請求到達。
    3. 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實現三層部署架構

 

 

 

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

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

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

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

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

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

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

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

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

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


免責聲明!

本站轉載的文章為個人學習借鑒使用,本站對版權不負任何法律責任。如果侵犯了您的隱私權益,請聯系本站郵箱yoyou2525@163.com刪除。



 
粵ICP備18138465號   © 2018-2025 CODEPRJ.COM