The protocol WebSocket ensures more speed on
the Internet. With that, Apps run in the browser just like on the desktop. By
Frederik Niemeyer
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
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.
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
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.
