本文讲述ASP.NET构架与安全机制和Provider模型，然而在写作的过程中，我发现由于涉及的知识面太广，Provider 模型在本文章中的地位已经大大降低了。与此同时，我认识到想用十个Part讲述清楚ASP.NET构架与安全机制是不可能的，但我仍会尝试用最少的文字讲述最多的内容。
希望通过这一系列文章的讲解，可以让你更好的理解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 听上去还挺气派，也算是“应用程序”呢，但仔细看看它的全称就明白了：它实际上只是一个接口，起到一个代理的作用，它的主要工作是映射所请求的页面(文件) 和与此后缀名相对应的实际的处理程序。
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构架与安全机制。
随后，我以一个访问我个人空间首页的例子，引出了本文主要讲述的三个内容：
1. Http请求刚刚到达时IIS时，IIS 所做的工作。
2. Http请求的宿主环境。
3. Http管道。
【编辑推荐】
