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上也還沒發現相關內容。

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