Utiliser ASP.NET Core avec HTTP/2 sur IIS
Remarque
Ceci n’est pas la dernière version de cet article. Pour la version actuelle, consultez la version .NET 9 de cet article.
Avertissement
Cette version d’ASP.NET Core n’est plus prise en charge. Pour plus d’informations, consultez la stratégie de support .NET et .NET Core. Pour la version actuelle, consultez la version .NET 9 de cet article.
Important
Ces informations portent sur la préversion du produit, qui est susceptible d’être en grande partie modifié avant sa commercialisation. Microsoft n’offre aucune garantie, expresse ou implicite, concernant les informations fournies ici.
Pour la version actuelle, consultez la version .NET 9 de cet article.
Par Justin Kotalik
HTTP/2 est pris en charge avec ASP.NET Core dans les scénarios de déploiement IIS suivants :
- Windows Server 2016 ou version ultérieure/Windows 10 ou version ultérieure
- IIS 10 ou version ultérieure
- TLS 1.2 ou connexion ultérieure
- Lors de l’écriture hors processus : Les connexions au serveur de périphérie public utilisent HTTP/2, mais la connexion par proxy inverse au serveur Kestrel utilise HTTP/1.1.
Pour un déploiement in-process, quand une connexion HTTP/2 est établie, HttpRequest.Protocol
signale HTTP/2
. Pour un déploiement hors processus, quand une connexion HTTP/2 est établie, HttpRequest.Protocol
signale HTTP/1.1
.
Pour plus d’informations sur les modèles d’hébergement in-process et hors processus, consultez Module ASP.NET Core (ANCM) pour IIS.
HTTP/2 est activé par défaut pour les connexions HTTPS/TLS. Les connexions reviennent à HTTP/1.1 si une connexion HTTP/2 n’est pas établie. Pour plus d’informations sur la configuration de HTTP/2 avec les déploiements IIS, consultez HTTP/2 sur IIS.
Fonctionnalités HTTP/2 avancées pour prendre en charge gRPC
Des fonctionnalités HTTP/2 supplémentaires dans IIS prennent en charge gRPC, notamment la prise en charge des bandes-annonces de réponse et l’envoi de trames de réinitialisation.
Configuration requise pour exécuter gRPC sur IIS :
- Hébergement in-process.
- Windows 11 Build 22000 ou version ultérieure, Windows Server 2022 Build 20348 ou version ultérieure.
- TLS 1.2 ou connexion ultérieure.
Bandes-annonce
Les codes de fin HTTP sont similaires aux en-têtes HTTP, sauf qu’ils sont envoyés après l’envoi du corps de la réponse. Pour IIS et HTTP.sys, seuls les codes de fin de réponse HTTP/2 sont pris en charge.
if (httpContext.Response.SupportsTrailers())
{
httpContext.Response.DeclareTrailer("trailername");
// Write body
httpContext.Response.WriteAsync("Hello world");
httpContext.Response.AppendTrailer("trailername", "TrailerValue");
}
Dans l’exemple de code précédent :
SupportsTrailers
garantit que les codes de fin sont pris en charge pour la réponse.DeclareTrailer
ajoute le nom de code de fin donné à l’en-tête de réponseTrailer
. La déclaration des codes de fin d’une réponse est facultative, mais recommandée. SiDeclareTrailer
est appelé, il doit être avant l’envoi des en-têtes de réponse.AppendTrailer
ajoute le code de fin.
Réinitialiser
La réinitialisation permet au serveur de réinitialiser une requête HTTP/2 avec un code d’erreur spécifié. Une requête de réinitialisation est considérée comme abandonnée.
var resetFeature = httpContext.Features.Get<IHttpResetFeature>();
resetFeature.Reset(errorCode: 2);
Reset
dans l’exemple de code précédent spécifie le code d’erreur INTERNAL_ERROR
. Pour plus d’informations sur les codes d’erreur HTTP/2, consultez la section du code d’erreur de spécification HTTP/2.