Microservices Engine:Enable HTTP/3 for a cloud-native gateway

HTTP/1.1

In HTTP/1.1, space-delimited text fields are used to transfer HTTP messages. Transferred messages are readable. However, space-delimited message formatting results in complex parsing and excessive tolerance for variant behavior. HTTP/1.1 does not contain a multiplexing layer. In most cases, multiple TCP connections are used to process requests in parallel. However, this implementation has a negative impact on congestion control and network efficiency. For more information, see HTTP/1.1.

HTTP/2

HTTP/2 introduces binary framing and multiplexing layers to reduce the latency without requiring you to modify the transport layer. However, the concurrency feature of HTTP/2 multiplexing does not take effect in scenarios in which lost TCP packets need to be restored. If packets are lost or reordered, all activity requests become suspended for a period of time regardless of whether the requests are affected by packet loss. For more information, see HTTP/2.

HTTP/3

On June 6, 2022, Robin Marx, a member of the IETF QUIC Working Group and HTTP Working Group, announced that HTTP/3 was published as a proposed standard in RFC 9114 through five years of effort. For more information, see HTTP/3 From A To Z: Core Concepts and RFC 9114.

HTTP/3, previously called HTTP-over-QUIC, is a UDP-based QUIC protocol that is developed by Google based on years of experience. IETF renamed HTTP-over-QUIC as HTTP/3 in 2018. Cloudflare, Google Chrome, and Firefox Nightly support HTTP/3.

For fixes of the head-of-line blocking issue that exists in HTTP/2, HTTP/3 is no longer implemented based on TCP but is built on top of UDP. In HTTP/3, streams are used to further extend the multiplexing capability provided by HTTP/2, and the performance in terms of congestion control and header compression is improved. For more information about head-of-line blocking, see Head-of-line blocking.

Enable HTTP/3 in the MSE console

1. Enable HTTP/3 for a cloud-native gateway.

   1. Log on to the MSE console. In the top navigation bar, select a region.

   2. In the left-side navigation pane, choose Cloud-native Gateway > Gateways. On the Gateways page, click the name of the gateway.

   3. In the left-side navigation pane, click Parameter Settings.

   4. In the Gateway Engine Parameters section, find the EnableHttp3 parameter, and click Edit in the Actions column.

      

   5. In the Modify Parameters dialog box, turn on the Value switch, and click OK.

2. Check whether HTTPS is configured as the protocol for the domain name of the gateway.

   HTTP/3 requires the HTTPS protocol to ensure secure transmission. Therefore, you need to enable HTTPS for the test domain name of the gateway. For more information about how to configure a domain name for a gateway, see Associate domain names with a cloud-native gateway.

   Note

   If an HTTPS domain name is configured for the gateway, you can click the name of the Classic Load Balancer (CLB) instance that is associated with the gateway on the Overview page. Go to the CLB console and check whether the health check status of the listener port 443 of the CLB instance is healthy.

3. Add an HTTP service to the gateway and add a routing rule.

   1. Add a backend test service that supports HTTP/1.1. For more information, see Add a service and Add a service source.

   2. Add a routing rule for the test service. For more information, see Create a routing rule.

      For example, you add a routing rule named quic.

   3. Run the following cURL command to initiate an HTTP/3 request test:

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

      Note

      To perform HTTP/3 tests, you need to compile the source code. If you use an existing cURL HTTP/3 image for testing, you do not need to compile the source code. You can select a test method based on your business requirements. For more information, see curl-http3.

Enable HTTP/3 by using Ingresses

1. Enable HTTP/3 for a cloud-native gateway.

   1. Log on to the MSE console. In the top navigation bar, select a region.

   2. In the left-side navigation pane, choose Cloud-native Gateway > Gateways. On the Gateways page, click the name of the gateway.

   3. In the left-side navigation pane, click Parameter Settings.

   4. In the Gateway Engine Parameters section, find the EnableHttp3 parameter, and click Edit in the Actions column.

      

   5. In the Modify Parameters dialog box, turn on the Value switch, and click OK.

2. Install MSE Ingress Controller in your Container Service for Kubernetes (ACK) cluster, and associate the gateway with MSE Ingress Controller.

   • For more information about how to install MSE Ingress Controller, see Manage the MSE Ingress Controller component.

   • For more information about how to associate an MSE cloud-native gateway with MSE Ingress Controller, see Configure an MseIngressConfig.

3. Configure an Ingress in the ACK cluster.

   Create an HTTPS secret and a routing rule for the HTTPS domain name in the ACK cluster. Sample 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. Run the following cURL command to initiate an HTTP/3 request test:

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