forked from cloudfoundry/docs-cf-admin
-
Notifications
You must be signed in to change notification settings - Fork 0
Expand file tree
/
Copy pathsupporting-websockets.html.md.erb
More file actions
45 lines (28 loc) · 4.22 KB
/
supporting-websockets.html.md.erb
File metadata and controls
45 lines (28 loc) · 4.22 KB
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
---
title: Supporting WebSockets
owner: Routing
---
<strong><%= modified_date %></strong>
This topic explains how Cloud Foundry (CF) uses WebSockets, why developers use WebSockets in their applications, and how operators can configure their load balancer to support WebSockets.
Operators who use a load balancer to distribute incoming traffic across CF [router](../concepts/architecture/index.html#router) instances must configure their load balancer for WebSockets. Otherwise, the [Loggregator](../loggregator/architecture.html) system cannot stream application logs to developers, or application event data and system metrics to third-party aggregation services. Additionally, developers cannot use WebSockets in their applications.
##<a id='understand'></a> Understand WebSockets
The WebSocket protocol provides full-duplex communication over a single TCP connection. Applications can use WebSockets to perform real-time data exchange between a client and a server more efficiently than HTTP.
CF uses WebSockets for the following metrics and logging purposes:
1. To stream all application event data and system metrics from the [Doppler](../loggregator/architecture.html#doppler) server instances to the [Traffic Controller](../loggregator/architecture.html#traffic-controller)
1. To stream application logs from the Traffic Controller to developers using the cf Command Line Interface (CLI) <%= vars.or_apps_man2 %>
1. To stream all application event data and system metrics from the Traffic Controller over the [Firehose](../loggregator/architecture.html#firehose) endpoint to external applications or services
For more information about these Loggregator components, see the [Overview of the Loggregator System](../loggregator/architecture.html) topic.
##<a id='config'></a> Configure Your Load Balancer for WebSockets
To form a WebSocket connection, the client sends an HTTP request that contains an `Upgrade` header and other headers required to complete the WebSocket handshake. You must configure your load balancer to not upgrade the HTTP request, but rather to pass the `Upgrade` header through to the CF router. The procedures required to configure your load balancer depends on your IaaS and load balancer. The following list includes several possible approaches:
* Some load balancers can recognize the `Upgrade` header and pass these requests through to the CF router without returning the WebSocket handshake response. This may or may not be default behavior, and may require additional configuration.
* Some load balancers do not support passing WebSocket handshake requests containing the `Upgrade` header to the CF router. For instance, the Amazon Web Services (AWS) Elastic Load Balancer (ELB) does not support this behavior. In this scenario, you must configure your load balancer to forward TCP traffic to your CF router to support WebSockets. If your load balancer does not support TCP pass-through of WebSocket requests on the same port as other HTTP requests, you can do one of the following:
* Configure an additional port for WebSocket requests, such as port 4443, and follow the steps below in the [Modify Your Release Manifest](#modify) section of this topic
* Add an additional load balancer with a domain that resolves to it, such as `ws.cf.example.com`, and ensure that all WebSocket traffic goes through this domain, especially if application clients only support standard ports
<p class="note"><strong>Note</strong>: Regardless of your IaaS and configuration, you must configure your load balancer to send the X-Forwarded-For and X-Forwarded-Proto headers for non-WebSocket HTTP requests on ports 80 and 443. See the <a href='../adminguide/securing-traffic.html'>Securing Traffic into Cloud Foundry</a> topic for more information.</p>
##<a id='modify'></a> Modify Your Release Manifest
By default, the CF release manifest assigns port 4443 for TCP/WebSocket communications. If you have configured your load balancer to use a port other than 4443 for TCP/WebSocket traffic, you must edit your CF manifest to set the value of `properties.logger_endpoint.port` to the correct port. Locate the following section of your CF manifest and replace `YOUR-WEBSOCKET-PORT` with the appropriate value:
```
properties:
logger_endpoint:
port: YOUR-WEBSOCKET-PORT
```