表一: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的最后一种方式是无人值守安装。和以前一样,这仍旧是唯一一种能够将工具和默认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。
图一
在图一中,注意“所有未知ISAPI扩展”和“所有未知CGI扩展”这两种Web服务扩展。默认情况下,这两种扩展是禁用的,意味着除非明确地允许一个应用在IIS 6.0上运行,否则它就不能运行。如果一个用户请求了某个没有启用的文件,IIS 6.0将向用户返回404错误——文件或目录没有找到,同时在W3SVC日志中记录“
404.2文件或目录无法找到:锁定策略禁止该请求”。在IIS 6.0中,404.2和其他子状态代码是W3SVC日志文件的一项可选功能,用来帮助排解故障、疑难(IIS 5.0和IIS 4.0中也有子状态代码,不过不会在日志文件中记录,但可以将它们转到定制的错误页面,便于根据子状态代码执行特殊的处理)。IIS 6.0的子状态代码很有用,它们提供了描述问题的详细信息,例如:403.20,禁止访问:Passport登录失败;403.18,禁止访问:无法在当前应用程序池中执行请求的URL;404.3,文件或目录无法找到:MIME映射策略禁止该请求;500.19,服务器错误:该文件的数据在配置数据库中配置不正确。所有这些错误和其他错误都映射到定制的错误页面,错误页面不会把子状态代码发送给用户,攻击者无法获知具体的错误信息。
另一个安全方面的改进之处是IIS 6.0允许指派一个加密服务提供者(Cryptographic Service Provider,CSP),能够将基于硬件的安全套接字层(SSL)加速器集成到IIS 6.0,从而把加密任务从服务器的通用CPU转移到了专门为加密操作而优化的专用设备,有利于提高性能和可靠性。
三、配置数据
在IIS 5.0和IIS 4.0中,配置数据库采用二进制文件结构,但IIS 6.0放弃了这一做法。IIS 6.0的配置数据由两个XML文件构成:一个是Metabase.xml,包含IIS 6.0服务器的配置信息;另一个是mbschema.xml,包含配置数据的模式定义。IIS管理器提供了一项新的功能,允许保存配置数据副本,只要右击Web网站,然后选择“所有任务”→“将配置保存到一个文件”,然后指定配置数据副本的文件名字和保存路径即可。按照这种方式保存配置数据时,IIS 6.0利用系统的机器码(Machine Key)加密配置数据的某些部分,因此,配置数据的副本只对创建该副本的机器有用。
不过,在“将配置保存到一个文件”对话框中,我们可以选中“用密码对配置进行加密”选项,然后指定密码,用密码来保护导出的配置文件。如果提供了密码,IIS 6.0将用密码来替代机器码,以后只要提供同一个密码,就可以将配置数据导入到另一个服务器。另外,我们可以使用命令行脚本iisback.vbs(在systemroot/System32中)创建和管理远程或本地计算机的IIS配置的备份副本,管理员可以使用此脚本工具创建其IIS配置的备份副本,从备份副本还原IIS配置以及列出和删除备份副本。
有些时候,我们只要保存某个应用程序池、Web网站或虚拟目录的配置,而不是保存全部的配置信息,这时可以按照如下步骤操作:右击要保持配置信息的对象,选择菜单“所有任务”→“将配置保存到一个文件”,如图二所示,如果准备将配置数据导入到另一个服务器,必须提供加密文件的密码。
图三
既然允许直接编辑配置文件,因配置文件不合法造成的服务器、应用程序故障也必然增多。为此,IIS 6.0提供了配置文件历史版本目录,即/system32/inetsrv/history,每次修改配置数据或重新启动IIS 6.0,IIS 6.0都会在该目录中保存一份原有的配置数据。
四、IIS管理器
每次产品重大升级,人们都会试图从用户界面寻找令人激动的新功能。IIS 6.0的管理器确实有了变化,不过改动之处出乎意料地少。
其中一个改动之处虽小,但很实用。如果在IIS管理器中右击一个文件夹,现在可以选择“权限”菜单打开文件夹的“安全”对话框。在这个对话
框中可以设置文件夹的NTFS授权,不必再离开IIS管理器。虽然这是一个小小的改动,也许它今年会为全世界所有的IIS管理员总共节省数千小时的工作时间。
右击一个Web网站,选择“属性”,转到“目录安全性”页,点击“安全通信”下面的“编辑”按钮,在这里可以找到另一个重要的改动之处——安全通信属性页允许配置SSL、证书信任列表(CTL)、客户证书。在IIS 5.0和IIS 4.0中,除非在Web网站上安装一个证书,否则不能访问该属性页,这一限制令人不快,因为从技术上看,配置CTL、客户证书并不要求服务器上安装了证书,换句话说,在IIS 5.0中我们安装证书的唯一用途可能就是因为用户界面需要它。IIS 6.0改正了这一多余的要求,现在我们不必在Web服务器上安装证书也可以访问和使用该属性页了。
四、通配符应用程序
如果你熟悉IIS 5.0和IIS 4.0的ISAPI筛选器,可能也熟悉它们的缺点。ISAPI筛选器不仅编写困难,而且由于它们在Inetinfo进程内运行,如果编写时不小心留下了一点错误,很容易导致灾难性的后果,出错的代码可能造成整个IIS崩溃。另外,ISAPI筛选器不能拥有常规ISAPI DLL拥有的功能。当然,不管怎样,在IIS 5.0和IIS 4.0中,ISAPI筛选器仍是一种非常有用的组件,是唯一可以针对所有进入Web服务器或Web网站的请求执行操作的代码。
IIS 6.0提供了一种更加灵活的新型机制来提供通常由ISAPI筛选器提供的服务,它就是ISAPI截取器(Interceptor),或者称为通配符应用程序(Wildcard Application)。通配符应用程序的配置方式是:在IIS管理器中右击Web网站,选择菜单“属性”,转到“主目录”页面,点击“应用程序设置”下面的“配置”按钮,出现“应用程序配置”对话框,如图四所示。在对话框的“映射”页中,我们可以将一个或多个ISAPI DLL配置成通配符应用程序。对于每一个接收到的请求,IIS 6.0将调用这里列出的各个通配符应用程序。除了针对所有网站配置通配符应用程序,还可以针对单个网站或在目录层次上配置通配符应用程序。由于这些ISAPI截取器是标准的ISAPI应用程序,它们具有普通ISAPI应用程序具备的所有功能,包括访问消息正文的能力,而不仅仅象ISAPI筛选器那样访问消息头。
图四
通配符应用程序可以做到开发者要做的任何事情,诸如URL定制、验证身份、记录特殊的日志信息、检测攻击企图、创建内容,等等。通配符应用程序结束处理后,它把请求转交给适当的处理引擎(例如处理ASP页面的asp.dll),由处理引擎进一步处理请求。另外,通配符应用程序还可以通过调用为ISAPI应用程序新增的ExecuteURL功能
,将请求传递到同一个应用程序池中的任意页面。
新增的ISAPI通配符应用程序为创造性的应用程序设计大开方便之门。例如,IIS 6.0的URL授权功能就是作为一个ISAPI通配符应用程序(urlauth.dll)实现。URL授权功能允许IIS 6.0根据一系列的规则授予对某个URL的访问权,例如用户是否为某个组的成员、地理位置,以及其他在数据库或AD中与用户有关的信息。有关ISAPI通配符应用程序和URL授权的更多信息,请参见IIS 6.0的帮助文档。
五、日志功能
服务器的日志功能很少成为首要的关注对象,但却是日复一日的服务器管理和监视工作不可或缺的助手。IIS 6.0在日志功能方面有许多重大的改进,但遗憾的是,W3SVC日志事件仍不能以本地时间记录。
在IIS 6.0中,记录日志的功能已经改为由http.sys实现,http.sys在内核模式下运行。这一改进加快了日志写入速度,同时避免了多个工作进程争用同一日志文件。某些特殊的情况下,http.sys会遇到错误,这时它应该但却不能将日志信息写入Web网站的日志,例如,工作进程正在被回收,禁止http.sys处理用户请求,或者用户试图连接到服务器,但请求中只提供了IIS所需信息的一部分。如果出现这类情况,http.sys将把事件写入一个新的日志文件httperr.log。
在排解故障、优化IIS 6.0的过程中,httperr.log日志文件是十分重要的。默认情况下,httperr.log文件保存在/system32/logfiles目录,但可以修改,修改方法是找到HKEY_LOCAL_MACHINE/SYSTEM/CurrentControlSet/Services/HTTP/Parameters注册子键,在它下面添加一个名为ErrorLoggingDir的字符串值,在ErrorLoggingDir中设置保存日志文件的完整路径。在httperr.log日志文件中可以找到的信息包括:所有的503(服务不可用)错误,空闲连接超时,解析URL时出现的各种错误,最后10个提交给失败的应用程序池的请求。
IIS 6.0还拥有一种称为二进制日志的功能,启用这个功能后,IIS 6.0将把Web网站的所有日志信息写入一个二进制格式的日志文件,日志文件的扩展名是.ibl。要启用二进制日志功能,只要把配置文件的W3SVCC/CentralBinaryLoggingEnabled条目设置成ture(1)即可。对于ISP来说,这个功能应该非常有用。ISP的每台机器上可能有1000甚至更多的Web网站,如果每个Web网站每天生成一个日志文件,日志文件的总数很快会达到一个天文数字。微软最近发布的Log Parser 2.0工具能够读取二进制日志文件并生成报告,这个工具可以从http://download.microsoft.com/download/iis50/utility/2.0/nt5xp/en-us/setup.exe下载。Log Parser 2.0还能够读取前面介绍的httperr.log文件并生成报告。
从很久以前开始,IIS就允许指定本地服务器上保存日志文件的目录了。不过,虽然IIS 5.0和IIS 4.0的IIS管理器允许在指定日志文件路径的时候输入一个远程服务器的通用命名规范(UNC)的路径,但Web服务器实际上不会把日志保存到远程服务器。只有IIS 6.0才真正支持日志文件路径的UNC路径名。
六、网站ID
对于IIS服务器来说,唯一标识一个网站的不是网站的名称,而是网站的ID数值。当我们在IIS 5.0和IIS 4.0中创建一个新的网站,Web服务器将下一个可用的数字顺序号指定给网站(即,Web服务器给默认站点指定的数字是1,下一个网站是2,接下来是2、3、4,等等),这个数
字就是网站的唯一ID。如果要访问一个网站的日志文件,首先必须知道该网站的ID,因为日志文件保存在/W3SVC/<网站的ID编号>目录。如果Web服务器上运行着一个以上的网站,仅仅依靠日志文件的路径名称根本无法判断哪一个日志目录属于哪一个网站。另外,无论是在编写管理脚本时,还是在修改配置数据文件时,网站ID都是必不可少的,例如,在IIS配置数据文件中指定ADSI(活动目录服务接口,Active Directory Service Interface)路径时往往要指定正确的网站ID。
尽管如此,在IIS 5.0和IIS 4.0中,从IIS管理器无法直接找到网站的ID编号。为此,IIS 6.0的管理器在网站清单中增加了一个新的“标识符”列,该列的内容就是网站的ID编号。不过,即使IIS 6.0 Web服务器上只有二三个网站,网站的ID也可能很大,例如387660891(因此该网站的日志文件路径是/W3SVC/387660891),不必奇怪,IIS 6.0不再按照顺序指定网站的ID了——它根据网站的名字计算出网站的ID。
如果你编写了一些脚本程序辅助管理,这些脚本要求使用原有的网站ID顺序生成方式,可以禁用IIS 6.0新式的ID生成方式,具体的操作步骤是:找到HKEY_LOCAL_MACHINE/SOFTWARE/Microsoft/InetMgr/Parameters注册子键,创建一个REG_DWORD值IncrementalSiteIDCreation,将它设置为2(注意,默认情况下,该键不存在)。
七、异步CGI处理
IIS 5.0和IIS 4.0以同步方式运行CGI(Common Gateway Interface,通用网关接口)进程,这实际上意味着每次只有一个线程能够访问一个CGI进程,所以IIS 5.0和IIS 4.0对CGI支持的可伸缩性不佳。IIS 6.0能够异步运行CGI进程,所以如果一个线程调用了一个CGI应用程序,它不必再等待CGI进程处理完毕和返回信息。异步CGI改善了IIS服务器运行CGI Web应用程序的性能,使得IIS能够运行更多执行关键任务的基于CGI的应用程序。
当Web服务器接收到包含CGI程序名和程序所需参数的URL时,CGI程序开始执行。如果将CGI程序编译为可执行 (.exe)文件,则必须提供包含程序执行权限的目录,以便用户可以运行程序。如果CGI程序以脚本形式(例如Perl脚本)编写,则既可为目录提供执行权限,也可为其提供脚本权限。另外,如果要使用脚本权限,必须将脚本解释程序标记为脚本引擎。
必须注意的是,默认情况下,IIS_WPG组不具备启动CGI进程的权限。如果创建了新帐户并将其添加到IIS_WPG组,还必须授予此帐户两种启动CGI进程的用户权限,即“调整进程的内存配额”和“替换进程级令牌”。
八、带宽限制
在IIS 5.0和IIS 4.0中,Web网站属性对话框的“性能”页允许启用带宽限制功能,指定允许网站占用的最大带宽。不过,这个功能不一定起作用,因为IIS 5.0和IIS 4.0不能直接操作服务器的网卡。
IIS 6.0则不同,第一次启用带宽限制功能时,Windows 2003自动安装QoS数据包计划程序供IIS服务器调用。QoS数据包计划程序使得服务器能够控制服务质量(即QoS),因此安装期间Windows 2003将临时地停止所有网络服务。配置好QoS数据包计划程序后,IIS才真正有了担负起控制网站带宽限制所需的驱动程序——对于ISP来说,这无疑是一个好消息。允许设置的最小带宽限制值是1024 Byte/秒。不要忘了检查一下网卡是否在Windows 2003硬件兼容清单(HCL)中,因为只有最新的网卡才支持QoS功能。
要配置QoS数据包计划程序,首先必须创建一个组策略控制台。点击“开始”→“运行”,输入“mmc”,然后点击“确定”。在控制台窗口中,选择菜单“文件”→“添加/删除管理单元”,点击“添加”,在“添加独立管理单元”对话框中,选择“组策略对象编辑器”,然后依次点击“添加”、“完成”、“关闭”、“确定”。现在依次扩展控制台中的“本
地计算机策略”、“计算机配置”、“管理模板”、“网络”,显示出“QoS数据包计划程序”,如图五所示。
图五
启用带宽限制之前,请使用系统监视器检查“网络接口”对象中的总字节数/秒或当前带宽计数器。如果希望比较传入和传出流量,请检查发送的字节数/秒和接收的字节数/秒,再比较“网络接口”对象的值和网络连接的总带宽。对于“正常”的负载,服务器使用的带宽不应超过其全部可用带宽的50%。如果服务器有较大的高峰负载,请将正常负载保持在50%以下,剩下的带宽可在高峰期使用。
带宽限制可以是针对全局WWW服务的(即对所有网站都有效),也可以是针对单个网站的。设置全局WWW服务最大带宽不会替代已为服务器上的单个网站设定的最大带宽。单个站点根据已设置的最大值来限制带宽,而全局设置限制所有其他未限制带宽的网站。另外,全局WWW服务带宽限制设置不会影响FTP站点或FTP服务。
九、默认设置的变化
在IIS 6.0中,许多配置项目的默认值已经与IIS 5.0或IIS 4.0的不同。例如,默认的连接超时时间已经从900秒减少到120秒,另外,EnableParentPaths设置默认关闭。还有其他一些新的设置项目也会影响服务器的性能和行为,包括:
⑴ 如果某种文件类型没有在MimeMap配置属性中映射,所有对该类文件的请求将被拒绝。
⑵ 默认情况下,所有工作进程会在1740分钟后自动回收,回收期间会话信息可能丢失。
⑶ 运行CGI应用程序的用户上下文必须是一个IIS_WPG组的成员。
⑷ Windows 2003不安装Collaboration Data Objects for Windows NT Server(CDONTS)。微软建议开发者改用CDO for Windows 2000(CDOSYS)对象。
⑸ ASP请求默认限制在204800字节之下,每一个域限制在100 KB之下。IIS 5.0和IIS 4.0没有这方面的限制。
⑹ 默认情况下,http.sys仅接受标题小于16 KB的请求。
本文关于IIS 6.0的介绍就到这里结束,虽然文章很长,但还是不可能做到面面俱到,例如,还没有提及受到广泛关注的Passport验证和摘要验证方面的改进,本文的重点放在一些具有突破性意义的IIS 6.0新特性以及几种较少有人提及的功能,以此证明IIS 6.0改进的广泛性、深入性。从许多方面来看,IIS 6.0的风头甚至盖过了Windows 2003——而且许多人认为,IIS 6.0确实有资格占据舞台的中央。