本系列是以iis6.0為準進行闡述的
當我們在瀏覽器位址列中鍵入比如
,回車後，相當於向伺服器（192.168.1.1）傳送了乙個web頁(test.aspx)請求，這個請求經由http.sys後**到iis。那麼在到達iis之前，http.sys對這個請求做了什麼？http.sys又是個啥呢？它又有什麼特點呢？這就是本系列的第一站：http.sys
http.sys是乙個核心模式網路驅動程式。即http.sys執行在核心模式下，作為驅動程式而存在。從結構上來講，http.sys是位於tcpip.sys之上的。也就是說，乙個請求首先由tcpip.sys處理，然後才**到http.sys上；同理，該請求被web應用程式處理後作為響應返回時則是先到達http.sys在**到tcpip.sys最後到達客戶端瀏覽器。注意：tcpip.sys和http.sys都處於核心模式下。
如圖：
注：為了避免使用者應用程式訪問或者修改關鍵的作業系統資料，
windows
提供了兩種處理器訪問模式：使用者模式（
user mode
）和核心模式（
kernel mode
）。一般地，使用者程式執行在
user mode
下，而作業系統**執行在
kernel mode
下。kernel mode
的**允許訪問所有系統記憶體和所有
cpu指令。
接下來讓我們看一下http.sys功能特點：
（1） http.sys的主要功能是監聽使用者（來自於tcpip.sys）的http請求。
（2） 管理tcp連線
（3） 驗證http請求。比如url和header長度等，如果驗證沒有通過則直接返回。否則將web請求放到適當請求隊 列中，並對其進行排隊。
（4） 路由http請求到正確的web應用程式池。http.sys中維護著乙個從url到web應用程式池的對應關係路由表（對映表），所以http.sys可以迅速將web請求**到web應用程式。注意，如果web請求沒找到相應的對映，則返回404錯誤，就是我們常見的那個並**觀的頁面。當然你也可以自己畫乙個漂亮的將這個頁面覆蓋掉。
（5） 快取web應用程式對於該請求的響應結果。當同一請求被頻繁訪問時可以不必**到web應用程式，直接從此快取中將結果返回給使用者，大大提高了其響應速度。
（6）實現比如連線限制、連線超時、訊息佇列長度限制以及iis寬頻限制等控制。
上面說了這麼多，其最最重要的功能就是監聽來自使用者的web請求，請一定要記住。
http.sys其模組結構，如圖：
上面介紹了http.sys是什麼以及其功能特點，那麼http.sys是如何工作的呢？
當你建立乙個web站點的時候，iis就會在http.sys上註冊這個站點，這樣就會接收來自該站點的任何web請求。http.sys從功能上講類似於乙個**器。傳送收到的web請求到web應用程式，並且傳送返回的響應到客戶端。
當iis6.0在工作程序隔離模式下執行時，http.sys就監聽使用者請求，並為這些收到的web請求在適當的佇列中進行排隊。每個請求佇列都對應乙個應用程式池，乙個應用程式池又對應乙個http.sys中的請求佇列和乙個或多個工作程序。
通過上面的介紹我想也應該對乙個web請求在http.sys中的歷程有所了解了，即http.sys收到使用者的請求後對其進行相關驗證，通過則去對映表中查詢其對應的應用程式池，找到後將該web請求**到應用程式池的工作程序中，經web應用程式處理後最終又通過tcpip.sys將處理結果返回給使用者瀏覽器。那麼web請求被**到web應用程式池後，接下來會發生什麼呢。
上文說到乙個web請求被http.sys**到了web應用程式池。顧名思義，web應用程式池就是乙個web應用程式的容器。那麼這個web請求在web應用程式池中又有著怎樣的經歷呢，這不得不引出另外兩個iis6.0的核心元件：工作程序(worker progess)和web管理器（web admin service），這也就是本文重點所講述的。
在表述這兩個元件之前，先來看一下它們的圖示：
我先來說說www service，也就是was。was是乙個管理和監視工作程序的元件，它宿主在svehost.exe中，執行在使用者模式下。was負責同metabase進行互動以獲取其配置資料資訊，這些配置資訊會通過was註冊到http.sys中。同時was還負責監視管理工作程序。一旦工作程序出現故障，was會為其建立新的工作程序以響應web請求。
was還負責管理管理工作程序，包括啟動工作程序和維護正在執行的工作程序。並判定何時啟動工作程序，何時**工作程序以及何時重新啟動處於阻塞狀態或不能處理更多web請求的工作程序。在工作程序隔離模式下，was負責健康管理和維護，包括應用程式池的健康監視，工作程序的**以及對工作程序異常的迅速保護。
以上是對was的簡述，接下來我著重說說工作程序（worker progress），在講工作程序之前，我來大致說說was、web應用程式池、工作程序以及web應用程式它們之間的關係。如果把web應用程式池比作乙個小區的話，那麼工作程序（w3wp.exe）就相當於管理這個小區的物業，而web應用程式相當於這個小區的住戶，was(svchost.exe)就相當於管理這個小區旁邊的派出所。下面我把工作程序（w3wp.exe）圖放大，如下圖：
乙個應用程式池中可包含多個工作程序，工作程序間是相互隔離的，直接和核心模式下的http.sys進行互動，互不影響。也就是說乙個工作程序出現故障並不會影響其它的工作程序的正常執行。
修改來自客戶端的請求(url或headers)，
控制物理檔案到url的對映
驗證完成後修改或分析請求
修改客戶端返回的響應
對「訪問被拒絕」的響應執行自定義處理
當請求結束後執行相應的處理
同客戶端的連線關閉後執行相應處理
記錄日誌和跟蹤分析
執行自定義的身份驗證
加密壓縮等功能。
可見乙個web請求要想順利到達web應用程式是多麼地不容易。好了，說了這麼多自己腦袋都懵了，還是捋一下web請求的思路吧。乙個web請求經http.sys**到web應用程式池對應的工作程序，如果該程序沒啟動則通過was來啟動，沒有找到相應的工作程序則建立，注意啟動工作程序時會載入相應的asp.net isapi動態庫，然後載入clr。這個請求通過isapi過濾器和isapi擴充套件的種種考驗，最終就會來的web應用程式的面前。我還是用圖例來描述一下這個web請求現在走到**了吧，此時還web請求的旅程並沒有走完。
我們知道，當乙個有效的web請求到達http.sys後，發現沒有相應有效的工作程序，則http.sys會告訴was(svchost.exe)，以為之建立並啟動乙個工作程序(w3wp.exe)。在啟動工作程序的過程中載入isapi（非託管**）以及clr（託管**），然後在工作程序中建立應用程式域。其實如上一系列操作只是為web請求準備好其執行環境。
當乙個web請求進入已經準備好的工作程序邊界（工作程序從http.sys的應用程式池對應的訊息佇列中取出該web請求），那此時首先會經過isapi filter的處理，比如修改http報頭和url等，具體功能參見上文。接下來就會將處理的web請求交給isapi extension。那麼isapi extension會幹什麼呢？我們先看下圖：
我們從上圖可以看出，它就是乙個應用程式副檔名的對映，即副檔名與處理該檔案的應用程式的乙個對映表，接下來我們看看具有aspx副檔名的檔案是由哪個應用程式集處理(dll)的，如下圖：
看到了嗎？其實也就告訴我們對於aspx副檔名的檔案，要交給aspnet_isapi.dll處理，其實大部分檔案都對映到了aspnet_isapi.dll，也就是說大部分動態的web請求檔案都交由程式集aspnet_isapi.dll來處理。對於靜態檔案比如jpg、js、以及css等都會直接將檔案返回給客戶端。注意：aspnet_isapi.dll是乙個非託管的win32動態庫，裡面封裝了很多用於與web進行互動的函式，它的處理速度那是相當的快。另外它被載入到了工作程序中，也就是說非託管的aspnet_isapi.dll與託管的web應用都處於乙個工作程序中，這顯然會加快其處理速度。跨程序訪問是要付出代價的，所以我們不必為此擔心。那麼如何才能呼叫aspnet_isapi.dll提供的一系列服務呢，這就引出了isapiruntime，它的主要功能就是負責isapi擴充套件的非託管**與託管**之間的溝通與互動。您只要記住這點就行了，具體實現細節我認為沒必要深究。如果您對此感興趣可以借助reflector.exe等工具進行跟蹤研判。
其實寫到此我只大概介紹了iis6.0的三個核心元件http.sys、was以及worker progress，另外兩個（inetinfo.exe和iis metabase）只是輕描淡寫，如果有時間我會繼續說說關於這兩個核心元件的內容，另外會順帶說說ssl。
http請求的全過程
這幾天看乙個講解乙個網頁從我們輸入位址到顯示在我們面前的乙個講解，是我對http又有了乙個完整的了解，現在做一下整個流程的記錄，雖然不是很詳細，但是整個過程是完整的。如果不對，請指正！開啟瀏覽器，位址列輸入blog.csdn.net。開始進行網域名稱解析 瀏覽器獲得網域名稱對應的ip位址後 發起ht...
HTTP請求全過程
http通訊機制是在一次完整的http通訊過程中，web瀏覽器與web伺服器之間將完成下列7個步驟 1.建立tcp連線 在http工作開始之前，web瀏覽器首先要通過網路與web伺服器建立連線，該連線是通過tcp來完成的，該協議與ip協議共同構建internet，即著名的tcp ip協議族，因此in...
HTTP請求的完全過程
1.1 瀏覽器根據網域名稱解析ip位址瀏覽器快取 首先搜尋瀏覽器自身的dns快取 快取的時間比較短，大概只有1分鐘，且只能容納1000條快取 看自身的快取中是否是有網域名稱對應的條目，而且沒有過期，如果有且沒有過期則解析到此結束。系統快取 如果瀏覽器自身的快取裡面沒有找到對應的條目，那麼瀏覽器會搜尋...