本文結構：
一、HTTP請求處理流程的基礎
1．網絡分層
因特網TCP/IP分層模型共有五層：應用層、傳輸層、網絡層、網絡接口層和物理層。這種分層模型不同於OSI七層參考模型，但是，是實際使用中采用的分層方式。
ISO提出的OSI（Open System Interconnection）模型將網絡分為七層，即物理層( Physical )、數據鏈路層(Data Link)、網絡層(Network)、傳輸層(Transport)、會話層(Session)、表示層(Presentation)和應用層(Application)。
| OSI中的層 |
功能 |
TCP/IP協議族 |
| 應用層 |
文件傳輸，電子郵件，文件服務，虛擬終端 |
TFTP，HTTP，SNMP，FTP，SMTP，DNS，Telnet |
| 表示層 |
數據格式化，代碼轉換，數據加密 |
沒有協議 |
| 會話層 |
解除或建立與別的接點的聯系 |
沒有協議 |
| 提供端對端的接口 |
TCP，UDP |
|
| 網絡層 |
為數據包選擇路由 |
IP，ICMP，RIP，OSPF，BGP，IGMP |
| 傳輸有地址的幀以及錯誤檢測功能 |
SLIP，CSLIP，PPP，ARP，RARP，MTU |
|
| 物理層 |
以二進制數據形式在物理媒體上傳輸數據 |
ISO2110，IEEE802。IEEE802.2 |
TCP/IP分層模型（TCP/IP Layering Model）被稱作因特網分層模型（Internet Layering Model）、因特網參考模型（Internet Reference Model）。
TCP/IP是事實的標准，所以自然取其前三層協議【應用層、傳輸層、網絡層（網間層）】作為網絡分層。而又， TCP/IP標准並不定義與OSI七層參考模型中的數據鏈路層和物理層相對應的功能。為了銜接這兩層，它定義了像地址解析協議(Address Resolution Protocol，ARP)這樣的協議，提供TCP/IP協議的數據結構和實際物理硬件之間的接口。所以，將在網絡層（網間層）之下，將由ARP、RAPR等協議組成的層，作為新的一個分層（網絡接口層）。該層又恰巧位於數據鏈路層和物理層之上。一般的適配器（網卡）都包括了數據鏈路層和物理層這兩層的功能。所以，在TCP/IP分層模型中，又將OSI七層參考模型中數據鏈路層和物理層合稱為“物理層”。
所以，因特網TCP/IP分層模型共有五層：應用層、傳輸層、網絡層、網絡接口層和物理層。雖然與OSI七層參考模型在名稱上相同的文字，但有的並不指相同的東西。
TCP/IP分層模型，是我們“現實所見”的各層。它是現實存在的，所以通過它，我們可以用比較簡單的方式，理解現實網絡是如何按網絡分層的方式搭載起來的。
2．端口
在網絡上，各主機間通過TCP/IP協議發送和接收數據包，各個數據包根據其目的主機的IP地址來進行互聯網絡中的路由選擇，把數據包順利的傳送到目的主機。大多數操作系統都支持多程序（進程）同時運行，那么目的主機應該把接收到的數據包傳送給眾多同時運行的進程中的哪一個呢？顯然這個問題有待解決，端口機制便由此被引入進來。
本地操作系統會給那些有需求的進程分配協議端口（protocol port，即我們常說的端口），每個協議端口由一個正整數標識，如：80，139，445，等等。當目的主機接收到數據包后，將根據報文首部的目的端口號，把數據發送到相應端口，而與此端口相對應的那個進程將會領取數據並等待下一組數據的到來。
端口其實就是隊，操作系統為各個進程分配了不同的隊，數據包按照目的端口被推入相應的隊中，等待被進程取用。在極特殊的情況下，這個隊也是有可能溢出的，不過操作系統允許各進程指定和調整自己的隊的大小。
不光接受數據包的進程需要開啟它自己的端口，發送數據包的進程也需要開啟端口，這樣，數據包中將會標識有源端口，以便接受方能順利地回傳數據包到這個端口。
3.網站、應用程序、虛擬路徑
出處：
http://www.iis.net/learn/get-started/planning-your-iis-architecture/understanding-sites-applications-and-virtual-directories-on-iis
在IIS 6.0，虛擬路徑和應用程序兩個概念，很容易讓人迷惑的。在技術實現上，界線不是很清晰。應用程序與虛擬路徑，並沒有完全切割開。同時，對諸如ASP、ISAPI、ASP.NET等擴展了服務器功能的技術來說，“應用程序”這個概念又比在IIS上更加重要。這些技術勢必使應用程序更加復雜，從而導致了IIS 6一個重要的問題，同個“如此復雜的應用程序”在不同應用程序池中不能相互隔絕（原話：The important question for IIS 6.0 was isolating such applications in a way that would prevent applications in one application pool from affecting applications in another application pool on the server.）。
在IIS 7，網站、應用程序和虛擬路徑，是相互獨立的概念。一個網站可以包含一個或者多個應用程序；一個應用程序可以包含一個或者多個虛擬路徑；一個虛擬路徑對應一個物理路徑。
另外，由於IIS和ASP.NET的請求處理管道的合並，促使了頁面可以預先利用托管代碼應用程序提供的功能。舉個例子，每個托管代碼應用程序都運行在一個應用程序域（AppDomain）中（注：上面提到的托管代碼應用程序提供的功能）。而一個應用程序可以有多個虛擬路徑，這樣，就可通過相同的應用程序域（當作應用程序）訪問每個虛擬路徑。【原話：This is because the IIS and ASP.NET request-processing pipelines have merged in IIS 7 and above so that content can take advantage of functionality previously provided for only managed code applications. For example, each managed code application runs in an Application Domain (AppDomain). An application can have several virtual directories, and each one will be served by the same AppDomain as the application to which they belong.】
1）網站
網站包括兩個重要的綁定：一個是協議綁定，一個是信息綁定。“協議綁定”所綁定的協議是客戶端和服務器交流的協議（例如HTTP）。“信息綁定”是用於訪問網站用的，比如IP址、端口等。如有需要，可以有多個協議綁定和信息綁定。
在早期版本的IIS中，只能支持HTTP、HTTPS的綁定，而在IIS 7 及更高版本中，可以綁定任何協議。這是由於Windows Process Activation Service (WAS)的改進。在IIS 7 及更高版本中，WAS保留了在IIS 6 相似的處理模式，比如，應用程序池、基於消息的進程激活；快速的故障保護（rapid failure protection）、監聽以及回收等。同時，WAS移除了依賴於HTTP的架構。這促使了應用程序與應用程序能夠通過標准協議進行交流。WCF的程序設計模型就是應用了這種技術，使得能夠通過標准協議（TCP、MSMQ等）進行通信交流。這種技術，讓采用了標准通信協議的應用程序（WCF）能夠利用IIS的特性，如進程回收（process recycling）、快速故障保護（rapid failure protection）、以前只有基於http的應用程序的配置等。
以下配置設置也屬於網站：
（1）連接超時：帶寬限制、連接數、站點連接時間
（2）日志：處理和存儲日志文件的配置的設置。
（3）失敗請求痕跡日志：記錄失敗請求痕跡的配置的設置。
2）應用程序
每人網站必須有一個默認應用程序，叫做根應用程序或者默認應用程序。一個網站可以有多個應用程序。
除了屬於一個網站，應用程序也屬於一個應用程序池。應用程序池用於隔離其他應用程序池里的應用程序。托管應用程序與其所屬的應用程序池的.net框架版本必須一致。
IIS默認支持HTTP及HTTPS，同時也支持另外的協議。每個網站有一個或者多個“綁定協議”和“綁定信息”。應用程序必須啟用其所需的協議（這個協議必須是其所屬網站的綁定協議），如果是非HTTP/HTTPS時，又必須保證服務器上有對應的監聽適配程序，並在配置文檔中配置<listenerAdapters>節點。
3）虛擬路徑
虛擬路徑，在IIS中指定的一個目錄名，用於映射本地或者遠程服務器的物理路徑。這個指定的目錄名將成URL一部分。每個應用程序都有一個虛擬路徑，用於映射包含了“應用程序內容（the application's content）”的物理路徑，這個虛擬路徑被稱為根虛擬目錄。然而一個應用程序可以有多個虛擬路徑。舉個例子，你有一個（物理的）目錄包含一些圖片文件，你希望這些圖片包含到應用程序中，但又不想將這些圖片文件移到根虛擬目錄對應的物理路徑下，這時你就可以為這個應用程序再指定一個虛擬路徑，映射到這些圖片文件所在的物理路徑。
可以為虛擬路徑指定用戶名、密碼、登錄方法。
IIS默認使用物理路徑及其子路徑下的Web.config配置。如果不希望使用子目錄的Web.config，則需要配置：
<sites><site>…<site>…<virtualDirectoryDefaults allowSubDirConfig="false " /></sites>
4）IIS配置
（1）配置文件所在位置：%windir%\system32\inetsrv\config \
（2）<sites>節點下的集合與元素的層級關系
（3）<applicationDefaults>與<virtualDirectoryDefaults>的意義
<applicationDefaults> 的父元素不同時，其所指的意義也不同：
| 父元素 |
說明 |
| <sites> section |
指定服務器上的所有應用程序的默認設置。 |
| <site> collection |
指定網站上的所有應用程序的默認設置。 |
<virtualDirectoryDefaults>的父元素不同時，其所指的意義也不同：
| 父元素 |
說明 |
| <sites> section |
指定服務器上所有的虛擬目錄的默認設置。 |
| <site> collection |
指定網站上所有的虛擬目錄的默認設置。 |
| <application> collection |
指定應用程序下所有的虛擬目錄的默認設置。 |
二、IIS架構
1.概述
無論是怎樣的HTTP請求處理流程，都必須講究一些必要的“規則”（即遵守一些共同的機制）。
1）其中，最重要的一個“規則”就是保證同一台服務器上的各站點、各應用程序的隔離。
2）第二個比較重要的“規則”就是，將HTTP請求開放給由開發網站的程序員開發的“應用程序”，由這些“應用程序”進行HTTP請求的處理。（當然，在不同的HTTP請求處理機制或者配置下，存在將資源直接返回到客戶端的情況）。
3）為實現上述兩個規則，幾個IIS版本，都共同采用了一些相同的方式：
（1）維護着一份腳本映射擴展表，將請求映射到應用程序池、工作者進程等。
（2）管道技術是很好的銜接程序員代碼的方式。
2.監聽
無論是怎樣的系統，怎樣的HTTP請求處理流程，第一步，永遠是讓某一“進程”監聽80端口。
在IIS 7處理模型中，監聽程序是作為Windows操作系統內核的一部分運行的，叫做HTTP.sys。它接收從網絡來的HTTP請求，安全過濾及預處理后，將其傳給IIS，交由IIS作更進一步的處理。最后，它又接收IIS處理后的結果，並將結果（響應）返回到客戶端的瀏覽器。
HTTP.sys在IIS 6就已經出現。而在比IIS 6更早的版本中，監聽程序是Windows Sockets API (Winsock)，它運行在操作系統的用戶模式上，並非在內核模式中。
關於HTTP.sys知識點還有：
1）內核模式緩存。HTTP.sys緩存歷史響應，當重新遇到相同請求時，直接返回仍然有效的響應，而無需切換到用戶模式（IIS處理）。
2）維護一個內核模式的請求隊列。HTTP.sys直接將請求轉發到正確的工作者進程（通過WAS等協助，映射找到相應的工作者進程）。如果沒有工作進程可以接受請求，內核模式的請求隊列保留該請求，直到工作者進程接收走請求。
3）請求的預處理和安全過濾。
4）HTTP.sys是IIS的一部分，作為監聽的默認選擇。在IIS 7及更高版本上，可以不用HTTP.sys監聽HTTP請求，可以通過WCF監聽適配程序【WCF listener adapter】（比如NetTcpActivator）來完成或者做更多工作。
3.萬維網發布服務
即：WWW service（World Wide Web Publishing Service）
1）WWW service在IIS 6 中的工作情況
（1）HTTP管理與配置
WWW service從IIS metabase 讀取配置信息，並用這些信息配置和更新HTTP監聽程序，HTTP.SYS。此外，WWW service對處理HTTP請求的工作進程進行啟動、停止、監控和管理。
（2）性能監控
WWW service監控性能，並為網站和IIS緩存提供性能計數器。
（3）進程管理
WWW service管理應用程序池和工作者進程，諸如啟動、停止和回收工作者進程。另外，WWW service監控工作者進程的“健康”，以及在配置的時間內調用“快速失敗監測”以阻止新工作者進程的啟動。
2）在IIS 7 中的工作情況
在IIS 7 及以上版本，WWW service被分成兩部分，其中一部分仍然叫WWW service，而另一部分叫做Windows Process Activation Service (WAS)。這兩部分運行在同一個進程中（svchost.exe）。
（1）新WWW service作為HTTP監聽程序（HTTP.SYS）的監聽適配器，主要負責兩個工作：一、在配置改變時，配置和更新HTTP.SYS；二、在請求加入到請求隊列時，通知WAS。
（2）WAS管理應用程序池和工作者進程，而不再是WWW service。不同的是，WAS做到了能夠同時管理“HTTP應用程序池和工作者進程”與“非HTTP的應用程序池和工作者進程”。WAS判斷工作者進程是否正在運行，如果應用程序池中的工作者進程沒在運行，則啟動工作者進程。
WAS讀取配置信息有：全局配置信息，協議配置信息（包括HTTP與非HTTP），網站配置信息（比如綁定和應用程序），應用程序配置信息（比如：應用程序啟用的協議，所屬的應用程序池）。
如果ApplicationHost.config改變，WAS接收到通知后，將新的配置信息更新監聽適配器上。
3）一分為二
將原WWW service一分為二后，可以讓你在“HTTP協議網站”與“非HTTP協議網站”上，運用相同的配置和處理模式。
另外，如果不需要處理HTTP請求的功能，可以只運行WAS而不運行WWW service。舉個例子，只通過WCF監聽適配器（比如：NetTcpActivator）管理運行一個不需要監聽HTTP請求的Web Service。
【到這里，我們知道，IIS幾個重要組成部分：協議監聽程序，監聽適配器，應用程序池和工作者進程的管理者，應用程序池和工作者進程。在HTTP請求處理上`，他們分別對應的是：HTTP.SYS； WWW Service；WAS；W3WP.exe。面對不同的協議請求，可以根據需要啟用不同的協議監聽程序和監聽適配器。在HTTP請求處理上，工作流程可以簡單地說成是這樣子：配置改變時，被WAS（應用程序池和工作者進程的管理者）讀到，並update到WWW Service（監聽適配器），WWW Service又將新配置信息配置update到HTTP.SYS（協議監聽程序），HTTP.SYS接收到請求時，將請求直接給了W3WP.exe（工作者進程）】
4.模塊（Modules）
與以前版本不同，新的IIS版本中，不再在服務器上持有多數的功能（Instead of keeping the majority of functionality within the server itself），而是用一個名為“Web服務器引擎（Web server engine）”來替代。在這個Web服務器引擎上，可以根據需要，添加或者移除模塊，用以實現各種功能。比如，用身份驗證模塊來實現鑒定客戶端的證書的功能，用緩存模塊管理緩存行為。（模塊所在位置是工作者進程）
采用模塊的方式，有以下幾個優點：
（1）可以控制哪些模塊在服務器上使用。
（2）可以自定義模塊替代現有模塊或者引用新特性。
（3）可以自定義服務器的角色（You can customize a server to a specific role in your environment.）。
（4）更加安全和便捷的管理。移除不必要的模塊，可以減少服務器可能被攻擊的地方，以及減少內存占用，舍去對“不必要功能”的管理。
1）本地模塊（Native Modules）
在完全安裝的IIS7及以上版本中，可以找到本地模塊。根據需要，你可以移除它們或者用自定義模塊替代它們。
（1）HTTP模塊
即在請求處理管理中，針對HTTP的模塊，包括重定向請求、返回HTTP錯誤、響應。
| Module Name |
Description |
Resource |
| CustomErrorModule |
Sends default and configured HTTP error messages when an error status code is set on a response. |
Inetsrv\Custerr.dll |
| HttpRedirectionModule |
Supports configurable redirection for HTTP requests. |
Inetsrv\Redirect.dll |
| ProtocolSupportModule |
Performs protocol-related actions, such as setting response headers and redirecting headers based on configuration. |
Inetsrv\Protsup.dll |
| RequestFilteringModule |
Added in IIS 7.5. Filters requests as configured to control protocol and content behavior. |
Inetsrv\modrqflt.dll |
| WebDAVModule |
Added in IIS 7.5. Allows more secure publishing of content by using HTTP over SSL. |
Inetsrv\WebDAV.dll |
（2）安全模塊
即在請求處理管理中，執行與安全相關的任務的模塊。根據身份驗證方案，選擇相應的模塊（各模塊是獨立的）。也包括URL驗證模塊和請求過濾模塊。
| Module Name |
Description |
Resource |
| AnonymousAuthenticationModule |
Performs Anonymous authentication when no other authentication method succeeds. |
Inetsrv\Authanon.dll |
| BasicAuthenticationModule |
Performs Basic authentication. |
Inetsrv\Authbas.dll |
| CertificateMappingAuthenticationModule |
Performs Certificate Mapping authentication using Active Directory. |
Inetsrv\Authcert.dll |
| DigestAuthenticationModule |
Performs Digest authentication. |
Inetsrv\Authmd5.dll |
| IISCertificateMappingAuthenticationModule |
Performs Certificate Mapping authentication using IIS certificate configuration. |
Inetsrv\Authmap.dll |
| RequestFilteringModule |
Performs URLScan tasks such as configuring allowed verbs and file name extensions, setting limits, and scanning for bad character sequences. |
Inetsrv\Modrqflt.dll |
| UrlAuthorizationModule |
Performs URL authorization. |
Inetsrv\Urlauthz.dll |
| WindowsAuthenticationModule |
Performs NTLM integrated authentication. |
Inetsrv\Authsspi.dll |
| IpRestrictionModule |
Restricts IPv4 addresses listed in the ipSecurity list in configuration. |
Inetsrv\iprestr.dll |
| Module Name |
Description |
Resource |
| AnonymousAuthenticationModule |
Performs Anonymous authentication when no other authentication method succeeds. |
Inetsrv\Authanon.dll |
| BasicAuthenticationModule |
Performs Basic authentication. |
Inetsrv\Authbas.dll |
| CertificateMappingAuthenticationModule |
Performs Certificate Mapping authentication using Active Directory. |
Inetsrv\Authcert.dll |
| DigestAuthenticationModule |
Performs Digest authentication. |
Inetsrv\Authmd5.dll |
| IISCertificateMappingAuthenticationModule |
Performs Certificate Mapping authentication using IIS certificate configuration. |
Inetsrv\Authmap.dll |
| RequestFilteringModule |
Performs URLScan tasks such as configuring allowed verbs and file name extensions, setting limits, and scanning for bad character sequences. |
Inetsrv\Modrqflt.dll |
| UrlAuthorizationModule |
Performs URL authorization. |
Inetsrv\Urlauthz.dll |
| WindowsAuthenticationModule |
Performs NTLM integrated authentication. |
Inetsrv\Authsspi.dll |
| IpRestrictionModule |
Restricts IPv4 addresses listed in the ipSecurity list in configuration. |
Inetsrv\iprestr.dll |
（3）內容模塊
即在請求處理管理中，執行與內容相關的任務的模塊。包括處理靜態文件請求、返回默認頁面（未指定請求何資源時）、列舉文件夾等模塊。
| Module Name |
Description |
Resource |
| CgiModule |
Executes Common Gateway Interface (CGI) processes to build response output. |
Inetsrv\Cgi.dll |
| DefaultDocumentModule |
Attempts to return a default document for requests made to the parent directory. |
Inetsrv\Defdoc.dll |
| DirectoryListingModule |
Lists the contents of a directory. |
Inetsrv\dirlist.dll |
| IsapiModule |
Hosts ISAPI extension DLLs. |
Inetsrv\Isapi.dll |
| IsapiFilterModule |
Supports ISAPI filter DLLs. |
Inetsrv\Filter.dll |
| ServerSideIncludeModule |
Processes server-side includes code. |
Inetsrv\Iis_ssi.dll |
| StaticFileModule |
Serves static files. |
Inetsrv\Static.dll |
| FastCgiModule |
Supports FastCGI, which provides a high-performance alternative to CGI. |
Inetsrv\iisfcgi.dll |
（4）壓縮模塊
即在請求處理管理中，有兩個模塊實現壓縮功能。
| Module Name |
Description |
Resource |
| DynamicCompressionModule |
Compresses responses and applies Gzip compression transfer coding to responses. |
Inetsrv\Compdyn.dll |
| StaticCompressionModule |
Performs pre-compression of static content. |
Inetsrv\Compstat.dll |
（5）緩存模塊
即在請求處理管理中，執行與緩存相關的任務的模塊。緩存可以改善網站和應用程序的性能。它通過在服務器的內存中保存已經處理過的信息（比如網頁）來實現。如果后續的講求是請求相同的資源，則這些信息將被重復利用。
| Module Name |
Description |
Resource |
| FileCacheModule |
Provides user mode caching for files and file handles. |
Inetsrv\Cachfile.dll |
| HTTPCacheModule |
Provides kernel mode and user mode caching in HTTP.sys. |
Inetsrv\Cachhttp.dll |
| TokenCacheModule |
Provides user mode caching of user name and token pairs for modules that produce Windows user principals. |
Inetsrv\Cachtokn.dll |
| UriCacheModule |
Provides user mode caching of URL information. |
Inetsrv\Cachuri.dll |
（6）日志和診斷模塊
即在請求處理管理中，執行與日志和診斷相關的任務和模塊。日志模塊支持加載自定義模塊，和向HTTP.SYS傳遞信息。診斷模塊在請求處理過程中，跟蹤並報告事件。
| Module Name |
Description |
Resource |
| CustomLoggingModule |
Loads custom logging modules. |
Inetsrv\Logcust.dll |
| FailedRequestsTracingModule |
Supports the Failed Request Tracing feature. |
Inetsrv\Iisfreb.dll |
| HttpLoggingModule |
Passes information and processing status to HTTP.sys for logging. |
Inetsrv\Loghttp.dll |
| RequestMonitorModule |
Tracks requests currently executing in worker processes and reports information with Runtime Status and Control Application Programming Interface (RSCA). |
Inetsrv\Iisreqs.dll |
| TracingModule |
Reports events to Microsoft Event Tracing for Windows (ETW). |
Inetsrv\Iisetw.dll |
（7）托管支持模塊（Managed Support Modules）
即在請求處理管理中，有兩個模塊用於支持托管代碼集成（A couple of modules in IIS support managed integration in the IIS request-processing pipeline.）。
| Module Name |
Description |
Resource |
| ManagedEngine |
Provides integration of managed code modules in the IIS request-processing pipeline. |
Microsoft.NET\Framework\v2.0.50727\webengine.dll |
| ConfigurationValidationModule |
Validates configuration issues, such as when an application is running in Integrated mode but has handlers or modules declared in the system.web section. |
Inetsrv\validcfg.dll |
2）托管模塊（Managed Modules）
除本地模塊之外，IIS允許你使用托管代碼模塊來擴展IIS的功能。一些托管模塊（比如：UrlAuthorization）會對應一個本地模塊。這個本地模塊是可供替代的選擇。
托管模塊依賴於ManagedEngine模塊。
| Module Name |
Description |
Resource |
| AnonymousIdentification |
Manages anonymous identifiers, which are used by features that support anonymous identification such as ASP.NET profile. |
System.Web.Security.AnonymousIdentificationModule |
| DefaultAuthentication |
Ensures that an authentication object is present in the context. |
System.Web.Security.DefaultAuthenticationModule |
| FileAuthorization |
Verifies that a user has permission to access the requested file. |
System.Web.Security.FileAuthorizationModule |
| FormsAuthentication |
Supports authentication by using Forms authentication. |
System.Web.Security.FormsAuthenticationModule |
| OutputCache |
Supports output caching. |
System.Web.Caching.OutputCacheModule |
| Profile |
Manages user profiles by using ASP.NET profile, which stores and retrieves user settings in a data source such as a database. |
System.Web.Profile.ProfileModule |
| RoleManager |
Manages a RolePrincipal instance for the current user. |
System.Web.Security.RoleManagerModule |
| Session |
Supports maintaining session state, which enables storage of data specific to a single client within an application on the server. |
System.Web.SessionState.SessionStateModule |
| UrlAuthorization |
Determines whether the current user is permitted access to the requested URL, based on the user name or the list of roles of which a user is a member. |
System.Web.Security.UrlAuthorizationModule |
| UrlMappingsModule |
Supports mapping a real URL to a more user-friendly URL. |
System.Web.UrlMappingsModule |
| WindowsAuthentication |
Sets the identity of the user for an ASP.NET application when Windows authentication is enabled. |
System.Web.Security.WindowsAuthenticationModule |
5．應用程序池
應用程序池通過進程邊界（非線程邊界等）將應用程序隔離開，阻止了同一個服務器上不同的應用程序池中的應用程序之間的相互影響。在IIS 7 及更高版本中，應用程序池仍舊使用IIS 6 工作者進程相同的隔離模式。此外，在IIS 7 及更高版本中，在涉及到托管資源的請求的處理上，還可以配置請求的處理方式：集成模式或者經典模式。
在IIS 6 中工作者進程的隔離模式與在IIS 5 中的隔離模式，都是被設置在服務器級別上，所以，這讓在同一服務器上同時運行這兩種隔離模式成為了可能。而在IIS 7 及更高版本上，集成模式和經典模式被設置在了應用程序池的級別上，這讓在同一個服務器上的不同應用程序池中的應用程序，采用不同的請求處理模式。
1）集成模式
集成處理模式，是將原IIS的請求處理模式與ASP.NET的請求處理模式集成到一個統一的處理模式中。這樣做，它有幾個好處：
（1）在IIS與ASP.NET之間，消除了一些重復的功能，比如身份驗證；舉個例子，客戶端請求一個托管的文件，在集成模式下，服務器調用適當的驗證模塊；而在之前的IIS版本中，相同的請求，將在IIS和ASP.NET都進行身份驗證。
（2）托管代碼所具有的特性適用了所有的文檔類型（Additionally, Integrated mode enables the availability of managed features to all content types.）。舉個例子，你可以讓“對ASP文件、靜態文件以及在網站和應用程序中其他的文件”的請求在處理上使用托管特性ASP.NET Forms authentication 和 Uniform Resource Locator (URL) authorization。
（3）在同一個位置管理所有的模塊，而不是在IIS上管理一部分功能，在ASP.NET上配置一部分功能。這簡化了網站和應用程序的管理。
在集成模式下，工作者進程接收到請求后，請求將穿過一組有序的事件。每個事件將調用必要的本地模塊和托管模塊來處理請求的部分內容，以及產生相應的響應。
2）經典模式
在經典模式下，IIS 7 及以上版本對請求的處理模式與IIS 6 相同。ASP.NET請求（是ASP.NET請求，即可用ASP.NET進行處理的語法，而不是別的請求）首先按IIS 本地處理步驟進行處理，然后再導入到Aspnet_isapi.dll進行處理，最后，請求返回到IIS以向客戶端返回響應。
分享的處理模式，導致了處理步驟的重復。
將已有的應用程序指定到集成模式，需要測試該應用程序對集成模式的兼容性。如果失敗，則需將其指定到經典模式。
三、處理流程
1．流程步驟
IIS 7 及更高版本與IIS 6 有類似的請求處理流程。
（1）客戶端請求一個在服務端的資源，HTTP.SYS監測到請求。
（2）HTTP.SYS聯系WAS，令其獲取配置信息。
（3）WAS從配置倉庫（applicationHost.config）讀取配置信息，並update到WWW Service。
（4）WWW Service接收到配置信息，比如應用程序池和網站配置。
（5）WWW Service將配置信息update到HTTP.SYS。
（6）WAS啟動一個工作者進程，該工作者進程將處理HTTP.SYS監測到的請求。
（7）HTTP.sys根據Update到的配置信息，直接將請求丟給相應的工作者進程，工作者進程處理請求后，將響應返回到HTTP.SYS。
（8）HTTP.SYS將請求返回到客戶端，客戶端接收到響應。
2．工作者進程中步驟
在工作者進程中，“HTTP請求”將穿過一組有序的步驟（上文有提及），這些步驟被稱為“事件”。在每個事件中，本地模塊（native module）處理請求的一部分（比如驗證用戶和添加事件日志）。如果一個請求需要托管模塊來處理，本地模塊（ManagedEngine）將創建AppDomain。在該AppDomain中，托管模塊才就可以繼續執行請求的處理。當請求穿過所有的事件，響應將返回到HTTP.SYS。
HTTP請求在工作者進程中的執行細節：
3. 進入AppDomain以后
什么是AppDomain？
操作系統和運行時環境都提供了一些用於隔離應用程序機制。舉個例子，Windows操作系統利用進程來隔離應用程序（在同一個計算機上，以往都是由“進程邊界”來隔離應用程序的運行：不能在兩個進程間直接調用，若要調用，則必須以間接的方式，比如使用代理）。
AppDomain在很多方面（比如：安全、可靠性、版本控制以及卸載程序集dll）也提供了隔離邊界。首先，AppDomain常是由“運行時宿主”（runtime hosts，一般“在應用程序運行前”引導CLR）創建。其次，托管代碼在運行前必須經過一個驗證流程（除非管理者授權許可可以跳過驗證）。這個驗證流程判斷托管代碼是否企圖訪問違法的內存地址或者是否執行一些能夠使“其所在的進程失敗時”卻正常運轉的行為（The verification process determines whether the code can attempt to access invalid memory addresses or perform some other action that could cause the process in which it is running to fail to operate properly.）。 托管代碼通過驗證，意味着其是類型安全的。驗證托管代碼的類型安全，讓CLR在一個很低的性能成本下具有 “與進程邊界相同級別”的隔離應用程序的能力。
AppDomain提供了一種更安全的通用處理機制，CLR用它隔離應用程序。在同一個進程中運行多個AppDomain，可使AppDomain間的隔離級別與“獨立進程間的隔離級別”一樣，卻不引起額外的開銷(進程間的調用和進程間的切換）。這提升了服務器可擴展性。
使用AppDomain的好處有：
(1）應用程序內的錯誤，不會影響到其他應用程序。這是因為類型安全的代碼不會引起內存錯誤。使用AppDomain保證了在進程內代碼運行不會影響到其他應用程序。
(2）可以單獨停止某個應用程序，而不用停止整個進程。注：不能卸載某個程序集或者類型，只能卸載一個完整的AppDomain。
(3）應用程序不能直接訪問另一個AppDomain中的代碼或者資源。CLR強制阻止了不同AppDomain應用程序間的直接調用。不同AppDomain對象的訪問，是通過其副本（copy）或者代理(proxy)。若通過副本，其調用則是本地的(local)，即調用者和被調用的對象都是在同一個AppDomain內的引用。若通過代理，其調用則是遠程的（remote），即調用者和被調用的對象是在不同的AppDomain內的引用。這種跨域的調用，所采用的遠程調用架構（remote call infrastructure），與兩個進程間或者兩個機器間的遠程調用架構一致。同樣的，為了讓“方法調用”能夠進行正確地JIT編譯，被跨域引用的對象的元數據應該要是可獲取的（對兩個AppDomain來說）。如果不能訪問元數據，則導致編譯時錯誤。
（4）應用程序域提供了配置設置,如應用程序版本策略,任何所訪問的遠程程序集的位置和信息。
（5）可以通過托管代碼所在的AppDomain來控制托管代碼的許可權限。
1)托管模塊中
當Http請求進入AppDomain以后，它的管道由托管模塊（Managed Modules）和處理程序（Handlers）組成，並且由管道來處理這個 Http請求:
自定義的托管模塊HttpModule通過在某些事件中注冊，把自己插入ASP.NET請求處理管道（因為管道合並，同時也是IIS管理）。當這些事件發生的時候，則會調用對相應的HTTP模塊，這樣該自定義的托管模塊就能處理請求了。
<httpModules>
<add name="TestModule" type="ClassLibrary831.TestModule,ClassLibrary831"/> </httpModules>
自定義的托管模塊HTTP模塊可以向System.Web.HttpApplication對象注冊下面一系列事件：
AcquireRequestState 當ASP.NET運行時准備好接收當前HTTP請求的對話狀態的時候引發這個事件。
AuthenticateRequest 當ASP.NET 運行時准備驗證用戶身份的時候引發這個事件。
AuthorizeRequest 當ASP.NET運行時准備授權用戶訪問資源的時候引發這個事件。
BeginRequest 當ASP.NET運行時接收到新的HTTP請求的時候引發這個事件。
Disposed 當ASP.NET完成HTTP請求的處理過程時引發這個事件。
EndRequest 把響應內容發送到客戶端之前引發這個事件。
Error 在處理HTTP請求的過程中出現未處理異常的時候引發這個事件。
PostRequestHandlerExecute 在HTTP處理程序結束執行的時候引發這個事件。
PreRequestHandlerExecute 在ASP.NET開始執行HTTP請求的處理程序之前引發這個事件。在這個事件之后，ASP.NET 把該請求轉發給適當的HTTP處理程序。
PreSendRequestContent 在ASP.NET把響應內容發送到客戶端之前引發這個事件。這個事件允許我們在內容到達客戶端之前改變響應內容。我們可以使用這個事件給頁面輸出添加用於所有頁面的內容。例如通用菜單、頭信息或腳信息。
PreSendRequestHeaders 在ASP.NET把HTTP響應頭信息發送給客戶端之前引發這個事件。在頭信息到達客戶端之前，這個事件允許我們改變它的內容。我們可以使用這個事件在頭信息中添加cookie和自定義數據。
ReleaseRequestState 當ASP.NET結束所搜有的請求處理程序執行的時候引發這個事件。
ResolveRequestCache 我們引發這個事件來決定是否可以使用從輸出緩沖返回的內容來結束請求。這依賴於Web應用程序的輸出緩沖時怎樣設置的。
UpdateRequestCache 當ASP.NET完成了當前的HTTP請求的處理，並且輸出內容已經准備好添加給輸出緩沖的時候，引發這個事件。這依賴於Web應用程序的輸出緩沖是如何設置的。
2）Handler中
Http請求經過所有的Module之后，它會被HttpHandler處理。一個請求對應一個HttpHandler。
在http請求的處理過程中，只能調用一個HttpHandler，但可以調用多個HttpModule。所以，一旦定義了自己的HttpHandler類，那么它對系統的HttpHandler的關系將是“覆蓋”關系。
Web.Config配置文件：
<httpHandlers>
<add verb="*" path="*" type="ClassLibrary831.TestHandler,ClassLibrary831"/>
</httpHandlers>