在写本系列文章的过程中，我遇到了很大的困惑：在我准备讲述问题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请求处理流程概述
思考“为什么在地址栏输入就可以看到张子阳的个人空间?”，类似于思考“为什么苹果是往地上掉不是往天上飘?”。对于普通访问者来说，这就像每天太阳东边升起西边落下一样是理所当然的;对于很多程序员来说，认为这个与己无关，不过是系统管理员或者网管员的责任。毕竟，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. 应用程序配置
我们按编号来看一下这幅图中的数据是如何流动的。
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管道。
希望这篇文章能给你带来帮助。
