Configuring HTTP/2 support

You can configure your VMware Tanzu Application Service for VMs (TAS for VMs) deployment to support HTTP/2 from ingress to egress. This article tells you how.

HTTP/2 support overview

For information about how HTTP/2 can benefit apps running on TAS for VMs, see Routing HTTP/2 and gRPC Traffic to Apps.

Apps can benefit from HTTP/2 even if not all network segments use HTTP/2. Headers are compressed and requests are multiplexed for HTTP/2 segments even if other network hops do not use HTTP/2.

However, some features like gRPC require all segments to use HTTP/2. While browsers and other clients might indicate a request is being served over HTTP/2, operators must ensure that all network hops use HTTP/2 to support gRPC.

Prerequisites

Before you can configure your TAS for VMs deployment to support HTTP/2, you must enable TLS.

Most implementations of HTTP/2 require TLS with Application-Layer Protocol Negotiation (ALPN). For more information about ALPN, see RFC 7301: Transport Layer Security (TLS) Application-Layer Protocol Negotiation Extension.

Security considerations

If you use a firewall or other tools to monitor network traffic, ensure that those tools support HTTP/2 connections. If your network monitoring tools do not support HTTP/2 connections, configuring HTTP/2 can cause problems with protecting and analyzing traffic on your network.

VMware recommends that you become familiar with common vulnerabilities in apps that support HTTP/2. For example, HTTP/1.1 has vulnerabilities such as request smuggling and desync attacks, but these might be more prevalent in HTTP/2 environments.

Enable end-to-end HTTP/2

This section describes how to enable HTTP/2 in your deployment from ingress to egress. To enable end-to-end HTTP/2, you must configure the load balancers, the TAS for VMs platform, and the app.

Configure load balancers

To support HTTP/2, operators must configure platform load balancers to enable HTTP/2 ingress and egress.

Load balancers in front of TAS for VMs can be either Layer 4 (TCP) or Layer 7 (Application). Layer 4 load balancers tend to be simpler, while Layer 7 load balancers offer more features by inspecting the contents of HTTP requests. For example, a Layer 7 load balancer might send requests to different TAS for VMs deployments based on the resources that are being requested. You can configure many load balancers to function in either Layer 4 or Layer 7 mode.

For more information, see the following sections:

• Configure Layer 4 TCP Load Balancers
• Configure Layer 7 Application Load Balancers

Configure layer 4 TCP load balancers

Layer 4 load balancers do not terminate HTTP connections and support passing HTTP/2 traffic.

If you are terminating TLS traffic at a Layer 4 load balancer, configure your load balancer to advertise support for HTTP/2 over ALPN. ALPN ensures that a client making an HTTP request knows that the app server that is servicing the request can support HTTP/2.

If a load balancer terminates TLS without advertising HTTP/2 over ALPN, then clients must be configured to use HTTP/2 with prior knowledge. For more information, see Starting HTTP/2 with Prior Knowledge in RFC 7540: Hypertext Transfer Protocol Version 2 (HTTP/2).

Configure layer 7 application load balancers

Layer 7 load balancers terminate the incoming HTTP connection and initiate new HTTP connections to their back ends. For end-to-end HTTP/2 support, Layer 7 load balancers must have HTTP/2 enabled for both ingress and egress HTTP connections.

The HAProxy BOSH release contains the canonical example of how to set up HTTP/2 load balancing for TAS for VMs. See the BOSH release for HAProxy on GitHub.

When HTTP/2 is enabled, HAProxy advertises support for HTTP/2 over ALPN, accepts HTTP/2 ingress traffic for all connections, and negotiates using HTTP/2 over ALPN when connecting to the Gorouter.

Gorouter and many Layer 7 load balancers do not support WebSockets over HTTP/2. For more information, see RFC 8441. TAS for VMs uses WebSockets for streaming logs and metrics as well as apps that serve WebSocket traffic.

To continue supporting WebSockets in TAS for VMs when you enable HTTP/2, you can do either of the following:

• Configure load balancers to forward WebSocket traffic over HTTP/1.1.
• Use a Layer 4 load balancer for WebSocket traffic.

For more information, see Supporting WebSockets.

Configure the TAS for VMs platform

In TAS for VMs v2.12 and later, HTTP/2 support is enabled by default. To deactivate HTTP/2 support, set the router.enable_http2 property to false.

When HTTP/2 is enabled, the Gorouter accepts HTTP/2 ingress traffic for all apps, but does not connect to app instances over HTTP/2 unless configured on app routes.

Configure TAS for VMs apps

Before the Gorouter can send HTTP/2 traffic to apps, the operator must configure HTTP/2 when mapping the route to the app. This is because the Gorouter defaults to HTTP/1.1 for compatibility unless it knows that a given route and app combination supports HTTP/2.

After you map a route with HTTP/2 support enabled, the Gorouter sends all traffic to that app over HTTP/2, even traffic that ingresses to the Gorouter over HTTP/1.1.

To map a route to the app with HTTP/2 support:

1. Log in to the Cloud Foundry Command Line Interface (cf CLI) by running:

   cf login -a API-URL -u USERNAME -p PASSWORD -o ORG -s SPACE
   

   Where:

   • API-URL is your API endpoint, the URL of the Cloud Controller in your TAS for VMs instance.
   • USERNAME is your username.
   • PASSWORD is your password. VMware discourages using the -p option, as it may record your password in your shell history.
   • ORG is the org where your app is deployed.
   • SPACE is the space in the org where your app is deployed.

2. Run the following command to map the route to your app:

   cf map-route MY-APP EXAMPLE.COM --destination-protocol=http2
   Creating route MY-APP.EXAMPLE.COM for org my-org / space my-space as admin...
   OK
   

   Where:

   • MY-APP is the name of your app.
   • EXAMPLE.COM is the route you want to map to your app.