ASP.NET构架与安全机制之Http请求处理

　　本文转自博客园，文中内容不代表本站观点，仅提供参考。

　　导读

　　在写本系列文章的过程中，我遇到了很大的困惑：在我准备讲述问题A的时候，我发现需要先解释问题B;当我考虑如何讲解问题B的时候，又发现如果对问题C不够清楚，很难较好地理解问题B。好吧，事已至此，我决定从问题C开始着手。不幸的是… 我已经跑题了。

　　本系列文章原计划分成十个部分讲述Asp.Net构架、安全机制 和 Provider模型，然而在写作的过程中，我发现由于涉及的知识面太广，Provider 模型在本系列文章中的地位已经大大降低了。与此同时，我认识到想用十个Part讲述清楚Asp.Net的构架与安全机制是不可能的，但我仍会尝试用最少的文字讲述最多的内容。

　　阅读的过程中，你可能会觉得文中有的内容看上去与正在讨论的内容关系不大，这时候请你耐心地读下去，它往往是你理解后面问题的关键。

　　在开始阅读这一系列文章之前，请注意以下几点：

　　·本系列文章文会详细讲述 Form验证，粗略讲述Windows验证，不讲述 Passport验证。

　　·有时候我会采用自顶向下的方式讲述，另一些时候我会采用自底向上的方式讲述，这一切视需要而定。

　　·尽管我很不愿意在段落之中插入过多的灰色说明文字，但是很多地方不如此很难讲述清楚，我会在所有Part全部发布完后对本系列文章进行修订。

　　·我们经常提到或者听到三层式开发，也不断在网上搜寻三层式开发的源码来研究。实际上，等你了解了Provider模型后，就会发现最近的三层构架其实就在身边。希望能认真学习Provider模型并思考其实用价值。

　　·文章中的插图是在 IIS 6.0 和 Windows Server2003 下截取的，如果与 IIS 5.0的区别大到足以产生误导，请反馈给我。

　　·由于本系列文章涉及的知识点比较多，而我又采用写一个Part发布一个的方式。所以，很可能写Part.4时候才发现Part.3很多地方没有讲清楚，这时候我会停下来重新修改Part.3;我也可能在写Part.5的时候发现Part.1的一些内容挪到Part.2更合适。 请原谅我在做这些改动的时候不再另行通知。

　　这将是一次漫长的旅途，如果你现在已经整装待发，那我们就上路吧!

　　引言

　　我查阅过不少Asp.Net的书籍，发现大多数作者都是站在一个比较高的层次上讲解Asp.Net。他们耐心、细致地告诉你如何一步步拖放控件、设置控件属性、编写CodeBehind代码，以实现某个特定的功能。

　　这种做法，实际上是回答了“如何去做”的问题，却没有回答“为什么可以这样做”的问题。

　　尽管我很推崇 悉江华 先生的《圣殿祭祀的Asp.Net开发详解》一书，但当我翻看了一下其对角色(Role) 和 用户(Member)的讲解时，我决定跳过去直接读后面的章节。因为我发现他也随了大流，对这部分的讲解停留在“如何去做”的层面上。我相信像悉先生 这样的牛人是不可能不了解底层运作原理的，仅仅是因为那本书原本就已经很厚了吧。

　　当你按“如何去做”所讲解的内容去开发程序的时候，对于你的用户，你仍是一名程序员;但对于实现了MembershipProvider 和 RoleProvider 抽象类的微软开发人员来说，你已经成了他们的一个用户。

　　NOTE：我既不反对一些作者只讲解“如何去做”，也不反对你只学“如何去做”，这样也有它的好处，就是可以快速开发。我只是建议多掌握一点底层知识，对一些问题会有更好的理解。

　　希望通过这一系列文章的讲解，可以让你更好的理解Asp.Net的安全机制和身份验证及权限管理的底层运作原理。

　　Http请求处理流程概述

　　思考“为什么在地址栏输入www.tracefact.net就可以看到张子阳的个人空间?”，类似于思考“为什么苹果是往地上掉不是往天上飘?”。对于普通访问者来说，这就像每天太阳东边升起西边落下一样是理所当然的;对于很多程序员来说，认为这个与己无关，不过是系统管理员或者网管员的责任。毕竟，IIS是 Windows 的一个组件，又不是 Asp.Net 的一个组成部分。而实际上，从你轻拍回车到页面呈现在你眼前的十分之一秒内，IIS和.Net Framework已经做了大量的幕后工作。

　　你可能觉得了解这些幕后工作是如何运作的无关紧要，作为程序员的你只要保证开发出的程序可以高效地运行就可以了。然而，在开发过程中，你却发现常常需要使用诸如 HttpContext 这样的类。这个时候，你可曾思考过这些类的构成和类的实体是如何创建的?你可能简单地回答：HttpContext代表当前请求的一个上下文环境。可你又知道IIS 、Framework、Asp.Net 是如何协同工作处理每个Http请求、如何区分不同的请求、IIS、Framework、Asp.Net三者之间的数据如何流动么?

　　回答上面这些问题，首先需要了解IIS是如何处理页面请求的，这也是理解 Form验证模式和Windows 验证模式 的基础。

　　Http请求刚刚到达服务器的时候

　　当服务器接收到一个 Http请求的时候，IIS 首先需要决定如何去处理这个请求(NOTE：服务器处理一个.htm页面和一个.aspx页面肯定是不一样的么)。那IIS依据什么去处理呢?―― 根据文件的后缀名。

　　服务器获取所请求的页面(NOTE：也可以是文件，比如 jimmy.jpg)的后缀名以后，接下来会在服务器端寻找可以处理这类后缀名的应用程序，如果IIS找不到可以处理此类文件的应用程序，并且这个文件也没有受到服务器端的保护(NOTE：一个受保护的例子就是 App_Code中的文件，一个不受保护的例子就是你的js脚本)，那么IIS将直接把这个文件返还给客户端。

　　能够处理各种后缀名的应用程序，通常被称为 ISAPI 应用程序(NOTE：Internet Server Application Programe Interface，互联网服务器应用程序接口)。虽然这 ISAPI 听上去还挺气派，也算是“应用程序”呢，但仔细看看它的全称就明白了：它实际上只是一个接口，起到一个代理的作用，它的主要工作是映射所请求的页面(文件) 和与此后缀名相对应的实际的处理程序。

　　让我们更进一步地看一下 ISAPI ，看看它到底是什么样子，请按下面的步骤进行：

　　1. 打开IIS。

　　2. 选择随意一个站点，鼠标右键，“属性”。

　　3. 选择“主目录”选项卡。

　　4. 选择“配置”。

　　你应该会看到如下的画面：

　　图1. 应用程序配置

　　很清楚地就可以看到，所有IIS所能处理，或者叫 ISAPI 所提供代理服务的 文件类型 及其相对应的实际的后台处理程序都在这里清楚地列出来了。

　　我们找到 .aspx 的应用处理程序，然后点“编辑”，会出现下面的画面：

　　图2. 编辑.aspx文件的处理程序

　　一路看到这里，可以看出，所有的.aspx文件实际上都是由 aspnet_isapi.dll 这个程序来处理的，当IIS把对于.aspx页面的请求提交给了aspnet_isapi.dll以后，它就不再关心这个请求随后是如何处理的了。

　　这里需要注意两点：

　　1、当你修改“限制为”后，可以限制页面(文件)只能以某种特定方式访问。

　　2、“确认文件是否存在”是实现 URL 地址映射的关键选项，我以后会专门讲述。

　　理解宿主环境(Hosting)

　　从本质上讲，Asp.Net 主要是由一系列的类组成，这些类的主要目的就是将Http请求转变为对客户端的响应。HttpRuntime类是Asp.Net的一个主要入口，它有一个称作 ProcessRequest 的方法，这个方法以一个 HttpWorkerRequest 类作为参数。HttpRuntime 类几乎包含着关于单个 Http请求的所有信息：所请求的文件、服务器端变量、QueryString、Http 头信息 等等。Asp.Net 使用这些信息来加载、运行正确的文件，并且将这个请求转换到输出流中，一般来说，也就是HTML页面。

　　NOTE：二般来说，也可以是张图片。

　　当 Web.config文件的内容发生改变 或者 .aspx文件发生变动的时候，为了能够卸载运行在同一个进程中的应用程序(NOTE：卸载也是为了重新加载)，Http请求被分放在相互隔离的应用程序域中。

　　NOTE：可能你以前就听过应用程序域，但是不了解怎么回事，应用程序域就是 AppDomain。

　　对于IIS来说，它依赖一个叫做 HTTP.SYS 的内置驱动程序来监听来自外部的 HTTP请求。在操作系统启动的时候，IIS首先在HTTP.SYS中注册自己的虚拟路径。

　　NOTE：实际上相当于告诉HTTP.SYS哪些URL是可以访问的，哪些是不可以访问的。举个简单的例子：为什么你访问不存在的文件会出现 404 错误呢?就是在这一步确定的。

　　如果请求的是一个可访问的URL，HTTP.SYS会将这个请求交给 IIS 工作者进程。

　　NOTE：IIS6.0中叫做 w3wq.exe，IIS5.0中叫做 aspnet_wp.exe。

　　每个工作者进程都有一个身份标识 以及 一系列的可选性能参数。

　　NOTE：可选性能参数，是指诸如 回收机制的设置、超时时间设置 等等。

　　接下来进行的事情就是上一章节讲述的 ISAPI 了。

　　NOTE：这部分的内容相关性比较强，为了让大家好理解，我最后还是决定把 ISAPI 放到前面了，可能全系列完成的时候会再调整吧。

　　除了映射文件与其对应的处理程序以外，ISAPI 还需要做一些其他的工作：

　　1. 从HTTP.SYS中获取当前的Httq请求信息，并且将这些信息保存到 HttpWorkerRequest 类中。

　　2. 在相互隔离的应用程序域AppDomain中加载HttpRuntime。

　　3. 调用 HttpRuntime的ProcessRequest方法。

　　接下来才是程序员通常编写的代码所完成的工作了，然后，IIS 接收返回的数据流，并重新返还给 HTTP.SYS，最后，HTTP.SYS 再将这些数据返回给客户端浏览器。

　　OK，现在你看到张子阳的空间主页了。

　　图3.Asp.Net 的宿主环境

　　理解管道(Pipeline)

　　在前面两章中，我们在一个相对比较低的层次上讨论了从发出Http请求到看到浏览器输出这转瞬即逝的十分之一秒内IIS和 Framework 所做的事情。但是我们忽略了一个细节：程序员编写的代码是如何在这一过程中衔接的，本章我们就来看看这个问题。

　　当Http请求进入 Asp.Net Runtime以后，它的管道由托管模块(NOTE：Managed Modules)和处理器(NOTE：Handlers，这可不是CPU)组成，并且由管道来处理这个 Http请求。

　　图4. 理解 Http 管道

　　我们按编号来看一下这幅图中的数据是如何流动的。

　　1. HttpRuntime将Http请求转交给 HttpApplication，HttpApplication代表着程序员创建的Web应用程序。HttpApplication创建针对此Http请求的 HttpContext对象，这些对象包含了关于此请求的诸多其他对象，主要是HttpRequest、HttpResponse、HttpSessionState等。这些对象在程序中可以通过Page类或者Context类进行访问。

　　2. 接下来Http请求通过一些Module，这些Module可以做一些执行某个实际工作前的事情。

　　3. 在这一步，执行实际的一些操作，通常也就是.aspx页面所完成的业务逻辑。

　　4. Http请求再一次回到Module，此时Module可以做一些某个工作已经完成了之后的事情。

　　NOTE：注意我用红色标识的字，然后回想一下：Asp.Net 中是不是有众多的 Inserting 、Inserted 之类成对的事件?其实，这里讲述的就是为什么Asp.Net可以将一个Insert操作分成前后两部分，然后再分别进行事件拦截的幕后原理。

　　总结

　　本文是《Asp.Net构架与安全机制》系列文章的第一篇。

　　我首先概要介绍了这系列文章将要为大家讲述的主题。然后，我提出了部分程序员存在的一个问题：在一个比较高的层次上学习和使用Asp.Net。

　　随后，我以一个访问我个人空间首页的例子，引出了本文主要讲述的三个内容：

　　1. Http请求刚刚到达时IIS时，IIS 所做的工作。

　　2. Http请求的宿主环境。

　　3. Http管道。

　　希望这篇文章能给你带来帮助。