尽管IIS 7.0的架构与IIS 6.0差异甚大，甚至IIS 7.0代码库都是完全重新编写的，但是IIS家族系列中的许多概念和大多数架构仍然延续下来。尽管可以编写管道模块来代替多数ISAPI应用程序，但是ISAPI仍然存在。工作进程和应用程序池也依然存在，进程隔离也以类似的方式继续发挥作用，inetinfo.exe和Http.sys仍然执行类似的功能。然而，在IIS 7.0中，Web服务器已经成为应用服务器，并且已经成为各个版本(包括core server版本)的Windows Server 2008操作系统中的有机组成部分。
IIS 6.0是许多应用程序(如ASP、ASP.NET和SharePoint)的支持平台，与此不同的是，IIS 7.0则成为应用程序本身的组成部分。在许多方面，IIS 7.0就是应用程序框架，可以支持应用程序代码和应用程序功能。IIS 7.0的架构就是围绕着这个基本概念进行设计的，因此，开发人员获得了极大的自由，开发人员不仅可以对其开发的应用程序进行替换、调优和改良，现在还可以对Web服务器进行替换、调优和改良。IIS 7.0的模块化和可扩展性远远超过了ISAPI扩展，在IIS 6.0中，ISAPI扩展主要用于处理某种类型的文件。利用IIS 7.0，开发人员可以修改服务器功能来满足其开发的应用程序的需要。
一、集成管道模式
IIS改善和发展的主要因素是IIS已经成为应用程序(特别是ASP.NET)的支持平台。通过将ASP.NET直接集成到IIS 7.0中，IIS 7.0进一步推动了平台的发展。从管理功能到身份验证，乃至请求处理管道本身，相关功能都已经集成到IIS 7.0之中。将管道集成到IIS 7.0中具有两个好处：一是为基于ASP.NET的Web应用程序及IIS 7.0扩展提供了更好的性能，二是通过使用托管代码获得了更好的控制能力。
ASP.NET的性能之所以能够得到改善，是因为ASP.NET应用程序不再需要退出管道并加载ISAPI进程来处理ASP.NET代码，然后再返回到管道为客户提供响应信息。为了保持应用程序的兼容性，IIS 7.0仍然支持经典管道模式，但是，现在应该尽可能地使用新的集成管道。
1. 经典模式
在IIS 6.0中，ASP.NET扮演了一个ISAPI过滤器的角色，也就是说，请求退出管道后，由aspnet.dll进行处理，然后返回到管道进行进一步处理，最终将响应返回给客户端。如图2-4所示，在IIS 6.0中，一个客户端的HTTP请求将沿着管道移动，直到确定了一个处理程序，如果这个文件是一个ASP.NET文件，那么它就转入ASP.NET ISAPI过滤器，通过ISAPI的处理，在将一个HTTP响应返回给客户端之前，这个请求还将返回管道。IIS 7.0继续提供了这种模式，称为经典模式。
2. 集成管道模式
利用IIS 7.0中的集成管道，开发人员可以将自己的托管代码在管道中集成为一个模块。在先前版本的IIS中，这需要开发ISAPI过滤器或应用程序，对多数开发人员而言，这是一项难度很高的工作。在IIS 7.0中，可以用托管代码开发模块，并且模块可以作为请求管道的组成部分。如图2-5所示，利用IIS 7.0的集成管道模式，可以在管道中处理ASP.NET文件，这样可以在处理过程的任意一个步骤使用ASP.NET代码。因为ASP.NET已经集成到管道中，所以，诸如身份验证之类的ASP.NET功能也可以用于处理非ASP.NET内容。每个请求都可以由IIS和ASP.NET进行处理，而不必考虑其所属类型。
与ASP.NET集成也意味着可以使用ASP.NET身份验证对任何文件、文件夹，以及IIS 7.0的功能，从而有效地进行访问控制。在IIS 7.0出现之前，因为ASP.NET需要退出管道才能完成处理工作，所以任何不是由ASP.NET处理的文件，如HTML、Perl，甚至图形图像等内容，都无法由ASP.NET进行处理，因此也不会由ASP.NET身份验证机制来进行访问控制。所以，就必须使用Windows集成的身份验证或自定义的身份验证机制对不是由ASP.NET处理的文件进行访问控制。利用集成管道，可以大大简化身份验证方法的开发工作。
3. 将应用程序迁移到集成管道
为了与先前版本的IIS保持兼容，IIS 7.0仍然提供了经典管道模式。如果某个应用程序在集成管道模式下运行存在着兼容性问题，那么便可以在经典管道模型下运行这个应用程序。因为在集成管道模式下，web.config配置文件结构与经典管道模式有所区别，所以，如果使用了httpModules或httpHandlers，那么必须将其迁移到新的模式中。对于大多数ASP.NET应用程序而言，将其迁移到新的管道模式的过程比较直接，可以使用IIS 7.0命令完成迁移操作。
在默认情况下，IIS 7.0需要在集成管道中配置ASP.NET应用程序，多数应用程序都可以正常工作，如果应用程序无法正常工作，也会生成配置错误信息，报告具体发生了什么情况。通过使用AppCmd.exe，IIS 7.0提供了一个命令行方法。AppCmd.exe可以将应用程序配置迁移到集成管道，这样就可以消除大部分由不兼容配置文件导致的错误。可以在命令行输入以下命令：
- appcmd.exe migrate config {Application Path}
我们需要将上述命令中的{Application Path}替换为网站名称和应用程序名称，其形式为default web site/application1。
4. 应用程序池和管道
管道模式是针对应用程序池的，可以在这个应用程序池中运行应用程序。为了将一个应用程序配置为在经典管道模式下运行，必须为经典管道创建一个应用程序池，并且将这个应用程序指派给这个应用程序池。也可以为经典管道配置一个应用程序池，并且为这个应用程序池指派一些应用程序，并将这些应用程序迁移到这个应用程序池中。最后令这个应用程序池运行在集成管道模式下。
二、可扩展性和模块化
IIS 7.0的模块式架构与先前版本的IIS中inetinfo.exe的单体架构不同。IIS 7.0中包括40多个组件，此外，还可以将定制开发的模块或由第三方开发的模块添加到IIS 7.0中。关于如何开发自定义模块，可以参考MSDN提供的图像版权模块(参见MSDN页面http://msdn2.microsoft.com/en-us/library/bb332050.aspx)。通过开发自定义模块，可以扩展核心服务器的功能。
利用模块化，IIS 7.0完成了两项任务。第一项任务是只需要加载应用程序执行或配置过程中需要的模块，这样就减少了IIS受到攻击的可能性，同时还减少了加载到内存中的代码数量。服务器管理的指导原则是：如果不需要做某事，那么就不要把对应的程序代码加载到内存中。IIS 7.0很好地实现了这个指导原则。模块化完成的第二项任务是提供了将定制的模块插入到管道中的能力。利用这个扩展功能，在Windows Server 2008发行之后，开发人员可以将集成模块添加到IIS中，这个模块与微软公司开发的模块看起来完全一样。
模块
IIS 7.0提供了40多个模块，可以处理从身份验证令牌缓存、ISAPI过滤器，乃至URL映射的功能。同时，是否安装这些功能，完全取决于Web网站和应用程序的需要。一般情况下，多数模块都被安装在系统中，例如HTTP缓存和HTTP日志功能等，利用这些模块提供的功能，我们可以将HTTP请求和标准的IIS日志在内核模式下缓存。其他功能，例如Digest身份验证或CGI模块，分别可以用于进行Digest身份验证和GCI应用程序，所以，除非必须支持这些功能，否则一般都无须安装这些模块。
下面我们对随Windows Server 2008一同发行的模块进行了归纳。
公用例程模块--公用例程模块是用于处理内部服务器操作的，但是不直接处理请求。这些模块提供了缓存功能，缓存对象包括文件、身份验证令牌，以及服务器状态--总而言之，缓存那些与URI请求有关的内容。如果不安装公用例程模块，那么系统性能将因为缓存减少而降级。
托管引擎：ASP.NET--这是一个独立的特殊模块，即ManagedEngine模块，这个模块的功能是将ASP.NET集成到请求管道中。如果不使用这个模块，那么IIS请求管道基本上就只能够运行于经典模式。
IIS 7.0本机模块--本机模块是指那些不依赖于ASP.NET框架编写的代码。这些模块主要是那些在IIS 6.0中编写，并且移动到IIS 7.0模块中的功能，这些代码仍然处于本机模式，这样有利于向后兼容。这些模块不需要使用ASP.NET框架，因此可以运行于core server版本Windows Server 2008服务器的IIS 7.0中，core server版本的Windows Server 2008没有提供ASP.NET框架。
托管模块--托管模块运行在托管代码中，这些代码是使用ASP.NET开发的。这些模块必须依赖于ASP.NET，例如Forms身份验证等功能，还包括需要处理配置文件、角色，以及ASP.NET会话状态等模块。
三、IIS Manager的可扩展性
在IIS 7.0中，IIS Manager是一个基于Windows表单的应用程序，与其他基于Windows表单的应用程序一样，具有良好的可扩展性。扩展管理用户界面时，首先需要使用一个模块提供程序，模块提供程序是一个服务器方的基础ASP.NET类，包括了IIS Manager模块的配置信息。在administration.config文件中存在一节名为moduleProviders的内容，这节内容定义了IIS Manager可以使用的模块，本章下面描述了这节内容。在同一个文件的modules一节内容中，列出了在Web服务器中实现的所有模块。
与此对应的客户端模块(注意，这个"客户"是IIS Manager中的客户程序，它有可能在服务器上运行)是基于Windows表单的应用程序，这些应用程序可以管理模块提供程序中的模块。为了支持对这个表单进行编程，微软公司提供了Microsoft.Web.Management.Client名称空间和Microsoft.Web.Management.Client.Win32名称空间，利用这两个名称空间，开发人员可以完成继承开发，从而保证了一致性和兼容性。
四、Metabase
IIS 7.0不再使用metabase，但是又并非完全不再使用metabase，这是因为IIS 7.0为了保持与IIS 6.0的兼容性，metabase仍然在IIS 7.0中存在。但是IIS 7.0从metabase中删除了与配置有关的内容，这部分内容的格式是专有的，因此内容本身难以理解。删除的内容被转移到XML配置文件中，这样，与配置有关的内容就成为用标准ASCII文本格式保存的工业界标准格式的文件了。IIS 7.0将几乎所有与配置有关的内容都保存在这些普通文本格式的XML文件中，这些内容可以用文本编辑器进行编辑，还可以用IIS Manager进行管理。之所以说"几乎"，是因为某些IIS配置信息仍然保存在注册表中。因为IIS仅在自身启动之后才可以读取配置文件，所以某些在IIS启动时必须使用的配置项只能保存在注册表中。
某些遗留系统仍然需要使用metabase。与IIS 6.0相同的是，FTP、SMTP和NNTP等的配置信息仍然保存在metabase中，这是因为在IIS 7.0中，这些功能与IIS 6.0是完全相同的，没有做出任何改变。注意：如果服务器是从Windows Server 2003和IIS 6.0升级而来的，并且在升级前已经安装了NNTP，那么这个结论对NNTP才是成立的。IIS 7.0不再支持NNTP，Windows Server 2008也不再提供NNTP。
FTP则有所不同。与Windows Server 2008一同发行的FTP服务程序，连同SMTP服务程序，与Windows Server 2003提供的FTP服务程序和SMTP服务程序是完全相同的。SMTP并无任何变化，但是IIS 7.0还另外提供了一个FTP服务程序，这个FTP服务程序可以从www.iis.net下载。
1. applicationHost.config和web.config
applicationHost.config和web.config是两个掌控IIS 7.0配置的文件。web.config可以在网站级和应用程序级对配置进行控制，而applicationHost.config可以控制服务器本身。因为配置是可继承的，所以web.config可以重新定义更高级别的设置。通过使用配置锁定和管理委托，管理员可以使开发人员和更低级别的管理者控制特定的配置部分，同时将其他配置部分锁定以防止修改。
文件applicationHost.config保存在%windir%\system32\inetsrv\config目录下，遵循形如<attribute-name>="<default-value>" [<metadata>] [<description>]的标准格式。这个文件中的配置节内容与以下代码类似：
<system.webserver>
<defaultDocument enabled="true">
<files>
<add value="Default.aspx" />
</files>
</defaultDocument>
</system.webserver>
它为服务器启用了默认访问文档，将该文档设置为Default.aspx，并且设置为仅可访问Default.aspx。通过修改web.config文件中网站级的设置，可以对这个设置进行修改，其语法与上述内容是完全相同的，请参考下面的代码。下面的代码只是将包括了web.config文件的网站的默认访问文档从Default.aspx修改为Home.asx。其他网站仍然要从applicationHost.config文件中继承相关设置。
<system.webserver>
<defaultDocument enabled="true">
<files>
<remove value="Default.aspx" />
<add value="Home.aspx" />
</files>
</defaultDocument>
</system.webserver>
在默认安装的情况下，IIS 7.0并没有在网站的根目录下创建web.config文件，因此，所有的设置都保存在applicationHost.config文件中。通过使用IIS Manager修改诸如默认文档等网站设置，可以在网站根目录下创建一个web.config文件，这个文件中保存了网站配置信息。同时，即使在没有ASP.NET的情况下，这个文件还保存了ASP.NET应用程序配置信息。此外，web.config文件中还保存了所有与applicationHost.config文件中默认内容不同的IIS设置。
为什么applicationHost.config没有被命名为webServer.config?
先前版本的IIS使用metabase保存IIS的配置信息。在IIS 7.0开发团队将配置信息迁移到IIS 7.0配置文件的过程中，为什么没有将配置文件直接命名为webServer.config呢？IIS 7.0已经为其他应用程序平台使用IIS 7.0的某些功能提供了支持，例如，其他应用程序平台可以在applicationHost.config文件中保存配置信息，并且可以使用Windows Process Activation Service。Windows Communication Foundation(WCF)就是这类平台之一。
2. 其他XML配置文件
IIS 7.0和Web网站配置还受到其他XML配置文件的影响，可以在%windir%\system32\ inetsrv\config目录下找到这些文件，此外，文件administration.config也会对IIS 7.0和Web网站配置产生影响，因为这个文件中保存了IIS Manager的配置。最后，redirection.config也会产生影响，因为这个文件中保存了集中配置文件的信息。
redirection.config文件只是简单地保存了指导Web服务器访问正确的集中配置文件的信息，以及访问这些文件的身份证书。这个文件的内容一般为以下形式内容：
<configuration>
<configSections>
<section name="configurationRedirection" />
</configSections>
<configurationRedirection enabled="true" path="\\server1\centralconfig$\" userName="domain1.local\config" password="Passw0rd1" />
</configuration>
administration.config文件保存了多得多的信息，例如，IIS Manager可以使用哪个模块等。利用如下内容的配置项，可以将默认文档模块添加到IIS Manager中，并且可以对所有网站生效。
<location path=".">
<modules>
<add name="defaultDocument" />
</modules>
</location>
需要添加自定义模块，那么administration.config文件就非常重要，因为必须首先在administration.config文件中为这些自定义模块添加生成一个项，然后才能在GUI管理界面中使用这些自定义模块。
3. Metabase Compatibility
遗留管理接口为IIS 7.0用XML配置文件进行系统管理提出了一个问题，如果IIS 7.0没有提供这些遗留接口，那么IIS 7.0中的某些修改可能会导致与IIS 6.0兼容的应用程序和例程产生一些问题。metabase compatibility为解决兼容性问题提供了支持。在IIS 7.0的默认安装过程中，metabase compatibility并未安装到系统中，因为一般情况下都不会用到这项功能，我们可以在安装IIS 6.0 manager时安装metabase compatibility。
需要使用metabase compatibility的脚本和应用程序是无法在IIS Manager中进行委托的，因此也不能访问IIS 7.0管理功能。因此，在IIS 7.0中移植这些应用程序与执行委托迁移过程颇为相似，在Windows Server 2008发行后，这些应用程序可能在很短时间内就可以修改完毕并对外发行。
metabase compatibility在处理遗留功能时，以及为遗留功能提供ADSI和WMI接口时，工作于API级别上。metabase compatibility对管理功能的调用进行了重新映射，使之能够调用合适的IIS 7.0函数，并且通过使用applicationHost.config文件中的配置项对这些映射进行了持久化。
五、WAS和工作进程
IIS 7.0提供了IIS 6.0的所有类似组件，例如侦听进程、工作进程和应用程序管理器，但是，IIS 7.0把这些内容从w3svc迁移到了Windows Process Activation Service(WAS)。在IIS 6.0和Windows Server 2003中，Http.sys截获的所有请求都被发送到一个HTTP侦听进程，这个HTTP侦听进程将请求传递给w3svc中某个合适的工作进程，在工作进程中，应用程序管理器把请求转发给具体的应用程序进行处理。虽然在IIS 7.0中存在类似的过程，但是WAS不仅处理HTTP请求，还可以处理TCP、命名管道和MSMQ。HTTP请求是由Http.sys截获的，并且在传递给WAS之前，就已经传递给w3svc中的HTTP管理器，但是，其他请求都是通过WAS侦听器的适配器接口转发给配置管理器和进程管理器的，而没有经过w3svc。
Http.sys和SMSsvchost.exe(SMSsvchost.exe是非HTTP侦听器的宿主)都位于IIS 7.0之外。这说明这些侦听器所截获的请求都可以在IIS 7.0之外进行处理，而Windows通信基础服务(Windows communication foundation service)可以作为服务运行，也可以作为Windows应用程序运行，还可以作为IIS 7.0之外的其他进程来运行。对于喜欢冒险的程序员来说，WAS是可以扩展的，当然，这需要编写自定义的侦听器处理程序，并且需要编写与此对应的应用程序域的协议处理程序。
IIS是Internet Information Server的缩写，它是微软公司主推的WEB服务器，现在用户一般常用的版本是Windows 2003里面包含的IIS 6或者是更早的IIS 5，IIS与Window NT Server完全集成在一起，因而用户能够利用Windows NT Server和NTFS(NT File System，NT的文件系统)内置的安全特性，建立强大、灵活而安全的Internet和Intranet站点。IIS支持ISAPI，使用ISAPI可以扩展服务器功能， IIS的设计目的是建立一套集成的服务器服务，用以支持HTTP、FTP和SMTP，它能够提供快速且集成了现有产品，同时可扩展的Internet服务器。
新的IIS7在Windows Server2008中加入了更多的安全方面的设计，用户现在可以通过微软的。Net语言来运行服务器端的应用程序。除此之外，通过IIS7新的特性来创建模块将会减少代码在系统中的运行次数，将遭受黑客脚本攻击的可能性降至最低。从安全的观点来考虑，这是IIS所涉及的一个新领域。 如此多的新特性，让我们对Windows Server2008中的IIS7充满了渴望，下面就让我们一起看看IIS中五个最为核心的增强特性：
完全模块化的IIS
如果你非常熟悉流行的Apache Web server软件，那么你会知道它最大的优势就在于它的定制化，你可以把它配置为只能显示静态的HTML，也可以动态的加载不同的模块以允许不同类型的服务内容。而现在使用的IIS却无法很好的实现这一特性，这样就造成了两方面的问题：其一，由于过多用户并未使用的特性对于代码的影响，性能方面有时不能让用户满意;第二，由于默认的接口过多所造成的安全隐患。
新的IIS7则完全解决了这个问题，IIS7从核心层讲被分割成了40多个不同功能的模块。像验证、缓存、静态页面处理和目录列表等功能全部被模块化。这意味着你的Web服务器可以按照你的运行需要来安装相应的功能模块。可能存在安全隐患和不需要的模块将不会再加载到内存中去，程序的受攻击面减小了，同时性能方面也得到了增强。
通过文本文件配置的IIS7
IIS7另一大特性就是管理工具使用了新的分布式web.config配置系统。IIS7不再拥有单一的metabase 配置储存，而将使用和ASP.NET支持的同样的web.config文件模型，这样就允许用户把配置和web应用的内容一起存储和部署，无论有多少站点，用户都可以通过web.config文件直接配置，这样当公司需要挂接大量的网站时，可能只需要很短的时间，因为管理员只需要拷贝之前做好的任意一个站点的web.config文件，然后把设置和web应用一起传送到远程服务器上就完成了，没必要再写管理脚本来定制配置了。
同时管理工具支持“委派管理(delegated administration)”，用户可以将一些可以确定的web.config文件通过委派的方式，委派给企业中其他的员工，当然在这种情形下，管理工具里显示的只是客户自己网站的设置，而不是整个机器的设置，这样IIS管理员就不用为站点的每一个微小变化而费心，版本控制同样简单，用户只需要在组织中保留不同版本的文本文件，然后在必要的时候恢复它们就可以了。
微软的产品向来以用户界面友好引以为豪，然而作为为IT人士设计的IIS7服务器这一点却好像并不明显，回想从IIS 4 到IIS 6 ，提供给用户的管理控制台操作起来并不十分方便，而且由于技术等原因的限制，用户很难通过一个统一的界面来实现全部的管理工作。
MMC 图形模式管理工具
而在新的IIS 7中，这一问题得到了明显的改观，用户现在可以用管理工具在Windows客户机器上创建和管理任意数目的网站。而不再局限于单个网站，同时相比IIS之前的版本，IIS7的管理界面也更加的友好和强大，此外IIS7的管理工具是用.NET和Windows Forms写成的，是可以被扩展的。这意味着用户可以添加自己的UI模块到管理工具里，为自己的HTTP 运行时模块和配置设置提供管理支持。
IIS 7安全方面的增强
安全问题永远是微软被攻击的重中之重，其实并非微软对安全漠不关心，实在是因为微软这艘巨型战舰过于庞大，难免百密一失，好在微软积极的响应着每一个安全方面的意见与建议。IIS的安全问题则主要集中在有关.NET程序的有效管理以及权限管理方面的问题。而IIS 7正是针对IIS 服务器遇到了安全问题做了相应的增强。
在新版本中IIS 和ASP.NET 管理设置集成到了单个管理工具里。这样，用户就可以在一个地方查看和设置认证和授权规则，而不是像以前那样要通过多个不同的对话框来做。这给管理人员提供了一个更加一致和清晰的用户界面，以及web平台上统一的管理体验。
在IIS7中，.NET应用程序直接通过IIS代码运行而不再发送到Internet Server API扩展上，这样就减少了可能存在的风险，并且提升了性能，同时管理工具内置对ASP.NET 3.0的成员和角色管理系统提供管理界面的支持。这意味着用户可以在管理工具里，创建和管理角色和用户，以及给用户指定角色,下面是IIS 7 完整的组件分报图。
IIS 7的Windows PowerShell 管理环境
相信关注脚本编程或者是Exchange Server 2007的朋友都不会对Windows PowerShell感到陌生， Windows PowerShell是一个特为系统管理员设计的Windows 命令行shell 。在这个 shell 中包括一个交互提示和一个可以独立，或者联合使用的脚本环境。对于热爱脚本管理的IT pro们Windows PowerShell必将让他们爱不释手。而对于IIS服务器，Windows PowerShell同样可以提供全面的管理功能。
不过虽然PowerShell也可以管理运行在Windows Server 2003上的IIS6，但是IIS7才是特为通过PowerShell的命令行来进行管理的。它包括了新的APPCMD功能，APPCMD通过标准的命令行界面来创建和配置站点，这样的命令行工具的应用场景也非常常见，当用户的环境中用到例如脚本管理的时候，APPCMD就将发挥非常其极大的优势。
IS 7.0是包括在Windows Vista客户机上的，该操作系统的家庭版本也带有IIS 7.0(而不象IIS 5.1，只有在XP Professional上才有)。服务器的IIS 7.0版本将在今年稍后随Windows Server2008服务器发布，将添加一堆额外的部署特性，包括更加丰富的主机支持，安全的FTP支持，以及内置的web farm部署支持等。
Web farm支持将是特别地酷，它将允许你在一个包含了运行一个服务器所需的所有编码，配置，内容和密钥的文件共享上部署你的web应用。然后你可以添加任意数目的无状态，无配置的web服务器到一个web farm上，只需将它们指向那个文件共享，来动态装载它们的配置设置(包括绑定，虚拟目录，应用池设置等等)和应用内容即可。这使得在多个机器上扩缩一个应用简直是小菜一碟，可避免使用复制方法来做配置和应用部署(只要把文件拷贝到文件共享上，web farm里的所有机器就会马上装载变动过的文件)。
推出Windows Server2008服务器的Beta3版本支持go-live许可，所以你不久就能利用这个功能。我们已经在用IIS 7.0集群运行 Windows Server2008 了，所以你不会寂寞的!
Windows PowerShell 管理图
IIS7.0 迁移
IIS7.0 迁移网站比IIS6.0更方便，因为Apache Web server它最大的优势就在于它的定制化管理，IIS7.0现在使用Apache概念，所以把站点的配置文件拷贝到另一台IIS7.0主机上即可以，详情请了解上面《通过文本文件配置的IIS7》，《IIS 7的Windows PowerShell 管理环境》。
ASP.NET和IIS 7.0之集成
在早期的IIS版本中，开发人员需要编写ISAPI扩展/过滤器来扩展服务器的功能。除了写起来非常痛苦外，ISAPI在如何接入服务器以及允许开发人员定制方面也是非常有限。例如，你无法在ISAPI扩展中实现URL重写代码(注：ASP.NET是以ISAPI扩展的方式实现的)。假如你把运行时间长的代码编写成ISAPI过滤器的话，结果是你将占用web服务器的I/O线程(这就是我们不让托管代码在请求的过滤器执行阶段运行的原因)。
我们在IIS7中对核心IIS处理引擎做的一个重大的架构级变动是通过一个新的模块化的请求管道架构来促成极其丰富的扩展性。你现在可以通过与web服务器注册一个HTTP扩展性模块(HTTP Extensibility Module)，在任意一个HTTP请求的生命周期的任何地方编写代码。这些扩展性模块可以使用native的C++代码或.NET托管代码来编写(你可以使用现有的ASP.NET System.Web.IHttpModule接口来实现)。
所有“内置”的IIS7功能(认证，授权，静态文件供应,目录清单支持，经典的ASP，记录日志等)，现在都是使用这个公开的模块化的管道API来实现的。这意味着你可以除去这些IIS7“内置”功能的任意一个，而以你自己的实现来替换/扩展这些功能。
IIS 7.0上的ASP.NET本身也从以ISAPI的实现形式变成直接接入IIS7管道的模块：
IIS6.0 和IIS7.0 比较图
这带来诸多好处：
1) 你现在可以对服务器的所有请求(例如， .htm，.php，.jsp文件)使用ASP.NET表单认证，成员/角色，以及任何其他特性。
2) 你现在可以轻松地重写任何web请求的URL或者以种种有趣的方式对请求做改动。
3) 你可以使用VB或C#替换或扩展任何现有的IIS特性(例如，你可以除去内置的目录清单模块，接入你自己的模块)。
这确实给.NET开发人员带来了无穷多的扩展性机会。
IIS 7.0 六大新特性：
1)模块化的网络核心允许用户增加和删除特定的功能。如果要使用服务统计构件，仅需几个模块(不包括ISAPI)。
2)一个统一标准的HTTP管道，它对应于本地管理方面的应用程序。用户可以对经典的ASP网页使用基于窗体的认证系统。
3)用户可以建立自己的IHttpModule以及IHttpHandlers，并且把它们插入到统一的管道。
4)新款分布式的XML设置系统，它利用了ASP.NET的设置系统的优点。
5)改善的诊断和问题解答机制，包括了新Runtime状态以及跟踪功能。
6)新型可扩展，面向任务的管理员用户界面。
总而言之，IIS 7将为Web管理员以及Web爱好者提供更加丰富，更加易用的管理工具。在新的IIS7中，无论是管理方面还是安全方面都得到了全新的设计，而从用户群的角度上讲，利用IIS7， 个人用户可以更快，更简便的建立自己的站点，而企业用户则可以更加全面，更加安全的维护和管理自己的WEB环境。
IIS6相对于IIS5有了很大的改进，针对IIS5中的缺陷，微软将IIS5的代码推到重来，重新设计了IIS6并和Windows Server2003一起发布。
在IIS6中，Web服务组件由以下三个组件构成：
1、运行在内核模式的HTTP.sys（HTTP协议栈）
2、运行在用户模式的WAS(Web Admin Service,包含于W3SVC服务中)
3、运行在用户模式的工作进程(WP,Worker Process)
HTTP.sys(HTTP协议栈)
HTTP.sys是工作在内核模式的HTTP请求侦听器，它的架构如下图所示：
HTTP.sys不会执行外部代码，它具有以下作用：
-
侦听和分析HTTP请求，支持IPv4和IPv6；
-
根据URL命名空间将接收到的HTTP请求路由到不同的工作进程；如果请求的URL并不位于本地的URL命名空间范围中，则返回400错误；
-
将HTTP请求进行队列缓存；
-
在内核模式中缓存静态的和无需身份验证的内容响应；这极大的提高了Web服务的响应速度，增强了Web服务器的性能。
-
支持PAE内存寻址方式，在x86上支持的内存容量为64GB；
WAS(W3SVC)
WAS包含于W3SVC服务中，负责管理IIS6的配置、应用程序池和工作进程，工作在用户模式，但不会执行外部代码，主要的作用有：
-
配置HTTP.sys；
-
管理应用程序池；
-
创建工作进程；
-
工作进程回收；
-
工作进程状态监视；
-
工作进程快速失败保护；
-
支持孤立工作进程以进行调试等；
应用程序池
应用程序池定义了可以共享工作进程的Web应用程序（Web站点）的集合，你可以认为它是一组URL命名空间，属于此URL命名空间范围中的Web站点将共享此应用程序池中的工作进程，而HTTP.sys是根据应用程序池所定义的URL命名空间将接收到的HTTP请求路由到此应用程序池对应的工作进程。
和IIS 5 中只能使用一个应用程序池不同，在IIS 6 中你可以创建多个应用程序池，并将不同的Web站点（Web应用程序）分配到不同的应用程序池中，一个应用程序池可以具有一个或多个Web应用程序。不同应用程序池之间是完全隔离的，某个应用程序池出现故障时不会影响其他应用程序池；这样当属于某个应用程序池的Web站点因为代码编写问题而导致停止服务时，不会影响到使用其他应用程序池的Web站点，这最大的实现了Web服务器的高可用性。
WP(工作进程)
工作进程则是真正用于处理客户发送的HTTP请求的组件，你可以认为它是一个全功能的Web服务器，就像一个微型的IIS 5 服务器一样。当HTTP.sys决定将接收到的HTTP请求路由到某个应用程序池时，它是将HTTP请求路由到此应用程序池对应的工作进程进行处理；工作进程处理HTTP请求，如果需要则加载其他组件（ISAPI扩展或过滤器等等）进行处理，并将处理结果返回给HTTP.sys。
当客户发起HTTP连接请求时，IIS 6完整的处理过程如下：
-
在W3SVC服务启动时，WAS即启动，并且根据metabase.xml中的设置来配置HTTP.sys；
-
当HTTP.sys接收到HTTP请求时，分析其URL命名空间，如果在自己的响应缓存中具有匹配值则直接从缓存中获取响应并返回给客户，如果没有匹配值则根据WAS提供的URL命名空间 范围来决定由哪个应用程序池处理此HTTP请求；
-
如果此应用程序池当前没有工作进程，那么HTTP.sys通知WAS为其创建一个新的工作进程；
-
HTTP.sys将接收到的HTTP请求路由到对应的工作进程中，工作进程处理此HTTP请求然后将结果返回给HTTP.sys，并且根据缓存活动算法来告知HTTP.sys是否缓存此结果；
-
HTTP.sys将请求的处理结果返回给原始客户，并根据工作进程的提示来决定是否保存此处理结果到自己的缓存中。
-
Internet Information Services（IIS，互联网信息服务），是由微软公司提供的基于运行Microsoft Windows的互联网基本服务。
IIS5 是随Win2000发布，其体系结构如下：
IIS5 的所有组件都工作在用户模式中，核心组件INETINFO侦听WinSock端口（例如常见的TCP 80端口）。当HTTP访问请求到达时，工作在内核模式的TCP/IP驱动将其直接路由到INETINFO进程，INETINFO进程自己本身对此请求进行处理或者将其交付扩展组件（如ISAPI扩展）进行处理。IIS5 使用COM+提供的DLLHOST基础结构方式进行工作。
IIS5具有以下的缺陷：
-
在INETINFO中执行第三方代码；这样的后果是如果执行的代码有问题，那么会导致整个Web服务器停止工作；
-
如果执行的代码工作在OOB方式，那么可能需要多次用户模式到用户模式的转换，这降低了执行效率；
-
Web服务器上的所有Web站点工作在一个应用程序池内，无法实现隔离；
-
