关于ASP.NET的底层的工作机制，最近园子里讨论的甚是火热。相信很多人都看过Rick Strahl先生的一篇经典之作：A low-level Look at the ASP.NET Architecture，经Rick Strahl同意，我把他的这篇文章翻译成中文，希望能够给想深入了解ASP.NET工作机制的朋友一点帮助。

　　特别说明：翻译此文的目的仅仅是为了给广大的ASP.NET爱好者提供一些帮助，由于本人能力有限，文中不对地方，还请批评指正。如果你需要转载，请你保留该文以及原英文的链接。多谢!

　　目录

　　1. ASP.NET是什么?

　　2.从浏览器到ASP.NET

　　3.ISAPI连接

　　4.IIS5和IIS6的不同之处

　　5.进入.NET运行时

　　6.加载.NET—稍微有点神秘

　　7.回到运行时

　　8.HttpRuntime，HttpContext以及HttpApplication

　　9.Web程序的主要部分：HttpApplication

　　10.穿过ASP.NET管道

　　11.HttpContext，HttpModules和HttpHandlers

　　12.HttpModules

　　13.HttpHandlers

　　14.是否已经提供了足够的底层知识?

　　摘要：ASP.NET是一个用于构建Web程序的强大平台，提供了巨大的弹性和能力以至于它可以构建任意的Web程序。许多人仅仅对处于ASP.NET高层次的框架如：WebForms和WebServices比较熟悉，因此，在这篇文章里，我将会阐述有关ASP.NET比较底层的知识，并且将会解释，如何将请求从Web Server移交给ASP.NET运行时，然后通过ASP.NET HTTP管道处理这些请求。

　　对于我来说，了解一个平台的内部工作机制总是会让我感到一些满足和安慰，如同洞察，可以帮助我写出更好的程序。知道了工具有什么用途，以及它们如何组装成复杂框架的一部分，这些将会使你很容易的找到问题的解决方案，以及在你修改和调试错误时，都显得非常重要。这篇文章的目的就是从底层了解ASP.NET以及帮助你理解请求如何流入ASP.NET处理管道里。同时，你将会了解ASP.NET引擎的核心，以及一个Web请求如何在这里结束。这里讲到的许多知识都是你日常工作中没必要知道的，但是，如果你理解了ASP.NET如何把请求路由到应用程序的代码里(通常比较高层次的)，这将对你非常有用。

　　注：整个ASP.NET引擎完全构建在托管代码里，其所有的扩展性都是通过托管代码去构建。

　　使用ASP.NET的大多数都比较熟悉WebForms和WebServices。这些高层次的实现，使得构建Web程序变得非常容易。ASP.NET被设计为驱动引擎，它把底层的接口提供给Web Server，为高层次Web应用程序的前端和末端提供了路由服务。WebForms和WebServices是建立在ASP.NET框架之上，有关HTTP处理的两种最常用的方式。

　　其实，在较低的层次上，ASP.NET也提供了足够多的灵活性。HTTP运行时和请求管道提供了同样的能力，可以构建类似于WebForms和WebServices的实现，当然，这些已经使用.NET托管代码实现了。如果你需要构建一个自定义HTTP处理平台，而这个平台要比WebForms所处的层次低一点，那么你就会用到所有这些类似的功能。

　　构建大多的Web界面，使用WebForms无疑是最容易的方法，但是，如果你想自定义一个内容处理器，或者需要对流入和流出的内容做特殊的处理，或者需要为一个应用程序定制一个应用服务器接口，那么使用这些低层次的处理或者模块将会得到更好的性能，以及可以在真正的请求处理中获得更多的控制权。尽管那些高层次的实现，如：WebForms和WebServices已提供了类似的功能，但由于它们针对请求添加了太多的控制(导致性能下降)。所以你完全可以另辟佳境，在较低层次上处理这些请求。

　　ASP.NET是什么?

　　让我们从最简单的定义开始，ASP.NET是什么?我通常喜欢用如下语句来描述ASP.NET。

　　ASP.NET是完全使用托管代码处理Web请求的一个成熟引擎平台。它不仅仅只是WebForms和WebServices。

　　ASP.NET是一个请求处理引擎。它获取客户端请求，然后通过它内置的管道，把请求传到一个终点，在这个终点，开发者可以添加处理这个请求的逻辑代码。实际上这个引擎和HTTP或者Web Server是完全分开的。事实上，HTTP运行时是一个组件，你可以把它宿主在IIS之外的应用程序上。甚至完全可以和其它的服务组合在一起。例如，你可以把HTTP运行时宿主在Windows桌面应用程序里(详细的内容请查看：http://www.west-wind.com/presentations/aspnetruntime/aspnetruntime.aspx)。

　　通过使用内置的管道路由请求，HTTP运行时提供了一套复杂的，但却很优雅的机制。在处理请求的每一个层面都牵涉到许多对象，但大多数对象都可以通过派生或者事件接口来扩展。所以，此框架具有非常高的可扩展性。通过这一套机制，可以进入较低层次的接口如：缓存，身份验证，授权等是有可能的。你可以在处理请求之前或之后过滤内容，或者仅仅把匹配指定签名的客户端请求直接路由到你的代码里或转向其它的URL。针对同一件事情，可以通过不同的处理方法完成，而且实现代码都非常的直观。除此之外，在容易开发和性能之间，HTTP运行时还提供了最佳的灵活性。

　　整个ASP.NET引擎完全构建在托管代码里，所有的扩展性功能都是通过托管代码的扩展提供。对于功能强大的.NET框架而言，使用自己的东西，构建一个成熟的、高性能的引擎体系结构已经成为一个遗嘱。尽管如此，但重要的是，ASP.NET给人印象最深的是高瞻远瞩的设计，这使得在其之上的工作变得非常容易，并且提供了几乎可以钩住请求处理当中任意部分的能力。

　　使用ASP.NET可以完成一些任务，之前这些任务是使用IIS上的ISAPI扩展和过滤来完成的。尽管还有一些限制，但与ASP相比，已经有了很大的进步。ISAPI是底层Win32样式的API，仅它的接口就有1兆，这对于大型的程序开发是非常困难的。由于ISAPI是底层的接口，因此它的速度也是非常的快。但对于企业级的程序开发是相当的难于管理的。所以，在一定的时间内，ISAPI主要充当其它应用程序或平台的桥接口。但是无论如何，ISAPI没有被废弃。事实上，微软平台上的ASP.NET和IIS的接口是通过宿主在.NET里的ISAPI扩展来通信的，然后直达ASP.NET运行时。ISAPI提供了与Web Server通信的核心接口，然后ASP.NET使用非托管代码获取请求以及对客户端请求发出响应。ISAPI提供的内容经由公共对象类似于HttpRequest和HttpResponse，通过一个设计优良的、可访问的接口，以托管对象的方式暴露非托管数据。

　　从浏览器到ASP.NET让我们从一个典型的ASP.NET Web请求的生命周期的起点开始。用户通过在浏览器中键入一个URL，点击一个超链接，提交一个HTML表单(一个post请求)，或者一个客户端程序调用基于ASP.NET的WebService(通过ASP.NET提供服务)。在服务器端，IIS5或者IIS6将会收到这个请求。ASP.NET的底层通过ISAPI扩展与IIS通信，然后，通过ASP.NET，这个请求通常被路由到一个带有.aspx扩展名的页面。但是，这个处理过程如何工作，则完全依赖于HTTP处理器(handler)的执行。这个处理器将被安装用于处理指定的扩展。在IIS中，.aspx经由“应用程序扩展”被映射到ASP.NET ISAPI的dll文件：aspnet_isapi.dll。每一个触发ASP.NET的请求，都必须经由一个已经注册的，并且指向aspnet_isapi.dll的扩展名来标识。

　　注：ISAPI是自定义Web请求处理中第一个并且具有最高性能的IIS入口点。

　　依靠扩展名，ASP.NET把一个请求路由到一个恰当的处理器，该处理器则负责处理这个请求。举个例子，WebServices的扩展名.asmx不会把一个请求路由到磁盘上的某一个页面，而是会路由到在定义中附加了指定特性(WebMethodAttribute)的类，此特性会把它标识成一个Web Services的实现。许多其它的处理器将随着ASP.NET一起被安装。当然也可以定义你自己的处理器。在IIS里所有的HttpHandler被映射并指向ASP.NET ISAPI扩展，并且这些HttpHandler也都在web.config里配置，用于把请求路由到指定的HTTP处理器里执行。每一个处理器都是一个.NET类，用于处理指定的扩展。而这些处理器可以处理简单到只有几行代码的Hello World，也可以处理复杂到类似ASP.NET的页面以及执行WebService。就目前而言，仅仅需要理解扩展就是一种基本的映射机制，ASP.NET用它可以从ISAPI里获取一个请求，然后把请求路由到指定处理该请求的处理器中。