ASP.NET Core Architecture: Hosting, Kestrel and the Request Pipeline

How ASP.NET Core Works: From Socket to Response#

Follow a single GET /orders/42 request through the system:

1. Accept. Kestrel accepts a TCP connection, or a QUIC connection for HTTP/3. For HTTPS, the TLS handshake runs first and Application-Layer Protocol Negotiation (ALPN) picks HTTP/1.1 or HTTP/2.
2. Parse and protect. Kestrel parses the headers and enforces its limits. The defaults allow 30 seconds to receive headers, bodies up to 30,000,000 bytes (about 28.6 MB), 130 seconds of keep-alive idle time, and at least 240 bytes per second after a 5-second grace period.
3. Create the context. The server builds an HttpContext. The hosting layer creates a dependency injection scope (HttpContext.RequestServices) and starts an Activity and request metrics for observability.
4. Run early middleware. Exception handling, HSTS, HTTPS redirection and static files run in registration order, and any of them can short-circuit.
5. Route. The routing middleware matches the path and HTTP method against all endpoints and stores the winner and its route values (id = 42) on the context.
6. Apply policies. Authentication, authorization, CORS, rate limiting and output caching read the selected endpoint's metadata, such as [Authorize], and apply the matching rules.
7. Execute. The endpoint binds parameters, runs filters, calls your handler and serializes the result, usually with System.Text.Json.
8. Unwind. The response flows back through the middleware in reverse order. Once the body is flushed, HttpResponse.HasStarted is true and headers are frozen. Kestrel keeps the connection alive and disposes the request scope.

This Program.cs makes steps 4 to 8 visible:

using System.Diagnostics;

var builder = WebApplication.CreateBuilder(args);
var app = builder.Build();

// Outermost middleware: first on the way in, last on the way out.
app.Use(async (context, next) =>
{
    var start = Stopwatch.GetTimestamp();
    app.Logger.LogInformation("Before routing, endpoint: {Endpoint}",
        context.GetEndpoint()?.DisplayName ?? "(none)");

    await next(context);

    app.Logger.LogInformation("{Method} {Path} -> {Status} in {Elapsed:F1} ms",
        context.Request.Method, context.Request.Path, context.Response.StatusCode,
        Stopwatch.GetElapsedTime(start).TotalMilliseconds);
});

app.UseRouting();

// Runs after matching, so the endpoint and its metadata are available.
app.Use(async (context, next) =>
{
    app.Logger.LogInformation("After routing, endpoint: {Endpoint}",
        context.GetEndpoint()?.DisplayName ?? "(no match)");
    await next(context);
});

app.MapGet("/orders/{id:int}", (int id) =>
    TypedResults.Ok(new { Id = id, Status = "Shipped" }));

app.Run();

Request /orders/42 and read the log. The first middleware reports (none) because nothing has been matched yet, and the second reports the selected endpoint. The timing line prints last, because the outer middleware resumes only after everything downstream has finished. That nesting is the whole ASP.NET Core middleware pipeline in miniature.