HTML and CSS Reference
In-Depth Information
In Listings 1-1 and 1-2, the total overhead is 871 bytes of solely header information
(that is, no actual data). These two examples show just the request's header information
that goes over the wire in each direction: from the client to the server, and the server to
client, regardless of whether the server has actual data or information to deliver to the
client.
With HTTP/1.0 and HTTP/1.1, the main inefficiencies stem from the following:
•
HTTP was designed for document sharing, not the rich,
interactive applications we've become accustomed to on our
desktops and now the Web
•
The amount of information that the HTTP protocol requires to
communicate between the client and server adds up quickly the
more interaction you have between the client and server
By nature, HTTP is also
half duplex
, meaning that traffic flows in a single direction at
a time: the client sends a request to the server (one direction); the server then responds
to the request (one direction). Being half duplex is simply inefficient. Imagine a phone
conversation where every time you want to communicate, you must press a button, state
your message, and press another button to complete it. Meanwhile, your conversation
partner must patiently wait for you to finish, press the button, and then finally respond
in kind. Sound familiar? We used this form of communication as kids on a small scale,
and our military uses this all the time: it's a walkie-talkie. While there are definitely
benefits and great uses for walkie-talkies, they are not always the most efficient form of
communication.
Engineers have been working around this issue for years with a variety of well-known
methods: polling, long polling, and HTTP streaming.
The Long Way Around: HTTP Polling, Long Polling,
and Streaming
Normally when a browser visits a web page, an HTTP request is sent to the server that
hosts that page. The web server acknowledges the request and sends the response back
to the web browser. In many cases, the information being returned, such as stock prices,
news, traffic patterns, medical device readings, and weather information, can be stale by
the time the browser renders the page. If your users need to get the most up-to-date real-
time information, they can constantly manually refresh the page, but that's obviously an
impractical and not a particularly elegant solution.
Current attempts to provide real-time web applications largely revolve around
a technique called
polling
to simulate other server-side push technologies, the most
popular of which is
Comet
, which basically delays the completion of an HTTP response to
deliver messages to the client.
Polling is a regularly timed synchronous call where the client makes a request to the
server to see if there's any information available for it. The requests are made at regular
intervals; the client receives a response, regardless of whether there's information.
Specifically, if there's information available, the server sends it. If no information is
available, the server returns a negative response and the client closes the connection.
