IIS 7.0的特性
IIS 7.0是在IIS 6.0 基础上重新开发的，开发IIS 7.0的目的在于为用户提供一种能够与操作系统高度集成的 Web 应用程序平台。IIS 7.0 能够与ASP.NET 框架高度集成，并且提供了完整的 API，从而可以为平台提供完整的可扩展能力和管理接口，所以，IIS 7.0使得程序员的梦想成为现实。另外，IIS 7.0 还提供了配置委托和完整的诊断套件，诊断套件可以对需求进行跟踪，还提供了高级日志功能，这些都满足了管理员的要求
IIS 7.0将 ASP.NET 与请求管道进行了集成，这也许是IIS 7.0所做出的最为重大的改变。此外，IIS 7.0的可扩展性得到了提高，IIS 7.0提供了配置委托，使用了 XML配置文件，加入了请求跟踪和诊断功能。因为 IIS 7.0提供了这些新的管理工具，所以，与先前版本的 IIS 相比，IIS 7.0受到了管理员的广泛欢迎
与先前版本的IIS 相比，IS 7.0的模块化设计还有利于我们开发定制模块，而且附加功能也更容易实现。从而有利于将内部开发的功能与 IIS更好地结合，还有利于将第三方资源与IIS 更好地结合，甚至有利于微软公司开发的功能与IIS更好地结合。这是因为；无论何时，在无须修改操作系统核心功能的情况下，这些模块和附加程序都可以作为 IIS的插件进行工作，因此，微软公司的IIS开发团队可以在微软公司的标准servicepack过程之外发布功能模块。最终，我们可以更加迅速地获得所需的产品
集成的请求管道
IIS 7.0 的最大变化之一是它可以与 ASP.NET及ASP.NET进程进行紧密集成。IIS 7.0提供了统一的事件管道，该管道将现有的两种独立管道——即IIS管道和ASP.NET管道进行了合并，这两种管道是IIS6.0以及先前版本的IIS提供的。ASP.NET的HTTP模块原先仅侦听 ASP.NET 管道的事件，现在可以监听任何请求。为了向后兼容，IIS7.0还提供了Classic 管道模式，Classic 管道模式可以模拟IIS6.0的 IIS管道，也可以模拟 IIS 6.0的ASP.NET管道
在 IIS 6.0 身份验证模型中，IIS 6.0 首先需要对一个HTTP 请求进行检查以完成身份验证，然后将请求传递给管道。任何已安装的 ISAPI 过滤器都要对请求进行求值(例如，由URLScan 对请求进行处理)；然后检查缓存，其目的在于检查该请求是否已经存在，如果无法从缓存中处理该请求，那么需要加上文件的扩展名来确定对应的请求处理程序。例如，如果扩展名是.SHTM，那么将激活服务器方的 includes 进程，在被处理的页面中加入附加代码，然后，该页面被当作一个 HTML 请求进行处理，并沿着管道进行传送，并且将响应记录到日志中，最后将请求页面返回给浏览器
如果请求文件是一个ASP.NET文件，其扩展名是.ASPX，那么上述处理过程就更复杂 了，这个处理过程可以参见下图。此时，该请求被发送给ASPNET_ISAPLDLL，然后开始在ASP.NET管道中进行处理。然后，再次对请求进行身份验证，并检查ASP.NET缓存，确定合适的 ASP.NET处理程序，然后处理请求，并对请求进行级存、记录日志，然后，将请求传递给 Http.sys管道完成处理，最后将请求的页面返回给浏览器
之所以如此处理，是因为IIS6.0架构中包括了一个单独的单体DLL，需要加载所有的组件模块。每个ISAPI扩展也是一个单独的DLL，与CGI进程一样，都需要加载到内存中，每个请求都要通过各个 DLL进行处理。IIS6.0可以使用应用程序池，还可以单独实现Http.sys进程，这样就提高了总体性能，但是我们无法对coreserver操作本身进行性能调优。
IIS7.0提供了一个单独的统一管道，如下图所示。ASP.NET提供的Forms身份验证和角色管理是身份验证和授权过程的组成部分，因此对一个请求仅验证一次。在IIS7.0中，所有的请求都要经过 ASP.NET的 Forms身份验证模块进行处理，而不仅仅是那些具有.ASPX 扩展名的文件才需要由 ASP.NET的 Forms身份验证模块进行处理。例如，对www.domain1.com/images/myimage.gif的请求首先要传递给ASP.NET的Forms身份验证进程，如果 web.config 文件中的某种身份验证方式拒绝访问该文件或文件夹，那么缺少权限的用户就无法观察或下载该图像。现在将请求传递给管道并退出，然后再传递给发出请求的浏览器，因此无须再传递给ASP.NET等 ISAPI 进程。考虑到兼容性问题，尽管 ISAPI处理程序退出时需要返回一个退出编码，但是实际上请求并没有在ISAPI中进行处理，如果我们不需要考虑遗留代码的兼容性，我们甚至不需要加载ISAPI处理程序
现在，程序员可能发现他们已经不再需要使用ISAPI，他们只要ASP.NET的托管代码(他们对此更为熟悉)就可以满足同样的需求。
在 IIS 7.0管道内部，每个进程都由一个单独的组件进行处理。需要使用这些组件的网站可以单独加载这些组件，如果网站或应用程序不需要在管道中使用这些组件，那么就无须加载这些组件。在应用程序级、网站级和服务器级，这些组件都是可配置的，而且，我们可以在上述任何一个级别中委托组件的配置功能。此外，我们还可以将自定义的组件插入管道，甚至可以将管道中组件的执行顺序重新进行排列——例如，当请求开始执行时，可以触发一个日志跟踪操作，并且当请求结束处理后，将日志跟踪写入一个文件。组件的执行顺序就是各个组件在配置文件中所处的顺序
IIS 7.0 的另一个变化是:
IIS 的配置过程已经集成到ASP.NET 应用程序的配置过程中，这个变化是一个相当显著的变化。现在我们无须再使用IIS注册表设置，而原先作为IIS配置库的 metabase 已经被基于 XML的配置文件所取代，这个基于 XML的配置文件中同时保存了 IIS 设置和 ASP.NET 设置。这样，不仅消除了 ASP.NET 应用程序和应用服务器之间的界限，同时还提高了 IIS 的可配置性，简化了网站和应用程序的部署过程。同时，在 web farm 中的多系统上部署应用程序也更为方便，并且改善了配置的可扩展性。IIS7.0引入了共享配置的概念，在这个概念中，多个 Web 服务器可以使用同一个物理文件作为各自的配置文件，这样，如果我们对 Web farm 的配置进行修改，那么修改的内容可以马上生效
现在，IIS 7.0 使用一个名为 applicationHost.config 的文件保存设置，此外，针对一个独立的 Web 网站或 Web 应用程序，IIS 7.0的配置选项也可以随着ASP.NET的设置一同保存在web.config 文件中，当然，IIS7.0的配置选项保存在该文件的system.webServer节点中
使用 applicationHost.config 配置文件
IIS 7.0 使用文件 applicationHost.config 为 Web 服务器和进程模型保存IIS配置，现在，全局配置保存在%windir%\system32Vinetsrv 目录下的 applicationHost.config 文件中，该文件包括两个主要的部分：
system.applicationHost——这部分内容保存了网站、应用程序、虚拟目录和应用程序池的配置信息
system.webServer——这部分保存了其他设置及全局默认设置
对 URL 位置所进行的配置既可以保存在applicationHost.config 文件中，也可以保存在web.config 文件中。这样，管理员可以设置服务器上的默认位置，而开发人员可以在必要的情况下重新定义这些设置。这些设置可以由 web.config 文件在根级和应用程序级进行继承。在对设置进行委托时，这一点非常重要，因为IIS 管理员可以允许开发人员在应用程序级以很细的粒度对设置进行控制，同时，IIS管理员还能够在网站级对设置进行控制
IIS安装结束后，可以使用applicationHost.config 文件来修改IIS服务器或网站的特性。例如，如果在一个IIS 网站中选择使用Windows身份验证，那么可以使用IIS Manager来添加 Windows身份验证，这个过程与先前版本的IIS类似。也可以在applicationHost.config文件中使用以下代码对一个名为 MyWebSite的网站进行设置，从而完成同样的工作：
<location path="MyWebSite">
<system.webServer>
<security>
<authentication>
<windowshuthentication/>
</authentication>
</security>
</system.vebBerver>
</location>
与此类似，为一个网站添加 ASP也非常简单：
<system.webBerver>
<asp/>
</system.webServer>
配置应用程序池同样也非常简单：
<system.applicationHost>
<applicationPoo1s>
<applicationPoo1Defaults>
<processModel userName="SitelAppPoolUser" password="Passw0rd"/>
</appl1cationPoo1Defaults>
</add name="SitelAppPoo1"/>
</appl1cationPools>
</system.applicatfonHost>
IIS 7.0采用这种新型配置方式具有两大优势。第一个优势是在无须使用配置注册表的情况下，就可以使用 XCopy 方式部署网站或应用程序，与使用导入/导出 metabase设置的方式相比，这将使得跨 Wcb farm 部署变得相当容易。同时，这种配置方式还提高了在远程服务器上部署的速度，而且，当Web网站应用程序包含了特定的配置时，这种配置方式还可以为自定义的Web网站应用程序提供简洁的客户安装手段
这种新配置方式的第二个优势是：开发人员可以为其所开发的应用程序修改配置文件，确定必要的IIS配置需求。这个修改操作可以进行委托，这样，必须使用的HIS配置就不会被意外修改。此外，设置具有层次结构，因此，服务器设置级联到网站和应用程序级，这样就可以暂时不修改低级的设置。这样，习惯于使用配置文件来配置应用程序的开发人员就无须再学习IIS的管理，而管理员可以让开发人员自行配置其开发的应用程序，同时，管理员仍然掌控着整个系统
可扩展的配置架构
利用新的配置模型，可以很容易对IIS 7.0配置进行扩展。现在，假定我们需要为IIS创建一个新的模块。此时，需要在 applicationHost.config 文件的<globalModules>节点指出模块对应的DLL文件，然后，在applicationHost.config文件中或适当的web.config文件中声明该模块。为新模块扩展配置架构与在系统的 inetsrv\config\schema 目录中创建架构文件一样简单。通过在applicationHost.config文件的<configSections>配置节中添加节点内容，就可以完成这项工作
例如，可以在<globalModules>节点中添加以下内容：
<globalModules>
<add name="MyNexModule”image="c:\modules\MyNewModule.dl1”/>
...
</globalModules>
然后,将以下内容添加到使用该模块的网站的applicationHost.config文件(或web.config文件)中的<modules>节点内：
<modules>
<add name="MyNewModule/>
...
</modules>
然后，需要为新模块在 inetsrvlconfigschema 文件夹中创建一个新的架构文件MyNewModule.xml:
<configSchema>
<sectionSchema name="MyNewModule">
<attribute name="enabled" type="bool" defaultVaiue="false" />
<attribute name="message" type="string" defaultValue="Hello World!" />
</sectionSchema>
</configSchema>
最后，需要在 applicationHost.config 文件中注册该节内容，如下所示：
<configSections>
<section name="MyNexModule" />
...
</configSections>
通过使用上述方法对配置文件进行简单修改，就已经成功地为 IIS 添加了一个自定义
模块MyNewModule，该模块具有自定义的架构
