http://sites.google.com/a/chromium.org/dev/spdy/spdy-whitepaper
---- Begin Extract -----
Today, HTTP and TCP are the protocols of the web. TCP is the generic,
reliable transport protocol, providing guaranteed delivery, duplicate
suppression, in-order delivery, flow control, congestion avoidance and
other transport features. HTTP is the application level protocol
providing basic request/response semantics. While we believe that
there may be opportunities to improve latency at the transport layer,
our initial investigations have focussed on the application layer,
HTTP.
Unfortunately, HTTP was not particularly designed for latency.
Furthermore, the web pages transmitted today are significantly
different from web pages 10 years ago such and demand improvements to
HTTP that could not have been anticipated when HTTP was developed. The
following are some of the features of HTTP that inhibit optimal
performance:
* Single request per connection. Because HTTP can only fetch one
resource at a time (HTTP pipelining helps, but still enforces only a
FIFO queue), a server delay of 500 ms prevents reuse of the TCP
channel for additional requests. Browsers work around this problem by
using multiple connections. Since 2008, most browsers have finally
moved from 2 connections per domain to 6.
* Exclusively client-initiated requests. In HTTP, only the client
can initiate a request. Even if the server knows the client needs a
resource, it has no mechanism to inform the client and must instead
wait to receive a request for the resource from the client.
* Uncompressed request and response headers. Request headers today
vary in size from ~200 bytes to over 2KB. As applications use more
cookies and user agents expand features, typical header sizes of
700-800 bytes is common. For modems or ADSL connections, in which the
uplink bandwidth is fairly low, this latency can be significant.
Reducing the data in headers could directly improve the serialization
latency to send requests.
* Redundant headers. In addition, several headers are repeatedly
sent across requests on the same channel. However, headers such as the
User-Agent, Host, and Accept* are generally static and do not need to
be resent.
* Optional data compression. HTTP uses optional compression
encodings for data. Content should always be sent in a compressed
format.
---- End Extract ----
Now it still says its using the HTTP methods so I'd guess its still
"REST" compliant, the main differences being that with the server
pushing information to the client it might break some of those
"stateless" pieces.
Its good to see people taking the latency problem seriously and
looking for a fix.
Steve
