IIS 7.0探索用于 Windows Vista 的 Web 服务器和更多内容

我

经常听到 Microsoft 内部和外部的人将新的 IIS 7.0 Web 服务器称为 Microsoft 在过去几年中所进行的最重要的开发工作之一。考虑到 Microsoft 最近推出了一系列引人注意的技术，包括 Windows Vista™，这个评语具有重要意义！

 

IIS 7.0 的发布时间正好是 Windows NT ^® 4.0 中第一个 IIS 版本发布十周年的纪念日。2001 年，在四个版本之后，IIS 5.0 成为了 Internet 上最流行的 Web 服务器，尽管几个月后它成了臭名昭著的 Code Red 和 Nimbda 蠕虫的攻击对象。IIS 6.0 是在 Windows Server ^® 2003 中发布的，它对服务器进行了重大改写，将重点完全放在改进安全性、可靠性和性能上面。此后，IIS 6.0 已被证明是坚如磐石的 Web 服务器，自从发布后，它获得了高可靠性和高安全性记录，而且只有一条关键安全公告（不是可远程利用的）。

在本文中，我要利用这个机会向开发人员和管理员介绍下一代 IIS 7.0 Web 服务器之所以有如此大的差异的主要原因，并使您在使用它的很多新功能时有个良好的开始。

IIS 7.0 的远景是要继承 IIS 6.0 基本代码的速度、可靠性和安全性，并将它演进成高度可扩展和可管理的 Web 服务器平台，具备足以运行未来 Web 应用程序的强大功能。最终成为最具前景的 Microsoft Web 服务器，并带来在 IIS 历史上最大程度的体系结构改进。

IIS 7.0 的核心是一个完全模块化的 Web 服务器，它由 40 多项功能组成，这些功能可以组合成一个针对在应用程序拓扑中的所需角色经过优化的小型 Web 服务器。这些功能基于一个新的可扩展层，这个层允许开发人员以本机代码或者用 Microsoft ^® .NET Framework 来扩展或替换服务器的几乎任何方面。IIS 7.0 在整个运行库、管理和操作功能方面都提供了可扩展性，以帮助您为特定需要构建端到端解决方案。在核心平台的基础上，IIS 7.0 解决了与服务器的可管理性和操作相关的很多问题。它采用全新的配置系统，能够对站点进行完全委派的管理，并最终使 Web 应用程序的 xcopy 部署成为现实。新的管理 API 和诊断功能使服务器的部署、管理和故障排除明显变得比以前更容易、更方便。

但在下一个 Windows Server 版本（代号为“Longhorn”）即将最后发布之前，为什么应当开始考虑 IIS 这个服务器应用程序呢？现在开始考虑采用它之所以重要，是因为 Windows Vista 将附带相同的全功能 IIS 7.0 程序，这些程序预计将在 Windows Server“Longhorn”中发布。这意味着您可以立即利用新的 IIS 7.0 功能构建您的个人网站，并将它承载在 Windows Vista 上。此外，当 Windows Server“Longhorn”发布时您将把生产 Web 应用程序以及 Web 服务器基础结构部署到相同的 IIS 平台上，就这一点来说，您可以率先开始开发和测试它们。

有兴趣吗？让我们深入讨论细节。

模块化 Web 服务器

IIS 7.0 将 Web 服务器分成一个轻型服务器核心，以及可以插入此核心中的 40 多个功能模块。这些模块（比如允许下载静态 Web 内容的 StaticFileModule，或者支持集成的 NTLM 身份验证的 WindowsAuthModule）可以单独安装在服务器上，以提供您需要的具体功能。

可以在任何时候从服务器上完全卸载这些模块（请参阅 图 1），或为不需要它们的特定应用程序而专门禁用它们。这将帮助服务器管理员快速地部署小型服务器，同时大大减少受攻击可能性，并通过只执行所需代码极大地提高性能。

图 1  只使用需要的功能 (单击该图像获得较大视图)

组件化体系结构是 IIS 7.0 的关键属性，它可以降低安全风险，并最大程度减少安装修补程序的必要。它还支持特殊化的服务器部署，这样的部署可以将选择 IIS 功能和自定义组件组合起来，针对应用程序拓扑中的特定服务器角色对它们进行优化，例如，反向代理和缓存服务器、HTTP 协议负载平衡器、或 SSL 和安全 sentinel 服务器。

IIS 7.0 所附带的所有服务器功能都基于新的公用可扩展 API。作为开发人员，您可以用您自己的功能替换任何现有服务器功能，也可以构建新的模块以添加到 IIS 7.0 功能集中。您是否希望用自定义的身份验证模块替换内置身份验证机制，或者提供新形式的响应压缩？请继续。

新的可扩展 API 是对以前的 ISAPI 可扩展模型的根本改进，使您能够更灵活、更轻松增强服务器。几乎服务器的每个方面（从核心服务器直到配置、管理和诊断）都提供了可扩展性，使您可以根据自己的需要扩展和裁减服务器。本文稍后将提供有关可扩展性的更多介绍。

经过简化的部署和配置

以前的 IIS 版本所采用的集中化配置存储（人们亲切称其为元数据库）已经一去不复返了。IIS 7.0 具有新的委派配置系统，它基于分布式 XML 配置文件的层次结构。此层次结构由全局 applicationHost.config 文件（该文件包含服务器级别的配置默认设置）以及应用程序的目录结构中的分布式 web.config 文件组成。这些文件与 ASP.NET 应用程序框架用于以可移植方式存储应用程序设置的 web.config 文件是相同的文件。因而可以使用干净和强大结构化的 XML 指令，并排地存储 IIS 和 ASP.NET 配置。下面是示例：

<?xml version="1.0" encoding="UTF-8"?>
<configuration>
<system.web>
<customErrors mode="Off" />
</system.web>
<system.webServer>
<directoryBrowse enabled="true" />
</system.webServer>
</configuration>

 

过去，必须在机器级的元数据库存储库中显式配置 IIS 应用程序设置，然后应用程序才能正常工作。而使用分布式 web.config 文件，应用程序则将必需的服务器配置封装在其目录结构中。这就大大简化了部署，从而可以将独立的应用程序直接复制到目标服务器的应用程序目录中，从而以所需设置立即启动和运行。

新的配置系统还为服务器管理员提供了全面控制权，允许他们将某些配置选项委派给应用程序，同时由于安全或业务原因保持对其他选项的控制。这样，托管服务器上的应用程序可以在其应用程序中直接设置必需的配置，而不需要求助于服务器管理员或使用外部配置面板。

在 IIS 7.0 中，配置系统是完全可扩展的。新模块可以添加它们自己的配置架构，从而使应用程序能够与 IIS 和 ASP.NET 配置一起并排配置其功能：

<configuration>
<system.webServer>
<directoryBrowse enabled="true" />
</system.webServer>
<myBandwidthThrottler enabled="true" />
</configuration>

 

自定义配置部分使用了与 IIS 7.0 功能的配置相同的配置架构，从而利用了强大的类型属性值、集合语法和分层重写及锁定语义。

IIS 7.0 继续支持现有安装代码使用管理基础对象 (ABO) API 向原有元数据库写入数据，或使用那些使用更高级别的 Active Directory ^® 服务接口 (ADSI) 和 Windows Management Instrumentation (WMI) 对象的脚本来配置 IIS。它通过提供模拟 ABO API 的兼容层来实现这样的支持（所有其他原有配置 API 均基于该兼容层），从而允许上述脚本就像在以前版本的 IIS 中一样读取和更改配置。（有关元数据库兼容性的详细信息，请参阅本文后面的“经过改进的性能”和“向后兼容”两节。）虽然新的结构化 XML 配置格式使您更容易在您喜欢的文本编辑器中处理配置，但 IIS 还是为管理员提供了很多管理工具和 API，以简化服务器管理，并支持自动配置和部署。

经过改进的管理

IIS 7.0 提供了一组丰富的管理功能，使得用户可以在广泛的方案中管理服务器。新的图形化 IIS 管理器管理工具取代了 InetMgr.exe MMC 管理单元，借助其基于任务的管理界面，使手动服务器管理变得非常简单（参见 图 2）。

图 2  IIS 管理器提供了图形化管理工具 (单击该图像获得较大视图)

IIS 管理器允许您管理大多数 IIS 7.0 功能，并监视服务器的操作。该工具支持通过防火墙友好的 HTTP/SSL 连接进行远程管理，并且可以选择同时支持用于身份验证的基于 Windows 的凭据和其他凭据。

此外，该工具支持委派管理，从而让应用程序所有者能够远程管理其应用程序，而不必对服务器计算机具有管理访问权。借助此功能，托管服务的用户可以在其家用桌面机上运行管理工具，并远程连接以管理其在托管服务器上的应用程序。当然，服务器管理员对可以将哪些管理功能委派给应用程序所有者拥有完全控制权。

最后，该管理工具是完全可扩展的，它基于配置系统可扩展性，允许将自定义管理 UI 添加到工具中。在 iis.net/default.aspx?tabid=7&subtabid=73 中可以详细了解 IIS 管理器工具以及如何添加自己的管理插件。

为了获得更灵活的命令行管理，IIS 7.0 提供了 appcmd.exe 命令行工具（参见 图 3）。此工具提供了一组全面的管理功能和比 UI 更好的批量操作支持。通过这个功能强大的实用程序，可以轻松从命令提示符读取和写入配置、访问站点和应用程序池状态信息以及执行几乎任何其他管理任务。

图 3  IIS 7.0 的 Appcmd.exe 命令行管理 (单击该图像获得较大视图)

利用 appcmd.exe，可以创建和配置站点、应用程序、应用程序池和虚拟目录。通过它，可以启动和停止站点、回收应用程序池、列出正在运行的工作进程、检查当前正在执行的请求以及搜索失败事件请求缓冲 (FREB) 跟踪日志。还可以搜索、编辑、导出和导入 IIS 及 ASP.NET 配置数据。

该工具旨在使您可以灵活搜索受支持的服务器对象，例如，使您能够快速找到有特定设置集的站点，或已停止的应用程序池。执行搜索时，可以对任何对象的属性使用任意数量的条件，包括使用数字范围和简单通配符字符串匹配。

Appcmd 还支持类似 Windows PowerShell™中出现的链接操作，从而允许从单个命令行一起执行针对一组相关对象的多个操作。例如，您可以用一条命令查找和回收承载某个站点的应用程序的所有应用程序池。若要了解如何用 AppCmd 管理 IIS，请参阅 iis.net/default.aspx?tabid=2&subtabid=25&i=954&p=1。

.NET Framework 和脚本

除了用 IIS 管理器或 appcmd.exe 命令行工具进行手动服务器管理以外，IIS 7.0 还为编程管理提供了丰富的选项。首先，可以利用 Microsoft.Web.Administration API 通过 .NET 应用程序管理服务器。也可以使用新的 COM API 直接管理 IIS 配置系统，或从诸如 ASP 或 Windows ^® Script Host (WSH) 这样的脚本环境访问它。还有新的 WMI 提供程序，以及通过元数据库兼容层实现的对原有 WMI 和 ADSI 提供程序的支持。

Microsoft.Web.Administration 是新的 .NET 管理 API，它使托管代码应用程序可以轻松地以编程方式设置 IIS 站点和应用程序、访问重要状态和诊断信息以及按其他方式配置服务器。通过让基于 .NET Framework 的应用程序轻松访问 IIS 配置及状态信息，为编写基于 .NET 的安装和管理应用程序，甚至是直接从 ASP.NET 页执行管理任务，提供了可能。

作为示例， 图 4 显示了一个小型 C# 程序，该程序使用 Microsoft.Web.Administration 从命令行新建网站。

Microsoft.Web.Administration 使 IIS 操作和配置任务能够直接在您选择的支持 .NET 语言的应用程序内部轻松完成。它还使您可以轻松访问有关服务器的运行库状态信息，例如，正在运行的工作进程或当前正在执行的请求。

Microsoft.Web.Administration API 是访问自定义 .NET 服务器模块内部的自定义配置和 IIS 管理器工具的 UI 插件的基础。有关端到端服务器包的示例，包括用于增强 Web 服务器和相关配置及管理组件的图像版权处理程序，请参阅 iis.net/default.aspx?tabid=2&subtabid=25&i=1076。

在 Windows Server“Longhorn”时间范围内，IIS 团队将为添加自定义管理对象或扩展现有管理对象而创建统一的可扩展模型，这些模型将使自定义管理功能通过不同管理功能（包括脚本和 Microsoft.Web.Administration API）自动公开。当您无法添加或扩展 Windows Vista 中的管理对象时，可以使用 Microsoft.Web.Administration 和其他 API，就像现有 IIS 配置部分一样，访问和管理自定义配置部分。

构建 Web 服务器功能

IIS 7.0 使您能够根据您的需要塑造服务器，允许您添加或替换服务器中的任何功能，以便提供您需要的功能。此功能的核心是全新的 Web 服务器可扩展 API，所有现有 IIS 7.0 HTTP 功能都建立在它之上。此 API 是公用的，这意味着您可以实现 IIS 7.0 附带的任何功能。这对 IIS 是第一次，并且是对以前的有限 ISAPI 可扩展模型的根本改进。

新的可扩展 API 是一组直观的 C++ 类，这些类定义了 Web 服务器对象模型，并使一个模块能够在 IIS 上提供请求处理服务。这些类被定义在 Windows Vista SDK 中的 \inc\httpserv.h 头文件中。

与 ISAPI 比较，这些 API 功能更强大，而且易用性得到了极大增强。这是如何实现的？首先，新的 API 具有类型安全、良好封装的对象模型。用新的服务器对象模型可以更轻松地进行开发，该模型为所有基本服务器对象和任务提供了专门的接口。包括：

• 用 IHttpRequest 类检查请求
• 用 IHttpResponse 类管理响应
• 从 IHttpServer 类使用有用的实用程序功能
• 用 IHttpUser 类提供身份验证
• 用配置 API 访问您的模块的自定义配置部分

 

这些类公开了比以前更多的服务器功能（超过了构建 IIS 附带的所有特性所需的功能），但仍然比松散的类型化 ISAPI 接口更容易使用。

开发人员还将受益于经过改进的内存和状态管理模式。大多数 IIS 7.0 服务器 API 都使用服务器托管内存来存储它们返回的数据，而不是像 ISAPI 和大多数现有 Win32 ^® API 那样需要您分配和管理缓冲区。过去，这一直是 ISAPI 开发中最容易产生错误也是最令人厌烦的方面。新的 API 还简化了很多复杂的请求处理任务，例如，响应缓冲、身份验证和为客户端准备响应数据。几个月以前，我开始发表我的一系列博客文章，以解释新编程模型中的重大改进和模式。如果您正在考虑针对 IIS 的 C++ 开发，可通过访问以下网址参考相关内容： mvolo.com/blogs/serverside/archive/2006/10/07/10-reasons-why-server-development-is-better-with-IIS7.aspx。

IIS 7.0 还为扩展服务器提供了完全集成的 .NET Framework API。此外，这与自从 Windows 2000 上的 ASP.NET 1.0 发布以来 ASP.NET 提供的用于构建 ASP.NET 模块和处理程序的 API 是相同的。但两者有区别，人们熟悉的 ASP.NET 模型允许现有 ASP.NET 模块和处理程序继续工作在 IIS 7.0 服务器上，但实际上它已完全不同于以前的旧技术。

在 IIS 7.0 中，ASP.NET 有两个版本：经典模式和集成模式。经典模式的工作方式与它在以前版本的 IIS 中完全相同。集成模式是新的平台默认设置，它使用全新的引擎来提供与 IIS Web 服务器前所未有的集成。在集成模式下，可以用 ASP.NET API 开发 IIS 7.0 模块，这样的模块可以直接与 Web 服务器集成，并且能够提供用基本 C++ API 即可实现的几乎所有服务。

这基本上是两个方面的最佳结合：像成员身份和角色管理这样的 .NET Framework 和 ASP.NET 2.0 应用程序服务所具有的熟悉的接口和方便性，以及以前只对基于 C 的 ISAPI 组件可用的扩展服务器的原始能力。

除了能够编写新的 ASP.NET 模块（建立在集成模式的特定优势之上）之外，只需通过在 web.config 文件中更改少量配置选项，就可以使很多原有 ASP.NET 模块变得更为强大。

ASP.NET 集成

使用 IIS 7.0，ASP.NET 2.0 不止是建立动态应用程序的优秀框架。它还成为扩展 IIS Web 服务器的平台，这使得 ASP.NET 组件成为 IIS 请求处理管道的完整成员。下面介绍它的工作原理。

在直到 6.0 版的 IIS 版本中，ASP.NET 均作为独立的应用程序框架连接到 Web 服务器。它负责处理向它注册的请求扩展（通常是 .aspx 和少量其他扩展名），并且它还为这些请求提供强大的功能，如窗体身份验证、响应输出缓存以及其他功能，包括由自定义 ASP.NET 模块提供的服务。因此，只有向 ASP.NET 注册的内容类型才能受益于这些服务。包括 ASP 页、PHP 页、图像和 CGI 应用程序在内的其他类型则无法受益。此外，由于运行库限制，即使对于 ASP.NET 资源，也无法在 ASP.NET 中实现某些 Web 服务器功能。例如，它不能检查传出 HTTP 响应标头集并在发送到客户端之前修改它们。

当 ASP.NET 模块在 IIS 7.0 中以集成模式运行时，将与本机 C++ IIS 模块并排运行在统一请求处理管道中（参见 图 5）。这意味着现有 ASP.NET 服务（如输出缓存、URL 重写和由自定义 ASP.NET 模块提供的任何其他服务）现在可以应用于任何内容类型。更好的运行库集成还使 ASP.NET 模块能够访问以前不可用的服务器功能，这样，在大多数情况下，不再需要编写本机 IIS 可扩展功能。

图 5  在 IIS 6.0 和 IIS 7.0 中与 ASP.NET 集成 (单击该图像获得较小视图)

最后，在集成模式中，ASP.NET 提供了少量新 API，用于公开由于与 IIS 紧密集成而可用的其他功能。其中包括检查所有响应标头（不管是谁生成了响应）的能力，以及将请求执行操作完全重写到另一个 URL 的能力。

通常，现有应用程序可以利用集成模式，而不需要使用特定于集成模式的功能的新 ASP.NET 模块。只需通过更改配置，应用程序就可以执行诸如以下操作：使用 ASP.NET 窗体身份验证和 URL 授权通过用户安全机制保护整个网站，或使用 ASP.NET URL 映射在应用程序中重写 URL 等。如需查看利用集成模式阻止 Web Leech 热链接到站点图像的示例，请参阅实现这一点的示例 ASP.NET 模块： mvolo.com/2006/11/10/stopping-hotlinking-with-iis-and-aspnet.aspx。该示例很好地说明了如何通过在集成模式中使用现有第三方 ASP.NET 模块来更好地利用它们。

如需查看利用现有应用程序的集成模式的详细步骤，请参阅我的文章： iis.net/default.aspx?tabid=2&subtabid=25&i=1081&p=1。

经过改进的安全性

IIS 7.0 建立在 IIS 6.0 基本代码之上，由于谨慎的编码实践和默认安全的设计原则，这些代码拥有已被证明的安全跟踪记录。在此之上，IIS 7.0 引入了几处体系结构更改，以提供更强大的安全性，还引入了大量功能，以帮助您建立安全的 Web 应用程序。

减少受攻击的可能性是设计和部署安全系统的基本原则之一。通过将 IIS 6.0 的默认锁定方法发展到下一级别，在默认情况下 IIS 7.0 安装的功能更少，从而可以锁定服务器的更多项。通过进一步利用服务器的模块化性质来删除所有没用的功能，可以将服务器的受攻击可能性降到最低，从而极大地降低服务器被攻击的风险。

如果在服务器上的任何不用组件中发现了漏洞，不需要为了防止遭到攻击或修补漏洞组件，立即让服务器停止工作。这样可以提高应用程序的可用性，并降低修补程序的管理成本。

除了核心安全性改进以外，IIS 7.0 还提供了大量安全功能，通过使用它们，可以进一步在服务器上锁定和部署安全应用程序。IIS 一直在为通过身份验证保护应用程序内容提供强大支持。现在，利用 ASP.NET 集成模式，您可以使用流行的 ASP.NET 安全功能（例如，窗体身份验证、成员身份和登录控制）来为整个应用程序提供完整的身份验证和访问控制解决方案。通常，可以在几分钟内完成此设置，而不必编写任何代码。

新的 URL 授权功能从 ASP.NET URL 授权功能发展而来，可以用于为整个应用程序配置声明性访问控制规则。利用这些访问规则可以根据用户名和角色允许或拒绝对应用程序中对 URL 的访问。URL 授权与 ASP.NET 2.0 成员身份和角色管理功能无缝集成在一起，可以有效地与 ASP.NET 窗体身份验证和登录控制一起使用，以快速启用应用程序的用户安全机制。

新的请求筛选功能提供了功能强大的锁定功能，该功能的一部分可在流行的 URLScan 工具中获得。通过拒绝包含可疑数据的请求、保护敏感资源或强制执行进攻性请求限制，可以用请求筛选功能进一步锁定站点。

IIS 7.0 还进行了大量更改，旨在使安全设置的部署和管理更轻松。新的 IIS_IUSR 匿名帐户是内置的，这意味着它不受密码过期的影响，而且不需要在计算机之间进行密码同步。新的 IIS_IUSRS 组取代了 IIS_WPG 组，在运行时自动注入工作进程的标识中，从而缓解了在使用自定义帐户时向该组手动添加工作进程标识的需要。

由于有了内置的 IIS_USR 帐户和 IIS_USRS 组，用于为匿名 IIS 帐户和组指定访问控制列表 (ACL) 的应用程序内容就可以从一个 IIS 服务器直接被复制到另一个 IIS 服务器，而不需要执行任何额外的步骤来保留安全设置。这就极大地简化了跨开发-测试-生产周期的应用程序部署过程。

前面讨论的分布式配置系统允许应用程序所有者直接在其应用程序内管理所需的 Web 服务器设置，而不必具备对服务器的管理员权限。应用程序管理员可以在将其应用程序上载到服务器时，可以在其应用程序内容内部在 web.config 文件中指定必需的配置，或使用 IIS 管理器工具远程配置其应用程序。

IIS 管理器工具通过防火墙友好的 HTTPS 连接提供安全远程管理功能。由于管理工具能够通过成员身份服务来验证应用程序管理员的身份（或者是 Windows 用户，或者是自定义用户帐户），因此管理工具允许进行远程应用程序管理，而不需要所有者对服务器有任何 Windows 权限。

作为服务器管理员，通过配置系统中的灵活的锁定支持，您对应用程序可以配置哪些设置拥有完全控制权。同样，对于远程管理其应用程序的应用程序管理员可以使用哪些 IIS 管理器工具功能，您也可以进行控制。

经过改进的诊断

在 Windows、IIS 7.0 和 Web 应用程序所支持的所有新功能中，Web 服务器是通常需要投入大量精力进行故障排除的非常复杂的系统。IIS 7.0 引入了大量新功能，可帮助您监视服务器的运行情况并调试应用程序的问题。

首先，IIS 7.0 允许您深入查看服务器的实时状态。此功能称为运行库状态和控制 API，或 RSCA（读作“reeska”），它可以公开站点和应用程序池的活动状态、运行中的工作进程，甚至允许您查看当前正在服务器上执行的请求。它还使您能够控制服务器的状态，例如，启动和停止站点，或回收应用程序池。在 Windows Vista 中，可以在 IIS 管理器中、通过 appcmd.exe 命令行工具或使用 Microsoft.Web.Administration API 以编程方式访问此信息。

例如，可以查看当前正在执行的请求以及它们所处的服务器阶段。这可以让您快速解决挂起的请求问题，并跟踪是哪些脚本正在耗费 CPU（参见 图 6）。

在调查服务器问题或调整服务器性能时，RSCA 功能非常易于使用，通过它既能快速看到系统中发生的情况，还能在执行故障排除时控制服务器。在办公室调查 Bug 时，我通常选择使用 appcmd.exe 来查看应用程序池的状态、检查工作进程、启动或停止有危害的应用程序池，以便找到问题所在。

图 6  在 IIS 管理器中跟踪阻塞的脚本 (单击该图像获得较小视图)

Web 应用程序中发生错误时，可能是由于不正确的服务器配置、应用程序错误或各种环境因素导致的。状态代码和标准错误消息所提供的错误线索很少，它们可能使服务器故障排除成为噩梦。IIS 7.0 提供了有关大多数错误的详细的错误信息，使您可以准确知道错误的根源、原因以及如何修复（参见 图 7）。

图 7  错误详细信息指出问题和解决方案 (单击该图像获得较小视图)

详细的错误遵从类似于 ASP.NET 详细错误的安全方案。默认情况下，您只有在从本地计算机浏览网站时才能获得详细信息。像以前一样，还可以为不同的错误代码配置自定义错误页，或重定向到自定义 URL。详细的错误页现在也已本地化，如果安装了相应语言的语言包，就可以按客户端的首选语言提供错误描述。

诊断错误而无需调试

如果您遇到的错误情况是未知的，或者是由多个 Web 服务器组件的复杂叠加而导致的，则会怎么样？不用担心，IIS 7.0 提供了全面的跟踪机制，它可以为每个请求生成详细的书面跟踪记录，以便能够快速跟踪问题。

Windows Server 2003 Service Pack 1 (SP1) 中向 IIS 6.0 中添加了 Windows 事件跟踪 (ETW) 事件，在此事件的基础上，IIS 7.0 添加了更多信息性事件。这些事件包含有关服务器处理的每个阶段的有用信息，通过检查这些信息可以反向跟踪请求执行过程，查明出错位置。可以将这些事件路由到 Windows 跟踪基础结构，后者允许多个 Windows 组件（包括 ASP.NET 和 SQL Server™）将其跟踪信息链接到该请求的单个逻辑执行跟踪。

还可以将它们路由到新的失败请求跟踪功能（又称为 FREB），后者会将跟踪日志保存到 XML 日志文件中，然后可以用提供的 XSLT 样式表查看这些文件（参见 图 8），或以编程方式使用它们。

图 8  查看 XML 日志文件 (单击该图像获得较小视图)

关于失败请求跟踪功能最酷的一点是您可以使它始终在服务器上保持启用状态。通过它可以自动捕获那些遇到可配置的故障状况的请求的跟踪日志，同时避免因保存已成功完成的请求的跟踪日志而导致性能降低。例如，对于导致服务器错误或完成时间超过特定时间的请求，可以将它打开。

使用失败请求跟踪，可以在错误发生时始终捕获有价值的跟踪信息，即使它们是间歇性的，或难以复现的。这可以帮助诊断和解决以前需要艰难调试的困难问题。

基本跟踪基础结构通过服务器可扩展模型向 IIS 模块公开，从而允许所有服务器组件（无论它们是 IIS 附带的，还是第三方开发的）在请求处理期间发出详细跟踪信息。通过 System.Diagnostics API 和 ASP.NET 页跟踪，IIS 7.0 跟踪功能与 ASP.NET 跟踪功能集成在一起，从而允许托管模块利用统一跟踪模型。若要更进一步，可以编写自己的跟踪模块，为处理和输出跟踪信息提供新的方式。例如，您可以成为编写模块以便将 IIS 跟踪信息保存到 SQL Server 或文本文件中的第一个人。

经过改进的性能

虽然 Windows Vista 是客户端操作系统，并不针对高吞吐量的生产部署（Windows Vista 上的 IIS 受限于每次 10 个并发请求），但它的确体现了一些旨在大幅提高 Web 应用程序性能的重要体系结构改进。通过与我们正在 Windows Server“Longhorn”时间范围内所进行的广泛的性能改进工作相结合，这些改进将帮助 IIS 7.0 提高服务器性能。

当然，第一项改进是组件化。服务器的模块化性质允许管理员删除不需要的服务器功能，从而在请求处理期间节省内存和 CPU 使用量。这会导致计算机的吞吐量和容量得到重大改进。在只有站点的某些部分需要特定功能的情况下，以粒度方式启用功能的能力（针对服务器上的每个应用程序打开和关闭相应功能）将进一步提高应用程序的性能。

在 IIS 7.0 中，另一个值得注意的性能特性是新的 IIS 输出缓存。此特性为在服务器上重复利用对高成本动态页面的响应提供了支持，从而缓解了对执行高成本的显示处理和数据库事务以便将响应返回客户端的需要。IIS 输出缓存是对 ASP.NET 中现有的丰富输出缓存功能的速度更快的替代方案，它可以支持一组更小的缓存功能，但能以增强性能的方式为缓存动态内容提供足够的灵活性。

通过将动态内容进行输出缓存，无论它是 ASP.NET 页、PHP 脚本还是 CGI 应用程序，您都可以获得 5-10 倍的性能提升，同时大大降低对磁盘和数据库的负载。

向后兼容

IIS 7.0 应当能够运行大多数现有应用程序，而不需要修改。考虑到在此版本中支持创新所需要的体系结构的更改范围，这是一项巨大成功。配置系统已经过最大更改，从集中的松散类型化配置存储转变为委派的 XML 配置文件层次结构。配置信息的结构和存储都完全不同于 IIS 6.0 元数据库，并且不支持通过原有配置 API 进行访问。

IIS 7.0 通过提供元数据库的仿真层来解决此问题，仿真层在配置系统的基本数据与元数据库 ABO API 所公开的接口之间执行实时转换。这就使得在通过 ABO 或更高级别的 WMI 或 ADSI 脚本访问为该元数据库编写的代码时，代码能够正确工作。但是，务必安装兼容性安装组件才能获得此功能。

虽然 IIS 7.0 为开发 IIS 组件提供了新的可扩展模型，但它仍然支持 ISAPI 组件。如果安装 ISAPI 扩展和 ISAPI 筛选器安装组件，就能够像以前那样运行您的扩展和筛选器。但是，如果正在开发新组件，则应当确保使用新的可扩展模型，以获得更强大和经过改进的开发体验。

与集成模式存在运行库不兼容情况的少数 ASP.NET 应用程序可能必须移动到运行于经典模式的应用程序池中。在这种情况下，通过将多个应用程序放在单独的应用程序池中，可以在相同服务器上以两种模式并排运行这些应用程序。如需 IIS 7.0 上的 ASP.NET 重大更改和常规 ASP.NET 兼容性信息的完整列表，请参阅 ASP.NET 兼容性白皮书： iis.net/default.aspx?tabid=2&subtabid=25&i=1223。

总结

在 Windows Vista 中发布的 IIS 7.0 旨在为下一代 Web 应用程序平台提供最佳体系结构基础，其重点是用于 Web 服务器的正确核心体系结构、可扩展性和管理平台。Windows Vista 使您能够在 Windows Vista 服务器版本发布时用于部署应用程序的相同服务器平台上开发和测试这些应用程序。

由于 IIS 7.0 是在 Windows Vista 中发布的，因此 Web 平台和工具团队的工作重点转移到使 Web 服务器为生产环境做好准备以及为生产方案提高稳定和性能这些方面。但是，Windows Vista 中附带的核心开发和管理功能将保持不变，而且，当 IIS 7.0 的服务器版本完成时，预计将通过 Service Pack 将其改进提供给 Windows Vista。那时，您的客户端和服务器计算机将再次运行完全相同的 IIS 版本，这样，您就可以继续在运行 Windows Vista 的桌面机上开发和测试 Web 应用程序了。

若要对 IIS 7.0 建立初步认识，请参阅 Web 上提供的大量非常有用的资源，首先是 iis.net 网站，它是 IIS 团队的新主页。我们的新站点是包含所有 IIS 7.0 相关信息的门户，其中包括所有 IIS 7.0 功能的详细文章和使用步骤。请确保使用论坛提问并与 IIS 团队及 IIS 社区一起讨论问题。

还可以在我的博客 [url]www.mvolo.com[/url] 上查找 IIS 7.0 的深入介绍和内部信息。请务必来访，好让我知道您喜欢的 IIS 7.0 主题，而且我将在我的博客中尽力讨论它们。

[url]http://msdn.microsoft.com/msdnmag/issues/07/03/IIS7/default.aspx?loc=zh[/url]

自由、创新、研究、探索……

0人

了这篇文章

类别： 应用服务器┆阅读( 0)┆评论( 0) ┆ 返回博主首页┆ 返回博客首页

上一篇 开源的虚拟机软件 VirtualBox v1.5.2 下一篇 MS MVC框架漩涡中的MonoRail未来