The WebSocket protocol enables web applications to use real-time bidirectional communication between clients and servers.

How it works

WebSocket is a protocol providing full-duplex communication channels over a single TCP connection. The WebSocket Protocol is an independent TCP-based protocol. Its only relationship to HTTP is that HTTP servers interpret its handshake as an upgrade request.

The WebSocket protocol makes bidirectional interaction between a browser and a website possible, facilitating the real-time data transfer from and to the server. This is possible by providing a standardized way for the server to send content to the browser without being solicited by the client, and allowing for the passing back and forth of message while keeping the connection open. In this way a two-way (bidirectional) ongoing conversation can take place between a browser and the server.

The WebSocket protocol is currently supported in most major browsers including Google Chrome, Internet Explorer, Firefox, Safari and Opera. WebSocket requires web applications on the server to support it and build functionality on top of it. For a WebSocket connection to work over HTTP in the clear, all network middleboxes along the way must support WebSockets.

Limitations

WebSocket support is a feature that is offered “as is.” Your WebSocket upgrade request may be declined and existing WebSocket connections dropped due to various reasons. Customer implementations must support connection retries and fall back to long polling when WebSocket upgrade requests fail. In addition, we cannot guarantee that WebSocket closes cleanly in all situations because the proxy is not aware of WebSocket frames and will close the TCP connection if either end is closed. The number of concurrent clients connected through ​Akamai​ to customer origin via WebSocket is limited and isn't configurable. WebSocket is available only on supporting clients, middle boxes, and origin servers. You must acknowledge that WebSocket is a third party protocol, and ​Akamai​ is not responsible for any bugs, security vulnerabilities, or performance issues resulting in its design or implementation.

Tips and best practices

• It's strongly recommended to enable WebSockets only for the URL that requires it, and not for the entire configuration.
• When you enable WebSockets, it is recommended to also add the Read Timeout behavior with a timeout of 300 seconds to optimize the long polling fallback, in case a WebSocket connection couldn't be established. Unless long polling is used as fallback, this timeout doesn't affect the WebSocket connection's read timeout if the connection is established. You need to build long polling fallback into the application, as ​Akamai​doesn't do it automatically.
• Although you can modify the WebSocket read timeout with ​Akamai​, this is rarely necessary. Instead, consider using ping and pong frames to control the heartbeat of the WebSocket. The flow of bytes generated by these frames keep the connection established. If you need to modify the timeout, contact your account representative for help.
• For more information about the WebSockets, refer to the WebSocket Protocol Standard (RFC 6455).

📘

If you enable WebSockets for specific matches, response body inspection for the given Application Security product won't work for the corresponding requests. For example, in case of WebSockets enabled for certain paths, the body inspection won't work for requests targeting these paths.