对我而言了解平台的内幕通常会带来满足感和舒适感，深入了解也能帮助我写出更好的应用。知道可以使用哪些工具以及他们是怎样作为整个复杂框架的一部分来互相配合的可以更容易地找出最好的解决方案，更重要的是可以在出现问题时更好的解决它们。这篇文章的目标是从系统级别了解ASP.NET并帮助理解请求（request）是如何在ASP.NET的处理管道中流转的。同样，我们会了解核心引擎和Web请求如何在那里结束。这些信息大部分并不是你在日常工作时必须了解的，但是它对于理解ASP.NET架构如何把请求路由到你的代码（通常是非常高层的）中是非常有益的。

    不管怎么样，ASP.NET从更低的层次上提供了更多的灵活性。HTTP运行时和请求管道在构建WebForms和WebServices上提供了同样的能力-它们事实上都是建立在。NET托管代码上的。而且所有这些同样的功能对你也是可用的，你可用决定你是否需要建立一个比WebForms稍低一点层次的定制的平台。

    WebForms显然是最简单的构建绝大多数Web接口的方法，不过如果你是在建立自定义的内容处理器（handler），或者有在处理输入输出内容上有特殊的要求，或者你需要为另外的应用建立一个定制的应用程序服务接口，使用这些更低级的处理器（handler）或者模块（module）能提供更好的性能并能对实际请求处理提供更多的控制。在WebForms和WebServices这些高层实现提供它们那些能力的同时，它们也对请求增加了一些额外负担，这些都是在更底层可以避免的。

    ASP.NET是什么

    让我们以一个简单的定义开始：什么是ASP.NET？我喜欢这样定义ASP.NET：

    ASP.NET是一个复杂的使用托管代码来从头到尾处理Web请求的引擎。

    它并不只是WebForms和WebServies…

    ASP.NET是一个请求处理引擎。它接收一个发送过来的请求，把它传给内部的管道直到终点，作为一个开发人员的你可以在这里附加一些代码来处理请求。这个引擎是和HTTP/Web服务器完全分隔的。事实上，HTTP运行时是一个组件，使你可以摆脱IIS或者任何其他的服务器程序，将你自己的程序寄宿在内。例如，你可以将ASP.NET运行时寄宿在一个Windows form程序中（查看http://www.west-wind.com/presentations/aspnetruntime/aspnetruntime.asp可以得到更加详细的信息）

    运行时提供了一个复杂但同时非常优雅的在管道中路由请求的机制。其中有很多相关的对象，大多数都是可扩展的（通过继承或者事件接口），在几乎所有的处理流程上都是如此。所以这个框架具有高度可扩展性。通过这个机制，挂接到非常底层的接口（比如缓存，认证和授权）都变得可能了。你甚至可以在预处理或者处理后过滤内容，也可以简单的将符合特殊标记的请求直接路由你的代码或者另一个URL上。存在着许多不同的方法来完成同一件事，但是所有这些方法都是可以简单直接地实现的，同时还提供了灵活性，可以得到最好的性能和开发的简单性。

    整个ASP.NET引擎是完全建立在托管代码上的，所有的扩展功能也是通过托管代码扩展来提供的

    整个ASP.NET引擎是完全建立在托管代码上的，所有的扩展功能也是通过托管代码扩展来提供的。这是对。NET框架具有构建复杂而且高效的框架的能力的最好的证明。ASP.NET最令人印象深刻的地方是深思熟虑的设计，使得框架非常的容易使用，又能提供挂接到请求处理的几乎所有部分的能力。

    通过ASP.NET你可以从事从前属于ISAPI扩展和IIS过滤器领域的任务-有一些限制，但是比起ASP来说是好多了。ISAPI是一个底层的Win32风格的API，有着非常粗劣的接口而且难以用来开发复杂的程序。因为ISAPI非常底层，所以它非常的快，但是对于应用级的开发者来说是十分难以管理的。所以，ISAPI通常用来提供桥接的接口，来对其他应用或者平台进行转交。但是这并不意味者ISAPI将消亡。事实上，ASP.NET在微软的平台上就是通过ISAPI扩展来和IIS进行交互的，这个扩展寄宿着。NET运行时和ASP.NET运行时。ISAPI提供了核心的接口，ASP.NET使用非托管的ISAPI代码通过这个接口来从Web服务器获取请求，并发送响应回客户端。ISAPI提供的内容可以通过通用对象（例如HttpRequest和HttpResponse）来获取，这些对象通过一个定义良好并有很好访问性的接口来暴露非托管数据。