Microservices Engine:Activer HTTP/3 pour une passerelle cloud-native

HTTP/1.1

HTTP/1.1 utilise des champs textuels délimités par des espaces pour transférer les messages HTTP. Ces messages sont lisibles, mais leur formatage complexe rend l’analyse difficile et tolère excessivement les variations de comportement. De plus, HTTP/1.1 ne dispose pas de couche de multiplexage. Le traitement parallèle des requêtes repose souvent sur plusieurs connexions TCP, ce qui nuit au contrôle de congestion et à l’efficacité du réseau. Pour en savoir plus, consultez la spécification HTTP/1.1.

HTTP/2

HTTP/2 introduit le framing binaire et des couches de multiplexage afin de réduire la latence sans modifier la couche de transport. Cependant, la fonctionnalité de concurrence du multiplexage HTTP/2 reste inefficace lorsque des paquets TCP perdus doivent être restaurés. En cas de perte ou de réordonnancement des paquets, toutes les requêtes actives sont suspendues pendant un certain temps, qu’elles soient ou non affectées par la perte de paquets. Pour plus de détails, reportez-vous à la spécification HTTP/2.

HTTP/3

Le 6 juin 2022, Robin Marx, membre des groupes de travail IETF QUIC et HTTP, a annoncé la publication de HTTP/3 en tant que norme proposée dans la RFC 9114, aboutissement de cinq années d’efforts. Consultez les ressources suivantes pour approfondir le sujet : HTTP/3 From A To Z: Core Concepts et RFC 9114.

Initialement nommé HTTP-over-QUIC, HTTP/3 est un protocole QUIC basé sur UDP, développé par Google fort de son expérience accumulée sur plusieurs années. L’IETF a rebaptisé HTTP-over-QUIC en HTTP/3 en 2018. Cloudflare, Google Chrome et Firefox Nightly prennent désormais en charge ce protocole.

Pour résoudre le problème de blocage en tête de ligne présent dans HTTP/2, HTTP/3 abandonne TCP au profit de UDP. Ce protocole étend davantage les capacités de multiplexage offertes par HTTP/2 grâce à l’utilisation de flux (« streams »), tout en améliorant les performances du contrôle de congestion et de la compression des en-têtes. Pour comprendre le blocage en tête de ligne, consultez l’article Head-of-line blocking.

Activer HTTP/3 dans la console MSE

1. Activez HTTP/3 pour une passerelle cloud-native.

   1. Connectez-vous à la console MSE. Dans la barre de navigation supérieure, sélectionnez une région.

   2. Dans le volet de navigation de gauche, accédez à Cloud-native Gateway > Gateways. Sur la page Gateways, cliquez sur l’ID de la passerelle.

   3. Dans le volet de navigation de gauche, cliquez sur Parameter Settings.

   4. Dans la section Gateway Engine Parameters, repérez le paramètre EnableHttp3 et cliquez sur Edit dans la colonne Actions.

   5. Dans la boîte de dialogue Modify Parameters, activez l’interrupteur Value puis cliquez sur OK.

2. Vérifiez que le protocole HTTPS est configuré pour le nom de domaine de la passerelle.

   HTTP/3 exige HTTPS pour garantir la sécurité. Vous devez activer HTTPS pour le domaine de test sur la passerelle. Pour plus d’informations, consultez la rubrique Créer un nom de domaine. Dans le volet de navigation de gauche, cliquez sur Domain Name Management. Dans la liste des domaines, assurez-vous que la colonne Protocol correspondant à votre domaine cible indique HTTPS et qu’un certificat associé est présent, par exemple 8880972-cn-hangzhou.

   Remarque

   Si un nom de domaine HTTPS est configuré pour la passerelle, vous pouvez cliquer sur le nom de l’instance Classic Load Balancer (CLB) associée à la passerelle depuis la page Overview. Accédez ensuite à la console CLB et vérifiez que le health check status de l’écouteur sur le port 443 de l’instance CLB est sain.

3. Ajoutez un service HTTP à la passerelle et définissez une règle de routage.

   1. Ajoutez un service backend de test prenant en charge HTTP/1.1. Pour plus d’informations, consultez les rubriques Ajouter un service et Ajouter une source de service.

   2. Ajoutez une règle de routage pour le service de test. Pour plus d’informations, consultez la rubrique Créer une règle de routage.

      Par exemple, ajoutez une règle de routage nommée quic.

      La règle est publiée, utilise une correspondance de chemin exacte pour /quic, est associée au domaine api.alibaba-inc.com et cible un single service.

   3. Exécutez la commande cURL suivante pour lancer un test de requête HTTP/3 :

      curl --http3 https://api.alibaba-inc.com/quic --resolve api.alibaba-inc.com:443:<IP address of the CLB instance> -k

      Remarque

      Les tests HTTP/3 nécessitent généralement la compilation du code source. Si vous utilisez une image cURL HTTP/3 préexistante, cette étape n’est pas nécessaire. Choisissez la méthode adaptée à vos besoins métier. Pour plus d’informations, consultez curl-http3.

Activer HTTP/3 via les Ingresses

1. Activez HTTP/3 pour une passerelle cloud-native.

   1. Connectez-vous à la console MSE. Dans la barre de navigation supérieure, sélectionnez une région.

   2. Dans le volet de navigation de gauche, accédez à Cloud-native Gateway > Gateways. Sur la page Gateways, cliquez sur l’ID de la passerelle.

   3. Dans le volet de navigation de gauche, cliquez sur Parameter Settings.

   4. Dans la section Gateway Engine Parameters, repérez le paramètre EnableHttp3 et cliquez sur Edit dans la colonne Actions.

   5. Dans la boîte de dialogue Modify Parameters, activez l’interrupteur Value puis cliquez sur OK.

2. Installez MSE Ingress Controller dans votre cluster Container Service for Kubernetes (ACK) et associez la passerelle à MSE Ingress Controller.

   • Pour installer MSE Ingress Controller, consultez la rubrique Gérer le module complémentaire MSE Ingress Controller.

   • Pour associer une passerelle cloud-native MSE à MSE Ingress Controller, consultez la rubrique Configurer un MseIngressConfig.

3. Configurez un Ingress dans le cluster ACK.

   Créez un secret HTTPS et une règle de routage pour le nom de domaine HTTPS dans le cluster ACK. Exemple de code :

   apiVersion: v1
   kind: Secret
   metadata:
     name: testsecret-tls
     namespace: default
   data:
     tls.crt: base64 # The Base64-encoded certificate. 
     tls.key: base64 # The Base64-encoded private key. 
   type: kubernetes.io/tls
   ---
   apiVersion: networking.k8s.io/v1
   kind: Ingress
   metadata:
     name: tls-example-ingress
     annotations:
       nginx.ingress.kubernetes.io/backend-protocol: HTTP # If your backend service uses HTTP/2, set this parameter to HTTP2. 
   spec:
     tls:
     - hosts:
         - https-example.foo.com
       secretName: testsecret-tls
     rules:
     - host: https-example.foo.com
       http:
         paths:
         - path: /quic
           pathType: Prefix
           backend:
             service:
               name: service1  # The backend service.
               port:
                 number: 80

4. Exécutez la commande cURL suivante pour lancer un test de requête HTTP/3 :

   curl --http3 https://https-example.foo.com/quic --resolve https-example.foo.com:443:<IP address of the CLB instance> -k