我经常听到 Microsoft 内部和外部的人将新的 IIS 7.0 Web 服务器称为 Microsoft 在过去几年中所进行的最重要的开发工作之一。考虑到 Microsoft 最近推出了一系列引人注意的技术,包括 Windows Vista™,这个评语具有重要意义……
我经常听到 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 配置。下面是示例:
过去,必须在机器级的元数据库存储库中显式配置 IIS 应用程序设置,然后应用程序才能正常工作。而使用分布式 web.config 文件,应用程序则将必需的服务器配置封装在其目录结构中。这就大大简化了部署,从而可以将独立的应用程序直接复制到目标服务器的应用程序目录中,从而以所需设置立即启动和运行。
新的配置系统还为服务器管理员提供了全面控制权,允许他们将某些配置选项委派给应用程序,同时由于安全或业务原因保持对其他选项的控制。这样,托管服务器上的应用程序可以在其应用程序中直接设置必需的配置,而不需要求助于服务器管理员或使用外部配置面板。
在 IIS 7.0 中,配置系统是完全可扩展的。新模块可以添加它们自己的配置架构,从而使应用程序能够与 IIS 和 ASP.NET 配置一起并排配置其功能:
自定义配置部分使用了与 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)。
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 头文件中。
开发人员还将受益于经过改进的内存和状态管理模式。大多数 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 可扩展功能。
通常,现有应用程序可以利用集成模式,而不需要使用特定于集成模式的功能的新 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 7.0 还提供了大量安全功能,通过使用它们,可以进一步在服务器上锁定和部署安全应用程序。IIS 一直在为通过身份验证保护应用程序内容提供强大支持。现在,利用 ASP.NET 集成模式,您可以使用流行的 ASP.NET 安全功能(例如,窗体身份验证、成员身份和登录控制)来为整个应用程序提供完整的身份验证和访问控制解决方案。通常,可以在几分钟内完成此设置,而不必编写任何代码。
新的 URL 授权功能从 ASP.NET URL 授权功能发展而来,可以用于为整个应用程序配置声明性访问控制规则。利用这些访问规则可以根据用户名和角色允许或拒绝对应用程序中对 URL 的访问。URL 授权与 ASP.NET 2.0 成员身份和角色管理功能无缝集成在一起,可以有效地与 ASP.NET 窗体身份验证和登录控制一起使用,以快速启用应用程序的用户安全机制。
在 Windows、IIS 7.0 和 Web 应用程序所支持的所有新功能中,Web 服务器是通常需要投入大量精力进行故障排除的非常复杂的系统。IIS 7.0 引入了大量新功能,可帮助您监视服务器的运行情况并调试应用程序的问题。
首先,IIS 7.0 允许您深入查看服务器的实时状态。此功能称为运行库状态和控制 API,或 RSCA(读作“reeska”),它可以公开站点和应用程序池的活动状态、运行中的工作进程,甚至允许您查看当前正在服务器上执行的请求。它还使您能够控制服务器的状态,例如,启动和停止站点,或回收应用程序池。在 Windows Vista 中,可以在 IIS 管理器中、通过 appcmd.exe 命令行工具或使用 Microsoft.Web.Administration API 以编程方式访问此信息。
详细的错误遵从类似于 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),或以编程方式使用它们。
基本跟踪基础结构通过服务器可扩展模型向 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 进行访问。
与集成模式存在运行库不兼容情况的少数 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 应用程序了。