forked from cloudfoundry/docs-cf-admin
-
Notifications
You must be signed in to change notification settings - Fork 0
/
supporting-http2.html.md.erb
129 lines (86 loc) · 6.68 KB
/
supporting-http2.html.md.erb
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
---
title: Configuring HTTP/2 Support
owner: CF for VMs Networking
---
This topic describes how operators can configure their <%= vars.app_runtime_first %> deployment to support HTTP/2 from ingress to egress.
## <a id="overview"></a> Overview
For information about how HTTP/2 can benefit apps running on <%= vars.app_runtime_abbr %>,
see [Routing HTTP/2 and gRPC Traffic to Apps](../devguide/http2-protocol.html).
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.
## <a id="prerequisites"></a> Prerequisites
Before you can configure your <%= vars.app_runtime_abbr %> 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](https://datatracker.ietf.org/doc/html/rfc7301).
### <a id="security"></a> 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.
<%= vars.recommended_by %> 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.
## <a id="enabling"></a> 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 <%= vars.app_runtime_abbr %> platform, and the app.
### <a id="load-balancer"></a> 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 <%= vars.app_runtime_abbr %> 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 <%= vars.app_runtime_abbr %> 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](#l4)
- [Configure Layer 7 Application Load Balancers](#l7)
#### <a id="l4"></a> 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](https://datatracker.ietf.org/doc/html/rfc7540#section-3.4) in _RFC 7540: Hypertext Transfer Protocol Version 2 (HTTP/2)_.
#### <a id="l7"></a> 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 <%= vars.app_runtime_abbr %>.
See the [BOSH release for HAProxy](https://github.com/cloudfoundry-incubator/haproxy-boshrelease) 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](https://datatracker.ietf.org/doc/html/rfc8441).
<%= vars.app_runtime_abbr %> uses WebSockets for streaming logs and metrics as well as apps that serve WebSocket traffic.
To continue supporting WebSockets in <%= vars.app_runtime_abbr %> 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](supporting-websockets.html).
### <a id="platform"></a> Configure the <%= vars.app_runtime_abbr %> Platform
<%= vars.http2_support_version %>
To disable 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.
### <a id="application"></a> Configure <%= vars.app_runtime_abbr %> 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, <%= vars.api_endpoint %>.
* `USERNAME` is your username.
* `PASSWORD` is your password. <%= vars.company_name %> 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.
1. 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.