比较IIS5、IIS6、IIS7的ASP.net请求处理过程

       SP NET是一个非常强大的构建Web应用的平台 它提供了极大的灵活性和能力以致于可以用它来构建所有类型的Web应用         绝大多数的人只熟悉高层的框架如 WebForms 和 WebServices 这些都在ASP NET层次结构在最高层

这篇文章的资料收集整理自各种微软公开的文档 通过比较 IIS IIS IIS 这三代 IIS 对请求的处理过程 让我们熟悉 ASP NET的底层机制 并对请求(request)是怎么从Web服务器传送到ASP NET运行时有所了解 通过对底层机制的了解 可以让我们对 有更深的理解

IIS 的 请求处理过程

IIS 的请求处理过程

对图的解释

IIS x 一个显著的特征就是 Web Server 和真正的 ASP NET Application 的分离 作为 Web Server 的IIS运行在一个名为 InetInfo exe 的进程上 InetInfo exe 是一个Native Executive 并不是一个托管的程序 而我们真正的 ASP NET Application 则是运行在一个叫做 aspnet_wp 的 Worker Process 上面 在该进程初始化的时候会加载CLR 所以这是一个托管的环境

ISAPI   指能够处理各种后缀名的应用程序 ISAPI 是下面单词的简写 Internet Server Application Programe Interface 互联网服务器应用程序接口

IIS 模式的特点

首先 同一台主机上在同一时间只能运行一个 aspnet_wp 进程 每个基于虚拟目录的 ASP NET Application 对应一个 Application Domain 也就是说每个 Application 都运行在同一个 Worker Process 中 Application之间的隔离是基于 Application Domain 的 而不是基于Process的 　 其次 ASP NET  ISAPI 不但负责创建 aspnet_wp Worker Process 而且负责监控该进程 如果检测到 aspnet_wp 的 Performance 降低到某个设定的下限 ASP NET  ISAPI 会负责结束掉该进程 当 aspnet_wp 结束掉之后 后续的 Request 会导致ASP NET ISAPI 重新创建新的 aspnet_wp Worker Process

最后 由于 IIS 和 Application 运行在他们各自的进程中 他们之间的通信必须采用特定的通信机制 本质上 IIS 所在的 InetInfo 进程和 Worker Process 之间的通信是同一台机器不同进程的通信（local interprocess munications） 处于Performance的考虑 他们之间采用基于Named pipe的通信机制 ASP NET ISAPI和Worker Process之间的通信通过他们之间的一组Pipe实现 同样处于Performance的原因 ASP NET ISAPI 通过异步的方式将Request 传到Worker Process 并获得 Response 但是 Worker Process 则是通过同步的方式向 ASP NET ISAPI 获得一些基于 Server 的变量 　

IIS 的 请求处理过程

IIS 的 请求处理过程

对图的解释

IIS x 是通过 InetInfo exe 监听 Request 并把Request分发到Work Process 换句话说 在IIS x中对Request的监听和分发是在User Mode中进行 在IIS 中 这种工作被移植到kernel Mode中进行 所有的这一切都是通过一个新的组件 sys 来负责 　注 为了避免用户应用程序访问或者修改关键的 *** 作系统数据 windows提供了两种处理器访问模式 用户模式（User Mode）和内核模式（Kernel Mode） 一般地 用户程序运行在User mode下 而 *** 作系统代码运行在Kernel Mode下 Kernel Mode的代码允许访问所有系统内存和所有CPU指令 　在User Mode下 sys接收到一个基于 aspx 的 request 然后它会根据IIS中的 Metabase 查看该基于该 Request 的 Application 属于哪个Application Pool 如果该Application Pool不存在 则创建之 否则直接将 request 发到对应Application Pool 的 Queue中 　每个 Application Pool 对应着一个Worker Process w wp exe 毫无疑问他是运行在User Mode下的 在IIS Metabase 中维护着 Application Pool 和worker process的Mapping WAS（Web Administrative service）根据这样一个mapping 将存在于某个Application Pool Queue的request 传递到对应的worker process（如果没有 就创建这样一个进程） 在 worker process 初始化的时候 加载ASP NET ISAPI ASP NET ISAPI 进而加载CLR 最后的流程就和IIS x一样了 通过AppManagerAppDomainFactory 的 Create方法为 Application 创建一个Application Domain 通过 ISAPIRuntime 的 ProcessRequest处理Request 进而将流程进入到ASP NET Http Runtime Pipeline

IIS   的 请求处理过程

IIS 站点启动并处理请求的步骤如下图

步骤 到 是处理应用启动 启动好后 以后就不需要再走这个步骤了

IIS   的 请求处理过程

上图的 个步骤分别如下

当客户端浏览器开始HTTP 请求一个WEB 服务器的资源时 HTTP sys 拦截到这个请求 HTTP sys contacts WAS to obtain information from the configuration store

WAS 向配置存储中心请求配置信息 nfig WWW 服务接受到配置信息 配置信息指类似应用程序池配置信息 站点配置信息等等 WWW 服务使用配置信息去配置 HTTP sys 处理策略 WAS starts a worker process for the application pool to which the request was made

The worker process processes the request and returns a response to HTTP sys

客户端接受到处理结果信息

W WP exe 进程中又是如果处理得呢？？ IIS 的应用程序池的托管管道模式分两种 经典和集成 这两种模式下处理策略各不相通

IIS 以及 IIS 经典模式的托管管道的架构

在IIS 之前 ASP NET 是以 IIS ISAPI extension 的方式外加到 IIS 其实包括 ASP 以及 PHP 也都以相同的方式配置（PHP 在 IIS 采用了两种配置方式 除了 IIS ISAPI extension 的方式 也包括了 CGI 的方式 系统管理者能选择 PHP 程序的执行方式） 因此客户端对 IIS 的 HTTP 请求会先经由 IIS 处理 然后 IIS 根据要求的内容类型 如果是 HTML 静态网页就由 IIS 自行处理 如果不是 就根据要求的内容类型 分派给各自的 IIS ISAPI extension 如果要求的内容类型是 ASP NET 就分派给负责处理 ASP NET 的 IIS ISAPI extension 也就是 aspnet_isapi dll 下图是这个架构的示意图

IIS 的执行架构图 以及IIS 应用程序池配置成经典模式的执行架构图

IIS 应用程序池的 托管管道模式  经典  模式也是这样的工作原理 这种模式是兼容IIS 的方式 以减少升级的成本

IIS  应用程序池的 托管管道模式  集成模式

IIS 的执行架构图（集成托管信道模式下的架构）

小结

IIS 到 IIS 的改进 主要是 HTTP sys 的改进

lishixinzhi/Article/program/net/201311/13216

一、2003应用程序池自动死了，不能恢复了，一直出现 Service Unavailable 常见方法如下。1：没有打SP1补丁的时候会出现这个IIS6.0假死问题，但现在微软都在自动更新里面出补丁了，一般你打好最新补丁后是不会出现此问题了。（所以现在的IIS假死与这个关系不是很大）2：从IIS6.0开始CPU资源都在应用池里面限制了，不象以前的IIS.5。所以假死的池的缘故就是池被拉死，你在网站打不开的时候可以看到你的某个应用池是禁用的，上面出现一个红叉。你鼠标右键启动网站又会自动恢复。 这个原因：大概是以下几个因数造成的。（1）：你限制了应用池的资源，限制得太小 比如：50这样或更少更多一点，这个时候如果你这个池下面的网站占用CPU太高，比如超过50% 那么5分钟后他就自动死了，手工默认建立的应用池默认是超过资源不 *** 作。出现上面这个情况解决方法：1：不限制CPU资源，（这个是不可取的，不限制资源，有的程序有BUG占用资源厉害了的，服务器都会被拉死，你可能都无法 *** 作服务器。）2：在超过资源那里选择关闭，这个关闭默认是失败5次，90秒内恢复，一般默认就可。网站能自动恢复，这个关闭：不是永久关闭，意思是超过资源关闭，然后在某时间内自动恢复池。不 *** 作就是不恢复，这个是很多人的误区。（2）：内存限制 在IIS6.0应用池上面有虚拟内存和最大内存限制，如果你设置了这个。那么网站访问量大了 也会出现假死，所以不建议设置这里。默认就可。3：就是服务器自身内存太小，网站运行当然需要使用到内存了，当内存不够的时候应用池也会死掉变成禁用。那么只有等内存全部释放出来才能恢复应用池了。出现这个情况：那么你就要考虑加内存或者检查到底是什么程序占用了内存了。比如MSSQL数据库，这个可是吃内存得大户啊，最好别和WEB服务器同时一个服务器上。很多人用1G内存做 2003系统，2003NET结构是很占用内存的，所以做服务器选2003还得把内存加到2G或更高才好。 内存不够上面 2点讲到的，是没办法 *** 作了，也无法自动恢复。4：就是ACCESS数据库太大或查询太多，这个也会出现把IIS拉死，解决方法；修复ACCESS数据库，或尽量少用ACCESS数据库，升级至sqlserver数据库；或者在技术方面革新，像现在有些网站系统，风讯、动易等cms；pjblog、zblog等博客程序，都支持生成静态功能.5：不同网站用不同应用池：根据你自己实际情况而定，站点大的最好独立一个应用池，限制他的资源超过了自动回收，看上面（1）讲到的，这样就不影响其他站点。中型站点：多个网站共用一个应用池，比如5个站点用一个池，设置他资源时间等等。这样他们就算超资源了也不影响其他应用池的网站。6：设置回收时间：很多人以为设置回收池越短越好，其实是错误的，每次回收当然是把内存回收回来了，但加重了一次服务器的负担，当服务器比较繁忙的时候，有可能导致其他应用池死。所以建议设置共1000就行了。其他独立池按照他网站流量而设置 可以设置600 也行，共用的不建议设置太短。7：网站后台过不了多久自动退出又要重新登陆：这个情况就是你设置回收时间太短了，按照 6点设置吧。 不要设置什么20分、30分这样的，这样不好的。另外一个原因就是和站的响应设置时间有关，设置得稍长些。8：windows 2003系统iis6访问本机的站点时提示“Service Unavailable”；查看iis的应用程序池,状况提示为：未指定错误，同时应用程序池自动停止运行；用事件查看器查看系统错误日志，发现如下提示：-----------------------------------应用程序-特定 权限设置未将 COM 服务器应用程序(CLSID 为{A9E69610-B80D-11D0-B9B9-00A0C922E750})的 本地 激活 权限授予用户 NT AUTHORITY\NETWORK SERVICE SID (S-1-5-20)。可以使用组件服务管理工具修改此安全权限。解决方法，给NETWORK SERVICE 加上访问iis服务的权限，具体方法如下：点击“开始”-“控制面板”-“管理工具”-“组件服务”-“计算机”-“我的电脑”-“DCOM”选项，选择其下的“IIS ADMIN SERVICE”，右健选择“属性”，找到“安全”，在“启动和激活权限”中编辑“自定义”，添加帐号“NETWORK SERVICE ”，给该帐号赋予“本地启动”和“本地激活”的权限，重新启动IIS之后再访问同一站点，则一切正常。9：重启IIS中的特定应用程序池命令和自动重启的方法在 *** 作系统是Windows server 2003 SP1+的情况下，可以用以下命令部分重启IIS应用程序池： cscript.exe c:\windows\system32\iisapp.vbs /a "DefaultAppPool" 其中/a 代表alternatively，"DefaultAppPool"代表应用程序池的实例名。如果要设置自动重启这个应用程序池，可以尝试放在批处理中，用计划任务调用此批处理即可。很多人觉得计划任务不安全，都要禁掉，事实上，计划任务的不安全是建立在其它方面不安全的前提上的，如果由于其它方面的不安全，被放入执行程序，计划任务执行，这和计划任务没有直接关系。当然，关掉，是会减少一些安全隐患，这是不错。

那些都是核心module和handler，不用杞人忧天了。

如果没用到.asp的话，可以禁用

如果你是webform的话，.aspx, .axd, .ashx不能禁用

用到webservice的话，.asmx, .soap不能禁用

用到wcf的话，.svc, .soap不能禁用

如果是mvc程序的话，.cshtml不能禁用

StaticFile不能禁用

---