ASP.NET Core 5-Kestrel源碼解讀


上節講到了kestrel服務器的配置及使用,相信很多同學已經對kestrel服務器有了初步的了解,那么有的同學可能會想更加深入的了解一下Kestrel服務器的是怎么實現監聽和接收http請求的,今天我們來看下Kestrel服務器的源碼,相信看完這些,你一定會對Kestrel服務器的運行機制有更深入的了解。

首先,讓我們從程序啟動類Program.cs開始分析。

public class Program
{
    public static void Main(string[] args)
    {
        CreateHostBuilder(args).Build().Run();
    }
 
    public static IHostBuilder CreateHostBuilder(string[] args) =>
        Host.CreateDefaultBuilder(args)
            .ConfigureWebHostDefaults(webBuilder =>
             {
                 webBuilder.UseStartup<Startup>();
             });
}

 

其中,Host類鏈式調用了兩個方法:

  • CreateDefaultBuilder
  • ConfigureWebHostDefaults

首先我們來看下CreateDefaultBuidler方法:

public static IHostBuilder CreateDefaultBuilder(string[] args)
{
      HostBuilder hostBuilder = new HostBuilder();
      hostBuilder.UseContentRoot(Directory.GetCurrentDirectory());
      hostBuilder.ConfigureHostConfiguration((Action<IConfigurationBuilder>) (config =>
      {
        ...
      }));
      hostBuilder.ConfigureAppConfiguration((Action<HostBuilderContext, IConfigurationBuilder>) ((hostingContext, config) =>
      {
        ...
      })).ConfigureLogging((Action<HostBuilderContext, ILoggingBuilder>) ((hostingContext, logging) =>
      {
        ...
      })).UseDefaultServiceProvider((Action<HostBuilderContext, ServiceProviderOptions>) ((context, options) =>
      {
        ...
      }));
      return (IHostBuilder) hostBuilder;
    }
 }

 

從上述代碼可以看出,CreateDefaultBuilder並未涉及Kestrel服務器相關代碼,僅僅是進行一些應用的初始化配置,例如,設置應用程序目錄,設置配置文件等操作。

我們再來看下ConfigureWebHostDefaults方法:

public static IHostBuilder ConfigureWebHostDefaults(
      this IHostBuilder builder,
      Action<IWebHostBuilder> configure)
{
      if (configure == null)
        throw new ArgumentNullException(nameof (configure));
      return builder.ConfigureWebHost((Action<IWebHostBuilder>) (webHostBuilder =>
      {
        Microsoft.AspNetCore.WebHost.ConfigureWebDefaults(webHostBuilder);
        configure(webHostBuilder);
      }));
}

通過閱讀源碼可以發現: ConfigureWebHostDefaults方法中的Microsoft.AspNetCore.WebHost.ConfigureWebDefaults(IWebHostBuilder)為實際執行初始化Kestrel服務器的代碼。

internal static void ConfigureWebDefaults(IWebHostBuilder builder)
{
     ...
     builder.UseKestrel((Action<WebHostBuilderContext, KestrelServerOptions>) ((builderContext, options) => options.Configure((IConfiguration) builderContext.Configuration.GetSection("Kestrel"), true))).ConfigureServices((Action<WebHostBuilderContext, IServiceCollection>) ((hostingContext, services) =>
     {
       services.PostConfigure<HostFilteringOptions>((Action<HostFilteringOptions>) (options =>
       {
        ...
       }
     })).UseIIS().UseIISIntegration();
}

看到這里,可能有的同學已經的迫不及待的想要看下Kestrel初始化流程相關的代碼了。別着急,我們一步一步來。

首先我們查看一下上面的UseKestrel擴展方法:

public static IWebHostBuilder UseKestrel(
      this IWebHostBuilder hostBuilder,
      Action<WebHostBuilderContext, KestrelServerOptions> configureOptions)
    {
      return hostBuilder.UseKestrel().ConfigureKestrel(configureOptions);
    }

發現該方法只是對傳入的配置項KestrelServerOptions做了封裝,最終是調用了IWebHostBuilder的擴展方法UseKestrel和ConfigureKestrel(Action<WebHostBuilderContext, KestrelServerOptions> configureOptions)擴展方法來初始化Kestrel服務器配置,同樣是鏈式調用。

現在我們來看下UseKestrel()這個擴展方法:

public static IWebHostBuilder UseKestrel(this IWebHostBuilder hostBuilder)
{
    return hostBuilder.ConfigureServices((Action<IServiceCollection>) (services =>
    {
      services.TryAddSingleton<IConnectionListenerFactory, SocketTransportFactory>();
      services.AddTransient<IConfigureOptions<KestrelServerOptions>, KestrelServerOptionsSetup>();
      services.AddSingleton<IServer, KestrelServerImpl>();
    }));
}

細心的同學可能會發現,配置一個Kestrel服務器居然只需要僅僅三行代碼?是不是感覺有些不可思議?Kestrel服務器這么簡單?是的,Kestrel服務器就是這么簡單。那么,Kestrel服務器是如何實現監聽和接收請求的呢?

首先看下IConnectionListenerFactory接口類:

public interface IConnectionListenerFactory
{
    ValueTask<IConnectionListener> BindAsync(
      EndPoint endpoint,
      CancellationToken cancellationToken = default (CancellationToken));
}

這個接口職責只有一個,就是執行Sokcert的綁定EndPoint操作,然后返回一個IConnectionListener對象。EndPoint可以有三種實現:

  • FileHandleEndPoint
  • UnixDomainSocketEndPoint
  • IPEndPoint

我們再來看下實現類SocketTransportFactory:

public sealed class SocketTransportFactory : IConnectionListenerFactory
{
    private readonly SocketTransportOptions _options;
    private readonly SocketsTrace _trace;
    public SocketTransportFactory(
      IOptions<SocketTransportOptions> options,
      ILoggerFactory loggerFactory)
    {
      if (options == null)
        throw new ArgumentNullException(nameof (options));
      if (loggerFactory == null)
        throw new ArgumentNullException(nameof (loggerFactory));
      this._options = options.Value;
      this._trace = new SocketsTrace(loggerFactory.CreateLogger("Microsoft.AspNetCore.Server.Kestrel.Transport.Sockets"));
    }
    public ValueTask<IConnectionListener> BindAsync(
      EndPoint endpoint,
      CancellationToken cancellationToken = default (CancellationToken))
    {
      SocketConnectionListener connectionListener = new SocketConnectionListener(endpoint, this._options, (ISocketsTrace) this._trace);
      connectionListener.Bind();
      return new ValueTask<IConnectionListener>((IConnectionListener) connectionListener);
    }
}

代碼非常簡單,先實例化SocketConnectionListener對象,然后調用SocketConnectionListener的Bind方法並根據傳入的EndPoint類型來創建Socket對象,來實現對EndPoint的監聽和綁定操作。

internal void Bind()
{
    if (this._listenSocket != null)
      throw new InvalidOperationException(SocketsStrings.TransportAlreadyBound);
    Socket listenSocket;
    switch (this.EndPoint)
    {
      case FileHandleEndPoint fileHandleEndPoint:
        this._socketHandle = new SafeSocketHandle((IntPtr) (long) fileHandleEndPoint.FileHandle, true);
        listenSocket = new Socket(this._socketHandle);
        break;
      case UnixDomainSocketEndPoint domainSocketEndPoint:
        listenSocket = new Socket(domainSocketEndPoint.AddressFamily, SocketType.Stream, ProtocolType.IP);
        BindSocket();
        break;
      case IPEndPoint ipEndPoint:
        listenSocket = new Socket(ipEndPoint.AddressFamily, SocketType.Stream, ProtocolType.Tcp);
        if (ipEndPoint.Address == IPAddress.IPv6Any)
          listenSocket.DualMode = true;
        BindSocket();
        break;
      default:
        listenSocket = new Socket(this.EndPoint.AddressFamily, SocketType.Stream, ProtocolType.Tcp);
        BindSocket();
        break;
    }
    this.EndPoint = listenSocket.LocalEndPoint;
    listenSocket.Listen(this._options.Backlog);
    this._listenSocket = listenSocket;
    void BindSocket()
    {
      try
      {
        listenSocket.Bind(this.EndPoint);
      }
      catch (SocketException ex) when (ex.SocketErrorCode == SocketError.AddressAlreadyInUse)
      {
        throw new AddressInUseException(ex.Message, (Exception) ex);
      }
    }
}

現在我們已經知道了Kestrel服務器內部是如何進行綁定和監聽操作。那么Kestrel服務器是如何對http請求進行接收處理的呢?

接下來我們來看IServer接口:

public interface IServer : IDisposable
{
    IFeatureCollection Features { get; }
    Task StartAsync<TContext>(IHttpApplication<TContext> application, CancellationToken cancellationToken) where TContext : notnull;
    Task StopAsync(CancellationToken cancellationToken);
}

IServer接口也非常簡單,定義了一個Server最基本的有兩個功能:啟動和停止。那么Kestrel服務器是怎么實現的這個接口呢?

下面我們來看下微軟官方為IServer注入的實現類KestrelServerImpl:

internal class KestrelServerImpl : IServer
{
    ...
    public IFeatureCollection Features { get; }
    public KestrelServerOptions Options => ServiceContext.ServerOptions;
    private ServiceContext ServiceContext { get; }
    private IKestrelTrace Trace => ServiceContext.Log;
    private AddressBindContext AddressBindContext { get; set; }
    public async Task StartAsync<TContext>(IHttpApplication<TContext> application, CancellationToken cancellationToken)
    {
        ...
        async Task OnBind(ListenOptions options)
        {
            if (!BitConverter.IsLittleEndian)
            {
                throw new PlatformNotSupportedException(CoreStrings.BigEndianNotSupported);
            }
            ValidateOptions();
            if (_hasStarted)
            {
                    // The server has already started and/or has not been cleaned up yet
                throw new InvalidOperationException(CoreStrings.ServerAlreadyStarted);
            }
            _hasStarted = true;

            ServiceContext.Heartbeat?.Start();
            if ((options.Protocols & HttpProtocols.Http3) == HttpProtocols.Http3)
            {
                if (_multiplexedTransportFactory is null)
                {
                    throw new InvalidOperationException($"Cannot start HTTP/3 server if no {nameof(IMultiplexedConnectionListenerFactory)} is registered.");
                }
 
                options.UseHttp3Server(ServiceContext, application, options.Protocols);
                var multiplexedConnectionDelegate = ((IMultiplexedConnectionBuilder)options).Build();
 
                multiplexedConnectionDelegate = EnforceConnectionLimit(multiplexedConnectionDelegate, Options.Limits.MaxConcurrentConnections, Trace);
                options.EndPoint = await _transportManager.BindAsync(options.EndPoint, multiplexedConnectionDelegate, options.EndpointConfig).ConfigureAwait(false);
            }
 
            if ((options.Protocols & HttpProtocols.Http1) == HttpProtocols.Http1
                || (options.Protocols & HttpProtocols.Http2) == HttpProtocols.Http2
                || options.Protocols == HttpProtocols.None) // TODO a test fails because it doesn't throw an exception in the right place
                                                                // when there is no HttpProtocols in KestrelServer, can we remove/change the test?
            {
               if (_transportFactory is null)
                {
                    throw new InvalidOperationException($"Cannot start HTTP/1.x or HTTP/2 server if no {nameof(IConnectionListenerFactory)} is registered.");
                }
                options.UseHttpServer(ServiceContext, application, options.Protocols);
                var connectionDelegate = options.Build();
                connectionDelegate = EnforceConnectionLimit(connectionDelegate, Options.Limits.MaxConcurrentConnections, Trace);
                options.EndPoint = await _transportManager.BindAsync(options.EndPoint, connectionDelegate, options.EndpointConfig).ConfigureAwait(false);
            }
         }

         AddressBindContext = new AddressBindContext
         {
             ServerAddressesFeature = _serverAddresses,
             ServerOptions = Options,
             Logger = Trace,
             CreateBinding = OnBind,
         };
         await BindAsync(cancellationToken).ConfigureAwait(false);
         ...
    }
 
    public async Task StopAsync(CancellationToken cancellationToken)
    {
            ...
    }
    ...
    private async Task BindAsync(CancellationToken cancellationToken)
    {
             ...
         await AddressBinder.BindAsync(Options.ListenOptions, AddressBindContext).ConfigureAwait(false);
             ...
    }
    ...
}

我們來整理一下StartAsync方法的流程:

  1. 字節序校驗:不支持BigEndian
  2. 請求參數長度校驗,最大8kb
  3. 判斷服務器是否已經啟動過
  4. 啟動心跳檢測
  5. 實例化AddressBindContext用於BindAsync方法使用
  6. 執行BindAsync方法來綁定地址操作

BindAsync調用了AddressBindContext的OnBind方法。OnBind方法會根據使用的http協議類型創建不同的HttpConnectionMiddleware中間件並加入到connection管道中,用於處理Http請求。

具體規則如下:

  • 當協議是HttpProtocols.Http1/2時,創建HttpConnectionMiddleware中間件
  • 當協議是HttpProtocols.Http3時,創建Http3ConnectionMiddleware中間件

目前常用的是HttpConnectionMiddleware:

IConnectionBuilder UseHttpServer<TContext>(
      this IConnectionBuilder builder,
      ServiceContext serviceContext,
      IHttpApplication<TContext> application,
      HttpProtocols protocols)
    {
      HttpConnectionMiddleware<TContext> middleware = new HttpConnectionMiddleware<TContext>(serviceContext, application, protocols);
      return builder.Use((Func<ConnectionDelegate, ConnectionDelegate>) (next => new ConnectionDelegate(middleware.OnConnectionAsync)));
    }

 

UseHttpServer方法為connection管道(注意不是IApplicationBuilder中的請求管道)添加了一個HttpConnectionmiddleware中間件,當請求到達時,會執行OnConnectionAsync方法來創建HttpConnection對象,然后通過該對象處理http請求:

public Task OnConnectionAsync(ConnectionContext connectionContext)
{
     IMemoryPoolFeature memoryPoolFeature = connectionContext.Features.Get<IMemoryPoolFeature>();
     HttpConnectionContext context = new HttpConnectionContext();
     context.ConnectionId = connectionContext.ConnectionId;
     context.ConnectionContext = connectionContext;
     HttpProtocolsFeature protocolsFeature = connectionContext.Features.Get<HttpProtocolsFeature>();
     context.Protocols = protocolsFeature != null ? protocolsFeature.HttpProtocols : this._endpointDefaultProtocols;
     context.ServiceContext = this._serviceContext;
     context.ConnectionFeatures = connectionContext.Features;
     context.MemoryPool = memoryPoolFeature?.MemoryPool ?? MemoryPool<byte>.Shared;
     context.Transport = connectionContext.Transport;
     context.LocalEndPoint = connectionContext.LocalEndPoint as IPEndPoint;
     context.RemoteEndPoint = connectionContext.RemoteEndPoint as IPEndPoint;
     return new HttpConnection(context).ProcessRequestsAsync<TContext>(this._application);
}

ProcessRequestsAsync為具體的處理請求的方法,此方法會根據使用的http協議版本來創建Http1Connection還是Http2Connection,然后使用此httpConnection來創建context對象(注意不是HttpContext對象)。

Kestrel服務器對請求的接收是通過OnBind里面的TransportManager.BindAsync來實現的。

public async Task<EndPoint> BindAsync(
      EndPoint endPoint,
      ConnectionDelegate connectionDelegate,
      EndpointConfig? endpointConfig)
{
     if (this._transportFactory == null)
       throw new InvalidOperationException("Cannot bind with ConnectionDelegate no IConnectionListenerFactory is registered.");
     IConnectionListener connectionListener = await this._transportFactory.BindAsync(endPoint).ConfigureAwait(false);
     this.StartAcceptLoop<ConnectionContext>((IConnectionListener<ConnectionContext>) new TransportManager.GenericConnectionListener(connectionListener), (Func<ConnectionContext, Task>) (c => connectionDelegate(c)), endpointConfig);
     return connectionListener.EndPoint;
}

 

其中StartAcceptLoop方法為實際接收數據的方法,通過方法名“開始循環接收”,我們猜測,是不是Kestrel服務器是通過對Socket的Accept方法進行循環監聽來接收數據的?那么到底是不是呢?讓我們來繼續跟蹤一下connectionDispatcher.StartAcceptingConnections方法:

public Task StartAcceptingConnections(IConnectionListener<T> listener)
{
     ThreadPool.UnsafeQueueUserWorkItem<IConnectionListener<T>>(new Action<IConnectionListener<T>>(this.StartAcceptingConnectionsCore), listener, false);
     return this._acceptLoopTcs.Task;
}
private void StartAcceptingConnectionsCore(IConnectionListener<T> listener)
{
     AcceptConnectionsAsync();
 
     async Task AcceptConnectionsAsync()
     {
       try
       {
         while (true)
         {
           T connectionContext = await listener.AcceptAsync(new CancellationToken());
           if ((object) connectionContext != null)
           {
             long id = Interlocked.Increment(ref ConnectionDispatcher<T>._lastConnectionId);
             KestrelConnection<T> kestrelConnection = new KestrelConnection<T>(id, this._serviceContext, this._transportConnectionManager, this._connectionDelegate, connectionContext, this.Log);
             this._transportConnectionManager.AddConnection(id, (KestrelConnection) kestrelConnection);
             this.Log.ConnectionAccepted(connectionContext.ConnectionId);
             KestrelEventSource.Log.ConnectionQueuedStart((BaseConnectionContext) connectionContext);
             ThreadPool.UnsafeQueueUserWorkItem((IThreadPoolWorkItem) kestrelConnection, false);
           }
           else
             break;
         }
       }
       catch (Exception ex)
       {
         this.Log.LogCritical((EventId) 0, ex, "The connection listener failed to accept any new connections.");
       }
       finally
       {
         this._acceptLoopTcs.TrySetResult();
       }
  }
}

相信現在大家已經了解是怎么回事了吧?原來Kestrel服務器是通過while(true)循環接收的方式接收用戶請求數據,然后通過線程池的ThreadPool.UnsafeQueueUserWorkItem方法將請求分發到CLR線程池來處理的。換句話說,在請求到來時,TransportManager將OnConnectionAsync方法加入線程池並待CLR線程池調度。

那么回到開始的時候,Kestrel服務器是如何啟動的呢?

讓我們再回顧一下Program.cs中的方法

public static void Main(string[] args)
{
   CreateHostBuilder(args).Build().Run();
}

相信聰明的同學已經猜到了,是通過Run()方法來執行的,Run()方法做了些什么呢?

Run方法實際上是執行了Host類中的StartAsync方法,此方法通過獲取預先注入的GenericeWebHostService類中注入的IServer類來最終調用到IServer實現類的StartAsnyc方法的。

internal class GenericWebHostService : IHostedService
{
  ...
  public IServer Server { get; }
  ...
    public async Task StartAsync(CancellationToken cancellationToken)
    {
     ...
     var httpApplication = new HostingApplication(application, Logger, DiagnosticListener, HttpContextFactory);
     await Server.StartAsync(httpApplication, cancellationToken);
     ...
    }
}

至此,Kestrel成功啟動並開始監聽用戶請求。

一句話總結:其實ASP.NET Core 5中的Kestrel服務器只是對Socket的簡單封裝,簡單到直接用socket通過while(true)的方式來循環接收socket請求,並直接放入clr線程池中來等待線程池調度處理。

原來,Kestrel服務器這么簡單~

相信通過本文的介紹,大家已經對ASP.NET Core 5中的Kestrel服務器有了解了吧?


免責聲明!

本站轉載的文章為個人學習借鑒使用,本站對版權不負任何法律責任。如果侵犯了您的隱私權益,請聯系本站郵箱yoyou2525@163.com刪除。



 
粵ICP備18138465號   © 2018-2025 CODEPRJ.COM