iis ■ W3SVC
W3SVC也許是IIS 6.0體系中最不令人注意的組件,不過這並不說明它不重要。W3SVC的任務是根據配置資料的設定建立和監視背景工作執行緒,由背景工作執行緒運行Web網站應用程式。在IIS 5.0中,與IIS 6.0 W3SVC組件最接近的是IIS管理服務,IIS管理服務是Inetinfo的一部分;因此,如果Inetinfo出現問題,IIS管理服務也會出現問題,而且此時的IIS管理服務不能再重新啟動Inetinfo或其他故障的應用程式。在IIS 6.0中,W3SVC作為一個獨立的進程運行,Web應用的故障不可能波及W3SVC,因為W3SVC之內根本沒有第三方的代碼運行。W3SVC總是處於運行狀態,因此它能夠監視Web應用的健康情況,並在必要時採取行動。由於這一策略,伺服器能夠根據使用者指定的參數監視和重新啟動應用程式。
■ http.sys
IIS 6.0體系設計中最重大的變化是加入了http.sys驅動程式,http.sys驅動程式的任務是處理HTTP請求,而且它在核心模式下執行操作。不要小看這一改變,將處理HTTP請求的任務從IIS 5.0、IIS 4.0的使用者模式改變到IIS 6.0的核心模式標誌著新一代IIS伺服器的誕生。
在Win 2K和NT 4.0中,IIS在使用者模式下運行。運行在使用者模式下的應用程式不直接與硬體通訊,它們直接調用的是一些標準流程,這些標準流程或者將資料傳入核心模式的組件(例如網路卡驅動程式,圖形子系統),或者調用核心模式組件的函數,以此完成儲存檔案、設定IP地址、將HTML檔案發送到網路之類的任務。
使用者模式和核心模式之間的轉換是一項開銷很大的操作,伺服器首先從核心模式的TCP/IP棧將傳入的HTTP請求傳遞給使用者模式的Winsock,由Winsock將請求傳遞給IIS。從核心模式到使用者模式的切換很快發生,但不可避免地給處理過程帶來瞬間的延遲。當負載較大時,這種延遲不斷累加,同時由於這種轉換是必不可少的,所以管理員根本沒有辦法最佳化處理過程。
IIS 6.0的https.sys核心模式驅動程式極大地減少了使用者模式和核心模式之間的切換次數。http.sys監聽著HTTP請求,決定由哪一個使用者模式的進程來處理該請求,或者是否由驅動程式本身返回使用者請求的內容。
IIS 6.0在使用者模式下運行,完全依賴核心模式的http.sys作為接收使用者請求的伺服器引擎。因此,http.sys必須能夠在任何時候作出相應,必須具有極高的可靠性。使用者代碼可能導致進程出錯,所以微軟把http.sys設計成不執行任何使用者代碼,這樣,即使應用程式出現了故障,也不會影響到IIS 6.0本身,IIS 6.0仍能夠照常監聽HTTP請求。
如果要從核心模式的緩衝區返回靜態應答,一個高速的、核心模式的、不允許運行應用程式代碼的HTTP處理器是十分理想的,它減少了切換到使用者模式的昂貴開銷,能夠從核心模式的緩衝區快速返回應答。IIS 6.0的http.sys就管理著這樣一個緩衝區,而且使用了高度最佳化的啟發學習法緩衝區演算法來確定哪些內容要放入緩衝區,例如,http.sys可能只緩衝那些出現了一次以上請求的內容。
由於http.sys直接從應答緩衝區提取靜態內容,不必再切換到使用者模式,所以與IIS 5.0的效能相比,IIS 6.0的整體效能有了顯著提升。根據微軟的資料顯示,WebBench基準測試表明IIS 6.0返回靜態內容的速度要比IIS 5.0快150%。即使以IIS 5.0的隔離模式運行IIS 6.0伺服器(這時,IIS 6.0的體繫結構與IIS 5.0的相似),同樣也能從http.sys驅動程式的應答緩衝區和其他改進之處獲益。
另外,微軟在http.sys驅動程式中採用了許多最佳化的演算法,使其能夠將請求直接轉寄到適當的背景工作處理序。在IIS 4.0和IIS 5.0中,必須通過多個步驟才能確定進程的哪一個執行個體擁有了應當接收當前請求的Web應用,但在IIS 6.0中,http.sys註冊了所有IIS 6.0應用,賦予每一個進程一個控制代碼,IIS內部利用這些控制代碼來標識註冊的應用程式要用到的一個或多個名稱空間。因此,當http.sys接收到一個HTTP請求,它能夠很快地將請求從核心模式的http.sys傳遞到正確的使用者模式的Web應用。
http.sys驅動程式還要執行其他一些任務,其中包括:
⑴ 將傳入的URL與各種長度、格式方面的規則進行比較。
⑵ 管理傳入請求的隊列。
⑶ 擔負著記錄IIS Web網站日誌資訊的任務(從而提高了記錄日誌的效能)。
⑷ 實施頻寬節流設定策略以及支援TCP/IP級的管理。
⑸ 實現客戶認證請求服務(但不支援安全通訊端層——SSL)。