在面试的过程中，会遇到一些公司偶尔问道asp.net的整个运行机制的问题。下面我就来看看asp.net的整个的运行原理吧-------(在邹大牛的基础上加上个人的理解)。
首先你得知道：当你在浏览器中地址栏里面敲了一个你要访问的地址之后，“其实就相当于你通过 浏览器 去访问一台电脑上访问文件一样，只不过浏览器 的访问请求是由被访问的电脑上的一个 WEB服务器软件 来接收处理，它会分析接收到的请求信息，从而按照请求信息来找到服务器电脑上的文件，经过处理，最终将生成的内容发回到浏览器。”（摘自邹大牛）。看到这里的时候，也许有点绕了，什么浏览器，什么web服务器软件，其实说白了：浏览器和服务器就是两个应用程序，他们之间是通过Socket按照http协议来相互通信的。
知道了这一点，那你就可以了解到：当浏览器发送的请求报文到达web服务器(通常是IIS)时，IIS就会去分析请求报文，从中获取请求的页面路径并判断页面的后缀名，如果是静态页面(.html/.jpg等图片文件/.css/.js等)且这些文件并不在App_Code文件夹中(A)直接由IIS软件的组件读取该文件内容，并将内容通过Socket发送回浏览器。
但是如果请求的时动态页面，如：aspx,ashx,jsp,php等页面的话，IIS是无法处理这个请求的，具体原因暂且不论。
请求的动态页面IIS无法处理，那当然由我们强大的.net FrameWork来处理了。请求报文通过扩展程序接口aspnet_isapi与.net FrameWork进行交互，将请求报文“传递”给了.net运行环境来处理，具体步骤如下：
1：调用FrameWork里的类ISAPIRuntime里面的ProcessRequest，该方法实现了IISAPIRuntime接口，此方法中做了两重大的事情：
a.创建WorkerRequest对象：通过调用CreateWorkerRequest (IntPtr ecb, bool useOOP)方法来创建一个ISAPIWorkerRequest对象，
此对象中包含了请求报文，并拥有和aspnet_isapi.dll通讯的能力。
b. 调用HttpRuntime.ProcessRequestNoDemand(HttpWorkerRequest wr)方法，然后在此方法里通过调用HttpRuntime实例方法
ProcessRequestInternal(HttpWorkerRequest wr)，开始处理请求。
2:HttpRuntime调用的ProcessRequestInternal(HttpWorkerRequest wr)做了3个重要的事情：
a.生成上下文对象(HttpContext)，为上下文对象context内部的两个重要的成员赋值：Reqeust和Response，前者负责向ASP.NET和程序员提供请求报文的数据，后者向ASP.NET和程序员提供储存要输出到浏览器的数据的地方。
(I).内部的HttpRequest对象：根据wr里封装的报文数据进一步封装出了HttpRequest对象。
(II).内部的HttpResponse对象：在内部初始化了一个HtmlWriter对象，用来保存服务端要输出给浏览器的页面代码。
(III).注意，如果在创建context时出现错误，比如浏览器发来的请求报文格式错误，那么就会直接在此时向浏览器输出400响应报文。
b.创建HttpApplication handler，此对象中执行请求的动态页面对象创建和执行的整个过程。
(I).通过HttpApplicationFactory创建-HttpApplicationFactory.GetApplicationInstance(context);
如何生成的HttpApplication对象，这里暂时不分析，其实原理也挺简单的，故不描述~~
注意此方法中为创建的HttpApplication对象传入了上下文对象context，“HttpContext类是管道的“粘合剂”，因为它把与当前请求有关的所有信息保存在一个地方，把所有类合成一体。第一次创建HttpContext对象时，它分配HttpRequest和HttpResponse类的新实例并且字段存储它们。它还为应用程序和会话状态提供了专用的访问器”。
(II).HttpApplication对象负责处理整个请求，HttpApplication具体执行过程如下。
c.当HttpApplication执行完后，调用FinishRequest方法，生成并输出响应报文到浏览器。
3：那么，HttpApplication具体执行过程到底如何呢？
(I):HttpApplication调用ProcessRequest(HttpContext context),该方法要求传入上下文对象,该方法开始执行19个委托对象(传说中的执行 请求管道)。下面贴上一张图让我们看看这19个事件吧(以下的管道事件图都是来自博客园上的另外一位仁兄的，特此说明。)。 
微软向我们程序员公开的这些事件是可以由我们程序员来自定义的注册事件的，因此熟悉一些事件对于我们在做类似于权限验证操作或是类似于一些系统的全局的处理都可以在这些事件处理，从而节省一些性能。
下面我们来看一下一些常用的事件处理：
第8个事件：在第八个事件时创建了被请求的页面类对象，并将其转换为IHttpHandler接口对象(面向接口编程的思想)。
在请求管道的第9个到11个事件中有一个事件会接收浏览器传送过来的SessionId,并根据此值到session池中找到相应的session对象，并将其赋值给页面类对象的Session属性。具体实现过程如下：
首先尝试将页面类对象转换为IRequiresSessionState接口对象，如果转换不成功,则不加载session对象；
如果转换成功，则在请求报文中获取到cookie里面的SessionId,再根据SessionId到服务器的Session池中获取到Session对象，并将其赋值给页面类对象的Session属性。
在第11和12个事件之间执行了在第八个事件中创建的页面类对象的ProcessRequest方法：具体过程不详细解释，紧接着调用给方法内部的_bulidControlTree(),紧接着调用当前页面类对象的ProcessRequestMain()方法， 在该方法里面执行了整个页面生命周期：具体如下(这张图也是借用博客园上另外一位仁兄的图，暂时找不到底是哪位仁兄的了，如有看到，请莫抛砖~~)：
当然在查看源码后，有些方法与途中相关的方法名不一致，参考源码中的方法名；在执行完RenderControl()方法后，向浏览器输出html代码，自此整个asp.net的运行机制与页面生命周期就结束了。
从整个过程来看，似乎显得有些臃肿，微软也意识到这一点，因此在看到webform编程方式给程序员带来的痛苦之后，便又推出了一种全新的编程方式：mvc，虽然整个流程与机制原理不会相差太远，但mvc全新的编程方式让我们这一帮程序员在睡梦中都回笑醒~~~