介绍

Microsoft Active Server Pages（微软动态网页服务），同样也被大家称为ASP，首先是在1996年末年发布的，为程序员提供一个用来建立WEB应用程序丰富复杂的框架。几年后，他的基础构造发展改进了很多，也就是大家现在所了解的ASP.net.ASP.net是一个用来构件WEB应用程序的框架，也就是说，他必须运行在WEB服务上，用客服端-服务端模型了表述的话通常是浏览器发送不同类型的资源请求到WEB服务器。在出现动态服务器资源生成技术（如CGI，PHP，JSP以及ASP），所有的WEB服务只能接受客服端的静态资源请求并把他们回送到客服端。

表面上看起来,这样在服务端和客户端的交互是非常的简单。会话通过HTTP协议进行，他是一个建立在TCP和IP协议（用来在2个连接到不同类型的网络端点交换数据，如我们所知道的WWW万维网）上的应用程序级协议。

 本质上任何动态服务器技术需要运行在特定WEB服务上，同样ASP.net紧密地和微软因特网信息服务，也叫做IIS。

不同的服务选择不同的方式去生成动态资源等等。。。我们将要解析一下IIS是怎么做到的当一个请求信息一旦到达服务端以及最后回送到客户端。

 IIS and ISAPI 扩展

如上面提到的，静态资源不需要被服务器处理；一旦这样的资源请求到达服务器，服务器只需要从文件系统中找到他的内容并且以字节流形式发送到客户端通过HTTP协议。静态资源可以是图片，javascript,CSS或者普通HTML页面。很显然服务器需要知道怎样去区分静态和动态资源，动态资源需要如何被处理而不是直接发送回客户端。因此出现了ISAPI扩展，ISAPI是因特网服务应用程序编程的接口。ISAPI作为模块被执行如早期的Win32.dll.IIS依靠ISAPI来处理特定的资源。通过IIS映射ISAPI扩展和文件的方式，把每种文件扩展类型关联到特定的ISAPI扩展，也就是说，当一个请求某种文件的请求到达，IIS处理并转到相应的ISAPI扩展，以确认这种请求能被处理。

图表1：在IIS5.0中配置ISAPI扩展映射

ISAPI扩展明显需要符合一个通用接口，这样他们才能被IIS调用并提供必要的数据用来处理请求和生成回送。

如图1，.ASP扩展名被映射到asp.dll ISAPI扩展；在ASP处理时段，这个组件负责执行所有需要的任务去生成回送，也就是说，通过收集请求信息，并使得他能够在ASP页面可用，其他ASP内部对象，解析并执行ASP页面最后以HTML形式返回结果。

尽管，这样相对于CGI技术来说已经是很大的进步了，但是ASP.net更强大。

在安装ASP.net后，ASP.net配置IIS 把ASP.net指定的文件请求重定向到一个新的ISAPI扩展aspnet_isapi.dll.这个扩展有些不同于以前的asp.dll扩展。

表格I：aspnet_isapi.dll在IIS应用程序中的映射

Extension	Resource Type
.asax	ASP.NET 应用程序文件. 常用的有 global.asax.
.ascx	ASP.NET 用户控件文件.
.ashx	HTTP handlers, the managed counterpart of ISAPI extensions.
.asmx	ASP.NET web services.
.aspx	ASP.NET web pages.
.axd	ASP.NET internal HTTP handlers.

除了表格1所列出的文件扩展名，ASP.net ISAPI扩展也管理其他一些通常不提供给浏览器访问的文件扩展类型，如Visual Studio工程文件，资源文件以及配置文件。

ASP.NET处理模型

到目前为止，我们已经明白当请求一个asp.net文件的请求传到IIS后，他被转递到aspnet_isapi.dll,他是asp.net相关处理的主要入口点。实际上，这个扩展明显依赖于系统上IIS的版本，因此处理模型是通过asp.net运行时通过有序的操作执行来处理请求并生成回送，也许有那么一点改变。

在IIS5.X，所有asp.net相关请求通过ISAPI扩展被分配到外部工作进程叫做aspnet_wp.exe.ISAPI扩展，在IIS进程（inetinfo.exe)中运行,再传递控制权连同所有关于当前传入请求的信息到aspnet_wp.exe。2个进程间的通信通过命名管道（众所周知IPC[内部进程通信]机制建立。ASP.NET工作进程执行ISAPI扩展的大部分任务。注意一下每个WEB应用程序的实质，以及与IIS下不同虚拟目录的通讯，他们在asp.net工作进程同一个进程的上下文中被执行。为了实现读取各自执行中上下文ASP.net引入了应用程序域的概念，缩写AppDomains.他们可以被认为是一个轻量级的进程。更多的将在后面介绍。

如果运行在IIS6上，aspnet_wp.exe进程没有被使用，选择一个更优的进程叫做w3wp.exe.同时，inetinfo.exe也不再用来传递HTTP请求到ISAPI扩展，尽管这样他还是保持为其他协议的请求提供服务。虽然IIS6能够运行在兼容模式下并且模拟之前的行为，但是相对于先前的IIS5处理模型有了很多的变化。相对早期最大改变，当处理模型运行在IIS5上，传入进来的请求以lower-kernel-level形式然后传递到正确的ISAPI扩展，从而避免在内部信息处理方面花费过多的操作。在下面的段落中，我们将进行更深入的研究。

IIS5.0 处理模型

在windows2000以及XP系统上这是默认的处理模型。如上所说他有IIS inetinfo.exe进程默认在TCP端口80监听传入的HTTP请求并且把他们推送进队列等待处理。如果请求类型是asp.net,处理将委托给asp.net isapi扩展 aspnet_isapi.dll.这样轮流通过命名管道与asp.net工作进程通信，最终工作进程处理并传递请求到asp.net HTTP运行时环境。图表2将具体描叙这个过程。

图表2：IIS5.0处理模型

图表2显示一个我们尚未提到过的元素—ASP.NET HTTP运行时环境。目前他并不是我们这编文章的主题，他将在接下来的文章中被解析。HTTP运行时可以被看作一个黑色盒子，所有ASP.NET指定处理在这里发生，所有的受管制代码运行场所，从HTTP运行时一直到httphandler最终处理请求并生成回送都在这里被处理。这里还涉及到asp.net管道或http运行时管道。

就这个模型有一个有趣的地方就是所有请求，一旦被ISAPI扩展处理，就被传递到asp.net工作进程。每次活动时间有且仅有一个进行实例，一个例外，后面讨论。因此所运行在IIS上的asp.net web应用程序实际上也运行在工作进程上。尽管如此，这并不意味着所有应用运行在同一个上下文上并共享他们所有的数据。值得一提，asp.net引入APPDomain概念，本质上是一种提供独立和安全边界的受管制轻量级进程。每个IIS虚拟目录在一个APPDomain里执行，他将自动加载到工作进程只要资源是属于第一次请求的应用程序。一旦appdomain被加载，换句话说，当前请求所有需要的程序集被加载到appdomain–实际上是传递到asp.net管道处理。若干appdomains能够这样运行在同样的进程中，当多个请求对于同样的appdomain能够在多个线程出来。尽管如此，一个线程并不属于一个appdomain，他能为多个不同的appdomians处理多个请求,但是同一个给定的时间一个线程属于一个APPdomain.

处于性能目的，工作线程能够根据一些标准（通过MACHINCE.CONFIG文件配置）被回收。这些标准包括进程生命周期，请求以及队列数量，空闲时间，内存分配。一旦达到这些参数中一项临界值，ISAPI扩展将生成一个新的工作进程实例用来处理请求。实际上，先前的进程实例并没有被关闭，但是他被终止服务等待的请求。

IIS6.0处理模型

IIS6是WINDOWS2003系统默认的。在IIS5处理模型的上他有几个改变和改进。其中之一最大改变就是应用程序池概念。在IIS5系列应用程序上，即所有的appDomains—运行在asp.net工作进程上。为了在安全以及特性上完成一个出色的界定，IIS6处理模型允许应用程序运行在同一个工作进程的不同拷贝上。每个应用程序池能够包含多个appdomains（运行在单独一个工作进程拷贝上).换而言之，这个变化是从单一进程运行所有程序到多个进程运行每一个应用池。这个模型也叫做工作过程隔离模式。

例外一个大变化相对先前的模型在IIS监听所有传入数据方面。在IIS5里，由IIS进程,inetinfo.exe监听指定的TCP端口。在IIS6中，传入请求被处理并队列在核心级别来替换先前通过核心驱动调用http.sys的用户模式；这种方法有几个优势相对于先前的模式被叫作 kernel-level 请求队列。

图表3 IIS6处理模型

图表3主要由请求处理组成。一旦一个请求到达核心级别设备驱动http.sys，然后发送到相应的应用程序池队列，每个队列属于一个指定的应用程序池。

工作进程负责加载asp.net ISAPI扩展，依次加载 CRL 委派所有工作到HTTP运行时。

W3WP.exe进程与IIS5下面的aspnet_wp.exe不同，他不是asp.net特有的，能够用来处理任何类型的请求。什么样的ISAPI模块被加载类型根据需要的服务资源类型。

二. HTTP压缩工作原理
Web服务器处理HTTP压缩的工作原理如下：
Web服务器接收到浏览器的HTTP请求后，检查浏览器是否支持HTTP压缩；
如果浏览器支持HTTP压缩，Web服务器检查请求文件的后缀名；
如果请求文件是HTML、CSS等静态文件，Web服务器到压缩缓冲目录中检查是否已经存在请求文件的最新压缩文件；
如果请求文件的压缩文件不存在，Web服务器向浏览器返回未压缩的请求文件，并在压缩缓冲目录中存放请求文件的压缩文件；
如果请求文件的最新压缩文件已经存在，则直接返回请求文件的压缩文件；
如果请求文件是ASPX等动态文件，Web服务器动态压缩内容并返回浏览器，压缩内容不存放到压缩缓存目录中。

三. IIS 6.0中配置HTTP Gzip压缩的步骤:
1) 打开Internet信息服务(IIS)管理器，右击"网站"->"属性"，选择"服务"。在"HTTP压缩"框中选中"压缩应用程序文件"和"压缩静态文件"，按需要设置"临时目录"和"临时目录的最大限制"；
2) 在Internet信息服务(IIS)管理器，右击"Web服务扩展"->"增加一个新的Web服务扩展..."，在"新建Web服务扩展"框中输入扩展名"HTTPCompression"，添加"要求的文件"为C:\WINDOWS\system32\inetsrv\gzip.dll  (文件为IIS安装自带)，其中Windows系统目录根据您的安装可能有所不同，选中"设置扩展状态为允许"；
3) 使用文本编辑器打开C:\Windows\System32\inetsrv\MetaBase.xml(建议先备份),
找到Location ="/LM/W3SVC/Filters/Compression/gzip"，
如果需要压缩动态文件，则将HcDoDynamicCompression设置为"TRUE"，并在HcScriptFileExtensions中增加您要压缩的动态文件后缀名，如aspx；
如果需要压缩静态文件，则将HcDoStaticCompression和HcDoOnDemandCompression设置为"TRUE"，并在HcFileExtensions中增加您需要压缩的静态文件后缀名，如xml、css等；
HcDynamicCompressionLevel和HcOnDemandCompLevel表示需要的压缩率，数字越小压缩率越低；
4) 编辑完毕后保存MetaBase.xml文件；如果文件无法保存，则可能IIS正在使用该文件。打开"开始"->"管理工具"->"服务"，停止"IIS Admin Service"后，即可保存；
5) 最后，重新启动IIS。可以到HTTP压缩测试网站http://www.pipeboost.com/验证结果。

问题2：未启用父路径
症状举例：
Server.MapPath() 错误 'ASP 0175 : 80004005'
不允许的 Path 字符
/0709/dqyllhsub/news/OpenDatabase.asp，行 4
在 MapPath 的 Path 参数中不允许字符 '..'。
原因分析：
许多Web页面里要用到诸如../格式的语句（即回到上一层的页面，也就是父路径），而IIS6.0出于安全考虑，这一选项默认是关闭的。
解决方法：
在IIS中 属性->主目录->配置->选项中。把"启用父路径"前面打上勾。确认刷新。

问题3：ASP的Web扩展配置不当（同样适用于ASP.NET、CGI） 
症状举例：
HTTP 错误 404 - 文件或目录未找到。
原因分析：
在IIS6.0中新增了web程序扩展这一选项，你可以在其中对ASP、ASP.NET、CGI、IDC等程序进行允许或禁止，默认情况下ASP等程序是禁止的。
解决方法：
在IIS中的Web服务扩展中选中Active Server Pages，点击"允许"。

问题4：身份认证配置不当
症状举例：
HTTP 错误 401.2 - 未经授权：访问由于服务器配置被拒绝。
原因分析：IIS 支持以下几种 Web 身份验证方法：
匿名身份验证
IIS 创建 IUSR_计算机名称 帐户（其中 计算机名称 是正在运行 IIS 的服务器的名称），用来在匿名用户请求 Web 内容时对他们进行身份验证。此帐户授予用户本地登录权限。你可以将匿名用户访问重置为使用任何有效的 Windows 帐户。
基本身份验证
使用基本身份验证可限制对 NTFS 格式 Web 服务器上的文件的访问。使用基本身份验证，用户必须输入凭据，而且访问是基于用户 ID 的。用户 ID 和密码都以明文形式在网络间进行发送。
Windows 集成身份验证
Windows 集成身份验证比基本身份验证安全，而且在用户具有 Windows 域帐户的内部网环境中能很好地发挥作用。在集成的 Windows 身份验证中，浏览器尝试使用当前用户在域登录过程中使用的凭据，如果尝试失败，就会提示该用户输入用户名和密码。如果你使用集成的 Windows 身份验证，则用户的密码将不传送到服务器。如果该用户作为域用户登录到本地计算机，则他在访问此域中的网络计算机时不必再次进行身份验证。
摘要身份验证
摘要身份验证克服了基本身份验证的许多缺点。在使用摘要身份验证时，密码不是以明文形式发送的。另外，你可以通过代理服务器使用摘要身份验证。摘要身份验证使用一种挑战/响应机制（集成 Windows 身份验证使用的机制），其中的密码是以加密形式发送的。
.NET Passport 身份验证
Microsoft .NET Passport 是一项用户身份验证服务，它允许单一签入安全性，可使用户在访问启用了 .NET Passport 的 Web 站点和服务时更加安全。启用了 .NET Passport 的站点会依靠 .NET Passport 中央服务器来对用户进行身份验证。但是，该中心服务器不会授权或拒绝特定用户访问各个启用了 .NET Passport 的站点。
解决方法：
根据需要配置不同的身份认证（一般为匿名身份认证，这是大多数站点使用的认证方法）。认证选项在IIS的属性->安全性->身份验证和访问控制下配置。

问题5：IP限制配置不当
症状举例：
HTTP 错误 403.6 - 禁止访问：客户端的 IP 地址被拒绝。
原因分析：
IIS提供了IP限制的机制，你可以通过配置来限制某些IP不能访问站点，或者限制仅仅只有某些IP可以访问站点，而如果客户端在被你阻止的IP范围内，或者不在你允许的范围内，则会出现错误提示。
解决方法：
进入IIS的属性->安全性->IP地址和域名限制。如果要限制某些IP地址的访问，需要选择授权访问，点添加选择不允许的IP地址。反之则可以只允许某些IP地址的访问。

问题6：IUSR账号被禁用
症状举例：
HTTP 错误 401.1 - 未经授权：访问由于凭据无效被拒绝。
原因分析：
由于用户匿名访问使用的账号是IUSR_机器名，因此如果此账号被禁用，将造成用户无法访问。
解决办法：
控制面板->管理工具->计算机管理->本地用户和组，将IUSR_机器名账号启用。

问题7：NTFS权限设置不当
症状举例：
HTTP 错误 401.3 - 未经授权：访问由于 ACL 对所请求资源的设置被拒绝。
原因分析：
Web客户端的用户隶属于user组，因此，如果该文件的NTFS权限不足（例如没有读权限），则会导致页面无法访问。
解决办法：
进入该文件夹的安全选项卡，配置user的权限，至少要给读权限。关于NTFS权限设置这里不再馈述。

问题8：IWAM账号不同步
症状举例：
HTTP 500 - 内部服务器错误
原因分析：
IWAM账号是安装IIS时系统自动建立的一个内置账号。IWAM账号建立后被Active Directory、IIS metabase数据库和COM+应用程序三方共同使用，账号密码被三方分别保存，并由操作系统负责这三方保存的IWAM密码的同步工作。系统对IWAM账号的密码同步工作有时会失效，导致IWAM账号所用密码不统一。
解决办法：
如果存在AD，选择开始->程序->管理工具->Active Directory用户和计算机。为IWAM账号设置密码。
运行c:\Inetpub\AdminScripts>adsutil SET w3svc/WAMUserPass +密码 同步IIS metabase数据库密码
运行cscript c:\inetpub\adminscripts\synciwam.vbs -v 同步IWAM账号在COM+应用程序中的密码

问题9：MIME设置问题导致某些类型文件无法下载（以ISO为例）
症状举例：
HTTP 错误 404 - 文件或目录未找到。
原因分析：
IIS6.0取消了对某些MIME类型的支持，例如ISO，致使客户端下载出错。
解决方法：
在IIS中 属性->HTTP头->MIME类型->新建。在随后的对话框中，扩展名填入.ISO，MIME类型是application。
另外，防火墙阻止，ODBC配置错误，Web服务器性能限制，线程限制等因素也是造成IIS服务器无法访问的可能原因.