ASP.NET Core真实管道详解[2]:Server是如何完成针对请求的监听、接收与响应的【上】

Server是ASP .NET Core管道的第一个节点,负责完整请求的监听和接收,最终对请求的响应同样也由它完成。Server是我们对所有实现了IServer接口的所有类型以及对应对象的统称,如下面的代码片段所示,这个接口具有一个只读属性Features返回描述自身特性集合的FeatureCollection对象,另一个Start方法用于启动服务器。

   1: public interface IServer : IDisposable
   2: {
   3:     IFeatureCollection Features { get; }
   4:     void Start<TContext>(IHttpApplication<TContext> application);    
   5: }

当我们Start方法启动指定的Server的时候,它必须指定一个类型为IHttpApplication<TContext>的参数,我们将实现才接口的所有类型及其对应对象统称为HttpApplication。当Server在接收到抵达的请求之后,实际上会直接交给这个HttpApplication对象来处理,所以我们需要先来认识一下这个对象。

目录
一、HttpApplication
二、请求的处理与执行上下文的创建与释放
三、日志记录
    请求处理开始与结束时记录的日志
    针对请求的日志上下文范围
    请求唯一标识的生成

一、HttpApplication

对于ASP.NET Core管道来说,HttpApplication被用来处理Server接收的请求,这个对象可以视为对注册的所有中间件的封装,它对请求的处理工作实际上最终会委托这些中间件来完成。HttpApplication针对请求的处理实际上会在一个执行上下文中完成,这个上下文实际上为应用对单一请求的整个处理过程定义了一个边界。单纯描述HTTP请求的HttpContext是这个执行上下文中最为核心的部分,除此之外,我们还可以根据需要将其他相关的信息定义其中,所以IHttpApplication<TContext>接口采用泛型参数的形式来表示定义这个上下文的类型。

HttpApplication不仅仅需要在这个执行上下文中处理Server转发给它的请求,这个上下文对象的创建和回收释放同样需要由它来完成。如下面的代码片段所示,IHttpApplication<TContext>接口的CreateContext和DisposeContext方法分别体现了针对执行上下文的创建和释放,CreateContext方法的参数contextFeatures表示描述原始上下文的特性集合。在此上下文中针对请求的处理实现在另一个方法ProcessRequestAsync之中。

   1: public interface IHttpApplication<TContext>
   2: {
   3:     TContext CreateContext(IFeatureCollection contextFeatures);
   4:     void     DisposeContext(TContext context, Exception exception);
   5:     Task     ProcessRequestAsync(TContext context);
   6: }

在默认情况下创建的HttpApplication是一个HostingApplication对象。对于HostingApplication来说,它创建的执行上下文的类型是一个具有如下定义的结构体Context,它内嵌于HostingApplication类之中。对于这个Context对象表示的针对当前请求的执行上下文来说,描述当前HTTP请求的HttpContext是最为核心的部分。除了这个HttpContext属性之外,Context还具有额外两个属性,其中Scope是为追踪诊断而创建的日志上下文范围,该范围将针对同一个请求的多项日志记录进行关联,而另一个属性StartTimestamp表示应用开始处理请求的时间戳。

   1: public class HostingApplication : IHttpApplication<Context>
   2: {
   3:     //省略成员
   4:     public struct Context
   5:     {
   6:         public HttpContext     HttpContext { get; set; }
   7:         public IDisposable     Scope { get; set; }
   8:         public long            StartTimestamp { get; set; }
   9:     }
  10: }


二、请求的处理与执行上下文的创建与释放

由于HostingApplication针对请求的处理是通过注册的中间件来完成的,而后者最终会利用上面介绍的ApplicationBuilder对象转换成一个类型为RequestDelegate的委托对象,所以我们在创建HostingApplication的时候需要提供这么一个RequestDelegate对象。有HostingApplication创建的Context对象包含表示HTTP上下文的HttpContext对象,而后者是通过对应的工厂HttpContextFactory创建的,所以HttpContextFactory在创建时也是必须要提供的。如下面的代码片段所示,HostingApplication类型的构造函数需要将这两个对象作为输入参数,至于另外两个参数(logger和diagnosticSource),它们与日志记录有关,我们稍后会对此作专门的介绍。

   1: public class HostingApplication : IHttpApplication<HostingApplication.Context>
   2: {
   3:     private readonly RequestDelegate         _application;
   4:     private readonly DiagnosticSource        _diagnosticSource;
   5:     private readonly IHttpContextFactory     _httpContextFactory;
   6:     private readonly ILogger                 _logger;
   7:  
   8:     public HostingApplication(RequestDelegate application, ILogger logger,  DiagnosticSource diagnosticSource, IHttpContextFactory httpContextFactory)
   9:     {
  10:         _application         = application;
  11:         _logger              = logger;
  12:         _diagnosticSource    = diagnosticSource;
  13:         _httpContextFactory  = httpContextFactory;
  14:     }
  15: }

下面给出的代码片段基本体现了HostingApplication创建和释放Context对象,以及在此上下文中处理请求的逻辑。在CreateContext方法中,它直接利用初始化提供的HttpContextFactory创建一个HttpContext并将其作为Context对象的同名属性,至于Context额外两个属性(Scope和StartTimestamp)该作何设置,我们会在本节后续部分对此作专门介绍。实现在ProcessRequestAsync方法中针对请求的处理最终体现在对构造时指定的这个RequestDelegate对象的执行。当DisposeContext方法被执行的时候,Context的Scope属性会率先被释放,在此之后HttpContextFactory的Dispose方法被调用以完成对Context对象自身的回收释放。

   1: public class HostingApplication : IHttpApplication<HostingApplication.Context>
   2: {
   3:     public Context CreateContext(IFeatureCollection contextFeatures)
   4:     {
   5:         //省略其他实现代码
   6:         return new Context
   7:         {
   8:                HttpContext      = _httpContextFactory.Create(contextFeatures),
   9:                Scope            = ...,
  10:                StartTimestamp   = ...
  11:         };
  12:     }
  13:  
  14:     public Task ProcessRequestAsync(Context context)
  15:     {
  16:         Return _application(context.HttpContext);
  17:     }
  18:  
  19:     public void DisposeContext(Context context, Exception exception)
  20:     {        
  21:         //省略其他实现代码
  22:         context.Scope.Dispose();
  23:         _httpContextFactory.Dispose(context.HttpContext);
  24:     }
  25: }


三、日志记录

由于管道处理其中总是在一个由HttpApplication创建的执行上下文中进行,所有上下文的创建和回收释放可以视为 整个请求处理流程开始和结束的标识。对于HostingApplication来说,CreateContext和DisposeContext方法分别被调用的时候,它会利用初始化时指定的Logger对象作相应的日志记录。除此之外,作为开始处理请求标志的CreateContext方法还是创建一个日志上下文范围,其目的是将针对同一请求的日志时间关联起来。这个上下文范围对应着Context对象的Scope对象,通过上面的代码片段我们可以看出针对这个日志上下文范围的释放同样发生在DisposeContext方法中。

请求处理开始与结束时记录的日志

接下来我们通过实例演示的形式来看看究竟怎样的日志消息分别被它的CreateContext和DisposeContext方法记录下来。在一个ASP.NET Core控制台应用中,为了将记录的日志消息直接打印到控制台上,我们需要为管道使用的LoggerFactory注册一个ConsoleLoggerProvider。在添加相应NuGet包(“Microsoft.Extensions.Logging.Console”)之后,我们定义了如下一个Startup类型,它采用构造函数注入的方式得到这个LoggerFactory并调用扩展方法AddConsole实现了对ConsoleLoggerProvider的注册。

   1: public class Startup
   2: {
   3:     public Startup(ILoggerFactory loggerFactory)
   4:     {
   5:         loggerFactory.AddConsole();
   6:     }
   7:  
   8:     public void Configure(IApplicationBuilder app)
   9:     {
  10:         app.Run(context => context.Response.WriteAsync("Hello World!"));
  11:     }
  12: }

我们启动这个控制台应用让它开始利用KestrelServer在默认的端口(5000)进行请求监听,然后利用浏览器向对应的地址(我们将目标地址设定为“http://localhost:5000/helloworld”)发送请求,控制台上将会输出管道在请求处理过程中写入的日志消息。如下所示的两条等级为Information的日志就是在开始和完成请求时分别被HostingApplication的CreateContext和DisposeContext方法写入的。第一条日志包含不仅仅包含请求的目标地址,还包括请求采用的协议(HTTP/1.1)和HTTP方法(GET),第二条则反映了整个请求处理过程所花的时间。

image

上面演示的时候请求被正常处理的情况下管道自身记录的日志,如果在处理过程中抛出异常,该异常会作为参数传递给HostingApplication的DisposeContext方法,后者会额外写入一条等级为Error的日志记录发生的错误。下面的代码片段展现了出现异常情况下写入的三条日志。

image

针对请求的日志上下文范围

为了查看HostingApplication在CreateContext方法针对当前请求创建的日志上下文范围,我们在为LoggerFactory注册ConsoleLoggerProvider的时候需要显式开始针对日志上下文范围的支持,所以我们在调用AddConsole方法的时候将true作为额外的参数。除此之外,我们在Configure方法中利用注入的LoggerFactory创建相应的Logger,并利用它记录一条等级为Information的日志,日志内容为“Write \"Hello World!\"”。

   1: public class Startup
   2: {
   3:     public Startup(ILoggerFactory loggerFactory)
   4:     {
   5:         loggerFactory.AddConsole(true);
   6:     }
   7:  
   8:     public void Configure(IApplicationBuilder app, ILoggerFactory loggerFactory)
   9:     {
  10:         app.Run(context =>
  11:         {
  12:             loggerFactory.CreateLogger("App").LogInformation("Write \"Hello World!\"");
  13:             return context.Response.WriteAsync("Hello World!");
  14:         });
  15:     }
  16: }

程序启动后我们采用浏览器向相同的目标地址(“http://localhost:5000/helloworld”)发送两次请求。对于这两次请求记录的日志,它们分别是在不同的日志上下文中被写入的,我们可以根据这个上下文范围对记录下来的日志消息进行有效地分组。针对这两次请求,服务端一共有如下6条日志消息被记录下来,针对同一请求的三条日志具有相同的上下文范围信息,该体现不仅仅包含请求的路径(“/helloworld”),还具有一个唯一标识请求的ID。

image

请求唯一标识的生成

日志上下文范围携带的用于唯一标识当前请求的ID,同时也可以视为当前HttpContext的唯一标识,它对应着HttpContext的TranceIdentifier属性。对于DefaultHttpContext来说,针对这个属性的读写是借助一个名为HttpRequestIdentifierFeature的特性实现的,下面的代码提供了该对象对应的接口IHttpRequestIdentifierFeature和默认实现类HttpRequestIdentifierFeature的定义。

   1: public abstract class HttpContext
   2: {
   3:     //省略其他成员
   4:     public abstract string TraceIdentifier { get; set; }
   5: }
   6:  
   7: public interface IHttpRequestIdentifierFeature
   8: {
   9:     string TraceIdentifier { get; set; }
  10: }
  11:  
  12: public class HttpRequestIdentifierFeature : IHttpRequestIdentifierFeature
  13: {
  14:     private string _id;
  15:     private static long _requestId = DateTime.UtcNow.Ticks;
  16:     private static unsafe string GenerateRequestId(long id);
  17:     public string TraceIdentifier
  18:     {
  19:         get { return _id??(id= GenerateRequestId(Interlocked.Increment(ref _requestId)));}
  20:         set { this._id = value; }
  21:     }
  22: }

HttpRequestIdentifierFeature生成TraceIdentifier的逻辑很简单。如上面的代码片断所示,它具有一个静态长整型字段_requestId,其初始值为当前时间戳。对于某个具体的HttpRequestIdentifierFeature对象来说,它的TraceIdentifier属性的默认值返回的是这个字段_requestId加1之后转换的字符串。具体的转换逻辑定义在GenerateRequestId方法中,它会采用相应的算法 将指定的整数转换一个长度为13的字符串(比如“0HKSDQNPC0424”)。

本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如若转载,请注明出处:http://www.mzph.cn/news/438416.shtml

如若内容造成侵权/违法违规/事实不符,请联系多彩编程网进行投诉反馈email:809451989@qq.com,一经查实,立即删除!

相关文章

pos机未能连接服务器,pos 机链接不了服务器

pos 机链接不了服务器 内容精选换一换在本章节中&#xff0c;您将运行已部署好的游戏&#xff0c;登录游戏客户端。已准备好Windows机器&#xff0c;硬盘至少20G&#xff0c;且必须安装有显卡。服务器地址&#xff1a;节点的弹性IP地址&#xff0c;请登录CCE控制台&#xff0c;…

ASP.NET Core管道深度剖析(1):采用管道处理HTTP请求

之所以称ASP.NET Core是一个Web开发平台&#xff0c;源于它具有一个极具扩展性的请求处理管道&#xff0c;我们可以通过这个管道的定制来满足各种场景下的HTTP处理需求。ASP. NET Core应用的很多特性&#xff0c;比如路由、认证、会话、缓存等&#xff0c;也同时定制消息处理管…

emui消息推送服务器,别再抱怨,这次或许真的轮到你了,EMUI9.1推送进度再次更新...

最近几年里&#xff0c;华为在系统方面下的功夫可谓是大家有目共睹的。以往大家在使用华为EMUI操作系统的时候&#xff0c;或许会感觉到卡顿、应用启动时间过长、运行不流畅以及UI界面毫无亮点可言等&#xff0c;但那已经是过去的EMUI系统了&#xff0c;今日的EMUI系统已与往日…

ASP.NET Core管道深度剖析(2):创建一个“迷你版”的管道来模拟真实管道请求处理流程

从《ASP.NET Core管道深度剖析&#xff08;1&#xff09;&#xff1a;采用管道处理HTTP请求》我们知道ASP.NET Core请求处理管道由一个服务器和一组有序的中间件组成&#xff0c;所以从总体设计来讲是非常简单的&#xff0c;但是就具体的实现来说&#xff0c;由于其中涉及很多对…

ASP.NET Core管道深度剖析(3):管道是如何处理HTTP请求的?

我们知道ASP.NET Core请求处理管道由一个服务器和一组有序的中间件组成&#xff0c;所以从总体设计来讲是非常简单的&#xff0c;但是就具体的实现来说&#xff0c;由于其中涉及很多对象的交互&#xff0c;我想很少人能够地把它弄清楚。为了让读者朋友们能够更加容易地理解管道…

ASP.NET Core管道深度剖析(4):管道是如何建立起来的?

在《管道是如何处理HTTP请求的&#xff1f;》中&#xff0c;我们对ASP.NET Core的请求处理管道的构成以及它对请求的处理流程进行了详细介绍&#xff0c;接下来我们需要了解的是这样一个管道是如何被构建起来的。这样一个管道由一个服务器和一个HttpApplication构成&#xff0c…

ASP.NET MVC 入门1、简介

什么是MVC模式 MVC&#xff08;Model-View-Controller&#xff0c;模型—视图—控制器模式&#xff09;用于表示一种软件架构模式。它把软件系统分为三个基本部分&#xff1a;模型&#xff08;Model&#xff09;&#xff0c;视图&#xff08;View&#xff09;和控制器&#xf…

ASP.NET MVC 入门2、项目的目录结构与核心的DLL

我们新建一个ASP.NET MVC的Web Application后&#xff0c;默认的情况下&#xff0c;项目的目录结构如下&#xff1a; App_Data &#xff1a;这个目录跟我们一般的ASP.NET website是一样的&#xff0c;用于存放数据。Content &#xff1a;这个目录是建议用来存放一下资源文件的。…

Maven超详细配置

&#x1f468;‍&#x1f393; 博主介绍&#xff1a;大家好&#xff0c;我是超梦梦梦梦&#xff0c;很高兴认识大家~&#x1f357;关注➕点赞➕评论➕收藏 &#x1f604;&#x1f64f;博主水平有限&#xff0c;如有错误&#xff0c;欢迎各位大佬纠正&#xff01; 目录&#x1f…

ASP.NET MVC 入门3、Routing

本系列文章基于Microsoft ASP.NET MVC Beta. 在一个route中&#xff0c;通过在大括号中放一个占位符来定义( { and } )。当解析URL的时候&#xff0c;符号"/"和"."被作为一个定义符来解析&#xff0c;而定义符之间的值则匹配到占位符中。route定义中不在大…

一篇教你xftp连接阿里云轻量级应用服务器。超级详细,避免踩坑

&#x1f468;‍&#x1f393; 博主介绍&#xff1a;大家好&#xff0c;我是超梦梦梦梦&#xff0c;很高兴认识大家~ &#x1f357;关注➕点赞➕评论➕收藏 &#x1f604; &#x1f64f;博主水平有限&#xff0c;如有错误&#xff0c;欢迎各位大佬纠正&#xff01; &#x1f52…

ASP.NET MVC 入门4、Controller与Action

本系列文章基于ASP.NET MVC Preview5. Controller是MVC中比较重要的一部分。几乎所有的业务逻辑都是在这里进行处理的&#xff0c;并且从Model中取出数据。在ASP.NET MVC Preview5中&#xff0c;将原来的Controller类一分为二&#xff0c;分为了Controller类和ControllerBase类…

Postman下载与安装操作步骤【超详细】

&#x1f468;‍&#x1f393; 博主介绍&#xff1a;大家好&#xff0c;我是超梦梦梦梦&#xff0c;很高兴认识大家~&#x1f357;关注➕点赞➕评论➕收藏 &#x1f604;&#x1f64f;博主水平有限&#xff0c;如有错误&#xff0c;欢迎各位大佬纠正 Postman下载与安装&#x1…

C#异步编程模型

什么是异步编程模型 异步编程模型(Asynchronous Programming Model&#xff0c;简称APM)是C#1.1支持的一种实现异步操作的编程模型&#xff0c;虽然已经比较“古老”了&#xff0c;但是依然可以学习一下的。通过对APM的学习&#xff0c;我总结了以下三点&#xff1a; 1. APM的…

不会卸载MySQL?我连夜肝了一篇教你如何干干净净地卸载掉MySQL

&#x1f468;‍&#x1f393; 博主介绍&#xff1a;大家好&#xff0c;我是超梦梦梦梦&#xff0c;很高兴认识大家~ &#x1f64f;如果本博文对小伙伴们有帮助的话&#xff0c;&#x1f50e;关注➕&#x1f91e;点赞➕&#x1f4cb;评论➕&#x1f604;收藏一波哦~ &#x1…

设计模式篇

一. 什么是设计模式 纠结了好久&#xff0c;今天终于下定决心开始写设计模式系列&#xff0c;因为这个系列章节确实不好写&#xff0c;在这之前&#xff0c;也看了好多关于设计模式的博客、视频、书籍等&#xff0c;大多数用的例子要么猫啊狗啊、大雁等动物类&#xff1b;要么就…

Navicat15安装笔记

&#x1f468;‍&#x1f393; 博主介绍&#xff1a;大家好&#xff0c;我是超梦梦梦梦&#xff0c;很高兴认识大家~ &#x1f50e;关注➕&#x1f91e;点赞➕&#x1f4cb;评论➕&#x1f604;收藏 &#x1f4c5;创作日期&#xff1a;2021年12月29日 &#x1f4c5;修改日期…

MySQL5安装配置笔记【超详细】

&#x1f468;‍&#x1f393; 博主介绍&#xff1a;大家好&#xff0c;我是超梦梦梦梦&#xff0c;很高兴认识大家~ &#x1f64f;如果本博文对小伙伴们有帮助的话&#xff0c;&#x1f50e;关注➕&#x1f91e;点赞➕&#x1f4cb;评论➕&#x1f604;收藏一波哦~ &#x1…

IDEA常用快捷键大合集

&#x1f468;‍&#x1f393; 博主介绍&#xff1a;大家好&#xff0c;我是超梦梦梦梦&#xff0c;很高兴认识大家~ &#x1f64f;如果本博文对小伙伴们有帮助的话&#xff0c;&#x1f50e;关注➕&#x1f91e;点赞➕&#x1f4cb;评论➕&#x1f604;收藏一波哦~ &#x1…

KnockoutJs篇:快速掌握KnockoutJs

一、引言 之前这个系列文章已经介绍Bootstrap。由于最近项目中&#xff0c;前端是Asp.net MVC KnockoutJs Bootstrap来做的。所以我又重新开始写这个系列。今天就让我们来看看Web前端的MVVM框架——KnockoutJs。 二、KnockoutJs是什么&#xff1f; 做.NET开发的人应该都知道…