HTTP.sys webbserver-implementering i ASP.NET Core

Av Tom Dykstra och Chris Ross

HTTP.sys är en webbserver för ASP.NET Core som endast körs i Windows. HTTP.sys är ett alternativ till Kestrel server och erbjuder vissa funktioner som Kestrel inte tillhandahåller.

Viktig

HTTP.sys är inte kompatibelt med ASP.NET Core-modulen och kan inte användas med IIS eller IIS Express.

HTTP.sys stöder följande funktioner:

• Windows-autentisering
• Portdelning
• HTTPS med SNI
• HTTP/2 via TLS (Windows 10 eller senare)
• Direkt filöverföring
• Cachelagring av svar
• WebSockets (Windows 8 eller senare)

Windows-versioner som stöds:

• Windows 7 eller senare
• Windows Server 2008 R2 eller senare

Visa eller ladda ned exempelkod (hur du laddar ned)

När du ska använda HTTP.sys

HTTP.sys är användbart för distributioner där:

• Det finns ett behov av att exponera servern direkt för Internet utan att använda IIS.

  

• En intern distribution kräver att en funktion inte är tillgänglig i Kestrel. Mer information finns i Kestrel jämfört med HTTP.sys

  

HTTP.sys är en mogen teknik som skyddar mot många typer av attacker och ger robusthet, säkerhet och skalbarhet för en webbserver med fullständiga funktioner. Själva IIS körs som en HTTP-lyssnare ovanpå HTTP.sys.

HTTP/2-stöd

HTTP/2- är aktiverat för ASP.NET Core-appar när följande grundläggande krav uppfylls:

• Windows Server 2016/Windows 10 eller senare
• Application-Layer Protocol Negotiation (ALPN) anslutning
• TLS 1.2 eller senare anslutning

Om en HTTP/2-anslutning upprättas rapporterar HttpRequest.ProtocolHTTP/2.

HTTP/2 är aktiverat som standard. Om en HTTP/2-anslutning inte har upprättats återgår anslutningen till HTTP/1.1. I en framtida version av Windows kommer HTTP/2-konfigurationsflaggor att vara tillgängliga, inklusive möjligheten att inaktivera HTTP/2 med HTTP.sys.

HTTP/3-stöd

HTTP/3 är aktiverat för ASP.NET Core-appar när följande grundläggande krav uppfylls:

• Windows Server 2022/Windows 11 eller senare
• En https url-bindning används.
• Registernyckeln EnableHttp3 har angetts.

Tidigare versioner av Windows 11 Build kan kräva användning av en Windows Insider build.

HTTP/3 identifieras som en uppgradering från HTTP/1.1 eller HTTP/2 via alt-svc-huvudet. Det innebär att den första begäran normalt använder HTTP/1.1 eller HTTP/2 innan den växlar till HTTP/3. Http.Sys lägger inte automatiskt till alt-svc-huvudet. Det måste läggas till av programmet. Följande kod är ett mellanprogramsexempel som lägger till alt-svc-svarsrubriken.

app.Use((context, next) =>
{
    context.Response.Headers.AltSvc = "h3=\":443\"";
    return next(context);
});

Placera föregående kod tidigt i pipelinen för begäran.

Http.Sys har också stöd för att skicka ett AltSvc HTTP/2-protokollmeddelande i stället för ett svarshuvud för att meddela klienten att HTTP/3 är tillgängligt. Se registernyckeln EnableAltSvc. Detta kräver netsh sslcert-bindningar som använder värdnamn i stället för IP-adresser.

Autentisering i kernelläge med Kerberos

HTTP.sys delegerar till kernellägesautentisering med Kerberos-autentiseringsprotokollet. Autentisering i användarläge stöds inte med Kerberos och HTTP.sys. Datorkontot måste användas för att dekryptera Kerberos-token/-biljetten som hämtas från Active Directory och vidarebefordras av klienten till servern för att autentisera användaren. Registrera tjänstens huvudnamn (SPN) för värden, inte appens användare.

Stöd för buffring av svar i kärnläge

I vissa scenarier kan stora mängder små skrivningar med hög svarstid orsaka betydande prestandapåverkan för HTTP.sys. Den här effekten beror på att det inte finns någon Pipe buffert i HTTP.sys implementeringen. För att förbättra prestanda i dessa scenarier ingår stöd för svarsbuffertning i HTTP.sys. Aktivera buffring genom att ange HttpSysOptions.EnableKernelResponseBuffering till true.

Svarsbuffertning ska aktiveras av en app som utför synkron I/O eller asynkron I/O med högst en utestående skrivning i taget. I dessa scenarier kan svarsbuffertning avsevärt förbättra dataflödet över anslutningar med långa svarstider.

Appar som använder asynkron I/O och som kan ha mer än en skrivoperation samtidigt bör inte använda den här flaggan. Om du aktiverar den här flaggan kan det leda till högre processor- och minnesanvändning av HTTP.Sys.

Så här använder du HTTP.sys

Konfigurera ASP.NET Core-appen så att den använder HTTP.sys

Anropa UseHttpSys-tilläggsmetoden när du bygger värden och specificera alla nödvändiga HttpSysOptions. I följande exempel anges alternativ till deras standardvärden:

using Microsoft.AspNetCore.Hosting.Server;
using Microsoft.AspNetCore.Hosting.Server.Features;
using Microsoft.AspNetCore.Http.Features;
using Microsoft.AspNetCore.Server.HttpSys;

var builder = WebApplication.CreateBuilder(args);

builder.WebHost.UseHttpSys(options =>
{
    options.AllowSynchronousIO = false;
    options.Authentication.Schemes = AuthenticationSchemes.None;
    options.Authentication.AllowAnonymous = true;
    options.MaxConnections = null;
    options.MaxRequestBodySize = 30_000_000;
    options.UrlPrefixes.Add("http://localhost:5005");
});

builder.Services.AddRazorPages();

var app = builder.Build();

Ytterligare HTTP.sys konfiguration hanteras via registerinställningar.

Mer information om HTTP.sys-alternativen hittar du i HttpSysOptions.

MaxRequestBodySize

Den maximala tillåtna storleken för alla begärandetexter i byte. När värdet är nullär den maximala storleken på begärandetexten obegränsad. Den här gränsen påverkar inte uppgraderade anslutningar, som alltid är obegränsade.

Den rekommenderade metoden för att åsidosätta gränsen i en ASP.NET Core MVC-app för en enda IActionResult är att använda attributet RequestSizeLimitAttribute för en åtgärdsmetod:

[RequestSizeLimit(100000000)]
public IActionResult MyActionMethod()

Ett undantag utlöses om appen försöker konfigurera gränsen för en begäran när appen har börjat läsa begäran. En IsReadOnly-egenskap kan användas för att indikera om MaxRequestBodySize-egenskapen är i ett skrivskyddat läge, vilket betyder att det är för sent att konfigurera gränsen.

Om appen ska åsidosätta MaxRequestBodySize för varje begäran använder du IHttpMaxRequestBodySizeFeature:

app.Use((context, next) =>
{
    context.Features.GetRequiredFeature<IHttpMaxRequestBodySizeFeature>()
                                             .MaxRequestBodySize = 10 * 1024;

    var server = context.RequestServices
        .GetRequiredService<IServer>();
    var serverAddressesFeature = server.Features
                                 .GetRequiredFeature<IServerAddressesFeature>();

    var addresses = string.Join(", ", serverAddressesFeature.Addresses);

    var loggerFactory = context.RequestServices
        .GetRequiredService<ILoggerFactory>();
    var logger = loggerFactory.CreateLogger("Sample");

    logger.LogInformation("Addresses: {addresses}", addresses);

    return next(context);
});

Om du använder Visual Studio kontrollerar du att appen inte är konfigurerad för att köra IIS eller IIS Express.

I Visual Studio är standardstartprofilen för IIS Express. Om du vill köra projektet som en konsolapp ändrar du den valda profilen manuellt, enligt följande skärmbild:

Konfigurera Windows Server

1. Fastställa vilka portar som ska öppnas för appen och använd Windows-brandväggen eller New-NetFirewallRule PowerShell-cmdlet för att öppna brandväggsportar så att trafik kan nå HTTP.sys. I följande kommandon och appkonfiguration används port 443.

2. När du distribuerar till en virtuell Azure-dator öppnar du portarna i Nätverkssäkerhetsgrupp. I följande kommandon och appkonfiguration används port 443.

3. Hämta och installera X.509-certifikat om det behövs.

   I Windows skapar du självsignerade certifikat med hjälp av New-SelfSignedCertificate PowerShell-cmdleten. Ett exempel som inte stöds finns i UpdateIISExpressSSLForChrome.ps1.

   Installera antingen självsignerade eller CA-signerade certifikat i serverns local machine>Personal store.

4. Om appen är en ramverksberoende distributioninstallerar du .NET Core, .NET Framework eller båda (om appen är en .NET Core-app som riktar sig mot .NET Framework).

   • .NET Core: Om appen kräver .NET Core hämtar och kör du installationsprogrammet .NET Core Runtime från .NET Core Downloads. Installera inte hela SDK:t på servern.
   • .NET Framework: Om appen kräver .NET Framework kan du läsa installationsguiden för .NET Framework. Installera det nödvändiga .NET Framework. Installationsprogrammet för det senaste .NET Framework finns på sidan .NET Core Downloads.

   Om appen är en fristående distributioninkluderar appen körmiljön i sin distribution. Ingen ramverksinstallation krävs på servern.

5. Konfigurera URL:er och portar i appen.

   Som standard binder ASP.NET Core till http://localhost:5000. Om du vill konfigurera URL-prefix och portar inkluderar alternativen:

   • UseUrls
   • urls kommandoradsargument
   • ASPNETCORE_URLS miljövariabel
   • UrlPrefixes

   Följande kodexempel visar hur du använder UrlPrefixes med serverns lokala IP-adress 10.0.0.4 på port 443:

   var builder = WebApplication.CreateBuilder(args);
   
   builder.WebHost.UseHttpSys(options =>
   {
       options.UrlPrefixes.Add("https://10.0.0.4:443");
   });
   
   builder.Services.AddRazorPages();
   
   var app = builder.Build();
   

   En fördel med UrlPrefixes är att ett felmeddelande genereras omedelbart för felaktigt formaterade prefix.

   Inställningarna i UrlPrefixes åsidosätter inställningarna i UseUrls/urls/ASPNETCORE_URLS. Därför är en fördel med UseUrls, urlsoch ASPNETCORE_URLS miljövariabeln att det är enklare att växla mellan Kestrel och HTTP.sys.

   HTTP.sys identifierar två typer av jokertecken i URL-prefix:

   • * är en svag bindning, även kallad en reservbindning. Om URL-prefixet är http://*:5000och något annat är bundet till port 5000 används inte den här bindningen.
   • + är en stark bindning. Om URL-prefixet är http://+:5000används den här bindningen före andra port 5000-bindningar.

   Mer information finns i UrlPrefix Strings.

   Varning

   Jokerteckenbindningar på toppnivå (http://*:80/ och http://+:80) bör inte användas. Jokerteckenbindningar på toppnivå skapar sårbarheter för appsäkerhet. Detta gäller både starka och svaga jokertecken. Använd explicita värdnamn eller IP-adresser i stället för jokertecken. Jokerteckenbindning för underdomäner (till exempel *.mysub.com) är inte en säkerhetsrisk om du kontrollerar hela den överordnade domänen (till skillnad från *.com, som är sårbar). Mer information finns i RFC 9110: Avsnitt 7.2: Värd och :utfärdare.

   Appar och containrar får ofta bara en port att lyssna på, till exempel port 80, utan ytterligare begränsningar som värd eller sökväg. HTTP_PORTS och HTTPS_PORTS är konfigurationsnycklar som anger lyssnarportarna för servrarna Kestrel och HTTP.sys. Dessa nycklar kan anges som miljövariabler som definieras med prefixen DOTNET_ eller ASPNETCORE_ eller anges direkt via andra konfigurationsindata, till exempel appsettings.json. Var och en är en semikolonavgränsad lista med portvärden, som du ser i följande exempel:

   ASPNETCORE_HTTP_PORTS=80;8080
   ASPNETCORE_HTTPS_PORTS=443;8081
   

   Föregående exempel är en förkortning för följande konfiguration, som anger schemat (HTTP eller HTTPS) och valfri värd eller IP-adress.

   ASPNETCORE_URLS=http://*:80/;http://*:8080/;https://*:443/;https://*:8081/
   

   Konfigurationsnycklarna HTTP_PORTS och HTTPS_PORTS har lägre prioritet och åsidosättas av URL:er eller värden som anges direkt i koden. Certifikat måste fortfarande konfigureras separat via serverspecifik mekanik för HTTPS.

   Dessa konfigurationsnycklar motsvarar jokerteckenbindningar på toppnivå. De är praktiska för utvecklings- och containerscenarier, men undvik jokertecken när de körs på en dator som också kan vara värd för andra tjänster.

6. Förregistrera URL-prefix på servern.

   Det inbyggda verktyget för att konfigurera HTTP.sys är netsh.exe. netsh.exe används för att reservera URL-prefix och tilldela X.509-certifikat. Verktyget kräver administratörsbehörighet.

   Använd verktyget netsh.exe för att registrera URL:er för appen:

   netsh http add urlacl url=<URL> user=<USER>
   

   • <URL>: Den fullständigt kvalificerade uniformsresurslokaliseraren (URL). Använd inte en jokerteckenbindning. Använd ett giltigt värdnamn eller en lokal IP-adress. URL:en måste innehålla ett avslutande snedstreck.
   • <USER>: Anger användarens eller användargruppens namn.

   I följande exempel är serverns lokala IP-adress 10.0.0.4:

   netsh http add urlacl url=https://10.0.0.4:443/ user=Users
   

   När en URL registreras svarar verktyget med URL reservation successfully added.

   Om du vill ta bort en registrerad URL använder du kommandot delete urlacl:

   netsh http delete urlacl url=<URL>
   

7. Registrera X.509-certifikat på servern.

   Använd verktyget netsh.exe för att registrera certifikat för appen:

   netsh http add sslcert ipport=<IP>:<PORT> certhash=<THUMBPRINT> appid="{<GUID>}"
   

   • <IP>: Anger den lokala IP-adressen för bindningen. Använd inte en jokerteckenbindning. Använd en giltig IP-adress.
   • <PORT>: Anger porten för bindningen.
   • <THUMBPRINT>: X.509-certifikatets tumavtryck.
   • <GUID>: Ett utvecklargenererat GUID som representerar appen i informationssyfte.

   I referenssyfte lagrar du GUID i appen som en pakettagg:

   • I Visual Studio:
     • Öppna appens projektegenskaper genom att högerklicka på appen i Solution Explorer och välja Egenskaper.
     • Välj fliken Paket.
     • Ange GUID:et som du skapade i fältet Taggar.
   • När du inte använder Visual Studio:

     • Öppna appens projektfil.

     • Lägg till en <PackageTags>-egenskap i en ny eller befintlig <PropertyGroup> med det GUID som du skapade:

       <PropertyGroup>
         <PackageTags>00001111-aaaa-2222-bbbb-3333cccc4444</PackageTags>
       </PropertyGroup>
       

   I följande exempel:

   • Serverns lokala IP-adress är 10.0.0.4.
   • En slumpmässig GUID-generator online ger värdet appid.

   netsh http add sslcert 
       ipport=10.0.0.4:443 
       certhash=b66ee04419d4ee37464ab8785ff02449980eae10 
       appid="{00001111-aaaa-2222-bbbb-3333cccc4444}"
   

   När ett certifikat har registrerats svarar verktyget med SSL Certificate successfully added.

   Om du vill ta bort en certifikatregistrering använder du kommandot delete sslcert:

   netsh http delete sslcert ipport=<IP>:<PORT>
   

   Referensdokumentation för netsh.exe:

   • Netsh-kommandon för HTTP(Hypertext Transfer Protocol)
   • URL-prefixsträngar

8. Kör appen.

   Administratörsbehörigheter krävs inte för att köra appen vid bindning till localhost med HTTP (inte HTTPS) med ett portnummer större än 1024. För andra konfigurationer (till exempel med hjälp av en lokal IP-adress eller bindning till port 443) kör du appen med administratörsbehörighet.

   Appen svarar på serverns offentliga IP-adress. I det här exemplet nås servern från Internet på dess offentliga IP-adress 104.214.79.47.

   Ett utvecklingscertifikat används i det här exemplet. Sidan laddas säkert efter att ha kringgått webbläsarens varning om ett ej betrott certifikat.

   

Scenarier för proxyserver och lastbalanserare

För appar som hanteras av HTTP.sys som interagerar med begäranden från Internet eller ett företagsnätverk kan ytterligare konfiguration krävas när du är värd för proxyservrar och lastbalanserare. Mer information finns i Konfigurera ASP.NET Core att fungera med proxyservrar och lastbalanserare.

Få detaljerad tidsinformation med IHttpSysRequestTimingFeature

IHttpSysRequestTimingFeature innehåller detaljerad tidsinformation för begäranden:

• Tidsstämplar hämtas med hjälp av QueryPerformanceCounter.
• Tidsstämpelfrekvensen kan hämtas via QueryPerformanceFrequency.
• Indexet för tidsinställningen kan överföras till HttpSysRequestTimingType för att veta vad tidpunkten representerar.
• Värdet kan vara 0 om tidpunkten inte är tillgänglig för den aktuella begäran.
• Kräver Windows 10 version 2004, Windows Server 2022 eller senare.

using Microsoft.AspNetCore.Http.Features;
using Microsoft.AspNetCore.Server.HttpSys;

var builder = WebApplication.CreateBuilder(args);

builder.WebHost.UseHttpSys();

var app = builder.Build();

app.Use((context, next) =>
{
    var feature = context.Features.GetRequiredFeature<IHttpSysRequestTimingFeature>();
    
    var loggerFactory = context.RequestServices.GetRequiredService<ILoggerFactory>();
    var logger = loggerFactory.CreateLogger("Sample");

    var timestamps = feature.Timestamps;

    for (var i = 0; i < timestamps.Length; i++)
    {
        var timestamp = timestamps[i];
        var timingType = (HttpSysRequestTimingType)i;

        logger.LogInformation("Timestamp {timingType}: {timestamp}",
                                          timingType, timestamp);
    }

    return next(context);
});

app.MapGet("/", () => Results.Ok());

app.Run();

IHttpSysRequestTimingFeature.TryGetTimestamp hämtar tidsstämpeln för den angivna tidstypen:

using Microsoft.AspNetCore.Http.Features;
using Microsoft.AspNetCore.Server.HttpSys;
var builder = WebApplication.CreateBuilder(args);

builder.WebHost.UseHttpSys();

var app = builder.Build();

app.Use((context, next) =>
{
    var feature = context.Features.GetRequiredFeature<IHttpSysRequestTimingFeature>();

    var loggerFactory = context.RequestServices.GetRequiredService<ILoggerFactory>();
    var logger = loggerFactory.CreateLogger("Sample");

    var timingType = HttpSysRequestTimingType.RequestRoutingEnd;

    if (feature.TryGetTimestamp(timingType, out var timestamp))
    {
        logger.LogInformation("Timestamp {timingType}: {timestamp}",
                                          timingType, timestamp);
    }
    else
    {
        logger.LogInformation("Timestamp {timingType}: not available for the "
                                           + "current request",    timingType);
    }

    return next(context);
});

app.MapGet("/", () => Results.Ok());

app.Run();

[IHttpSysRequestTimingFeature.TryGetElapsedTime](/dotnet/api/microsoft.aspnetcore.server.httpsys.ihttpsysrequesttimingfeature.trygetelapsedtime ger den förflutna tiden mellan två angivna tidpunkter:

using Microsoft.AspNetCore.Http.Features;
using Microsoft.AspNetCore.Server.HttpSys;

var builder = WebApplication.CreateBuilder(args);

builder.WebHost.UseHttpSys();

var app = builder.Build();

app.Use((context, next) =>
{
    var feature = context.Features.GetRequiredFeature<IHttpSysRequestTimingFeature>();

    var loggerFactory = context.RequestServices.GetRequiredService<ILoggerFactory>();
    var logger = loggerFactory.CreateLogger("Sample");

    var startingTimingType = HttpSysRequestTimingType.RequestRoutingStart;
    var endingTimingType = HttpSysRequestTimingType.RequestRoutingEnd;

    if (feature.TryGetElapsedTime(startingTimingType, endingTimingType, out var elapsed))
    {
        logger.LogInformation(
            "Elapsed time {startingTimingType} to {endingTimingType}: {elapsed}",
            startingTimingType,
            endingTimingType,
            elapsed);
    }
    else
    {
        logger.LogInformation(
            "Elapsed time {startingTimingType} to {endingTimingType}:"
            + " not available for the current request.",
            startingTimingType,
            endingTimingType);
    }

    return next(context);
});

app.MapGet("/", () => Results.Ok());

app.Run();

Avancerade HTTP/2-funktioner för att stödja gRPC

Ytterligare HTTP/2-funktioner i HTTP.sys stöder gRPC, inklusive stöd för svarstrailer och sändning av återställningsramar.

Krav för att köra gRPC med HTTP.sys:

• Windows 11 Build 22000 eller senare, Windows Server 2022 Build 20348 eller senare.
• TLS 1.2 eller senare anslutning.

Släp

HTTP-trailers liknar HTTP-huvuden, förutom att de skickas efter att svarstexten har skickats. För IIS och HTTP.sysstöds endast HTTP/2-svarstrailer.

if (httpContext.Response.SupportsTrailers())
{
    httpContext.Response.DeclareTrailer("trailername");	

    // Write body
    httpContext.Response.WriteAsync("Hello world");

    httpContext.Response.AppendTrailer("trailername", "TrailerValue");
}

I föregående exempelkod:

• SupportsTrailers ser till att släpvagnar stöds för svaret.
• DeclareTrailer lägger till det angivna trailernamnet i Trailer-svarsrubriken. Att deklarera ett svars släpvagnar är valfritt, men rekommenderas. Om DeclareTrailer anropas måste det vara innan svarsrubrikerna skickas.
• AppendTrailer lägger till släpfilen.

Återställ

Med återställning kan servern återställa en HTTP/2-begäran med en angiven felkod. En återställningsbegäran anses avbruten.

var resetFeature = httpContext.Features.Get<IHttpResetFeature>();
resetFeature.Reset(errorCode: 2);

Reset i föregående kodexempel anger INTERNAL_ERROR felkod. Mer information om HTTP/2-felkoder finns i avsnittet HTTP/2-specifikationsfelkod.

Spårning

Information om hur du hämtar spårningar från HTTP.sysfinns i HTTP.sys Hanterbarhetsscenarier.

Ytterligare resurser

• Aktivera Windows-autentisering med HTTP.sys
• HTTP Server API-
• aspnet/HttpSysServer GitHub-lagringsplats (källkod)
• Värdens
• Felsök och avbugga ASP.NET Core-projekt