win2003 IIS6.0安装设置和功能应用详解2

　　进一步分析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都会接受。