Thursday, 8 November 2012

WEBSOCKETS for highspeed internet

We always want to run apps like chat, news feeds, live tickers and games in a browser without having to install plug-ins. Apps should run in real time and automatically stay up-to-date. However, the classic design of the Internet was not planned for modern Rich Internet Applications and has caused developers a lot of trouble to get RIA apps up and running. A complete transformation in the client-server communication model was needed. Real time, bidirectional connections were the way forward from the single-track question-answer model of HTTP, and the adoption of the WebSocket protocol by W3C and IETF in December 2011 helped spur the change. Web-Apps no longer need complicated HTTP workarounds any more; they run faster and more easily via WebSockets.

HTTP is a one-way street

In order to send or load data over a network, the client opens a TCP (Transmission Control Protocol) connection to a server. TCP couples the IP addresses and ports of both the client and server, and is concerned with flawless data transmission between the two. However, since information must not only be transferred but be understood as well, an application protocol runs above the TCP layer, over which the client and server communicate. In the case of websites, the application protocol is mostly HTTP, and although TCP off ers bidirectional data transmission as a virtually blind transport layer, HTTP does not use this option. The protocol allows one to send push messages from the server to the client, just as much as we need for modern web applications. HTTP works according to a simple pattern - the client queries and the server replies. This pattern is slow and expensive. Workarounds are available to programmers so that users don’t have to continually update the page, some of which suggest live communication over HTTP. The easiest workaround is polling, which involves a script in the browser querying the server about new events at set intervals. Polling sets up a new connection for each request, which the server ends after it replies - even though it has no changes to report. This takes time, and increases traffic through the overhead and the network load by frequently rebuilding TCP connections. Long polling goes one step further by maintaining the connection until the server has events to report. This shortens the latency between the event and the response, but causes traffi c and network congestion. HTTP streaming is one of the best workarounds. In this, the connection remains open for a long time and the server can send data at irregular sequences. The disadvantage of HTTP streaming is the expensive implementation of JavaScript objects and XMLHttpRequests, which is not similar in all browsers. Besides, you always need two HTTP connections for bidirectional real time communication.

WebSockets are quick and efficient

The WebSocket protocol solves these problems by installing a socket that holds a permanent channel for the server via an IP address and a port. This enables both end points to send data simultaneously without requests over the same connection. WebSocket uses an almost forgotten function in the HTTP Handshake for establishing a connection - changing the protocol via an upgrade. This option originally helped code unencrypted Port 80-connections via TLS upgrades, but was never used. Websocket now brings the upgrade back and uses it to replace the old protocol with WebSocket via the HTTP- Handshake. The browser implementation of Websocket API runs over a JavaScript object. Active WebSocket connections can be recognized by the URL pattern “ws” or “wss”. In order to ensure that only permissible WebSocket end points speak with each other, the developers have added some security features in the HTTP header - the client generates a base-64-encoded security key, which the server supplements by a standard string, creates an SHA-1-hash value from that, encodes it and sends it back to the client. This lets both the end points ensure that they are using the WebSocket protocol. The original specifications in the request also protect a WebSocket server from unwanted attacks from unknown sources so that only known or supported clients can establish connections. The last important protection mechanism occurs after the HTTP Handshake. The WebSocket client must encrypt every data package with a simple XOR template so that the interconnected proxy servers do not mistake the WebSocket traffic as HTTP requests. If the data packages are not encrypted, it is possible for malicious scripts to control affected Proxy servers and misuse them for attacks against other users. However, since the proxy servers cannot read encrypted traffi c, they simply forward it to the specified end point. At the moment, not all browsers support the Websocket protocol. However, this will change in the next few months, as WebSocket only offers advantages with Internet applications moving closer to users, growing into multi-faceted objects and running faster.


Posts a comment

© 2012 CodeCows | privacy policy | Terms and Conditions | Sitemap
Reproduction without explicit permission is prohibited.
All content except photos and videos copyright © 2011-2012, Codecows.
All rights reserved. *Any images or videos on this site are not mine and are copyright to their respectful owners unless otherwise noted and were used under creative common license or fair use standards. IF A PHOTO OR VIDEO IS YOUR MATERIAL AND YOU DO NOT WISH IT TO BE ON THE SITE, PLEASE EMAIL ME AND I WILL REMOVE IT IMMEDIATELY
Back to top