-
Notifications
You must be signed in to change notification settings - Fork 110
/
supporting-http2.html.md.erb
136 lines (90 loc) · 6.85 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
130
131
132
133
134
135
136
---
title: Configuring HTTP/2 support
owner: CF for VMs Networking
---
You can configure your <%= vars.app_runtime_first %> deployment to support HTTP/2 from ingress to egress.
## <a id="overview"></a> HTTP/2 support 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 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.
### <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:
<ul>
<li><code>API-URL</code> is your API endpoint, <%= vars.api_endpoint %>.</li>
<li><code>USERNAME</code> is your username.</li>
<li><code>PASSWORD</code> is your password. <%= vars.company_name %> discourages using the <code>-p</code> option, as it might record your password in your shell history.</li>
<li><code>ORG</code> is the org where your app is deployed.</li>
<li><code>SPACE</code> is the space in the org where your app is deployed.</li>
</ul>
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:
<ul>
<li><code>MY-APP</code> is the name of your app.</li>
<li><code>EXAMPLE.COM</code> is the route you want to map to your app.</li>
</ul>