ASP.NET Core管道虽然在结构组成上显得非常简单，但是在具体实现上却涉及到太多的对象，所以我们在 “通过重建Hosting系统理解HTTP请求在ASP.NET Core管道中的处理流程”（上篇、中篇、下篇） 中围绕着一个经过极度简化的模拟管道讲述了真实管道构建的方式以及处理HTTP请求的流程。在本系列 中，我们会还原构建模拟管道时可以舍弃和改写的部分，向读者朋友们呈现一个真是的HTTP请求处理管道。 ASP.NET Core 的请求处理管道由一个服务器与一组有序排列的中间件构成，前者仅仅完成请求监听、接收和响应这些与底层网络相关的工作，至于请求接收之后和响应之前的所有工作都交给中间件来完成。ASP.NET Core的中间件通过一个类型Func<RequestDelegate, RequestDelegate>的委托对象来表示，而RequestDelegate也是一个委托，它代表一项请求处理任务。 [本文已经同步到《ASP.NET Core框架揭秘》之中]
目录
一、RequestDelegate
二、HttpContext
FeatureCollection
DefaultHttpContext
HttpContextFactory
三、ApplicationBuilder
ApplicationBuilderFactory
中间件类型
中间件类型的注册
一、RequestDelegate
服务器接受到抵达的HTTP请求之后会构建一个描述当前请求的原始上下文，服务器的类型决定了这个原始上下文的类型，比如在我们模拟管道默认采用的HttpListenerServer由于采用HttpListener来监听、接收并响应请求，所以它对应的原始上下文是一个HttpListenerContext对象。但是对于管道的后续部分，即由注册的中间件构建的链表，它们需要采用统一的方式来处理请求，所以服务器最终会根据原始的上下文来创建一个抽象的HTTP上下文，后者通过抽象类HttpContext来表示。
我们不仅可以利用这个HttpContext获取描述当前请求的上下文信息，同样可以利用它来实现对响应的控制。针对当前请求的任何处理操作总是在这么一个上下文中进行，所以一项请求处理任务完全可以抽象成一个类型Func<HttpContext,Task>的委托来表示，实际上具有如下定义的RequestDelegate委托具有类似的定义。
1: public delegate Task RequestDelegate(HttpContext context);
每个中间件都承载着独立的请求处理任务，它本质上也体现了在当前HttpContext下针对请求的处理操作，那么为什么中间件不直接通过一个RequestDelegate对象来表示，而是表示为一个类型为Func<RequestDelegate, RequestDelegate>的委托对象呢？原因很简单，中间件并不孤立地存在，所有注册的中间件最终会根据注册的先后顺序组成一个链表，每个中间件不仅仅需要完成各自的请求处理任务外，还需要驱动链表中的下一个中间件。
延伸阅读
- ssh框架 2016-09-30
- 阿里移动安全 [无线安全]玩转无线电——不安全的蓝牙锁 2017-07-26
- 消息队列NetMQ 原理分析4-Socket、Session、Option和Pipe 2024-03-26
- Selective Search for Object Recognition 论文笔记【图片目标分割】 2017-07-26
- 词向量-LRWE模型-更好地识别反义词同义词 2017-07-26
- 从栈不平衡问题 理解 calling convention 2017-07-26
- php imagemagick 处理 图片剪切、压缩、合并、插入文本、背景色透明 2017-07-26
- Swift实现JSON转Model - HandyJSON使用讲解 2017-07-26
- 阿里移动安全 Android端恶意锁屏勒索应用分析 2017-07-26
- 集合结合数据结构来看看(二) 2017-07-26
学习是年轻人改变自己的最好方式