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