关于IIS 6.0的故事一言难尽，如果你已经在IIS技术上有所投资，IIS 6.0无疑是一个动人的、非听不可的话题。鉴于IIS 6.0和以前版本的差别实在太大了，只用一篇文章很难做到面面俱到，所以本文首先探讨IIS 6.0的安装、体系结构以及由于体系结构方面的差异带来的全新服务功能，下一篇文章接着介绍IIS 6.0的新特性——其中有些你可能还没有听说过，另外还有默认配置方面的一些重要变化，这些变化可能会影响到你的迁移计划。
一、安装IIS 6.0
首先从最基本的说起吧。IIS 6.0包含在Windows Server 2003服务器的四种版本之中：数据中心版，企业版，标准版，Web版。另外，顺便再回答一个最常见的IIS 6.0问题：IIS 6.0不能在Windows XP、2000或NT上运行。
安装好Windows 2003之后，马上就可以看到Windows 2003/IIS 6.0的与众不同之处，其中一个关键的变化是，除了Windows 2003 Web版之外，Windows 2003的其余版本默认不再安装IIS。按照微软过去的理念，安装操作系统的同时IIS也自动启动，为许多Web应用提供服务，Windows 2003的做法可谓一大突破。在Windows 2003中，安装IIS有三种途径：利用“管理您的服务器”向导，利用控制面板“添加或删除程序”的“添加/删除Windows组件”功能，或者执行无人值守安装。
第一次启动Windows 2003系统时，“管理您的服务器”向导自动启动，如图一所示。
图一
||||||选择“添加或删除”角色，在“配置服务器”向导中可以看到一系列可配置的服务器角色，其中就有“应用程序服务器（IIS，ASP.NET）”选项，如图二，选中该选项之后点击“下一步”，向导提供了是否安装ASP.NET和Microsoft FrontPage服务器扩展的选项。可以看到，微软在这里采用了一种新型的“安装任何部件之前总是征求用户意见”的IIS安装策略，对于微软来说，这是一个彻底的转变，证明微软确实在认真对待安全问题。
图二
使用控制面板中的“添加/删除Windows组件”功能还要灵活一些。在向导中选择“应用程序服务器”，再点击“详细信息”，向导显示出一系列组件的清单，其中就有“Internet信息服务（IIS）”选项，还有一些选项是以前的“添加/删除Windows组件”向导没有提供的，表一概括比较了IIS 6.0和IIS 5.0 的主要组件。如果从这里安装IIS 6.0，最后得到的Web服务器可能只支持静态内容（除非在安装期间选中了某些扩展组件）。选中Internet信息服务选项，再点击“详细信息”，可以看到IIS 6.0的子组件，如图三所示。
图三
表一：IIS 6.0和IIS 5.0组件比较
IIS 6.0
IIS 5.0
应用程序服务器
Internet信息服务
应用程序服务器控制台
公用文件
ASP.NET
文档
启用网络COM+访问
文件传输协议（FTP）服务
启用网络DTC访问
FrontPage 2000服务器扩展
Internet信息服务
Internet信息服务管理单元
后台智能传送服务（BITS）服务器扩展
Internet服务管理器（HTML）
BITS管理控制台管理单元
NNTP
BITS服务器扩展ISAPI
SMTP
公用文件
万维网服务
文件传输协议（FTP）服务
FrontPage 2002服务器扩展
Internet信息服务管理器
Internet打印
NNTP服务
SMTP服务
万维网服务
Active Server Pages
Internet数据连接器
远程管理（HTML）
远程桌面Web连接
在服务器端的包含文件
WebDAV发布
万维网服务
消息队列
Active Directory集成
公用
下层客户端支持
MSMQ HTTP支持
路由支持
触发器
||||||也许你已经注意到了表一列出的某些新增组件选项，但你注意到IIS 6.0少了什么吗？IIS 6.0中消失不见的最主要的一个项目是文档。在IIS 6.0中，所有文档都以帮助文件的形式发布，不再有IISHelp虚拟目录。在IIS 5.0中，如果从本地访问服务器，默认Web网站自动打开IIS的文档，但在IIS 6.0中，如果打开“http://localhost”，只能看到一个声明网站正在构建之中的页面。
另外，在IIS 5.0的IISHelp虚拟目录中有一些错误处理页面，这些错误处理页面以ASP的方式实现。如果你要用到定制的（或者修改过的）帮助文件、错误处理页面，在IIS 6.0网站上必须自己创建该目录。
进一步分析IIS 6.0的子组件清单，可以发现：原来在IIS 5.0和IIS 4.0中默认安装的Internet服务管理器（ISM）已经不见了。但是，如果你点击“万维网服务”（IIS 6.0的子组件之一，但图三没有显示出来），再点击“详细信息”，可以发现IIS 6.0的万维网服务还有子组件，如图四所示，其中包括原来的Internet服务器管理器，不过现在已经改名为“远程管理（HTML）”；还有Windows 2003和XP版本的终端服务高级客户端（TSAC）——现在它叫做“远程桌面Web连接”。现在，我们不仅可以方便地添加或删除这两个子组件，对其他子组件也一样，包括：ASP，Internet数据连接器，在服务器端的包含文件，WebDAV发布，当然还有万维网服务。
图四
安装IIS 6.0的最后一种方式是无人值守安装。和以前一样，这仍旧是唯一一种能够将工具和默认Web网站安装到其他驱动器（而不是系统驱动器）的安装方式。Windows 2003无人值守安装方式大体上仍和Win 2K一样，都是用Sysocmgr和一个应答文件实施安装。当然，新的特性需要新的参数、选项，有关这方面的详细说明，可以在Windows 2003 Release Candidate 2 （RC2）找到，地址是：http://www.microsoft.com/technet/treeview/default.asp?url=/technet/prodtechnol/windowsnetserver/proddocs/datacenter/gs_installingiis.asp。
||||||如果将IIS 5.0或IIS 4.0服务器升级到Windows 2003，IIS 6.0不会被设置成自动启动。也就是说，如果采用升级的方式安装，IIS 6.0默认是禁用的，除非遇到下列情况之一：
⑴ 以前的IIS服务器上已经安装了IIS Lockdown工具。
⑵ 存在注册子键HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\W3SVC\RetainW3SVCStatus，且它包含一个任意的注册键。例如，你可以创建一个名为EnableIIS6的键，设定它的值为DWORD类型的1。
⑶ 在无人值守的升级安装中，应答文件的[InternetServer]部分存在DisableWebServiceOnUpgrade = True/False条目。
二、支持服务
自IIS 6.0发布以来，它的某些新特性一直是人们关注和议论的焦点，成为众人瞩目的明星，但另一些Internet支持服务虽然不是经常有人说起，却同样值得关注，其中之一就是POP3服务和POP3服务Web管理器。我们无从得知微软为何不在“应用程序服务器”组件清单中列出POP3服务，但是继SMTP服务之后（SMTP服务随同POP3服务一起安装），管理员们盼望POP3服务已经很久了，他们一直在期盼着用一个简单的POP3服务来替代庞大的Microsoft Exchange Server。
统一描述、发现和集成协议（Universal Description, Discovery, and Integration，即UDDI）服务是Windows 2003提供的又一种新的功能，它也与IIS有关，但默认不安装（注意，Windows 2003 Web版不能安装UDDI）。UDDI是一种产业标准（即不是微软的发明），能够通过广告发布IIS服务器提供的Web服务——这里“广告”一词的含义与日常生活中的广告不同，它是指一种让客户程序（通常是Web浏览器）获知Web服务（通常是ASP.NET应用）各种细节的方式。UDDI仍在发展之中，但一些企业已经在内部采用UDDI，以便开发者将自己的代码发布给其他协作开发的人。有关UDDI的更多知识，可以在下列网站找到：http://www.uddi-china.org/（中文），http://www.uddi.org（英文），http://www.uddicentral.com（英文）。
最后一种重要的支持服务是后台智能传送服务，即 Background Intelligent Transfer Service或BITS。BITS是一种后台文件传输机制和队列管理器，也称作节流传输服务。BITS控制文件请求，减少带宽消耗并改善最终用户的体验。针对IIS启用BITS可保证Web服务器的服务质量，如果没有BITS，当100个用户同时下载一个500 MB的文件，服务器的带宽可能就被消耗殆尽，导致其他访问Web服务的用户频繁地遇到超时错误。如果BITS就象广告说的那样有效，可以料想它将是一种非常实用的服务。Windows 2003发布之后，按照计划，BITS还将移植到Win2K上。关于BITS的更多信息，请参见http://www.microsoft.com/windows.netserver/techinfo/overview/bits.mspx。
三、全新的内核
从体系结构上看，IIS 5.0和IIS 4.0其实是一样的：它们都是在用户模式下运行的发布Web内容的应用程序，或者在Inetinfo进程之内以System帐户运行，或者在Inetinfo进程之外以IWAM用户运行。虽然在较重的负载下，IIS 5.0也有相当出色的表现；不过从IIS 6.0开始，我们对IIS底层结构的看法应该改变了。为了使IIS不仅能够轻松地支持1000个Web网站，而且能够支持10000个甚至更多的网站，同时还要提高Web服务器的安全性和可靠性，微软放弃了原有的IIS内核，重新构造了一个。
另一个促使微软重新构建IIS内核的原因是，微软（以及其他厂商）认识到，Web服务器的性能和可靠性问题绝大部分是由于质量低劣的Web应用造成。IIS 5.0通过带缓冲池的Out of Process容器减轻这类问题。在IIS 5.0中，在Out of Process池中运行的应用一旦崩溃，一般不会波及到IIS本身，因为应用程序在Inetinfo之外的进程中运行，但运行在Out of Process池之内的所有Web应用都会终止——在默认情况下，所有的应用程序都在该池之中运行。在这种情况下，排解故障很不容易，因为要确定哪一个应用程序导致了问题非常困难。IIS 6.0将监听请求、创建和监视Web网站、运行Web服务这些不同的任务隔离了开来，这一新型体系可望解决IIS 5.0存在的问题。从理论上看，新的体系将极大地改善可用性、安全和性能；从实际情况看，根据微软和Beta测试者的报告，新的体系令稳定性和性能有了奇迹般地提高。IIS 6.0的内核体系主要建立在三个组件之上：W3SVC，http.sys，以及W3Core。
||||||■ W3SVC
W3SVC也许是IIS 6.0体系中最不令人注意的组件，不过这并不说明它不重要。W3SVC的任务是根据配置数据的设置创建和监视工作线程，由工作线程运行Web网站应用。在IIS 5.0中，与IIS 6.0 W3SVC组件最接近的是IIS管理服务，IIS管理服务是Inetinfo的一部分；因此，如果Inetinfo出现问题，IIS管理服务也会出现问题，而且此时的IIS管理服务不能再重新启动Inetinfo或其他故障的应用程序。在IIS 6.0中，W3SVC作为一个独立的进程运行，Web应用的故障不可能波及W3SVC，因为W3SVC之内根本没有第三方的代码运行。W3SVC总是处于运行状态，因此它能够监视Web应用的健康状况，并在必要时采取行动。由于这一策略，服务器能够根据用户指定的参数监视和重新启动应用程序。
■ http.sys
IIS 6.0体系设计中最重大的变化是加入了http.sys驱动程序，http.sys驱动程序的任务是处理HTTP请求，而且它在内核模式下执行操作。不要小看这一改变，将处理HTTP请求的任务从IIS 5.0、IIS 4.0的用户模式改变到IIS 6.0的内核模式标志着新一代IIS服务器的诞生。
在Win 2K和NT 4.0中，IIS在用户模式下运行。运行在用户模式下的应用程序不直接与硬件通信，它们直接调用的是一些标准过程，这些标准过程或者将数据传入内核模式的组件（例如网卡驱动程序，图形子系统），或者调用内核模式组件的函数，以此完成保存文件、设置IP地址、将HTML文件发送到网络之类的任务。
用户模式和内核模式之间的转换是一项开销很大的操作，服务器首先从内核模式的TCP/IP栈将传入的HTTP请求传递给用户模式的Winsock，由Winsock将请求传递给IIS。从内核模式到用户模式的切换很快发生，但不可避免地给处理过程带来瞬间的延迟。当负载较大时，这种延迟不断累加，同时由于这种转换是必不可少的，所以管理员根本没有办法优化处理过程。
IIS 6.0的https.sys内核模式驱动程序极大地减少了用户模式和内核模式之间的切换次数。http.sys监听着HTTP请求，决定由哪一个用户模式的进程来处理该请求，或者是否由驱动程序本身返回用户请求的内容。
IIS 6.0在用户模式下运行，完全依赖内核模式的http.sys作为接收用户请求的服务器引擎。因此，http.sys必须能够在任何时候作出相应，必须具有极高的可靠性。用户代码可能导致进程出错，所以微软把http.sys设计成不执行任何用户代码，这样，即使应用程序出现了故障，也不会影响到IIS 6.0本身，IIS 6.0仍能够照常监听HTTP请求。
如果要从内核模式的缓冲区返回静态的应答，一个高速的、内核模式的、不允许运行应用程序代码的HTTP处理器是十分理想的，它减少了切换到用户模式的昂贵开销，能够从内核模式的缓冲区快速返回应答。IIS 6.0的http.sys就管理着这样一个缓冲区，而且使用了高度优化的启发式缓冲区算法来确定哪些内容要放入缓冲区，例如，http.sys可能只缓冲那些出现了一次以上请求的内容。
由于http.sys直接从应答缓冲区提取静态内容，不必再切换到用户模式，所以与IIS 5.0的性能相比，IIS 6.0的整体性能有了显著提升。根据微软的资料显示，WebBench基准测试表明IIS 6.0返回静态内容的速度要比IIS 5.0快150％。即使以IIS 5.0的隔离模式运行IIS 6.0服务器（这时，IIS 6.0的体系结构与IIS 5.0的相似），同样也能从http.sys驱动程序的应答缓冲区和其他改进之处获益。
另外，微软在http.sys驱动程序中采用了许多优化的算法，使其能够将请求直接转发到适当的工作进程。在IIS 4.0和IIS 5.0中，必须通过多个步骤才能确定进程的哪一个实例拥有了应当接收当前请求的Web应用，但在IIS 6.0中，http.sys注册了所有IIS 6.0应用，赋予每一个进程一个句柄，IIS内部利用这些句柄来标识注册的应用程序要用到的一个或多个名称空间。因此，当http.sys接收到一个HTTP请求，它能够很快地将请求从内核模式的http.sys传递到正确的用户模式的Web应用。
http.sys驱动程序还要执行其他一些任务，其中包括：
⑴ 将传入的URL与各种长度、格式方面的规则进行比较。
⑵ 管理传入请求的队列。
⑶ 担负着记录IIS Web网站日志信息的任务（从而提高了记录日志的性能）。
⑷ 实施带宽限制策略以及支持TCP/IP级的管理。
⑸ 实现客户证书请求服务（但不支持安全套接字层——SSL）。
||||||由于http.sys是一个操作系统的驱动程序，而不是一个IIS组件，因此该驱动程序的配置在注册表而不是IIS配置数据中进行。当前，还有许多http.sys的注册表设置项目尚无正式的说明文档，它可能意味着微软不鼓励用户修改这些设置，因为这些设置项目将来可能会有变化。http.sys驱动程序的注册表设置项目位于HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\HTTP下面，在这里可添加各种注册键（默认配置中不包含这些注册键），诸如：
⑴ EnableNonUTF8：如果加入EnableNonUTF8子键，并将它的值设置成0，http.sys只接受UTF-8编码的URL。UTF-8的全称是Universal Character Set（UCS）Transformation Format 8，这是一种字符集标准，标准全文在http://www.ietf.org/rfc/rfc2279.txt，它允许使用多国语言的字符集。默认情况下，EnableNonUTF8的值是1，表示IIS接受UTF-8、ANSI、双字节字符集（DBCS）编码的URL。
⑵ PercentUAllowed：当这个子键设置成1时（默认值），http.sys认可那些部分字符用％uNNNN表示的URL，其中NNNN是一组表示实际字符的数字。当PercentUAllowed设置成0时，IIS 6.0将拒绝那些部分字符用这种方式表示的URL。
％uNNNN是一种不太常用的Unicode符号，不要将它与常见的UTF-8表示形式混淆。在UTF-8表示形式中，％20表示一个空格，例如http://www.iisanswers.com/new article.htm相当于http://www.iisanswers.com/new％20article.htm，两者之间的转换由IE浏览器自动完成，不管EnableNonUTF8和PercentUAllowed设置成了什么值，IIS 6.0都会接受。
这两项设置，再加上其他可以在IIS 6.0文档中找到的设置项目，从一个侧面反映了IIS 6.0在URL解析方面的改进。在IIS 5.0中，一些重大的安全问题与Web服务器解析URL的方式有密切的关系，现在微软终于解决了原先存在的缺陷，同时作出了一些改进，允许管理员更加明确地定义IIS 6.0解析URL的规则。在天生具有国际化特点的Internet上，多国语言并存，这些改进之处尤其具有重要意义。
关于Unicode的更多信息，请参见http://www.unicode.org；关于IIS 5.0缺陷的更多信息，请参见 http://www.wiretrip.net/rfp/p/doc.asp/i5/d57.htm。在Windows Server 2003 Resource Kit中可以找到一个帮助配置http.sys的工具。
■ W3Core
默认情况下，IIS 6.0在工作进程隔离模式下运行，如图五所示。在这种模式中，对于每一个Web应用，IIS 6.0都用一个独立的w3wp.exe的实例来运行它。w3wp.exe也称为工作进程（Worker Process），或W3Core。
图五
||||||因此，工作进程隔离模式不存在进程内（In-Process）应用程序存在的问题，有效地提高了可靠性和安全性。可靠性的提高是因为一个Web应用的故障不会影响到其他Web应用，也不会影响http.sys，每一个Web应用由W3SVC单独地监视其健康状况。安全性的提高是由于应用程序不再象IIS 5.0和IIS 4.0的进程内应用那样用System帐户运行，默认情况下，w3wp.exe的所有实例都在一个权限有限的“网络服务”帐户下运行，如图六所示，必要时，还可以将工作进程配置成用其他用户帐户运行。
图六
如果缓冲区溢出攻击成功入侵了一个Web应用，攻击者只能访问当时运行工作进程的帐户有权访问的资源，默认的网络服务帐户不能写入Inetpub文件夹，执行权限也极其有限，所以象CodeRed蠕虫之类的攻击根本不可能得逞。
某些Web应用，特别是有些Internet Server API（ISAPI）筛选器，在进程外运行时可能会遇到问题。在IIS 5.0和IIS 4.0中，ISAPI筛选器总是在Inetinfo之内运行，它们的设计目标本来就不是在进程外运行，正是由于这个原因，某些筛选器在IIS 6.0的工作进程隔离模式中运行时可能会出现问题——特别地，调用SF_READ_RAW_DATA或SF_SEND_RAW_DATA的筛选器尤其明显。为此，IIS 6.0还提供了第二种操作模式，称为IIS 5.0隔离模式。如果ISAPI筛选器不能在工作进程隔离模式下正常运行，在IIS 5.0隔离模式下应该没有问题。在这第二种操作模式中，应用程序仍旧能够从IIS 6.0的许多改进中获益，例如http.sys驱动程序带来的性能、可靠性的提高。
在IIS 6.0文档中，可以看到一种叫做“应用程序池”的新特性。一个应用程序池包含一个或者一组工作进程，而且应用程序池是可以命名的。应用程序池可以从下列角度理解：在IIS 5.0中，我们可以将应用程序保护设置为低级（IIS进程）、中级（缓冲池）、高级（隔离），这个功能虽然很有用，但如果我们想要在一个池（一个dllhost.exe的实例）中运行两个应用程序，在另一个池（另一个dllhost.exe的实例？）中运行另外两个应用，该怎么办？IIS 5.0没有提供命名dllhost.exe实例的途径，因而也就不能将两个特定的应用放入某个池运行。IIS 6.0的应用程序池允许指定名称，如图七，通过网站“属性”对话框的“主目录”页，可以方便地将Web网站或目录放入应用程序池。
图七
||||||四、应用程序池详解
前面我们了解了IIS 6.0体系结构的关键组件，下面来看看有关应用程序池的一些问题。应用程序池的“属性”对话框有四页——回收，性能，运行状况，标识，如图六所示。在这些选项页中，最引人注目的恐怕就是“回收”页，使用该选项页可以管理工作进程的回收。在工作进程隔离模式中，IIS可以配置成定期重新启动应用程序池中的工作进程，从而更好地管理那些有错误的工作进程。这确保了池中的应用程序运行正常，并且可以恢复丢失的系统资源。为了回收工作进程，失败工作进程接收请求的能力将被限制，直到它处理完存储在请求队列中的所有剩余请求。为了排出当前请求，可以给予进程配置限制。同一命名空间组的替换工作进程在旧的工作进程停止前启动，从而防止服务中断。旧的进程完成其未决的请求，然后正常关闭，或者如果在达到了配置的时间限制、请求数、设置的时间计划，或当达到指定的内存用量限制后仍没有关闭，则明确地终止进程。默认情况下，应用程序池每隔1740分钟（29小时）回收一次。
W3SVC根据“运行状况”页的选项来判断应用程序池运行是否正常，包括：每隔指定的时间Ping工作进程，时间按秒计，默认值30秒；启动时间限制（工作进程必须在指定的时间内开始）；关闭时间限制（工作进程必须在指定的时间内关闭）；是否启动快速失败保护（如果在指定的时间段内一定数目的工作进程发生失败，则禁用应用程序池）。另外，ISAPI应用程序（包括ASP.NET和asp.dll）可以声明自己不再适合提供服务，要求回收。
默认情况下，当IIS 6.0回收一个池时，它会使用一种称为overlapped recycle的回收技术。在这种回收模式下，失败的工作进程仍会保持运行状态，同时创建一个新的工作进程。IIS 6.0把新传入的请求传递给新的工作进程，但不拆除老的工作进程，直至老的工作进程处理完它队列中的请求，或者遇到超时错误。在此期间，TCP/IP连接不会丢失，因为有http.sys保持着连接的有效性。当失败的工作进程超时出错时，下一个请求传递给工作进程的请求是新的请求，因此原来保存在进程中的会话信息就会丢失。所有这类回收操作都自动进行，无需管理员干预，而且在大多数情况下，不会造成明显的服务中断现象。如有必要，可以将配置数据属性LogEventOnRecycle的值设置为1，指示W3SVC执行回收操作时生成一条事件日志记录。
对于那些不能以多个实例运行的应用程序，overlapped recycle回收技术可能引起问题。如果遇到这类问题，可以将配置数据属性DissallowOverlappingRotation的值设置成True（1），关闭某个应用程序池回收操作时的进程“重叠”现象。另外，对于失败的工作进程，有时我们可能不想将它拆除，仍旧保留该进程，以便检测和寻找发生问题的根源，这时可以将配置数据属性OrphanActionExe设置成执行文件的名字，使得工作进程成为“孤儿”时执行文件仍保持运行状态。
另一个与应用程序池有关的特性是，IIS 6.0允许将应用程序池配置成一个Web园（Web Garden）。要理解Web园的概念，可以设想这样一种情形：假设有一个IIS 5.0服务器和三个Web网站，每一个Web网站运行着相同的应用程序，如果IIS 5.0能够自动按照圆形循环的模式将请求依次发送给这些功能上等价、实际上分离的Web网站，将负载分离到三个不同的进程，就可以构成一个小型的Web农场（Web Farm）——这就是Web园。
在IIS 6.0的Web园中，我们不必创建额外的Web网站，只要指定用于某个应用程序池的工作进程的数量就可以了。具体的配置步骤是：打开应用程序池的“属性”对话框，转到“性能”页，在“Web园”下面的“最大工作进程数”输入框中输入进程数量，如图八。当服务器的负载较小，不需要额外的工作进程时，IIS 6.0在一定的时间后（默认20分钟，可配置）自动缩减实际的工作进程数量；如果负载变大，需要额外的工作进程，IIS 6.0再次增加工作进程数量。这一切操作都自动进行，不需要管理员干预。
图八
两个新的配置数据属性——SMPAffinitze和SMPAffinitzeCPUMask——允许配置为工作进程指派的特定处理器：将SMPAffinitized属性设置成true表示应该把分配给应用程序池的特定工作进程指派给特定的CPU，SMPProcessorAffinityMask属性用来配置十六进制的处理器掩码，该十六进制处理器掩码指出应用程序池中的工作进程应该绑定到哪个CPU。
写到这里，文章的篇幅似乎已经太长了。本文主要从体系结构的角度介绍IIS 6.0的新特性，并且尽力做到全面，至少要比通常见到的介绍更完善一些。文章的第二部分将涵盖更多的IIS 6.0新特性，你会发现许多新特性正是自己长久以来盼望的。
