Partager via


Utiliser HTTP/3 avec le serveur web ASP.NET Core Kestrel

Note

Ceci n’est pas la dernière version de cet article. Pour la version actuelle, consultez la version .NET 8 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 prise en charge de .NET et .NET Core. Pour la version actuelle, consultez la version .NET 8 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 8 de cet article.

HTTP/3 est une norme approuvée et la troisième version majeure du protocole HTTP. Cet article présente la configuration requise pour HTTP/3. HTTP/3 est pleinement pris en charge dans ASP.NET Core 7.0 et versions ultérieures.

Important

Les applications configurées pour tirer parti de HTTP/3 doivent être conçues pour prendre également en charge HTTP/1.1 et HTTP/2.

Configuration requise pour HTTP/3

La configuration requise pour HTTP/3 dépend du système d’exploitation. Si la plateforme sur laquelle s’exécute Kestrel ne présente pas toute la configuration requise pour HTTP/3, celui-ci est désactivé et Kestrel bascule vers d’autres protocoles HTTP.

Windows

  • Windows 11 build 22000 ou version ultérieure OU Windows Server 2022.
  • TLS 1.3 ou connexion ultérieure.

Linux

  • Package libmsquic installé.

libmsquic est publié via le référentiel officiel de packages Linux de Microsoft à l’adresse packages.microsoft.com. Pour installer ce package :

  1. Ajoutez le référentiel packages.microsoft.com. Consultez Référentiel logiciel Linux pour les produits Microsoft pour obtenir des instructions.
  2. Installez le package libmsquic à l’aide du gestionnaire de package de la distribution. Par exemple, apt install libmsquic=1.9* sur Ubuntu.

Remarque : .NET 6 est compatible uniquement avec les versions 1.9.x de libmsquic. Libmsquic 2.x n’est pas compatible en raison de changements cassants. Libmsquic reçoit des mises à jour pour 1.9.x quand il est nécessaire d’intégrer des correctifs de sécurité.

macOS

HTTP/3 n’est actuellement pas pris en charge sur macOS et sera peut-être disponible dans une version ultérieure.

Prise en main

HTTP/3 n’est pas activé par défaut. Ajoutez la configuration à Program.cs pour activer HTTP/3.

var builder = WebApplication.CreateBuilder(args);

builder.WebHost.ConfigureKestrel((context, options) =>
{
    options.ListenAnyIP(5001, listenOptions =>
    {
        listenOptions.Protocols = HttpProtocols.Http1AndHttp2AndHttp3;
        listenOptions.UseHttps();
    });
});

Le code précédent configure le port 5001 pour :

  • Utiliser HTTP/3 avec HTTP/1.1 et HTTP/2 en spécifiant HttpProtocols.Http1AndHttp2AndHttp3.
  • Activer HTTPS avec UseHttps. HTTP/3 nécessite HTTPS.

Comme tous les routeurs, pare-feu et proxys prennent correctement en charge HTTP/3, ce dernier doit être configuré avec HTTP/1.1 et HTTP/2. Pour ce faire, spécifiez HttpProtocols.Http1AndHttp2AndHttp3 en tant que protocoles pris en charge par un point de terminaison.

Pour plus d’informations, consultez Configurer des points de terminaison pour le serveur web ASP.NET Core Kestrel.

Alt-svc

HTTP/3 est découvert comme une mise à niveau à partir de HTTP/1.1 ou HTTP/2 via l’en-tête alt-svc. Cela signifie que la première requête utilise normalement HTTP/1.1 ou HTTP/2 avant de passer à HTTP/3. Kestrel ajoute automatiquement l’en-tête alt-svc si HTTP/3 est activé.

Test localhost

  • Les navigateurs n’autorisent pas les certificats auto-signés sur HTTP/3, tels que le certificat de développement Kestrel.

  • HttpClient peut être utilisé pour le test localhost/bouclage dans .NET 6 ou version ultérieure. Une configuration supplémentaire est requise lors de l’utilisation de HttpClient pour effectuer une requête HTTP/3 :

Avantages de HTTP/3

HTTP/3 utilise la même sémantique que HTTP/1.1 et HTTP/2 : les mêmes méthodes de requête, codes d’état et champs de message s’appliquent à toutes les versions. Les différences se trouvent dans le transport sous-jacent. HTTP/1.1 et HTTP/2 utilisent TCP comme transport. HTTP/3 utilise une nouvelle technologie de transport développée avec HTTP/3 appelé QUIC.

HTTP/3 et QUIC présentent un certain nombre d’avantages par rapport à HTTP/1.1 et HTTP/2 :

  • Temps de réponse plus rapide de la première requête. QUIC et HTTP/3 négocient la connexion avec moins d’allers-retours entre le client et le serveur. La première requête atteint le serveur plus rapidement.
  • Amélioration de l’expérience en cas de perte de paquets de connexion. HTTP/2 multiplexe plusieurs requêtes via une connexion TCP. La perte de paquets sur la connexion affecte toutes les requêtes. Ce problème est appelé « blocage en tête de ligne ». Étant donné que QUIC fournit un multiplexage natif, les paquets perdus affectent uniquement les requêtes dans lesquelles des données ont été perdues.
  • Prend en charge la transition entre les réseaux. Cette fonctionnalité est utile pour les appareils mobiles qui passent couramment entre le WIFI et les réseaux cellulaires lors des déplacements de leur utilisateur. Actuellement, les connexions HTTP/1.1 et HTTP/2 échouent avec une erreur lors du basculement de réseaux. Une application ou un navigateur web doit retenter les requêtes HTTP ayant échoué. HTTP/3 permet à l’application ou au navigateur web de continuer à fonctionner de manière transparente en cas de changements de réseau. Kestrel ne prend pas en charge les transitions réseau dans .NET 8. Il peut être disponible dans une prochaine version.

HTTP/3 est une norme proposée et la troisième version majeure du protocole HTTP. Cet article décrit la configuration requise pour HTTP/3. HTTP/3 est pleinement pris en charge dans ASP.NET Core 7.0 et versions ultérieures.

Important

Les applications configurées pour tirer parti de HTTP/3 doivent être conçues pour prendre également en charge HTTP/1.1 et HTTP/2.

Configuration requise pour HTTP/3

La configuration requise pour HTTP/3 dépend du système d’exploitation. Si la plateforme sur laquelle Kestrel s’exécute ne présente pas toute la configuration requise pour HTTP/3, celui-ci est désactivé et Kestrel bascule vers d’autres protocoles HTTP.

Windows

  • Windows 11 build 22000 ou version ultérieure OU Windows Server 2022.
  • TLS 1.3 ou connexion ultérieure.

Linux

  • Package libmsquic installé.

libmsquic est publié via le référentiel officiel de packages Linux de Microsoft à l’adresse packages.microsoft.com. Pour installer ce package :

  1. Ajoutez le référentiel packages.microsoft.com. Consultez Référentiel logiciel Linux pour les produits Microsoft pour obtenir des instructions.
  2. Installez le package libmsquic à l’aide du gestionnaire de package de la distribution. Par exemple, apt install libmsquic=1.9* sur Ubuntu.

Remarque : .NET 6 est compatible uniquement avec les versions 1.9.x de libmsquic. Libmsquic 2.x n’est pas compatible en raison de changements cassants. Libmsquic reçoit des mises à jour pour 1.9.x quand il est nécessaire d’intégrer des correctifs de sécurité.

macOS

HTTP/3 n’est actuellement pas pris en charge sur macOS et sera peut-être disponible dans une version ultérieure.

Prise en main

HTTP/3 n’est pas activé par défaut. Ajoutez la configuration à Program.cs pour activer HTTP/3.

var builder = WebApplication.CreateBuilder(args);

builder.WebHost.ConfigureKestrel((context, options) =>
{
    options.ListenAnyIP(5001, listenOptions =>
    {
        listenOptions.Protocols = HttpProtocols.Http1AndHttp2AndHttp3;
        listenOptions.UseHttps();
    });
});

Le code précédent configure le port 5001 pour :

  • Utiliser HTTP/3 avec HTTP/1.1 et HTTP/2 en spécifiant HttpProtocols.Http1AndHttp2AndHttp3.
  • Activer HTTPS avec UseHttps. HTTP/3 nécessite HTTPS.

Comme tous les routeurs, pare-feu et proxys prennent correctement en charge HTTP/3, ce dernier doit être configuré avec HTTP/1.1 et HTTP/2. Pour ce faire, spécifiez HttpProtocols.Http1AndHttp2AndHttp3 en tant que protocoles pris en charge par un point de terminaison.

Pour plus d’informations, consultez Configurer des points de terminaison pour le serveur web ASP.NET Core Kestrel.

Alt-svc

HTTP/3 est découvert comme une mise à niveau à partir de HTTP/1.1 ou HTTP/2 via l’en-tête alt-svc. Cela signifie que la première requête utilise normalement HTTP/1.1 ou HTTP/2 avant de passer à HTTP/3. Kestrel ajoute automatiquement l’en-tête alt-svc si HTTP/3 est activé.

Test localhost

  • Les navigateurs n’autorisent pas les certificats auto-signés sur HTTP/3, tels que le certificat de développement Kestrel.

  • HttpClient peut être utilisé pour le test localhost/bouclage dans .NET 6 ou version ultérieure. Une configuration supplémentaire est requise lors de l’utilisation de HttpClient pour effectuer une requête HTTP/3 :

Avantages de HTTP/3

HTTP/3 utilise la même sémantique que HTTP/1.1 et HTTP/2 : les mêmes méthodes de requête, codes d’état et champs de message s’appliquent à toutes les versions. Les différences se trouvent dans le transport sous-jacent. HTTP/1.1 et HTTP/2 utilisent TCP comme transport. HTTP/3 utilise une nouvelle technologie de transport développée avec HTTP/3 appelé QUIC.

HTTP/3 et QUIC présentent un certain nombre d’avantages par rapport à HTTP/1.1 et HTTP/2 :

  • Temps de réponse plus rapide de la première requête. QUIC et HTTP/3 négocient la connexion avec moins d’allers-retours entre le client et le serveur. La première requête atteint le serveur plus rapidement.
  • Amélioration de l’expérience en cas de perte de paquets de connexion. HTTP/2 multiplexe plusieurs requêtes via une connexion TCP. La perte de paquets sur la connexion affecte toutes les requêtes. Ce problème est appelé « blocage en tête de ligne ». Étant donné que QUIC fournit un multiplexage natif, les paquets perdus affectent uniquement les requêtes dans lesquelles des données ont été perdues.
  • Prend en charge la transition entre les réseaux. Cette fonctionnalité est utile pour les appareils mobiles qui passent couramment entre le WIFI et les réseaux cellulaires lors des déplacements de leur utilisateur. Actuellement, les connexions HTTP/1.1 et HTTP/2 échouent avec une erreur lors d’un basculement entre réseaux. Une application ou un navigateur web doit retenter les requêtes HTTP ayant échoué. HTTP/3 permet à l’application ou au navigateur web de continuer à fonctionner de manière transparente en cas de changements de réseau. Kestrel ne prend pas en charge les transitions réseau dans .NET 6. Il peut être disponible dans une prochaine version.

HTTP/3 est la troisième et prochaine version majeure du protocole HTTP. Cet article décrit les conditions requises pour HTTP/3 et comment configurer Kestrel pour l’utiliser.

Important

HTTP/3 est disponible dans .NET 6 en tant que fonctionnalité d’évaluation. La spécification HTTP/3 n’est pas finalisée et des problèmes de comportement ou de performances peuvent exister dans HTTP/3 avec .NET 6.

Pour plus d’informations sur la prise en charge des fonctionnalités d’évaluation, consultez la section Fonctionnalités d’évaluation prises en charge.

Les applications configurées pour tirer parti de HTTP/3 doivent être conçues pour prendre également en charge HTTP/1.1 et HTTP/2. Si des problèmes sont identifiés dans HTTP/3, nous vous recommandons de désactiver HTTP/3 jusqu’à ce que ces problèmes soient résolus dans une prochaine version d’ASP.NET Core. Des problèmes importants sont signalés dans le dépôt GitHub Annonces.

Configuration requise pour HTTP/3

La configuration requise pour HTTP/3 dépend du système d’exploitation. Si la plateforme sur laquelle Kestrel s’exécute ne présente pas toute la configuration requise pour HTTP/3, celui-ci est désactivé et Kestrel bascule vers d’autres protocoles HTTP.

Windows

  • Windows 11 build 22000 ou version ultérieure OU Windows Server 2022.
  • TLS 1.3 ou connexion ultérieure.

Linux

  • Package libmsquic installé.

libmsquic est publié via le référentiel officiel de packages Linux de Microsoft à l’adresse packages.microsoft.com. Pour installer ce package :

  1. Ajoutez le référentiel packages.microsoft.com. Consultez Référentiel logiciel Linux pour les produits Microsoft pour obtenir des instructions.
  2. Installez le package libmsquic à l’aide du gestionnaire de package de la distribution. Par exemple, apt install libmsquic=1.9* sur Ubuntu.

Remarque : .NET 6 est compatible uniquement avec les versions 1.9.x de libmsquic. Libmsquic 2.x n’est pas compatible en raison de changements cassants. Libmsquic reçoit des mises à jour pour 1.9.x quand il est nécessaire d’intégrer des correctifs de sécurité.

macOS

HTTP/3 n’est actuellement pas pris en charge sur macOS et sera peut-être disponible dans une version ultérieure.

Prise en main

HTTP/3 n’est pas activé par défaut. Ajoutez la configuration à Program.cs pour activer HTTP/3.

var builder = WebApplication.CreateBuilder(args);

builder.WebHost.ConfigureKestrel((context, options) =>
{
    options.ListenAnyIP(5001, listenOptions =>
    {
        listenOptions.Protocols = HttpProtocols.Http1AndHttp2AndHttp3;
        listenOptions.UseHttps();
    });
});

Le code précédent configure le port 5001 pour :

  • Utiliser HTTP/3 avec HTTP/1.1 et HTTP/2 en spécifiant HttpProtocols.Http1AndHttp2AndHttp3.
  • Activer HTTPS avec UseHttps. HTTP/3 nécessite HTTPS.

Comme tous les routeurs, pare-feu et proxys prennent correctement en charge HTTP/3, ce dernier doit être configuré avec HTTP/1.1 et HTTP/2. Pour ce faire, spécifiez HttpProtocols.Http1AndHttp2AndHttp3 en tant que protocoles pris en charge par un point de terminaison.

Pour plus d’informations, consultez Configurer des points de terminaison pour le serveur web ASP.NET Core Kestrel.

Alt-svc

HTTP/3 est découvert comme une mise à niveau à partir de HTTP/1.1 ou HTTP/2 via l’en-tête alt-svc. Cela signifie que la première requête utilise normalement HTTP/1.1 ou HTTP/2 avant de passer à HTTP/3. Kestrel ajoute automatiquement l’en-tête alt-svc si HTTP/3 est activé.

Test localhost

  • Les navigateurs n’autorisent pas les certificats auto-signés sur HTTP/3, tels que le certificat de développement Kestrel.

  • HttpClient peut être utilisé pour le test localhost/bouclage dans .NET 6 ou version ultérieure. Une configuration supplémentaire est requise lors de l’utilisation de HttpClient pour effectuer une requête HTTP/3 :

    • Définissez HttpRequestMessage.Version sur 3.0, ou
    • Affectez la valeur HttpRequestMessage.VersionPolicy à HttpVersionPolicy.RequestVersionOrHigher.

Limitations

Certains scénarios HTTPS ne sont pas encore pris en charge pour HTTP/3 dans Kestrel. Lors de l’appel de Microsoft.AspNetCore.Hosting.ListenOptionsHttpsExtensions.UseHttps avec HttpsConnectionAdapterOptions lors de l’utilisation de HTTP/3, la définition des options suivantes sur HttpsConnectionAdapterOptions n’a aucun effet (no-op) :

L’appel des implémentations suivantes de Microsoft.AspNetCore.Hosting.ListenOptionsHttpsExtensions.UseHttps lève une erreur lors de l’utilisation de HTTP/3 :

Avantages de HTTP/3

HTTP/3 utilise la même sémantique que HTTP/1.1 et HTTP/2 : les mêmes méthodes de requête, codes d’état et champs de message s’appliquent à toutes les versions. Les différences se trouvent dans le transport sous-jacent. HTTP/1.1 et HTTP/2 utilisent TCP comme transport. HTTP/3 utilise une nouvelle technologie de transport développée avec HTTP/3 appelé QUIC.

HTTP/3 et QUIC présentent un certain nombre d’avantages par rapport à HTTP/1.1 et HTTP/2 :

  • Temps de réponse plus rapide de la première requête. QUIC et HTTP/3 négocient la connexion avec moins d’allers-retours entre le client et le serveur. La première requête atteint le serveur plus rapidement.
  • Amélioration de l’expérience en cas de perte de paquets de connexion. HTTP/2 multiplexe plusieurs requêtes via une connexion TCP. La perte de paquets sur la connexion affecte toutes les requêtes. Ce problème est appelé « blocage en tête de ligne ». Étant donné que QUIC fournit un multiplexage natif, les paquets perdus affectent uniquement les requêtes dans lesquelles des données ont été perdues.
  • Prend en charge la transition entre les réseaux. Cette fonctionnalité est utile pour les appareils mobiles qui passent couramment entre le WIFI et les réseaux cellulaires lors des déplacements de leur utilisateur. Actuellement, les connexions HTTP/1.1 et HTTP/2 échouent avec une erreur lors d’un basculement entre réseaux. Une application ou un navigateur web doit retenter les requêtes HTTP ayant échoué. HTTP/3 permet à l’application ou au navigateur web de continuer à fonctionner de manière transparente en cas de changements de réseau. Kestrel ne prend pas en charge les transitions réseau dans .NET 6. Il peut être disponible dans une prochaine version.