Introduction to WebSockets
For a long time the web has contained pages which are static, the facts and the figures were updated once in a while, and the information got stale and outdated. These pages did not reflect the changes in data in real-time until they were reloaded. In this era, there are certain sectors where real-time communication is very important (real-time stock market prices, real-time transmission of patients’ vitals etc). The progression of real-time data transfer has also allowed us to implement services like Video Conferencing and Voice over Internet Protocol(VoIP).
DIFFERENT METHODS TO ACHIEVE REAL-TIME COMMUNICATION
Polling: The earliest and the easiest way to implement real-time communication. The client sends a request to the server. When a server receives this request, it responds with a new message, if there is one, or with an empty response if no new message is available. Again after a short time, the client resends the request to the server again to see if any new messages are available. This short time Δ is called the polling interval.
A shortcoming of this way is if there are no new messages for the client, there are still requests from the client which contains the headers. This increases the load on the server and also consumes bandwidth of the network.
Long Polling: Long Polling came up as a solution to the unnecessary requests sent by the client when there was no new data on the server. With long polling, the server doesn’t send an empty response when there are no new messages available for a client. Instead, the server holds the request until a new message is available or a timeout expires. This reduces the number of client requests when no new messages are available.
A shortcoming of this way is, to keep a connection alive the connection has to be saved locally on the server which requires extra computation and space.
WebSockets: Sockets came up as the solution to both the problems. With web sockets, we can reduce the metadata (HTTP headers) that are sent in every request (a shortcoming of Polling) and we can also provide full–duplex communication through a single socket (a shortcoming of Long Polling).
WEBSOCKETS
Web sockets act like proxies over HTTP, meaning they tunnel a TCP connection over HTTP. It is considered the most ideal option when compared to HTTP Polling and HTTP Long Polling. Web sockets have their own set of protocols, ws:// (web socket) and wss:// (web socket secure).
Currently, there are many websites which deploy web sockets to gain real-time communication. But across the internet we never see a website address with wss:// or ws:// but majorly http:// and https://. This is due to the fact that web sockets are deployed as a proxy over HTTP, so it basically uses the same ports as used by http i.e. port 80(HTTP) and port 443(HTTPS). The data transfer through WebSockets can be analysed using the network analyzer in a web browser.
A request to upgrade to Websockets is sent and applied during the initial handshake between the client and server. The HTTPS headers contain all the information required by the server to process the request. Once the request is processed, the WebSocket protocol is mapped over the HTTP/HTTPS protocol.
Once the WebSocket is implemented, the HTTP header reduces to a size of an additional 2 bytes as compared to normal polling headers which have headers of size minimum of 871 bytes. This massively reduces the server load and also reduces the bandwidth clogging.
At the time of writing, web sockets are supported by almost every mainstream browser.
Websockets are also compatible with IoT devices. They can work on MicroPy and Arduino as well. There are also many WebSocket libraries made for the clients and servers due to their huge popularity.
SHORTCOMINGS OF WEBSOCKETS
Even with all these advantages, WebSockets aren’t perfect.
- They are still not compatible with mobile web browsers.
2. Web sockets are still susceptible to DOS attacks as malicious software can create a large number of websocket connections to the server.
3. They are also not compatible with various API calls
4. They are also not compatible with REST APIs.
5. We often need special configurations for load balancing
6. Websockets introduce a new vulnerability called Cross-Site Websockets Scripting (CRWS).
References:
[1] Victoria Pimentel, Bradford G. Nickerson: Communicating and displaying real-time data with WebSocket
[2] Eliot Estep: Mobile HTML5: Efficiency and Performance of WebSockets and Server-Sent Events
[3] www.caniuse.com
