supporting-websockets.html.md.erb

---
title: Supporting WebSockets in Cloud Foundry
owner: CF for VMs Networking
---

<%# Reset page title based on platform type %>
<% if vars.platform_code != 'CF' %>

<% set_title("Supporting WebSockets in", vars.app_runtime_abbr) %>

<% end %>

In this topic, learn how <%= vars.app_runtime_abbr %> uses WebSockets, why use WebSockets in your apps, and how to configure your
load balancer to support WebSockets.

You can use a load balancer to distribute incoming traffic across <%= vars.app_runtime_first %> router instances and configure your load balancer for WebSockets. Otherwise, the Loggregator system cannot stream app logs to developers, or app event data and component metrics to third-party aggregation services. Additionally, developers cannot use WebSockets in their apps.

## <a id='overview'></a> WebSocket overview

The WebSocket protocol provides full duplex communication over a single TCP connection. Apps use WebSockets to perform real time data exchange between a client and a server more efficiently than HTTP.

<%= vars.app_runtime_abbr %> uses WebSockets for the following metrics and logging purposes:

1. To stream all app event data and component metrics from the Doppler server instances to the Traffic Controller.

1. To stream app logs from the Traffic Controller to developers using the Cloud Foundry Command Line Interface (cf CLI) <%= vars.or_apps_man2 %>.

1. To stream all app event data and component metrics from the Traffic Controller over the Firehose endpoint to external apps or services.

For more information about these Loggregator components, see [Loggregator Architecture](../loggregator/architecture.html).

## <a id='config'></a> Configuring 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 <%= vars.app_runtime_abbr %> 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 <%= vars.app_runtime_abbr %> router without returning the WebSocket handshake response. This might or might not be default behavior, and might require additional configuration.

* Some load balancers do not support passing WebSocket handshake requests containing the `Upgrade` header to the <%= vars.app_runtime_abbr %> 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 <%= vars.app_runtime_abbr %> 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 your load balancer to listen on a non-standard port (the built-in <%= vars.app_runtime_abbr %> load balancer listens on 8443 by default for this purpose), and forward requests for this port in TCP mode. App clients must make WebSockets upgrade requests to this port. If you choose this strategy, you must follow the steps in [Set Your Loggregator Port](#modify).
  * If a non-standard port is not acceptable, add a load balancer that handles WebSocket traffic (or another IP on an existing load balancer) and configure it to listen on standard ports 80 and 443 in TCP mode. Configure DNS with a new hostname, such as `ws.cf.example.com`, to be used for WebSockets. This hostname should resolve to the new load balancer interface.

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. For more information, see <a href="https://docs.vmware.com/en/VMware-Tanzu-Application-Service/3.0/tas-for-vms/securing-traffic.html
">Securing Traffic into TAS for VMs</a>.

Gorouter rejects WebSockets requests for routes that are bound to route services.
These requests return a 503 error and a <code>X-Cf-Routererror
 route_service_unsupported</code> header.

 <p class="note">
 <span class="note__title"><strong>Note</strong></span>
 Gorouter does not support WebSockets over HTTP/2.
 For more information, see <a href='https://datatracker.ietf.org/doc/html/rfc8441'>RFC 8441</a>.
 Configure your load balancer to always send WebSocket requests to Gorouter over HTTP/1.1.
 For more information, see <a href='./supporting-http2.html#load-balancer'>Configuring HTTP/2 Support</a>.</p>

## <a id='modify'></a> Setting your Loggregator port

<% if vars.platform_code == 'CF' %>
By default, the <%= vars.app_runtime_abbr %> 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 <%= vars.app_runtime_abbr %> manifest to set the value of `properties.logger_endpoint.port` to the correct port. Locate the following section of your <%= vars.app_runtime_abbr %> manifest and replace `YOUR-WEBSOCKET-PORT` with the appropriate value:

```
properties:
  logger_endpoint:
    port: YOUR-WEBSOCKET-PORT
```

<% else %>
<%= vars.supporting_websockets %>

<img alt="Find Loggregator port field underneath the HAProxy Trusted CIDRs." src="./images/loggregator-port.png">

<% end %>