Dela via

HTTP.sys webbserver-implementering i ASP.NET Core

Note

Det här är inte den senaste versionen av den här artikeln. Den aktuella versionen finns i den .NET 9-versionen av den här artikeln.

Warning

Den här versionen av ASP.NET Core stöds inte längre. Mer information finns i .NET och .NET Core Support Policy. Den aktuella versionen finns i den .NET 9-versionen av den här artikeln.

Important

Den här informationen gäller en förhandsversionsprodukt som kan ändras avsevärt innan den släpps kommersiellt. Microsoft lämnar inga garantier, uttryckliga eller underförstådda, med avseende på den information som tillhandahålls här.

Den aktuella versionen finns i den .NET 9-versionen av den här artikeln.

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.

Important

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)
  • HTTP/3 via TLS (Windows 11 eller senare)
  • Direkt filöverföring
  • Cachelagring av svar
  • WebSockets (Windows 8 eller senare)
  • Anpassningsbara säkerhetsbeskrivningar
  • Automatisk borttagning av minnespool

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.

    HTTP.sys kommunicerar direkt med Internet

  • 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 kommunicerar direkt med det interna nätverket

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:

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.

Anpassa säkerhetsbeskrivningar

En begärankö i HTTP.sys är en struktur på kernelnivå som tillfälligt lagrar inkommande HTTP-begäranden tills programmet är redo att bearbeta dem. Hantera åtkomst till begärandekön med egenskapen RequestQueueSecurityDescriptor på HttpSysOptions. Ange den till en GenericSecurityDescriptor instans när du konfigurerar din HTTP.sys-server.

Genom att anpassa säkerhetsbeskrivningen kan du tillåta eller neka specifika användare eller grupper åtkomst till begärandekön. Detta är användbart i scenarier där du vill begränsa eller delegera HTTP.sys begärandehantering på operativsystemnivå.

Följande kod tillåter till exempel alla autentiserade användare men nekar gäster:

using System.Security.AccessControl;
using System.Security.Principal;
using Microsoft.AspNetCore.Server.HttpSys;

// Create a new security descriptor
var securityDescriptor = new CommonSecurityDescriptor(isContainer: false, isDS: false, sddlForm: string.Empty);

// Create a discretionary access control list (DACL)
var dacl = new DiscretionaryAcl(isContainer: false, isDS: false, capacity: 2);
dacl.AddAccess(
    AccessControlType.Allow,
    new SecurityIdentifier(WellKnownSidType.BuiltinUsersSid, null),
    -1,
    InheritanceFlags.None,
    PropagationFlags.None
);
dacl.AddAccess(
    AccessControlType.Deny,
    new SecurityIdentifier(WellKnownSidType.BuiltinGuestsSid, null),
    -1,
    InheritanceFlags.None,
    PropagationFlags.None
);

// Assign the DACL to the security descriptor
securityDescriptor.DiscretionaryAcl = dacl;

// Configure HTTP.sys options
var builder = WebApplication.CreateBuilder();
builder.WebHost.UseHttpSys(options =>
{
    options.RequestQueueSecurityDescriptor = securityDescriptor;
});

Egenskapen RequestQueueSecurityDescriptor gäller endast när du skapar en ny begärandekö. Egenskapen påverkar inte befintliga begärandeköer.

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:

Välj konsolappprofil

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 distribution installerar du .NET, .NET Framework eller båda (om appen är en .NET-app som riktar sig mot .NET Framework).

    • .NET: Om appen kräver .NET hämtar och kör du installationsprogrammet för .NET Runtime från .NET 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 är tillgängligt från .NET-nedladdningssidan .

    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:

    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.

    Warning

    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:

  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.

    webbläsarfönster som visar appens indexsida som laddats in

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.

Trailers

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.

Reset

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.

Tracing

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

Automatisk borttagning från minnespoolen

Minnespoolerna som används av Kestrel, IIS och HTTP.sys avlägsnar automatiskt minnesblock när programmet är inaktivt eller under låg belastning. Funktionen körs automatiskt och behöver inte aktiveras eller konfigureras manuellt.

I versioner av .NET tidigare än 10 förblir det minne som allokeras av poolen reserverat, även om det inte används. Den här funktionen för automatisk borttagning minskar den totala minnesanvändningen och hjälper program att hålla sig responsiva under varierande arbetsbelastningar.

Använd mått för minnespooler

Standardminnespoolen som används av ASP.NET Core-serverimplementeringar innehåller mått som kan användas för att övervaka och analysera minnesanvändningsmönster. Mätvärdena är under beteckningen "Microsoft.AspNetCore.MemoryPool".

Information om mått och hur du använder dem finns i ASP.NET Core-mått.

Hantera minnespooler

Förutom att använda minnespooler effektivt genom att avlägsna onödiga minnesblock tillhandahåller ASP.NET Core en inbyggd IMemoryPoolFactory och en implementering. Det gör implementeringen tillgänglig för ditt program via beroendeinmatning.

I följande kodexempel visas en enkel bakgrundstjänst som använder den inbyggda implementeringen av minnespoolfabriken för att skapa minnespooler. Dessa pooler drar nytta av funktionen för automatisk borttagning:

public class MyBackgroundService : BackgroundService
{
    private readonly MemoryPool<byte> _memoryPool;

    public MyBackgroundService(IMemoryPoolFactory<byte> factory)
    {
        _memoryPool = factory.Create();
    }

    protected override async Task ExecuteAsync(CancellationToken stoppingToken)
    {
        while (!stoppingToken.IsCancellationRequested)
        {
            try
            {
                await Task.Delay(20, stoppingToken);
                // do work that needs memory
                // consider checking _memoryPool.MaxBufferSize
                var rented = _memoryPool.Rent(100);
                rented.Dispose();
            }
            catch (OperationCanceledException)
            {
                return;
            }
        }
    }
}

Om du vill använda en anpassad minnespoolfabrik skapar du en klass som implementerar IMemoryPoolFactory och registrerar den med beroendeinmatning, som i följande exempel. Minnespooler som skapats på det här sättet drar också nytta av funktionen för automatisk borttagning:

services.AddSingleton<IMemoryPoolFactory<byte>,
CustomMemoryPoolFactory>();

public class CustomMemoryPoolFactory : IMemoryPoolFactory<byte>
{
    public MemoryPool<byte> Create()
    {
        // Return a custom MemoryPool implementation
        // or the default, as is shown here.
        return MemoryPool<byte>.Shared;
    }
}

När du använder en minnespool bör du vara medveten om poolens MaxBufferSize.

Ytterligare resurser

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.

Important

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.

    HTTP.sys kommunicerar direkt med Internet

  • 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 kommunicerar direkt med det interna nätverket

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:

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.

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:

public static IHostBuilder CreateHostBuilder(string[] args) =>
    Host.CreateDefaultBuilder(args)
        .ConfigureWebHostDefaults(webBuilder =>
        {
            webBuilder.UseHttpSys(options =>
            {
                options.AllowSynchronousIO = false;
                options.Authentication.Schemes = AuthenticationSchemes.None;
                options.Authentication.AllowAnonymous = true;
                options.MaxConnections = null;
                options.MaxRequestBodySize = 30000000;
                options.UrlPrefixes.Add("http://localhost:5005");
            });
            webBuilder.UseStartup<Startup>();
        });

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:

public void Configure(IApplicationBuilder app, IWebHostEnvironment env, 
    ILogger<Startup> logger, IServer server)
{
    app.Use(async (context, next) =>
    {
        context.Features.Get<IHttpMaxRequestBodySizeFeature>()
            .MaxRequestBodySize = 10 * 1024;

        var serverAddressesFeature = 
            app.ServerFeatures.Get<IServerAddressesFeature>();
        var addresses = string.Join(", ", serverAddressesFeature?.Addresses);

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

        await next.Invoke();
    });

    if (env.IsDevelopment())
    {
        app.UseDeveloperExceptionPage();
    }
    else
    {
        app.UseExceptionHandler("/Error");
    }

    app.UseStaticFiles();
    app.UseRouting();

    app.UseEndpoints(endpoints =>
    {
        endpoints.MapRazorPages();
    });
}

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:

Välj konsolappprofil

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 distribution installerar du .NET, .NET Framework eller båda (om appen är en .NET-app som riktar sig mot .NET Framework).

    • .NET: Om appen kräver .NET hämtar och kör du installationsprogrammet för .NET Runtime från .NET 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 är tillgängligt från .NET-nedladdningssidan .

    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:

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

    public static IHostBuilder CreateHostBuilder(string[] args) =>
    Host.CreateDefaultBuilder(args)
        .ConfigureWebHostDefaults(webBuilder =>
        {
            webBuilder.UseHttpSys(options =>
            {
                options.UrlPrefixes.Add("https://10.0.0.4:443");
            });
            webBuilder.UseStartup<Startup>();
        });

    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 använder HTTP Server API UrlPrefix-strängformat.

    Warning

    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.

  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:

  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.

    webbläsarfönster som visar appens indexsida som laddats in

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.

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.

Trailers

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.

Reset

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.

Ytterligare resurser

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.

Important

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.

    HTTP.sys kommunicerar direkt med Internet

  • 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 kommunicerar direkt med det interna nätverket

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 om följande grundläggande krav uppfylls:

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.

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.

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:

public static IHostBuilder CreateHostBuilder(string[] args) =>
    Host.CreateDefaultBuilder(args)
        .ConfigureWebHostDefaults(webBuilder =>
        {
            webBuilder.UseHttpSys(options =>
            {
                options.AllowSynchronousIO = false;
                options.Authentication.Schemes = AuthenticationSchemes.None;
                options.Authentication.AllowAnonymous = true;
                options.MaxConnections = null;
                options.MaxRequestBodySize = 30000000;
                options.UrlPrefixes.Add("http://localhost:5005");
            });
            webBuilder.UseStartup<Startup>();
        });

Ytterligare HTTP.sys konfiguration hanteras via registerinställningar.

HTTP.sys alternativ

Property Description Default
AllowSynchronousIO Kontrollera om synkrona indata/utdata tillåts för HttpContext.Request.Body och HttpContext.Response.Body. false
Authentication.AllowAnonymous Tillåt anonyma begäranden. true
Authentication.Schemes Ange de tillåtna autentiseringsschemana. Kan ändras när som helst innan lyssnaren tas bort. Värden tillhandahålls av AuthenticationSchemes-enum: Basic, Kerberos, Negotiate, Noneoch NTLM. None
EnableResponseCaching Försök använda cachehantering i kärnläge för svar med kvalificerade rubriker. Svaret kanske inte innehåller Set-Cookie, Varyeller Pragma rubriker. Den måste innehålla ett Cache-Control-huvud som är public och antingen ett shared-max-age- eller max-age-värde eller ett Expires-huvud. true
Http503Verbosity Det HTTP.sys beteendet när begäranden avvisas på grund av begränsningsvillkor. Http503VerbosityLevel.
Grundläggande
MaxAccepts Det maximala antalet samtidiga accepter. 5 × Miljö.
AntalProcessorer
MaxConnections Det maximala antalet samtidiga anslutningar som ska accepteras. Använd -1 för oändligt. Använd null för att använda registrets datoromfattande inställning. null
(machine-wide
setting)
MaxRequestBodySize Se avsnittet MaxRequestBodySize. 30000000 byte
(~28,6 MB)
RequestQueueLimit Det maximala antalet begäranden som kan placeras i kö. 1000
RequestQueueMode Detta anger om servern ansvarar för att skapa och konfigurera begärandekön eller om den ska ansluta till en befintlig kö.
De flesta befintliga konfigurationsalternativ gäller inte när du ansluter till en befintlig kö.		 RequestQueueMode.Create
RequestQueueName Namnet på HTTP.sys begärandekön. null (anonym kö)
ThrowWriteExceptions Ange om svarstextskrivningar som misslyckas på grund av klientfrånkopplingar ska utlösa undantag eller slutföras normalt. false
(fullständigt normalt)
Timeouts Exponera HTTP.sys TimeoutManager konfigurationen, som också kan konfigureras i registret. Följ API-länkarna om du vill veta mer om varje inställning, inklusive standardvärden:
UrlPrefixes Ange UrlPrefixCollection för registrering med HTTP.sys. Det mest användbara är UrlPrefixCollection.Add, som används för att lägga till ett prefix i samlingen. Dessa kan ändras när som helst innan lyssnaren tas bort.

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:

public void Configure(IApplicationBuilder app, IWebHostEnvironment env, 
    ILogger<Startup> logger, IServer server)
{
    app.Use(async (context, next) =>
    {
        context.Features.Get<IHttpMaxRequestBodySizeFeature>()
            .MaxRequestBodySize = 10 * 1024;

        var serverAddressesFeature = 
            app.ServerFeatures.Get<IServerAddressesFeature>();
        var addresses = string.Join(", ", serverAddressesFeature?.Addresses);

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

        await next.Invoke();
    });

    if (env.IsDevelopment())
    {
        app.UseDeveloperExceptionPage();
    }
    else
    {
        app.UseExceptionHandler("/Error");
    }

    app.UseStaticFiles();
    app.UseRouting();

    app.UseEndpoints(endpoints =>
    {
        endpoints.MapRazorPages();
    });
}

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:

Välj konsolappprofil

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 distribution installerar du .NET, .NET Framework eller båda (om appen är en .NET-app som riktar sig mot .NET Framework).

    • .NET: Om appen kräver .NET hämtar och kör du installationsprogrammet för .NET Runtime från .NET 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 är tillgängligt från .NET-nedladdningssidan .

    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:

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

    public static IHostBuilder CreateHostBuilder(string[] args) =>
    Host.CreateDefaultBuilder(args)
        .ConfigureWebHostDefaults(webBuilder =>
        {
            webBuilder.UseHttpSys(options =>
            {
                options.UrlPrefixes.Add("https://10.0.0.4:443");
            });
            webBuilder.UseStartup<Startup>();
        });

    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 använder HTTP Server API UrlPrefix-strängformat.

    Warning

    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.

  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:

  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.

    webbläsarfönster som visar appens indexsida som laddats in

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.

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 10, OS Build 19041.508 eller senare
  • TLS 1.2 eller senare anslutning

Trailers

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.

Reset

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.

Ytterligare resurser

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.

Important

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)
  • HTTP/3 via TLS (Windows 11 eller senare)
  • Direkt filöverföring
  • Cachelagring av svar
  • WebSockets (Windows 8 eller senare)
  • Anpassningsbara säkerhetsbeskrivningar

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.

    HTTP.sys kommunicerar direkt med Internet

  • 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 kommunicerar direkt med det interna nätverket

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:

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:

Välj konsolappprofil

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 distribution installerar du .NET, .NET Framework eller båda (om appen är en .NET-app som riktar sig mot .NET Framework).

    • .NET: Om appen kräver .NET hämtar och kör du installationsprogrammet för .NET Runtime från .NET 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 är tillgängligt från .NET-nedladdningssidan .

    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:

    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.

    Warning

    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:

  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.

    webbläsarfönster som visar appens indexsida som laddats in

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.

Trailers

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.

Reset

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.

Tracing

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

Ytterligare resurser