232 Chapter 9—WebSockets
GET determines the method for the request; in this case we want to get informa-
tion from the server. The second part is the URI; here, we call the script search
with the parameter q=html5. In the third part we specify the protocol version 1.0.
The server promptly replies with the following information:HTTP/1.0 200 OK
Cache-Control: private, max-age=0
Date: Fri, 28 Jan 2011 08:29:43 GMT
Expires: -1
Content-Type: text/html; charset=ISO-8859-1
...<!doctype html><head><title>html5 - Google Search</title>
....The first block of the message, the header, contains meta information separated
by an empty line from the following payload data (note how Google is already
using the new DOCTYPE). This gives us almost everything we need to program our
very own browser. Joking aside, the simplicity of the protocol is decisive for the
quick success and widespread use of HTTP. The header lines are nearly endlessly
expandable, making the protocol future-proof.
Each request is a closed issue after it has been answered. So, an HTML page
referencing a stylesheet and five images needs seven connections to load. This
means that a connection is established seven times, and each time metadata
and payload is transmitted. In version 1.1 of HTTP, this behavior was somewhat
improved by the keepalive function (new TCP connections do not need to be
created every time), but the meta information for each object is transmitted
separately. To track a user’s session, you need to resort to other tools (sessions,
cookies), because HTTP has not integrated this function.
These considerations provide the starting points for developing a new protocol,
which is by no means meant to replace HTTP but can complement it. The Web-
Sockets protocol transports data without meta information in a constant stream,
simultaneously from the server to the client and vice versa (full duplex).
Web applications that promptly show small changes in the browser can espe-
cially profit from this new method. Examples of such applications are a chat
program, the display of stock exchange prices, or online games. What was pre-
viously only possible via proprietary plug-ins or unpleasant JavaScript tricks is
now codified in a standardized protocol (as an IETF draft) and an associated API
(currently as an Editor’s Draft with the W3C). Both were still in a very early stage
at the time of this writing; however, both the WebKit engine (and thus Google
Chrome and Safari) and the Beta version of Mozilla Firefox contain a functioning
implementation.
We do not want to penetrate the depths of the WebSocket protocol, because the
communication on the protocol level is taken care of by the browser anyway.