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

Step 1: Turn on the EnableHttp3 parameter

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.

Step 2: Verify the HTTPS listener

Make sure the Classic Load Balancer (CLB) instance associated with the gateway has a healthy listener on port 443:

1. On the gateway's Overview page, click the CLB instance name.

2. In the CLB console, confirm that the health check status for the port 443 listener is healthy.

Step 3: Add a backend service and routing rule

1. Add a backend 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 service. For example, add a routing rule named quic. For more information, see Create a routing rule.

Step 4: Test the HTTP/3 connection

Run a cURL command to send an HTTP/3 request through the gateway:

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

Replace api.alibaba-inc.com with your domain name, /quic with the path defined in your routing rule, and <IP address of the CLB instance> with the actual CLB IP address.

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

Step 1: Turn on the EnableHttp3 parameter

Follow the same steps as Step 1 in the console method to turn on the EnableHttp3 parameter.

Step 2: Install and associate MSE Ingress Controller

1. Install MSE Ingress Controller in your Container Service for Kubernetes (ACK) cluster. For more information, see Manage the MSE Ingress Controller component.

2. Associate the gateway with MSE Ingress Controller. For more information, see Configure an MseIngressConfig.

Step 3: Create an HTTPS Secret and Ingress

Apply the following manifests to create a TLS Secret and an Ingress routing rule in your ACK cluster:

apiVersion: v1
kind: Secret
metadata:
  name: testsecret-tls
  namespace: default
data:
  tls.crt: <base64-encoded-certificate>    # Base64-encoded TLS certificate
  tls.key: <base64-encoded-private-key>     # Base64-encoded private key
type: kubernetes.io/tls
---
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: tls-example-ingress
  annotations:
    # Set to HTTP2 if your backend service uses HTTP/2
    nginx.ingress.kubernetes.io/backend-protocol: HTTP
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             # Your backend service name
            port:
              number: 80

Replace the placeholder values:

Step 4: Test the HTTP/3 connection

Run a cURL command to verify that HTTP/3 works through the Ingress:

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

If the connection succeeds, the response includes an alt-svc header that advertises HTTP/3 support.

HTTP/1.1 limitations

HTTP/1.1 transfers messages as space-delimited text. Without a multiplexing layer, browsers open multiple TCP connections to handle parallel requests, which hurts congestion control and network efficiency. For more information, see RFC 9112.

HTTP/2 improvements and remaining issues

HTTP/2 adds binary framing and multiplexing to reduce latency without changing the transport layer. However, because HTTP/2 runs on TCP, a single lost packet blocks all streams in the connection until recovery completes (head-of-line blocking). For more information, see RFC 9113.

How HTTP/3 solves these problems

HTTP/3 (previously called HTTP-over-QUIC) replaces TCP with QUIC, a UDP-based protocol originally developed by Google. IETF renamed HTTP-over-QUIC to HTTP/3 in 2018 and published it as a proposed standard in RFC 9114 on June 6, 2022.

QUIC gives each stream its own flow control, so a lost packet in one stream does not block others. HTTP/3 also improves congestion control and header compression over HTTP/2.

HTTP/3 is supported by Cloudflare, Google Chrome, and Firefox Nightly. For a detailed overview, see HTTP/3 from A to Z: core concepts.