WebSocket is a new standard for real time communication on the Web and mobile applications. WebSocket is designed to be implemented in web browsers and web servers, but can be used by client or server applications. WebSocket is a protocol that provides a full-duplex communication channel over a single TCP connection.
WebSocket is part of HTML5. WebSocket presents large connections in network traffic that are not important and latency compared to long polling and polling solutions that have been used to connect two-way connections by connecting two connections to stay connected.
When was WebSocket First Discovered?
WebSocket was first referred to as TCP Connection in the HTML5 specification, as a placeholder for the TCP socket-based API. In June 2008, the name WebSocket was created by Ian Hickson and Michael Carter, designed for discussion led by Michael Carter who published the first version of the protocol known as WebSocket.
Benefits of WebSocket
Websocket allows servers to push data to connected clients
Reduces unnecessary network traffic and latency using full duplex over a single connection.
Streaming through a proxy and firewall, supports simultaneous upstream and downstream communication.
Compatible with pre-WebSocket world by switching from HTTP connections to WebSockets.
The problem is solved by the existence of “WebSocket”
The background that underlies the creation of websocket is the demand of several clients who require developers to create real-time web-based applications or real-time applications. Real time application is a place to compile data changes, so at that moment the website in the client browser also changes or the completion of the notification appears. There are other alternatives for the developer concerned, namely the method of polling and long polling.
This polling method sends request data to the server continuously. If only one client makes repeated requests, it might not be a problem, but what if there are several clients who access one server and repeatedly do the Polling method. Then the server will be busy and vulnerable to DDOS attacks.
Long polling method is a polling method with periodic time intervals. So the request is not as often as the Polling method. The benefit is that the server is far more stable than the polling method. But the question is simple, Long Polls do not answer real time, because there are time intervals used.
Websocket emerged in 2009 as a proposal, then developed for 3 years so that WebSocket is now much more stable and has been supported by a variety of browsers.
Cross Origin Communication
Being a modern protocol, cross origin communication is baked right into WebSocket. While you should still make sure only to communicate with clients and servers that you trust, WebSocket enables communication between parties on any domain. The server decides whether to make its service available to all clients or only those that reside on a set of well defined domains.
Every new technology comes with a new set of problems. In the case of WebSocket it is the compatibility with proxy servers which mediate HTTP connections in most company networks. The WebSocket protocol uses the HTTP upgrade system (which is normally used for HTTP/SSL) to “upgrade” an HTTP connection to a WebSocket connection. Some proxy servers do not like this and will drop the connection. Thus, even if a given client uses the WebSocket protocol, it may not be possible to establish a connection. This makes the next section even more important 🙂
Use WebSockets Today
WebSocket is still a young technology and not fully implemented in all browsers. However, you can use WebSocket today with libraries that use one of the fallbacks mentioned above whenever WebSocket is not available. A library that has become very popular in this domain is socket.io which comes with a client and a server implementation of the protocol and includes fallbacks (socket.io doesn’t support binary messaging yet as of Februrary 2012). There are also commercial solutions such as PusherApp which can be easily integrated into any web environment by providing a HTTP API to send WebSocket messages to clients. Due to the extra HTTP request there will always be extra overhead compared to pure WebSocket.
The Server Side
Using WebSocket creates a whole new usage pattern for server side applications. While traditional server stacks such as LAMP are designed around the HTTP request/response cycle they often do not deal well with a large number of open WebSocket connections. Keeping a large number of connections open at the same time requires an architecture that receives high concurrency at a low performance cost. Such architectures are usually designed around either threading or so called non-blocking IO.
The wire protocol (a handshake and the data transfer between client and server) for WebSocket is now RFC6455. The latest Chrome and Chrome for Android are fully compatible with RFC6455 including binary messaging. Also, Firefox will be compatible on version 11, Internet Explorer on version 10. You can still use older protocol versions but it is not recommended since they are known to be vulnerable. If you have server implementations for older versions of WebSocket protocol, we recommend you to upgrade it to the latest version.
Use WebSocket whenever you need a truly low latency, near realtime connection between the client and the server. Keep in mind that this might involve rethinking how you build your server side applications with a new focus on technologies such as event queues. Some example use cases are:
- Multiplayer online games
- Chat applications
- Live sports ticker
- Realtime updating social streams