• IIS 5.X中的ASP.NET
  • 实现了Web Server和ASP.NET App的分离.
    • IIS作为Web Server运行在InetInfo.exe进程上.该进程是非托管的本地进程.
    • ASP.NET App运行在aspnet_wp的Worker进程上.该进程初始化时会加载CLR,所以是一个托管进程.
  • 通过创建虚拟目录将资源Host到IIS下,然后就可以通过IIS访问所有资源.
    • Server会区分静态资源和动态资源.
    • 对于静态资源的请求,不需要Server进行任何的处理,直接提取对应的文件作为Response返回给Client.
    • 对于动态资源.IIS将请求传递给处理程序.然后处理完毕后再经由IIS将结果回传给Client.
      • IIS的处理程序是通过ISAPI Extension实现的.
      • IIS的元数据数据库维护者一个负责把不同类型的资源映射为对应的ISAPI Extension的Mapping.
      • 对应于ASP.NET,是ASP.NET ISAPI.其通过aspnet_isapi.dll加载.
  • 对于不同虚拟目录下的web应用.都是运行于同一进程上下文(aspnet_wp)中.
    • 为了提供隔离性.引用了APP Domain.
    • 
  • IIS处理ASP.NET的流程
    • 对于asp.net的请求.IIS根据Mapping表,将请求交由ASP.NET ISAPI处理.
    • 加载aspnet_isapi.dll.接着创建aspnet_wp的worker进程.
    • worker进程加载CLR来创建一个托管环境.
    • CLR初始化时,会创建一个APP Domain.
    • 这样,流程就被拖入到了ASP.Net HTTP Runtime Piepeline的范畴内.
    • 一台PC只有一个aspnet_wp进程.每一个ASP.NET APP对应一个APP Domain.
    • ISAPI除了负责创建aspnet_wp进程外,还会监测其性能,当性能降低到一定的下限时,关闭该进程.并在下次请求时,重新创建.
  • 由于在不同的进程中运行,所以IIS和ASP.NET之间的通信属于IPC.
    • 采用命名管道来提高性能.
    • ISAPI异步地把请求传递给Worker process并得到结果.
    • 而worker process同步地从ISAPI中得到基于server的变量.
• IIS 6.X
  • IIS 5.X模型的缺陷
    • 在性能上,由于受不同进程间通信的影响,不能从根本上提升性能.
    • 在可靠性上.APP Domain提供了各个APP间的隔离性.但是一旦aspnet_wp进程崩溃,所有的ASPNET APP都会受到影响.
  • IIS 6.X的改进
    • 在可靠性上.引入APP Pool.
      • 初始化时首先创建若干APP Pool.
      • 在创建ASP.NET APP时,我们为其指定一个APP Pool.
      • 在运行时,一个APP Pool对应一个worker process(w3wp.exe).
      • 同一机器上可以有多个worker process.每个Pool中的每一个APP Domain对应于一个ASP.NET APP.
    • 在性能上
      • 对于请求的监听和分发被转移到Kernel Mode上来(组件http.sys)。
      • 请求到达后,http.sys把它传递到正确的APP POOL 队列中,每一个队列属于特定的Pool,即属于特定的工作进程.
      • 接下来工作进程从队列中接受请求.降低了进程间通信带来的性能损失,且可以在工作进程故障时,仍可以接受请求.
    • 每个工作进程有一个应用程序池.w3wp.exe与asp.net不相关,用于处理所有类型的请求,其根据要求的资源类型来加在不同的ISAPI模块.
  • 
  • IIS 元数据数据库中保存着负责APP POOL 和 worker process的映射(1:1)。
    • 在http.sys收到请求后，先查看应该被哪一个APP Pool处理。
    • 如果该pool不存在，创建之。否则，直接发到对应pool的queue上。
    • WAS(web管理服务)根据映射把请求发到worker process.
    • worker process 初始化时，加载ISAPI,ISAPI加载CLR.
• ISAPI运行时(Runtime)
  • ASP.NET本质上就是一个处理器.
    • 接受来自IIS(ISAPI)投递的HTTP请求,经过一系列的处理后,返回响应.
    •  
    • ISAPI运行于非托管环境.它经过一系列的COM调用,最终调用一个托管的,继承自System.Web.Hosting.ISAPIRuntime类的对象.该对象实现了IISAPIRuntime接口.该接口又是基于COM的.IIS调用该对象的ProcessRequest从非托管进入到托管环境.

    • ECB(执行控制块)

      • ISAPIRuntime通过它来实现对ISAPI的间接访问.

      • ISAPI对Runtime的调用是异步的.有时会造成得不到对应的ISAPI生成的响应.所以,在调用ProcessRequest方法时,ISAPI将自己的ECB传过去.这样,Runtime不仅能将结果传回,而且能够通过ECB来得到一些信息.

      • int ProcessRequest([In] IntPtr ecb, [In, MarshalAs(UnmanagedType.I4)] int useProcessModel);通过传入的ECB和iWRType创建一个ISAPIWorkerRequest对象,然后将该对象作为参数调用HttpRuntime.ProcessRequestNoDemand.
  • HTTPContext体现请求的上下文,其生命周期的结束是请求处理结束或超时.
    • 
    • HTTPApplication整个Asp.Net APP的体现.对应于虚拟目录的Gloabal.asax.其本身包含了对请求的各种处理.通过在不同阶段调用我们注册的方法来工作.
  • APPDomain:虽然对一个APP的请求最终都有HTTPApplication来承载.但是,由于pool的出现,app不再唯一对应一个固有的HTTPApplication对象.
    • 
    • 对于一个APP,可能出现多个APP Domain与之对应:在当前APP处理请求时.我们修改了设置文件,这个修改会立即生效.对于改动后的请求,会创建一个新的APP Domain.而原来的APP Domain会持续到请求完成.
    • HtppModule就是一个ASP.NET APP的体现.以plug-in方式: 在外部定义一些请求处理功能,再使用Module封装它,再将其注册到APP上.
      • 其实现了IHTTPModule接口,该接口只有2各方法: Dispose,init(),我们在自定义的实现了该接口的Module中的init方法内:application.事件+=new EventHandler(….)在machine.config和web.config中有其定义.
    • HttpHandler:关注于基于某种类型的资源的请求.
  • ISAPI扩展是使用Win32.dll实现的模块。IIS使用它来处理特殊的资源。
    • ISAPI扩展和文件的映射通过IIS来配置，并被存储在IIS元数据中。每一个文件扩展可以和特定的ISAPI扩展进行关联，IIS在接收到这种文件的请求后，就给相应的ISAPI扩展进行处理。(例如.asp扩展被映射到asp.dll的ISAPI扩展).
    • ASP.NET会配置IIS,使得特定的ASP.NET文件请求被送到aspnet_isapi.dll扩展进行处理.
• 从IIS到HTTP处理器的处理流程

  • l        IIS得到一个请求

    l        查询脚本映射扩展，然后把请求映射到aspnet_isapi.dll文件

    l        代码进入工作者进程（IIS5里是aspnet_wp.exe；IIS6里是w3wp.exe）

    l        .NET运行时被加载

    l        非托管代码调用IsapiRuntime.ProcessRequest()方法

    l        每一个请求调用一个IsapiWorkerRequest

    l        使用WorkerRequest调用HttpRuntime.ProcessRequest()方法

    l        通过传递进来的WorkerRequest创建一个HttpContext对象

    l         通过把上下文对象作为参数传递给HttpApplication.GetApplicationInstance()，然后调用该方法，从应用程序池中获取一个HttpApplication实例。

    l        调用HttpApplication.Init()，启动管道事件序列，钩住模块和处理器

    l        调用HttpApplicaton.ProcessRequest，开始处理请求

    l        触发管道事件

    l        调用HTTP处理器和ProcessRequest方法

    l        把返回的数据输出到管道，触发处理请求后的事件.

• 深入ISAPI
  • 作为约定，ISAPI支持ISAPI扩展（extensions）和ISAPI过滤（filters）。
    • 扩展是请求处理接口，提供了跟Web Server输入和输出相关的逻辑处理。从本质上来说，它是一个事务接口。ASP和ASP.NET都被看作ISAPI扩展的实现。
    • ISAPI过滤是钩子接口，它允许你查看进入IIS的每一个请求并且可以修改请求的内容（包括输入和输出）或者改变模块（如：身份验证等）的行为。
    • ASP.NET通过两个方面的内容：HTTP处理器（对应ISAPI扩展）和HTTP 模块（对应ISAPI过滤）映射到ISAPI.
  • ISAPI是代码的初始点，标识ASP.NET一个请求的开始。ASP.NET映射了不同的扩展到它的ISAPI扩展，当一个请求进来的时候，IIS会检查脚本映射，然后把请求路由到aspnet_isapi.dll.
  • 
  • IIS5直接把aspnet_isapi.dll寄宿在inetinfo.exe进程里.
  • IIS6不再直接寄宿像ISAPI扩展的任何外部可执行代码.IIS总会保持一个单独的工作进程：应用程序池。所有的处理都发生在这个进程里，包括ISAPI dll的执行.在IIS6里，ISAPI扩展运行在应用程序池的工作进程里。而.NET运行时也运行在这个进程里，所以ISAPI扩展和.NET运行时的通信是发生在进程内的。这就使得比必须使用命名管道接口的IIS5具有更高的性能.

ASP.NET在IIS 5/6上的运行模型(ISAPI),布布扣,bubuko.com

ASP.NET在IIS 5/6上的运行模型(ISAPI)