IIS7架构原理

ainila

原文链接http://www.cnblogs.com/isdavid/archive/2013/05/28/3103228.html
IIS7架构原理
　　IIS7架构简介：
　　1：Windows进程激活服务（WAS），使网站使用HTTP和HTTPS以外的其他协议。
　　Windows 进程激活服务通过删除对 HTTP 的依赖关系，可统一 Internet 信息服务 (IIS) 进程模型。通过使用非 HTTP 协议，以前只可用于 HTTP 应用程序的 IIS 的所有功能现在都可用于运行 Windows Communication Foundation (WCF) 服务的应用程序。IIS 7.0 还使用 Windows 进程激活服务通过 HTTP 实现基于消息的激活。
　　2：Web服务器引擎，它可以通过添加或删除模块定制。
　　3: 集成的IIS和ASP.NET请求处理管线。
IIS 7.0 的 ASP.NET 应用程序生命周期 托管管道模式：经典模式(Classic) 集成模式(Integrated)
　　首先声明两个概念：ASP.NET应用程序生命周期、 ASP.NET页生命周期(http://msdn.microsoft.com/zh-cn/library/ms178472(v=vs.100).aspx)
　　“管道模式”针对ASP.NET应用程序生命周期而言，区分为 经典模式和集成模式。
　　IIS7.0集成管道是一种统一的请求处理管道，它同时支持本机代码和托管代码模块。实现IHttpModule接口的托管代码模块可访问该请求管道中的所有事件。例如，托管代码模块可用于 ASP.NET 网页（.aspx 文件）和 HTML 页（.htm 或 .html 文件）的 ASP.NET Forms 身份验证。
　　权威参考：http://msdn.microsoft.com/zh-cn/library/bb470252(v=VS.100).aspx
　　在IIS6.0中，有两个请求处理管道：1.用于本机代码ISAPI筛选器和扩展组件；2.用于托管代码应用程序组件。在IIS7.0 中，ASP.NET运行时与Web服务器集成，有了一个针对所有请求的统一请求处理管道。
　　权威参考： http://msdn.microsoft.com/zh-cn/library/ms178473(v=vs.100).aspx
　　IIS5、IIS6原理：

　　IIS 5.x与ASP.NET
　　IIS 5.x运行在IIS进程InetInfo.exe中，在该进程中一个最重要的服务就是名为World Wide Web Publishing Service（简称W3SVC）的Windows Service。W3SVC的主要功能包括HTTP请求的监听、工作进程的管理以及配置管理（通过从Metabase中加载相关配置信息）等。
　　当检测到某个HTTP Request后，先根据扩展名判断请求的是否是静态资源（比如.html,.img,.txt,.xml等），如果是则直接将文件内容以HTTP Response的形式返回。如果是动态资源（比如.aspx,asp,php等等），则通过扩展名从IIS的脚本影射（Script Map）找到相应的ISAPI Dll。
　　ISAPI是Internet服务器API（Internet Server Application Programming Interface）的缩写，是一套本地的Win32 API，具有较高的执行性能,是IIS和Web应用或者平台之间的纽带。比如ASP ISAPI桥接IIS与ASP，而ASP.NET ISAPI则连接着IIS与ASP.NET。ISPAI定义在一个Dll中，ASP.NET ISAPI对应的Dll为Aspnet_isapi.dll,你可以在目录“%windir%\Microsoft.NET\Framework\{version no}\”中找到该Dll。
　　ISAPI支持ISAPI扩展和ISAPI筛选，前者是真正处理HTTP请求的接口，后者则可以在HTTP请求真正被处理之前查看、修改、转发或者拒绝请求，比如IIS可以利用ISAPI筛选进行请求的验证（Authentication）。
　　如果请求ASP.NET的资源类型，Aspnet_isapi.dll会被加载，ASP.NET ISAPI扩展会创建ASP.NET的工作进程（如果该进程尚未启动），对于IIS 5.x来说，该工作进程为aspnet_wp.exe。IIS进程与工作进程之间通过命名管道进程通信，以获得最好的性能。
　　在工作进程初始化过程中，.NET 运行时（CLR）被加载，从而构建了一个托管的环境。对于某个Web应用的初次请求，CLR会为其创建一个AppDomain。在此AppDomain中，HTTP Runtime被加载并用以创建相应的应用。对于寄宿于IIS 5.x的所有Web 应用都运行在同一个进程（工作进程Aspnet_wp.exe）的不同AppDomain中。
　　IIS 6与ASP.NET
　　通过上面的介绍，我们可以看出IIS 5.x至少存在着如下两个方面的不足：

• 　　ISAPI Dll被加载到InetInfo.exe进程中，它和工作进程之间是一种典型的跨进程通信方式，尽管采用性能最好的命名管道，但是仍然会带来性能的瓶颈；
  
• 　　所有的ASP.NET应用，运行在相同的进程（aspnet_wp.exe）中的不同的应用程序域（AppDomain）中，基于应用程序域的隔离级别不能从根本上解决一个应用程序对另一个程序的影响，在更多的时候，我们需要不同的Web应用运行在不同的进程中。
  

　　在IIS 6.0中，为了解决第一个问题，ISAPI.dll被直接加载到工作进程中。为了解决第2个问题，引入了应用程序池（Application Pool）的机制。我们可以为一个或者多个Web应用创建应用程序池，每一个应用程序池对应一个独立的工作进程，从而为运行在不同应用程序池中的Web应用提供基于进程的隔离级别。IIS 6.0的工作进程名称为w3wp.exe。
　　IIS 6.0创建了一个新的HTTP监听器：HTTP协议栈（HTTP Protocol Stack，HTTP.SYS）。HTTP.SYS运行在Windows的内核模式（Kernel Mode）下，作为驱动程序而存在。它是Windows 2003的TCP/IP网络子系统的一部分，从结构上，它属于TCP之上的一个网络驱动程序。严格地说，HTTP.SYS已经不属于IIS的范畴了，所以HTTP.SYS的配置信息并不保存在IIS的元数据库（Metabase），而是定义在注册表中。HTTP.SYS的注册表项位于下面的路径中：HKEY_LOCAL_MACHINE/SYSTEM/CurrentControlSet/Services/HTTP。HTTP.SYS能够带来如下的好处：

• 　　持续监听：由于HTTP.SYS是一个网络驱动程序，始终处于运行状态，对于用户的HTTP请求，能够及时作出反应；
  
• 　　更好的稳定性：HTTP.SYS运行在操作系统内核模式下，并不执行任何用户代码，所以其本身不会受到Web应用、工作进程和IIS进程的影响；
  
• 　　内核模式下数据缓存：如果某个资源被频繁请求，HTTP.SYS会把响应的内容进行内核模式的缓存(不存在内核模式和用户模式的切换，响应速度将得到极大的改进)，缓存的内容可以直接响应后续的请求。
  

　　图2体现了IIS的结构和处理HTTP请求的流程。从中可以看出，与IIS 5.x不同，W3SVC从InetInfo.exe进程脱离出来（对于IIS6.0来说，InetInfo.exe基本上可以看作单纯的IIS管理进程），运行在另一个进程SvcHost.exe中。不过W3SVC的基本功能并没有发生变化，只是在功能的实现上作了相应的改进。与IIS 5.x一样，元数据库（Metabase）依然存在于InetInfo.exe进程中。
　　当HTTP.SYS监听到用户的HTTP请求后，将其分发给W3SVC。W3SVC解析出请求的URL，并根据从Metabase获取的URL与Web应用之间的映射关系得到目标应用，并进一步得到目标应用运行的应用程序池或者工作进程。如果工作进程不存在（尚未创建或者被回收），则为该请求创建新的工作进程，工作进程的这种创建方式被称为请求式创建。在工作进程的初始化过程中，相应的ISAPI.dll被加载，对于ASP.NET应用来说，被加载的ISAPI.dll为Aspnet_ispai.dll。ASP.NET ISAPI再负责进行CLR的加载、AppDomain创建、Web Application的初始化等。
　　In IIS 6.0, W3SVC the following main areas in IIS:

• 　　HTTP管理和配置（从IIS元数据读取配置信息并配置协议栈HTTP.sys，）
  
• 　　进程管理（管理应用程序池和工作进程，启动、停止、回收，工作进程健康状态监视，失败检测）
  
• 　　进程监控
  　　
  

　　IIS 7.0与ASP.NET
　　权威参考：http://www.iis.net/learn/get-started/introduction-to-iis/introduction-to-iis-architecture
　　IIS 7.0对请求的监听和分发机制上又进行了革新性的改进，主要体现在对于Windows进程激活服务（Windows Process Activation Service，WAS）的引入，将原来（IIS 6.0）W3SVC承载的部分功能分流给了WAS。对于IIS 6.0来说，W3SVC主要承载着三大功能：

• 　　HTTP请求接收：接收HTTP.SYS监听到的HTTP请求；
  
• 　　配置管理：从元数据库（Metabase）中加载配置信息对相关组件进行配置；
  
• 　　进程管理：创建、回收、监控工作进程。
  

　　In IIS, the WWW service no longer manages worker processes. Instead, the WWW Service is the listener adapter for the HTTP listener, HTTP.sys. As the listener adapter, the WWW Service is primarily responsible for configuring HTTP.sys, updating HTTP.sys when configuration changes, and notifying WAS when a request enters the request queue.
　　Additionally, the WWW Service continues to collect the counters for Web sites. Because performance counters remain part of the WWW Service, they are HTTP specific and do not apply to WAS.
　　在IIS 7.0，后两组功能被移入WAS中，接收HTTP请求的任务依然落在W3SVC头上。
　　WAS的引入为IIS 7.0一项前所未有的特性：同时处理HTTP和非HTTP请求。在WAS中，通过一个重要的接口：监听器适配器接口（Listener Adapter Interface）抽象出不同协议监听器监听到的请求。至于IIS下的监听器，除了基于网络驱动的HTTP.SYS提供HTTP请求监听功能外，WCF提供了3种类型的监听器：TCP监听器、命名管道（Named Pipes）监听器和MSMQ监听器。对应3种监听适配器（Adapter）提供监听器与监听器适配器接口之间的适配。从这个意义上讲，IIS 7.0中的W3SVC更多地为HTTP.SYS起着监听适配器的功能。WCF提供的这3种监听器和监听适配器定义在程序集SMSvcHost.exe中，你可以通过下面的目录找到该程序集：%windir%\Microsoft.NET\Framework\v3.0\Windows Communication Foundatio。
　　WCF提供的这3种监听器和监听适配器最终以Windows Service的形式体现，虽然它们定义在一个程序集中，我们依然通过服务工作管理器（SCM，Service Control Manager）对其进行单独的启动、终止和配置。SMSvcHost.exe提供了4个重要的Windows Service：

• 　　NetTcpPortSharing：为WCF提供TCP端口共享；
  
• 　　NetTcpActivator：为WAS提供基于TCP的激活请求，包含TCP监听器和对应的监听适配器；
  
• 　　NetPipeActivator：为WAS提供基于命名管道的激活请求，包含命名管道监听器和对应的监听适配器；
  
• 　　NetMsmqActivator：为WAS提供基于MSMQ的激活请求，包含MSMQ监听器和对应的监听适配器。
  

　　ASP.NET集成
　　从上面对IIS 5.x和IIS 6.0的介绍中，我们不难发现这一点，IIS与ASP.NET是两个相互独立的管道（Pipeline），在各自管辖范围内，它们各自具有自己的一套机制对HTTP请求进行处理。两个管道通过ISAPI实现“联通”：IIS是第一道屏障，当对HTTP请求进行必要的前期处理（比如身份验证等）后，通过ISAPI将请求分发给ASP.NET管道。当ASP.NET在自身管道范围内完成对HTTP请求的处理后，处理后的结果再返回到IIS，IIS对其进行后期处理（比如日志记录、压缩等），最终生成HTTP响应（HTTP Response）。从另一个角度讲，IIS运行在非托管的环境中，而ASP.NET管道则是托管的，从这个意义上讲，ISAPI还是连接非托管环境和托管环境的纽带。下图反映了IIS 6.0与ASP.NET之间的桥接关系。

　　IIS 5.x和IIS 6.0下把两个管道进行隔离至少带来了下面一些局限与不足：

• 　　相同操作的重复执行：IIS与ASP.NET之间具有一些重复的操作，比如身份验证；
  
• 　　动态文件与静态文件处理的不一致：因为只有基于ASP.NET的动态文件（比如.aspx、.asmx、.svc等等）的HTTP请求才能通过ASP.NET ISAPI进入ASP.NET管道，而对于一些静态文件（比如.html、.xml、.img等）的请求，则由IIS直接响应，那么ASP.NET管道中的一些功能将不能用于这些基于静态文件的请求，比如，我们希望通过Forms认证应用于基于图片文件的请求；
  
• 　　IIS难以扩展：对于IIS的扩展基本上就体现在自定义ISAPI，但是对于大部分人来说，这不是一件容易的事情。因为ISAPI是基于Win32的非托管的API，并非一种面向应用的编程接口。通常我们希望的是诸如定义ASP.NET的HttpModule和HttpHandler一样，通过托管代码的方式来扩展IIS。
  

　　对于Windows平台下的IIS来讲，ASP.NET无疑是一等公民，它们之间不应该是“井水不犯河水”的关系，而应该是“你中有我，我中有你”的关系。为此，在IIS 7.0中，实现了两者的集成。对于集成模式下的IIS 7.0，我们获得如下的好处。

• 　　允许我们通过本地代码（Native Code）和托管代码（Managed Code）两种方式定义IIS Module，这些IIS Module注册到IIS中形成一个通用的请求处理管道。由这些IIS Module组成的这个管道能够处理所有的请求，不论请求基于怎样的资源类型。比如，可以将FormsAuthenticationModule提供的Forms认证应用到基于.aspx，CGI和静态文件的请求。
  
• 　　将ASP.NET提供的一些强大的功能应用到原来难以企及的地方，比如将ASP.NET的URL重写功能置于身份验证之前；
  
• 　　采用相同的方式去实现、配置、检测和支持一些服务器特性（Feature），比如Module、Handler映射、错误定制配置（Custom Error Configuration）等。
  

　　在ASP.NET集成模式下，IIS整个请求处理管道的结构。ASP.NET提供的托管组件可以直接应用在IIS管道中。