Presented By
NANDAN P

---

[attachment=10835]
ABSTRACT
Nowadays internet environment is getting sophisticated with the help of advanced web applications and improved connection speeds. But the base technology (protocols in layers) which we are using is not getting updated for today’s weighted web applications and browsers, which has lead to slow browsing. Hence Google initiative chromium group has developed an over fixing protocol called SPDY protocol (spelled Speedy protocol) which can fix up to 52% hike of speed in browsing.
Here are some major bottlenecks of HTTP protocol which has lead to slow browsing,
• More number of connection setup requests, which are overhead.
• Slow-start delays.
• Opening too many connections from one server.
• Poor pipelining requests.
• Other application layer problems.
SPDY protocol is a framing layer which multiplexes multiple, concurrent streams across a single TCP connection. The framing layer is optimized for HTTP-like request-response streams. This concentrates on resolving the above problems. The three basic improvements of SPDY over HTTP are,
• Multiplexed requests - No limit to the number of requests that can be issued concurrently over a single SPDY connection.
• Prioritized requests - Clients can request certain resources to be delivered first.
• Compressed headers – headers are compressed to save a significant amount of latency and bandwidth.
Introduction
SPDY (Speedy) Protocol is an application layer protocol built by chromium projects, which is a part of Google initiatives “Let’s make the web faster”. This protocol is built to reduce the latencies in the web pages.
This protocol is used for transporting content over the web, and it has been designed specifically for minimal latency. In addition to a specification of the protocol, they have developed a SPDY-enabled Google Chrome browser and open-source web server.
SPDY enabled browser is now available to experience, i.e. Google Chrome 6.0 is fastest web browser among its competent, even though it may have many components to speed up the browsing, SPDY is one among them. Lab tests has been conducted, and observed that there was 64% reduction in time for loading the pages. And hence SPDY protocol speeds up around 50% of less latency compared to HTTP protocol.
SPDY protocol is a framing layer which multiplexes multiple, concurrent streams across a single TCP connection. The framing layer is optimized for HTTP-like request-response streams.
About Web protocols and web latency
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 they believe that there may be opportunities to improve latency at the transport layer, their 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 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 are 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.
Previous approaches
SPDY is not the only research to make HTTP faster. There have been other proposed solutions to web latency, mostly at the level of the transport or session layer:
• Stream Control Transmission Protocol (SCTP) -- a transport-layer protocol to replace TCP, which provides multiplexed streams and stream-aware congestion control.
• HTTP over SCTP -- a proposal for running HTTP over SCTP. Comparison of HTTP Over SCTP and TCP in High Delay Networks describes a research study comparing the performance over both transport protocols.
• Structured Stream Transport (SST) -- a protocol which invents "structured streams": lightweight, independent streams to be carried over a common transport. It replaces TCP or runs on top of UDP.
• MUX and SMUX -- intermediate-layer protocols (in between the transport and application layers) that provide multiplexing of streams. They were proposed years ago at the same time as HTTP/1.1.
These proposals offer solutions to some of the web's latency problems, but not all. The problems inherent in HTTP (compression, prioritization, etc.) should still be fixed, regardless of the underlying transport protocol. In any case, in practical terms, changing the transport is very difficult to deploy. Instead, we believe that there is much low-hanging fruit to be gotten by addressing the shortcomings at the application layer. Such an approach requires minimal changes to existing infrastructure, and (we think) can yield significant performance gains.
Goals of SPDY Protocol
The SPDY project defines and implements an application-layer protocol for the web which greatly reduces latency. The high-level goals for SPDY are:
• To target a 50% reduction in page load time. Preliminary results have come close to this target (see further for results).
• To minimize deployment complexity. SPDY uses TCP as the underlying transport layer, so requires no changes to existing networking infrastructure.
• To avoid the need for any changes to content by website authors. The only changes required to support SPDY are in the client user agent and web server applications.
• To bring together like-minded parties interested in exploring protocols as a way of solving the latency problem. They hope to develop this new protocol in partnership with the open-source community and industry specialists.
Some specific technical goals are:
• To allow many concurrent HTTP requests to run across a single TCP session.
• To reduce the bandwidth currently used by HTTP by compressing headers and eliminating unnecessary headers.
• To define a protocol that is easy to implement and server-efficient. We hope to reduce the complexity of HTTP by cutting down on edge cases and defining easily parsed message formats.
• To make SSL the underlying transport protocol, for better security and compatibility with existing network infrastructure. Although SSL does introduce a latency penalty, we believe that the long-term future of the web depends on a secure network connection. In addition, the use of SSL is necessary to ensure that communication across existing proxies is not broken.
• To enable the server to initiate communications with the client and push data to the client whenever possible.
SPDY design and features
SPDY adds a session layer atop of SSL that allows for multiple concurrent, interleaved streams over a single TCP connection.
The usual HTTP GET and POST message formats remain the same; however, SPDY specifies a new framing format for encoding and transmitting the data over the wire.
Streams are bi-directional, i.e. can be initiated by the client and server.
SPDY aims to achieve lower latency through basic (always enabled) and advanced (optionally enabled) features.
Basic features
• Multiplexed streams
SPDY allows for unlimited concurrent streams over a single TCP connection. Because requests are interleaved on a single channel, the efficiency of TCP is much higher: fewer network connections need to be made, and fewer, but more densely packed, packets are issued.
• Request prioritization
Although unlimited parallel streams solve the serialization problem, they introduce another one: if bandwidth on the channel is constrained, the client may block requests for fear of clogging the channel. To overcome this problem, SPDY implements request priorities: the client can request as many items as it wants from the server, and assign a priority to each request. This prevents the network channel from being congested with non-critical resources when a high priority request is pending.
• HTTP header compression
SPDY compresses request and response HTTP headers, resulting in fewer packets and fewer bytes transmitted.
Advanced features
In addition, SPDY provides an advanced feature, server-initiated streams. Server-initiated streams can be used to deliver content to the client without the client needing to ask for it. This option is configurable by the web developer in two ways:
• Server push.
SPDY experiments with an option for servers to push data to clients via the X-Associated-Content header. This header informs the client that the server is pushing a resource to the client before the client has asked for it. For initial-page downloads (e.g. the first time a user visits a site), this can vastly enhance the user experience.
• Server hint.
Rather than automatically pushing resources to the client, the server uses the X-Subresources header to suggest to the client that it should ask for specific resources, in cases where the server knows in advance of the client that those resources will be needed. However, the server will still wait for the client request before sending the content. Over slow links, this option can reduce the time it takes for a client to discover it needs a resource by hundreds of milliseconds, and may be better for non-initial page loads.