配置 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上也还没发现相关内容。