httpRuntime與ASP.NET 運行時及IIS處理模型

配置 ASP.NET HTTP 運行時設置，以肯定如何處理對 ASP.NET 應用程序的請求，配置節及其描述以下所示。

   

<httpRuntime

executionTimeout="110"--------------------------指定在被 ASP.NET 自動關閉前，容許執行請求的最大秒數

maxRequestLength="4096"--------------------------指定輸入流緩衝閾值限制（以 KB 爲單位）。此限制可用於防止拒絕服務攻擊；例如，因用戶向服務器發送大型文件而致使的拒絕服務攻擊。

requestLengthDiskThreshold="256"--------------------------定輸入流緩衝閾值限制（以字節爲單位）。該值不該超過 maxRequestLength 屬性。

useFullyQualifiedRedirectUrl="false"

minFreeThreads="8"--------------------------請求時空閒時最小線程數

minLocalRequestFreeThreads="4"--------------------------本地請求時最小的空閒線程數

appRequestQueueLimit="5000"--------------------------指定 ASP.NET 將爲應用程序排隊的請求的最大數目。當沒有足夠的自由線程來處理請求時，將對請求進行排隊。當隊列超出了該屬性中指定的限制時，將經過"503 - 服務器太忙"錯誤信息拒絕傳入的請求。

enableKernelOutputCache="true"--------------------------啓用輸出緩存 IIS6之後版本生效

enableVersionHeader="true"--------------------------是否在頭部輸出版本

requireRootedSaveAsPath="true"--------------------------指定 SaveAs 方法中的 filename 參數是否必須爲絕對路徑。ASP.NET 進程必須具備在指定位置中建立文件的權限。

enable="true"--------------------------至關於關閉應用程序（連靜態頁面也沒法訪問）指定是否在當前的節點及子節點級別啓用應用程序域 (AppDomain)，以接受傳入的請求。若是爲 False，則實際上關閉了該應用程序

shutdownTimeout="90"--------------------------關閉超時單位 秒 指定容許輔助進程關閉的分鐘數。在達到該超時時間時，ASP.NET 關閉輔助進程。

delayNotificationTimeout="5"--------------------------延遲通知超時時間 秒爲單位

waitChangeNotification="0"--------------------------等待變動通知

maxWaitChangeNotification="0"--------------------------最大等待變動通知數

requestPriority="Normal"--------------------------請求策略

enableHeaderChecking="true"--------------------------啓用頭部檢查 以檢測可能的注入式攻擊。若是檢測到攻擊，ASP.NET 將返回錯誤做爲響應。

sendCacheControlHeader="true"--------------------------指定是否發送默認狀況下設置爲 Private 的緩存控制標頭。若是爲 True，則客戶端緩存被禁用。

apartmentThreading="false"-----------啓用單元線程處理以實現傳統的 ASP 兼容性。

/>

   

從上面的特性而言大概歸納成HttRuntime的自身運行方面（包括重啓時間，線程數控制，請求隊列），請求頭限制響應輸出。

而HttpRuntime還涉及到其餘方面，如Http管道，IIS的運行模型。有其餘博文從代碼角度列舉了從一個請求到達後，在AppDomain中建立HttpRuntime,HttpContext,HttpApplication,各個HttpModule,到HttpHandler處理。

舍長的《深刻理解ASP.NET的內部運行機制》

此外以前在看Http管道時一直沒仔細去搞清楚IIS的處理模型，在此也補一補。IIS到我如今看爲止已經到了7.0的版本，網上有很多資料從5.0開始提及，既然如此就從5.0提及，看看其變遷。

如下圖片均摘自蔣金楠總是的著做《ASP.NET MVC 4 框架揭祕》

IIS5處理模型

IIS 5.x 運行在進程 InetInfo.exe 中，該進程寄宿着一個名爲 World Wide Web Publishing Service（簡稱 W3SVC）的 Windows 服務。 W3SVC 的主要功能包括 HTTP 請求的監聽、工做進程和配置管理（經過從 Metabase 中加載相關配置信息）等。

若是咱們請求的是一個基於 ASP.NET 的資源類型，好比.aspx、 .asmx 和.svc 等，aspnet_isapi.dll 會被加載，而 ASP.NET ISAPI 擴展會建立 ASP.NET 的工做進程（若是該進程還沒有啓動）。對於 IIS 5.x 來講，該工做進程爲 aspnet.exe。 IIS 進程與工做進程之間經過命名管道（ Named Pipes）進行通訊。

在工做進程初始化過程當中， .NET 運行時（ CLR）被加載進而構建了一個託管的環境。對於某個 Web 應用的初次請求， CLR 會爲其建立一個應用程序域（ Application Domain）。在應用程序域中， HTTP 運行時（ HTTP Runtime）被加載並用以建立相應的應用。寄宿於IIS 5.x 的全部 Web 應用都運行在同一個進程（工做進程 aspnet_wp.exe）的不一樣應用程序域中。

IIS6處理模型

IIS5中有兩個弊端，其一是ISAPI與工做進程分離，會存在性能瓶頸；其二是全部ASP.NET應用程序存在於同一個進程中，應用程序間會存在影響。

針對這兩個問題，做了兩個改進，引入了應用程序池以及把ISAPI放到工做進程中。

此外IIS6中在系統內核層面引入了HTTP.SYS處理監聽HTTP請求。其好處是能夠持續監聽，更好的穩定性和內核模式下數據緩存。Inetinfo.exe單純用於存儲ISAPI的配置信息，W3SVC則寄宿於另外一個進程SvcHost.exe中，其內部職能並無發生任何變化，功能實現作了改進。

   

IIS7處理模型

在IIS7中引入了 Windows進程激活服務（ Windows Process Activation Service， WAS）的引入，將原來（ IIS 6.0） W3SVC承載的部分功能分流給了 WAS。其實是對監聽這一環節開放了可擴展的接口。W3SVC仍是存儲原有的HTTP請求的監聽，但這也成爲了它惟一的職責，後續的讀取ISAPI信息和工做進程管理那塊則移交給WAS。擴展的監聽接口看介紹是在WCF方面比較有用，如今暫且不關注它。ISAPI的配置信息也不依賴於原有的Metabase，改用了applicationHost.config。

IIS7的集成模式確定也要提到，在前面介紹httpHandlers的時候也提到IIS7有經典模式和集成模式。IIS7以前是使用雙管道處理Http請求，在IIS中有一堆模塊處理（例如身份認證），一樣在Http管道中有重複的處理。而在IIS7中新增了集成模式可使得這兩個管道處理變成單一管道統一處理。IIS7中一樣保留了雙管道的處理模式，稱之爲經典模式。在經典模式中對擴展的HttpModule和HttpHandler只做用於ISAPI擴展過的這些資源，但對靜態資源是沒有做用的，假設使用了集成模式，由於是單一管道統一處理，無論動態仍是靜態都會被httpModule和HttpHandler處理。

上面介紹的幾個IIS處理模型都是在HttpRuntime生成前，到了.NET Runtime的範圍內，HttpRuntime纔開始被建立出來。關於如何被生成，如何被調用鄙人則不想再粘貼代碼了。想看的話仍是那個連接：舍長的《深刻理解ASP.NET的內部運行機制》。

以上都是人云亦云的內容，在經峯哥教導後我以爲這樣學習就不踏實了，惋惜好像尚未任何有效途徑去驗證這些說法。至少在MSDN上也還沒發現相關內容。