喜欢该文的人也喜欢互联网技术爱好者
RabbitMq、ActiveMq、ZeroMq、kafka之间的比较,资料汇总
MQ框架非常之多，比较流行的有RabbitMq、ActiveMq、ZeroMq、kafka。这几种MQ到底应该选择哪个？要根据自己项目的业务场景和需求。下面我列出这些MQ之间的对比数据和资料。
第一部分：RabbitMQ,ActiveMq,ZeroMq比较
1、 TPS比较 一
ZeroMq 最好，RabbitMq 次之， ActiveMq 最差。这个结论来自于以下这篇文章。
测试环境：
Model: Dell Studio 1749
CPU: Intel Core i3 @ 2.40 GHz
OS: Windows 7 64 bits
其中包括持久化消息和瞬时消息的测试。注意这篇文章里面提到的MQ，都是采用默认配置的，并无调优。
更多的统计图请参看我提供的文章url。
2、TPS比较二
ZeroMq 最好，RabbitMq次之，
ActiveMq最差。这个结论来自于一下这篇文章。
显示的是发送和接受的每秒钟的消息数。整个过程共产生1百万条1K的消息。测试的执行是在一个Windows Vista上进行的。
3、持久化消息比较
zeroMq不支持，activeMq和rabbitMq都支持。持久化消息主要是指：MQ
down或者MQ所在的服务器down了，消息不会丢失的机制。
4、技术点：可靠性、灵活的路由、集群、事务、高可用的队列、消息排序、问题追踪、可视化管理工具、插件系统、社区
RabbitMq最好，ActiveMq次之，ZeroMq最差。当然ZeroMq也可以做到，不过自己必须手动写代码实现，代码量不小。尤其是可靠性中的：持久性、投递确认、发布者证实和高可用性。
所以在可靠性和可用性上，RabbitMQ是首选，虽然ActiveMQ也具备，但是它性能不及RabbitMQ。
从实现语言来看，RabbitMQ最高，原因是它的实现语言是天生具备高并发高可用的erlang语言。
按照目前网络上的资料，RabbitMQ、activeM、zeroMQ三者中，综合来看，RabbitMQ是首选。下面提供一篇文章，是淘宝使用RabbitMQ的心得，可以参看一些业务场景。
第二部分：kafka和RabbitMQ的比较
关于这两种MQ的比较，网上的资料并不多，最权威的的是kafka的提交者写一篇文章。
里面提到的要点：
RabbitMq比kafka成熟，在可用性上，稳定性上，可靠性上，RabbitMq超过kafka
Kafka设计的初衷就是处理日志的，可以看做是一个日志系统，针对性很强，所以它并没有具备一个成熟MQ应该具备的特性
Kafka的性能（吞吐量、tps）比RabbitMq要强，这篇文章的作者认为，两者在这方面没有可比性。
这里在附上两篇文章，也是关于kafka和RabbitMq之间的比较的：
1、http://www.mrhaoting.com/?p=139
2、http://www.liaoqiqi.com/post/227
两者对比后，我仍然是选择RabbitMq，性能其实是很强劲的，同时具备了一个成熟的MQ应该具有的特性，我们无需重新发明轮子。
好资料推荐：
1、最全最给力的kafka博客：http://blog.csdn.net/lizhitao/article/category/2194509
2、淘宝对rabbitmq的使用：http://www.docin.com/p-.html
扫码向博主提问
熟悉互联网高并发系统架构设计
擅长领域：
高并发系统架构设计
没有更多推荐了，. Net环境下消息队列（MSMQ）对象的应用 & & 关于消息对象（MSMQ）的一些基本概念可以从《》查阅，这里归纳在.Net 环境下应用消息队列（MSMQ）开发的一些基本对象和方法。 & 队列类型及其相应的路径格式： Public:& [MachineName]\[QueueName] Private:& [MachineName]\Private$\[QueueName] Journal:& [MachineName]\[QueueName]\Journal$ Machine journal:& [MachineName]\Journal$ Machine dead-letter:& [MachineName]\DeadLetter$ Machine transactional dead-letter:& [MachineName]\XactDeadLetter$ The first portion of the path indicates a computer or domain name or uses a period (.) to indicate the current computer. & 1. 创建消息队列 可以手动的方式通过Windows提供的工具创建，或者通过程序的方式创建： .Exists(".\\Private$\\MSMQDemo")) queue = new MessageQueue(".\\Private$\\MSMQDemo");
queue = MessageQueue.Create(".\\Private$\\MSMQDemo"); & 2. 发送消息 缺省情况下，消息序列化XML格式，也可设置为MessageQueue对象的Formatter属性为BinaryMessageFormatter，以二进制格式序列化。 设置消息序列化格式： .Checked) queue.Formatter = new XmlMessageFormatter();
queue.Formatter = new BinaryMessageFormatter(); & 发送简单的文本消息：
= "Hello, I am Rickie."; (strMessage, "Simple text message"); & 消息队列可以传送简单的文本消息，也可以传送对象消息，但需要满足如下条件： （1）class必须有一个无参数的公共构造函数，.Net使用这个构造函数在接收端重建对象。 （2）class必须标示为serializable（序列化）。 （3）所有的class属性必须可读写，因为.Net在重建对象时不能够恢复只读属性的属性值，因此只读属性不能够序列化。 & 发送对象消息（CustomerInfo class需要满足上述条件）：
= new CustomerInfo("0001", "Rickie Lee", ""); (theCustomer, "Object message"); & 3. 读/显示消息 当消息接受后，消息将从队列中删除。可以通过使用MessageQueue.Peek方法来检索消息队列中的第一个消息的复制，保留消息在队列中。不过，这样只能获取的相同的消息。更好的办法是通过foreach来读消息队列中的消息，但不删除队列中的消息。 foreach(System.Messaging.Message message in queue) { &&&&&&&&& txtResults.Text += message.Label + Environment.NewL } & 4. 接收消息 一般而言，可以通过Receive方法来读取队列中的消息，对于非事务性的队列，优先读取高优先级的消息。如果队列中有多个相同优先级的消息，则以先进先去的方式进行读取消息。对于事务性的队列，则完全以先进先去的方式进行读取消息，忽略消息的优先级。 .Message receivedMessage; .Receive(TimeSpan.FromSeconds(5)); & 上面采用同步调用，并且一直等到队列中有可用消息或超时过期。 & Demo界面(不在提供DEMO程序)：
& 其他相关事项：
关于消息的加密、路由等等特性，需要有配置Active Directory的消息队列服务器。 为了避免存放消息队列的计算机重新启动而丢失消息，可以通过设置消息对象的Recoverable属性为true，在消息传递过程中将消息保存到磁盘上来保证消息的传递，默认为false。 消息发送方和消息接收方需采用相同的序列化格式，如XML或Binary。 建议每一个消息队列存放相同类型的消息对象，这样可以省掉获取消息对象后，进行类型判别的麻烦。& 5.消息队列在分布式系统中的应用 消息队列MSMQ和数据库不一样，消息队列缺乏足够的错误检查能力，并且MSMQ由于需要束缚在windows平台，这些是MSMQ的不足之处。另外，在Production环境中，需要编写大量的代码来进行错误检测和响应。还有大量的死信队列、响应队列和日记队列可能部分在企业不同的计算机上，使得跟踪这些问题或进行诊断变得比较困难。 & 但是，MSMQ作为组件内部连接比较有用。例如，你可以创建一个XML Web Services使用MSMQ来转发对另一个Server端组件的请求，这种设计巧妙回避了其他异步调用的方法，并且确保可扩展性和性能。 && References: 1, Matthew MacDonald, Microsoft(R) .NET Distributed Applications: Integrating XML Web Services and .NET Remoting 2, Rickie,
阅读(...) 评论()　　Windows Communication Foundation(WCF)是Microsoft为构建面向服务的应用程序而提供的统一编程模型，该服务模型提供了支持松散耦合和版本管理的序列化功能，并提供了与消息队列（MSMQ）、COM+、Asp.net Web服务、.NET Remoting等微软现有的分布式系统技术。利用WCF平台，开发人员可以很方便地构建面向服务的应用程序（SOA）。可以认为，WCF是对之前现有的分布式技术（指的是MSMQ、.NET Remoting和Web 服务等技术）的集成和扩展，既然这样，我们就有必要首先了解下之前分布式技术，只有这样才能更深刻地明白WCF所带来的好处。今天就分享下MSMQ这种分布式技术。
二、MSMQ的介绍
&　　MSMQ全称是Microsoft Message Queue&&微软消息队列。它是一种异步传输模式，可以在不同的应用之间实现相互通信，相互通信的应用可以分布在同一台机器上，也可以分布于相连的网络空间中的任一位置。
2.1 MSMQ 工作原理
　　MSMQ的实现原理是：消息的发送者把自己想要发送的信息放入一个容器，然后把它保存到一个系统公用空间的消息队列中，本地或异地的消息接收程序再从该队列中取出发给它的消息进行处理。
　　消息队列是一个公用存储空间，它可以存在于内存中或物理文件中，因此，消息以两种方式发送，即快递方式和可恢复模式。它们的区别是消息存储位置的不同，快递方式，为了消息的快速传递，所以把消息放置在内存中，而不放在物理磁盘上，以获得较高的处理能力；而可恢复模式在传送过程的每一步骤中，都把消息写入物理磁盘上，这样当保存消息队列的机器发生故障而重新启动后，可以把发送的消息恢复到故障发送之前的状态，以获得更好的消息恢复能力。消息队列可以放在发送方、接收方所在的机器上，也可以单独放置在另外一台机器上。另外，采用消息队列机制，发送方不必要担心接收方是否启动，是否发生故障等因素，只要消息成功发送出去，就可以认为处理完成，而实际上对方可能甚至未开机，或者实际消息传递到对方可能在第二天。MSMQ机制类似QQ消息传递机制。下图演示了MSMQ的实现原理。
　　MSMQ中主要有两个概念。
　　一个是消息Message：Message是通信双方需要传递的消息，它可以是文本、图片、视频等。消息包含发送和接收者的标识，只有指定的用户才能取得消息。
　　一个是队列Queue：用来保存消息的存储空间，MSMQ中主要包括以下几种队列类型：
公共队列：在整个消息队列网络中复制，有可能由网络连接的所有站点访问。路径格式为：机器名称\队列名称
专用队列（或叫私有队列）：不在整个网络中发布，它们仅在所驻留的本地计算机上可用，专用队列只能由知道队列的完整路径名称或标签的应用程序访问。路径格式为：机器名称\Private$\队列名称
日志队列：包含确认在给定&消息队列中发送的消息回执消息&。路径格式为：机器名称\队列名称\Journal$
响应队列：包含目标应用程序接收到消息时返回给发送应用程序的响应消息，包括机器日志队列、机器死信队列和机器事务死信队列。
机器日志队列对应的格式为：机器名称\Journal$；
机器死信队列对应的格式为：机器名称\Deadletter$；
机器信道死信队列对应的格式为：机器名称\XactDeadletter$。
2.2 队列引用说明
　　当创建了一个MessageQueue实例之后，就应指明和哪个队列进行通信，在.NET中有3种访问指定消息队列的方法：
使用路径，消息队列的路径被机器名和队列名唯一确定，所以可以用消息队列路径来指明使用的消息队列。
使用格式名（format name），它是由MSMQ在消息队列创建时生成的唯一标识，个使命不由用户指定，而是由队列管理者自动生成的GUID。
使用标识名（label），它是消息队列创建时由消息管理者指定的带有意义的名字。
三、消息队列的优缺点
&　　采用消息队列的好处是：由于是异步通信，无论是发送方还是接收方都不同等待对方返回成功消息，就可以执行余下的代码，大大提高了处理的能力；在信息传递过程中，具有故障恢复能力；MSMQ的消息传递机制使得通信的双方具有不同的物理平台成为可能。
　　消息队列缺点是：不适合Client需要Server端实时交互情况，大量请求时候，响应可能延迟。对于客户端，必须是Windows系统。可以通过连接器跟其他的非微软技术集成。
四、利用MSMQ开发分布式应用
4.1 环境准备
&　　要想在.NET平台进行MSMQ的开发，需要安装消息队列，你需要打开控制面板-&程序-&打开或关闭Windows功能，勾选消息队列服务所有选项，具体操作如下图所示：
　　勾选完之后点击确定之后，可以在我的电脑-&管理-&服务和应用程序-&消息队列 看到下面的图：
　　看到上面这个图代表你已经成功配置了MSMQ的开发环境，下面就可以使用Visual Studio 进行开发。注意，对特定类型队列的操作代码，一定要成功安装对应的队列类型。
4.2 使用MSMQ开发分布式应用
　　首先，实现服务器端。创建一个控制台项目，添加System.Messaging引用，因为消息队列的类全部封装在System.Messaging.dll程序集里。具体服务端的代码如下：
2 using System.M
4 namespace MSMQServer
class Program
static void Main(string[] args)
// 创建一个公共队列,公共队列只能创建在域环境里
//if (!MessageQueue.Exists(@".\LearningHardMSMQ")) // 判断此路径下是否已经有该队列
using (MessageQueue mq = MessageQueue.Create(@".\LearningHardMSMQ"))
mq.Label = "LearningHardQueue"; // 设置队列标签
Console.WriteLine("已经创建了一个公共队列");
Console.WriteLine("路径为:{0}", mq.Path);
Console.WriteLine("队列名字为:{0}", mq.QueueName);
mq.Send("MSMQ Message", "Leaning Hard"); // 发送消息
//if (MessageQueue.Exists(@".\Private$\LearningHardMSMQ"))
// 删除消息队列
MessageQueue.Delete(@".\Private$\LearningHardMSMQ");
// 创建一个私有消息队列
if (!MessageQueue.Exists(@".\Private$\LearningHardMSMQ"))
using (MessageQueue mq = MessageQueue.Create(@".\Private$\LearningHardMSMQ"))
mq.Label = "LearningHardPrivateQueue";
Console.WriteLine("已经创建了一个私有队列");
Console.WriteLine("路径为:{0}", mq.Path);
Console.WriteLine("私有队列名字为:{0}", mq.QueueName);
mq.Send("MSMQ Private Message", "Leaning Hard"); // 发送消息
// 遍历所有的公共消息队列
//foreach (MessageQueue mq in MessageQueue.GetPublicQueues())
mq.Send("Sending MSMQ public message" + DateTime.Now.ToLongDateString(), "Learning Hard");
Console.WriteLine("Public Message is sent to {0}", mq.Path);
if (MessageQueue.Exists(@".\Private$\LearningHardMSMQ"))
// 获得私有消息队列
MessageQueue mq = new MessageQueue(@".\Private$\LearningHardMSMQ");
mq.Send("Sending MSMQ private message" + DateTime.Now.ToLongDateString(), "Leaning Hard");
Console.WriteLine("Private Message is sent to {0}", mq.Path);
Console.Read();
　　服务器端代码需要注意的是，公共队列只能在域环境中创建，由于我的个人电脑没有加入域环境，所以不能创建公共队列，从开始的消息队列的截图也可以看出，在图中并没有安装公共队列。
　　实现完服务器端之后，自然就是完成客户端。MSMQ程序的原理主要是：服务器端把消息发送到共享的消息队列中，然后，客户端从这个共享的消息队列中取出消息进行处理。具体客户端的实现代码如下所示：
2 using System.M // 需要添加System.Messaging引用
4 namespace MSMQClient
class Program
static void Main(string[] args)
if (MessageQueue.Exists(@".\Private$\LearningHardMSMQ"))
// 创建消息队列对象
using (MessageQueue mq = new MessageQueue(@".\Private$\LearningHardMSMQ"))
// 设置消息队列的格式化器
mq.Formatter = new XmlMessageFormatter(new string[] { "System.String" });
foreach (Message msg in mq.GetAllMessages())
Console.WriteLine("Received Private Message is: {0}", msg.Body);
Message firstmsg = mq.Receive(); // 获得消息队列中第一条消息
Console.WriteLine("Received The first Private Message is: {0}", firstmsg.Body);
Console.Read();
4.3 运行演示
　　经过上面步骤，我们已经完成了MSMQ分布式程序的实现了，下面看看如何运行该程序来查看效果。
　　首先，自然要启动服务器，右键MSMQServer项目-&调试-&启动新实例来启动服务器，具体步骤如下图所示：
　　运行成功之后，你将到服务器发送消息成功的控制台界面，效果图如下所示：
　　接下来运行客户端来从消息队列中取得消息并显示在控制台中，采用和服务器相同的方式来启动客户端，右键MSMQClient-&调试-&启动新实例，看到客户端的效果如下图所示：
　　从上图可以看出，客户端确实成功地取得了消息队列中的消息。
& & 以上MSMQ程序需要特别注意是：是取出消息队列中队列中的第一条消息，并从消息队列中移除它（MSDN中文翻译上是错误，MSDN写的是不移除，而英文原文是移除），而实际结果也是移除的，如果你再运行一次客户端时，你会发现消息队列中只有一条消息，具体运行效果如下图所示：
&　　到这里，MSMQ的内容就分享结束， 其MSMQ的实现原理也非常简单，一句话慨括就是服务器把消息放在一个公共的地方，这个地方叫做消息队列，而其他客户端可以从这个地方取出消息进行处理。下一章将分享.NET 平台上另外一种分布式技术&&.NET Remoting。
&　　本文的示例代码文件：。
阅读(...) 评论()彻底掌握IIS6.0功能及应用详解
您要打印的文件是：彻底掌握IIS6.0功能及应用详解
彻底掌握IIS6.0功能及应用详解
作者：佚名&&&&转贴自：天极网&&&&点击数：82146
关于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系统时，“管理您的服务器”向导自动启动，如图一所示。
740)this.width=740 border=undefined>　　图一 　　选择“添加或删除”角色，在“配置服务器”向导中可以看到一系列可配置的服务器角色，其中就有“应用程序服务器（IIS，ASP.NET）”选项，如图二，选中该选项之后点击“下一步”，向导提供了是否安装ASP.NET和Microsoft FrontPage服务器扩展的选项。可以看到，微软在这里采用了一种新型的“安装任何部件之前总是 征求用户意见”的IIS安装策略，对于微软来说，这是一个彻底的转变，证明微软确实在认真对待安全问题。
740)this.width=740 border=undefined>
　　　图二 [NextPage]
使用控制面板中的“添加/删除Windows组件”功能还要灵活一些。在向导中选择“应用程序服务器”，再点击“详细信息”，向导显示出一系列组件的清单，其中就有“Internet信息服务（IIS）”选项，还有一些选项是以前的“添加/删除Windows组件”向导没有提供的，表一概括比较了IIS 6.0和IIS 5.0 的主要组件。如果从这里安装IIS 6.0，最后得到的Web服务器可能只支持静态内容（除非在安装期间选中了某些扩展组件）。选中Internet信息服务选项，再点击“详细信息”，可以看到IIS 6.0的子组件，如图三所示。
表一：IIS&6.0和IIS&5.0组件比较
应用程序服务器
Internet信息服务
&&&&应用程序服务器控制台
&&&&公用文件
&&&&ASP.NET
&&&&启用网络COM+访问
&&&&文件传输协议（FTP）服务
&&&&启用网络DTC访问
&&&&FrontPage&2000服务器扩展
&&&&Internet信息服务
&&&&Internet信息服务管理单元
&&&&&&后台智能传送服务（BITS）服务器扩展
&&&&Internet服务管理器（HTML）
&&&&&&&&&BITS管理控制台管理单元
&&&&&&&&&BITS服务器扩展ISAPI
&&&&&&公用文件
&&&&万维网服务
&&&&&&文件传输协议（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网站上必须自己创建该目录。
[NextPage]
进一步分析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。
[NextPage]
　三、全新的内核 　　从体系结构上看，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应用。
[NextPage]
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网站或目录放入应用程序池。
[NextPage]
　四、应用程序池详解 　　前面我们了解了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新特性，你会发现许多新特性正是自己长久以来盼望的。
[NextPage]
前文介绍了IIS 6.0的安装和Web服务器的新型体系结构。IIS 6.0新特性的数量多得令人惊奇，其中一些特性是如此引人注目，以至于人们的大部分注意力都被它们吸引。在这第二篇介 绍IIS 6.0的文章中，我们不仅将了解这些已成为“明星”的特性，还将关注一下IIS 6.0各种较少有人注意却同样重要的改进之处。 　　一、安全 　　微软一次又一次地做着同样一件事情――某个软件产品出了问题，饱受人们诟病，于是赶紧发布新的版本将问题解决。例如，发布Windows NT 4.0之后，因稳定性问题而饱受批评；于是微软发布了Windows 2000，新操作系统的稳定性颇受好评，但Win 2K服务器默认安装的IIS 5.0却成了巨大的安全隐患，需要下大力气加以整治才能解决问题。IIS 6.0默认不安装，如果按照缺省方式安装，Web服务器只能提供静态内容服务。因此，从这个角度看，即使以后IIS 6.0应用引擎和组件突然出现了问题，IIS 6.0还是极大地降低了安全风险。另外，Windows Server 2003还有一个新的组策略“禁止安装IIS”，有了该组策略，我们就可以禁止Windows 2003在活动目录（AD）森林中禁止不准备作Web服务器用的机器上安装IIS 6.0，防止网络上出现根本无用的、不安全的IIS 6.0服务器。不过，目前这个组策略只对Windows 2003服务器有效，不能防止Windows XP Pro和Win 2K的机器安装IIS 5.0。 　　当然，由于刚刚安装好的IIS 6.0不支持动态内容，所以出现了第二个人们经常会问的问题：“为什么我的服务器不能运行ASP？”（前文提到，第一个人们经常会问的问题是：“IIS 6.0可以在Win 2K服务器上运行吗”？答案是“不”）。要想在IIS 6.0上运行程序，必须使用IIS 6.0的一种新特性，即Web服务扩展，或Web Service Extension（这个名字似乎意味着它与XML Web服务有某种关系，实际情况并非如此。） 　　如果要为某个程序启用Web服务扩展，首先打开IIS管理器（在“控制面板”→“管理工具”中。以前叫做Internet服务管理器或ISM），如图一，点击“添加一个新的Web服务扩展”，启动向导创建一个新的规则。为规则指定一个名字，然后找到想要启用的执行文件。另外，\system32\inetsrv下有一个iisext.vbs脚本，它也能够配置并管理运行带有IIS 6.0的Windows Server 2003的Web服务扩展、应用程序和单独的文件。管理员可以使用此脚本来启用和列出应用程序；添加和删除应用程序依赖性；启用、禁用和列出 Web 服务扩展；添加、删除、启用、禁用和列出单独文件。
　　图一 　　在图一中，注意“所有未知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转移到了专门为加密操作而优化的专用设备，有利于提高性能和可靠性。
[NextPage]
　二、配置数据 　　在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网站或虚拟目录的配置，而不是保存全部的配置信息，这时可以按照如下步骤操作：右击要保持配置信息的对象，选择菜单“所有任务”→“将配置保存到一个文件”，如图二所示，如果准备将配置数据导入到另一个服务器，必须提供加密文件的密码。
　　图二 　　如果右击一个应用程序池、Web网站组或单个网站，然后选择“新建”→“应用程序池（来自文件）”，或者“新建”→“网站”→“来自文件”，或者“新建”→“虚拟目录（来自文件）”，就可以从保存的配置文件创建新的应用程序池、Web网站或虚拟目录。因此，必要的时候，我们可以只创建和配置一个对象，利用“将配置保存到一个文件”功能导出对象 的配置信息，然后利用“新建”→“虚拟目录（来自文件）”等功能将配置信息导入到多个Web网站。这就是说，我们可以先精心配置一个模板，然后用它来创建和配置新的网站。当然，出现问题时，配置信息副本还可以用来恢复网站的设置。 　　由于IIS 6.0配置信息是可移植的，它还有另外一个好处，这就是方便了升级。假设我们升级时不能直接在Win 2K/IIS 5.0上安装Windows 2003/IIS 6.0，必须换一台机器，这时就要解决如何将IIS 5.0不可移植的配置数据转移到新的IIS 6.0服务器的问题。利用IIS 6.0配置数据的可移植性，解决办法是：首先安装好新的Windows 2003服务器，为原来的Win 2K服务器做一个完整的备份，然后在Win 2K服务器上安装第二个Windows 2003服务器将它升级，导出第二个Windows 2003服务器的配置数据（用密码加密），然后将配置数据导入到新的Windows 2003服务器。新安装的Windows 2003服务器必须作一些调整，例如允许IUSR帐户等，但至少现在不必重新执行全部配置操作了。 　　IIS 6.0的配置数据是标准的文本文件（XML文件），所以可以用记事本之类的文本编辑器打开和编辑。如果修改了IIS 5.0或IIS 4.0的配置数据，有时必须重新启动IIS，如果系统上网站的数量很多，可能需要不少时间，例如ISP的服务器就属于这类情况。为了解决这个问题，IIS 6.0支持一种“运行时允许编辑”功能。“运行时允许编辑”功能按照如下方式启用：在IIS管理器中，右击服务器，选择菜单“属性”，然后选中“允许直接编辑配置数据库”选项，如图三所示。启用了这个功能之后，如果我们用记事本打开配置数据文件，插入一个虚拟目录的配置，然后保存并关闭配置文件，IIS 6.0几乎立即就能根据配置文件的设置作相应的修改，根本无需重新启动。
　　图三 　　既然允许直接编辑配置文件，因配置文件不合法造成的服务器、应用程序故障也必然增多。为此，IIS 6.0提供了配置文件历史版本目录，即\system32\inetsrv\history，每次修改配置数据或重新启动IIS 6.0，IIS 6.0都会在该目录中保存一份原有的配置数据。
[NextPage]
　三、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的帮助文档。
[NextPage]
　五、日志功能 　　服务器的日志功能很少成为首要的关注对象，但却是日复一日的服务器管理和监视工作不可或缺的助手。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也可能很大，例如（因此该网站的日志文件路径是\W3SVC\），不必奇怪，IIS 6.0不再按照顺序指定网站的ID了――它根据网站的名字计算出网站的ID。 　　如果你编写了一些脚本程序辅助管理，这些脚本要求使用原有的网站ID顺序生成方式，可以禁用IIS 6.0新式的ID生成方式，具体的操作步骤是：找到HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\InetMgr\Parameters注册子键，创建一个REG_DWORD值IncrementalSiteIDCreation，将它设置为2（注意，默认情况下，该键不存在）。
[NextPage]
七、异步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确实有资格占据舞台的中央。