此文只是从中摘录整理下自己感兴趣的部分，以便备忘和方便查找回顾，详见：
- Artech - 博客园 (cnblogs.com)
- 《ASP.NET Core 6 框架揭秘》
请务必先通读以下官网概述（15min~30min）：
承载系统
借助 .NET Core 提供的承载系统（Hosting），我们可以将任意一个或多个长时间运行的服务寄宿或者承载于托管进程中。ASP.NET Core 应用仅仅是该承载系统的一种典型的服务类型而已，任何需要在后台长时间运行的操作都可以定义成标准化的服务并利用该系统来承载。
承载系统通过 IHost 接口表示承载服务的宿主，宿主实例由对应的 IHostBuilder 对象来创建。HostBuilder 类型是对 IHostBuilder 接口的默认实现，通过调用该对象的 Build 方法来提供作为宿主的 IHost 对象。在调用 Build 方法之前，可以调用 IHostBuilder 接口的 ConfigureService 方法，注册针对某 IHostedService 接口的服务。针对 IHostedService 服务的注册还可以调用 IServiceCollection 接口的 AddHostedService<THostedService> 扩展方法来完成。
承载服务通过 IHostedService 接口表示，该接口定义的 StartAsync 和 StopAsync 方法可以启动和关闭服务。
当作为宿主的 IHost 对象被启动时，它会利用依赖注入框架激活每个注册的 IHostedService 服务，并通过 StartAsync 方法来启动他们。当服务承载应用程序关闭时，作为服务宿主的 IHost 对象会被关闭，由它承载的每个 IHostedService 服务对象的 StopAsync 方法也随之被调用。
管道
请求处理管道 = 服务器 + 中间件
一个 ASP.NET Core 应用的核心就是由一个服务器和一组有序中间件组成的请求处理管道，服务器只负责监听、接收和分发请求、以及最终完成对请求的响应。所以，针对请求的处理能力和处理方式，由注册的中间件来决定，另外所有中间件针对请求的处理都在通过 HttpContext 对象表示的上下文中进行。
HTTP协议自身的特性决定了任何一个外部应用的工作模式都是监听、接收并处理HTTP请求，并且最终对请求予以响应。HTTP请求处理是管道式设计典型的应用场景：可以根据具体的需求构建一个管道，接收的HTTP请求像水一样流入这个管道，组成这个管道的各个环节依次对其做相应的处理。
HTTP请求处理流程始于对请求的监听与接收，终于对请求的响应。这两项工作均由同一个对象来完成，我们称之为服务器（Server）。ASP.NET Core 请求处理管道必须有一个服务器，他是整个管道的龙头。HTTP请求一旦抵达，服务器会将其标准化，并分发给管道后续的节点，我们将位于服务器之后的节点称为中间件（Middleware）。
服务器在管道中的职责非常明确，负责HTTP请求的监听，接收和最终的响应。具体来说，启动后的服务器会绑定到指定的端口进行请求监听。一旦有请求抵达，它会根据该请求创建代表请求上下文的 HttpContext 对象，并将该上下文分发给注册的中间件进行处理，当中间件管道完成了针对请求的处理之后，服务器会将最终生成的响应回复给客户端。
ASP.NET Core的请求处理管道由一个服务器和一组中间件组成，位于龙头的服务器负责请求的监听、接收、分发和最终的响应，而针对该请求的处理则由后续的中间件来完成。从概念上可以将请求处理管道理解为请求消息和响应消息流通的管道，服务器将接收的请求消息从一端流入管道并由相应的中间件进行处理，生成的响应消息反向流入管道，经过相应中间件处理后，由服务器分发给请求者。但从实现的程度来讲，管道中流通的并不是所谓的请求消息与响应消息。而是一个针对当前请求创建的上下文，这个上下文被抽象成如下这个HttpContext的类型。我们利用它不仅可以获取针对当前的请求的所有信息，还可以直接完成针对当前请求的所有响应工作。
中间件的注册可以通过调用 IWebHostBuilder 接口的Configure 扩展方法来完成，然后通过调用 IApplicationBuilder 接口的 Use 方法将表示中间件的 Func<RequestDelegate,RequestDelegate> 对象添加到当前中间件链条上。
自定义中间件
中间件的两种定义方式：
- 继承
IMiddleware接口。实现其InvokeAsync方法，完成针对请求的处理。 - 按照约定定义具有指定方法模式的类。
区别：强类型方式定义的中间件，可以注册为任意生命周期模式的服务。但是按照约定定义的中间件则总是一个Singleton 服务。
承载环境
派生于 IHostEnvironment 接口的 IWebHostEnviroment接口定义了两个属性：WebRootPath 和 WebRootFileProvider。
WebRootPath 属性表示用于存放Web资源文件根目录的路径，WebRootFileProvider 属性则返回该路径对应的 IFileProvider 对象。如果我们希望外部可以采用http请求的方式直接访问某个静态文件（如JS、CSS、图片等），只需要将它们放于WebRootPath属性表示的目录之下即可。默认为wwwroot文件夹。
如果没有显示指定环境名称，当前应用就会采用默认的
Production环境名称。
宏观概述
遇到问题，解决方案分为两种，一种是“扬汤止沸”，一种是“釜底抽薪”。
ASP.NET Core是一个全新的Web 开发平台，为我们构建了一个可复用和可定制的请求处理管道，微软在它上面构建了MVC、SingnalR、GRPC、Orleans这样广泛使用的web框架。
ASP.NET Core 框架的请求处理管道由服务器和中间件组成，管道利用服务器来监听和处理请求，并完成最终对请求的响应，应用针对请求的处理则体现在有序排列的中间件上。即当宿主程序（Host）启动后，管道被构建出来，作为管道龙头的服务器就开始监听来自客户端的HTTP请求。服务器解决针对HTTP请求的监听接收和最终的响应，具体针对请求的处理则由它递交给后续的中间件来完成。
.NET Core与传统.NET Framework最大的区别是跨平台，即开发出来的程序不再只是仅仅可以运行在Windows平台上，各种Linux和Mac上也都行了。除此之外，.NET Core针对容器也提供了原生的支持。
ASP.NET Core 框架依赖于一些基础框架，其中最重要的是依赖注入框架，它是构建请求处理管道的基石，也是应用的基本编程模式。整个ASP.NET Core框架建立在一个底层的依赖注入框架之上，它使用依赖注入容器提供所需的服务对象。
一个
ASP.NET Core应用本质上就是一个用来监听、接收、处理、响应HTTP请求的后台服务。
.NET Framework的结构组成
从.NET Framework的结构组成的角度来讲，.NET Framework由如下图所示的两个层级构成，它们分别是提供运行环境的CLR（Common Language Runtime）和提供API的FCL（Framework Class Library）。
即：.NET Framework = Runtime + FCL
CLR为程序的执行提供一个托管（Managed）的执行环境，它是.NET Framework的执行引擎，为托管程序的执行提供内存分配、垃圾回收、安全控制、异常处理和多线程管理等方面的服务。CLR是.NET Framework的子集，但是两者却具有不同的版本策略。到目前为止，微软仅仅发布了4个版本的CLR，它们分别是1.0、1.1、2.0和4.0，.NET Framework 1.0和1.1分别采用CLR 1.0和1.1，CLR 2.0被.NET Framework 2.0和3.x共享，.NET Framework 4.x下的运行时均为CLR 4.0。
.NET Framework的各个应用模型是相互独立的。在开发某种类型的应用时，我们只需要引用应用模型对应的程序集就可以了，也就是说我们开发一个Windows Forms应用，是不需要去引用System.Web.dll程序集的。
跨平台的.NET Core
对于真正跨平台的.NET Core来说，微软不仅为它设计了针对不同平台被称为CoreCLR的运行时，同时还重新设计了一套被称为CoreFX的BCL。
NET Core目前支持的AppModel有4种（ASP.NET Core、Windows Forms、WPF和UWP），其中ASP.NET Core 提供了全平台的支持，而Windows Forms、WPF和UWP只能在Windows上运行。
除了.NET Framework、.NET Core，.NET还具有另一个重要分支，即Xamarin，它可以为iOS、OS和Android 编写统一的应用。
.NET Standard
.NET Standard为.NET Framework、.NET Core和Xamarin提供了统一的API，那么我们在这组标准API基础上编写的代码自然就能被所有类型的.NET应用复用。
.NET 5
.NET Core 3.1是最后一个版本的.NET Core，今后不会再有.NET Core和.NET Framework之分，未来的.NET是一个统一平台，称为.NET 5/6/7……。所有类型的应用都是在统一的.NET Standard上开发的，所以不会再有移植性问题。
更新于：2023.5.20