Websocket: Internet In Real Time

7/10/2012 3:42:50 PM

The protocol WebSocket ensures more speed on the Internet. With that, Apps run in the browser just like on the desktop. By Frederik Niemeyer

Description: The protocol WebSocket ensures more speed on the Internet

The protocol WebSocket ensures more speed on the Internet

Chats, newsfeeds, games: we always want to run such applications in the browser, without having to first install plug-ins. Naturally, the Apps should run in real time and automatically stay up-to-date. The classic net design was not planned for these modern rich internet applications and caused several problems for the developers in the course. A complete transformation in the client server communication was needed: away from the single-track question-answer model from HTTP up to the bidirectional connections in real time. This has happened with the adoption of WebSocket protocol by W3C and IETF in December 2011. Web-Apps do not need complicated HTTP- workarounds anymore; they run faster and easier via WebSockets.

HTTP is a one-way street

Description: HTTP is a one-way street

HTTP is a one-way street

In order to send or load data over a network, the client opens a TCP connection (Transmission control protocol) to a server. TCP couples IP addresses and ports of the endpoints and is concerned with the flawless data transmission between the two. However, since information must not only be transferred but also be understood, an application protocol runs above the TCP layer, over which the client and server communicate. In the case of websites, it is mostly HTTP (Hypertext transfer protocol). Although TCP offers bidirectional data transmission as a virtually blind transport layer, HTTP does not use this option. Just as little, the protocol allows sending push messages from the server to the client, as we need for modern web applications. HTTP works according to a simple pattern: the client asks; the server replies. That is slow and expensive.

Description: The complexity of Comet applications
The complexity of Comet applications

In order that the users don't have to press the update button continuously, Workarounds are provided to the programmers, which suggest live communication over HTTP. The easiest method is polling. There, a script in the browser asks the server about new events, at set intervals. Polling sets up a new connection for every request, which the server ends after the reply even though it has no changes to report. This costs time, increases the traffic through the overhead and the network load by the frequent rebuilding of TCP connection. Long polling goes one step further by maintaining the connection till the server has events to report. This shortens the latency between the event and the response, but also causes traffic and network congestion.

HTTP streaming is the best method: The connection remains open for a long time here, while the server can send data in an irregular sequence. The disadvantage is the expensive implementation of the JavaScript object, XML HTTP request, which is not the same in all browsers. Besides, you always need two HTTP connections for bidirectional real time communication.

WebSockets are quick and efficient

Description: Kaazing WebSocket Gateway extends TCP-based messaging to the browser with ultra high performance

Kaazing WebSocket Gateway extends TCP-based messaging to the browser with ultra high performance

The WebSocket protocol solves these problems by installing a socket, which holds a permanent channel for the server via an IP address and a port. In this way, both endpoints can send data simultaneously without request over the same connection. WebSocket uses an almost forgotten function in HTTP Handshake for establishing a connection: changing protocol via upgrade. This option originally helped to code unencrypted Port-80-connections via TLS upgrade, but was never used. Websocket now introduces the upgrade again and uses it to replace the old protocol by WebSocket via the HTTP- Handshake. The browser implementation of Websocket API runs over a JavaScript object. Active WebSocket connections can be recognized in the link line in the URI pattern, "ws" or "wss".

In order to ensure that only permissible WebSocket end points speak with each other, the developers have added some security mechanisms in the HTTP header: The Client generates a base-64- coded security key in his request, which the server supplements by a standard string, creates an SHA-1-hash value from that, even encodes it and sends it back to the client. In this way, both the end points ensure that they use the WebSocket protocol. The original specifications in the request also protect a WebSocket server from unwanted attacks from unknown sources so that only the known or supported clients can establish connections.

The last important protection mechanism occurs after 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. Without encryption of the data packages it is possible for malicious scripts to control the affected Proxy servers and to misuse attacks against other users. However, since the proxy servers cannot read the encrypted traffic, they simply forward it to the specified endpoint.

At the moment, not all browsers support the latest Websocket protocol. But, this will change in the next few months, as WebSocket only offers advantages: Internet applications are moving closer to the user, becoming multi-faceted and running faster.

Video tutorials
- How To Install Windows 8

- How To Install Windows Server 2012

- How To Install Windows Server 2012 On VirtualBox

- How To Disable Windows 8 Metro UI

- How To Install Windows Store Apps From Windows 8 Classic Desktop

- How To Disable Windows Update in Windows 8

- How To Disable Windows 8 Metro UI

- How To Add Widgets To Windows 8 Lock Screen

- How to create your first Swimlane Diagram or Cross-Functional Flowchart Diagram by using Microsoft Visio 2010
programming4us programming4us