ASP.NET Core管道虽然在结构组成上显得非常简单，但是在具体实现上却涉及到太多的对象，所以我们在 《ASP.NET Core管道深度剖析[共4篇]》 中围绕着一个经过极度简化的模拟管道讲述了真实管道构建的方式以及处理HTTP请求的流程。在这个系列 中，我们会还原构建模拟管道时刻意舍弃和改写的部分，想读者朋友们呈现一个真是的HTTP请求处理管道。
ASP.NET Core 的请求处理管道由一个Server和一组有序排列的中间件构成，前者仅仅完成基本的请求监听、接收和响应的工作，请求接收之后和响应之前的所有工作都交给注册的中间件来完成。ASP.NET Core的中间件通过一个类型Func<RequestDelegate, RequestDelegate>的委托对象来表示，而RequestDelegate也是一个委托，它代表一项请求处理任务。
目录
一、一个重要的委托：RequestDelegate
二、描述当前请求的上下文：HttpContext
封装“特性”的容器：FeatureCollection
HttpContext的默认实现：DefaultHttpContext
上下文的创建者：HttpContextFactory
三、管道的注册者和构建者：ApplicationBuilder
ApplicationBuilder的创建者：ApplicationBuilderFactory
当Server接受到抵达的HTTP请求之后，会构建一个描述当前请求的原始上下文，Server的类型决定了这个原始上下文的类型，比如在我们模拟管道默认采用的HttpListenerServer由于采用HttpListener来监听、接收并响应请求，所以它对应的原始上下文是一个HttpListenerContext对象。但是对于管道的后续部分，即由注册的中间件构建的链表，它们需要采用统一的方式来处理请求，所以Server最终会根据原始的上下文来创建一个抽象的HTTP上下文，后者通过抽象类HttpContext来表示。
我们不仅可以利用这个HttpContext获取描述当前请求的上下文信息，同样可以利用它来实现对响应的控制。针对当前请求的任何处理操作总是在么一个上下文中进行，所以一项请求处理任务完全可以抽象成一个类型Func<HttpContext,Task>的委托来表示，实际上具有如下定义的RequestDelegate委托具有类似的定义。