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