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.