INRODUCTION:

As part of the "Let's make the web faster" initiative, we are experimenting with alternative protocols to help reduce the latency of web pages. One of these experiments is SPDY (pronounced "SPeeDY"), an application-layer protocol for transporting content over the web, designed specifically for minimal latency

Being unhappy with the performance of the venerable hypertext transfer protocol (HTTP), researchers at Google , Mike Belshe and Roberto Peon, think they can do better.

The main problem with HTTP is that today, it's used in a way that it wasn't designed to be used. HTTP is very efficient at transferring an individual file. But it wasn't designed to transfer a large number of small files efficiently, and this is exactly what the protocol is called upon to do with today's websites. Pages with 60 or more images, CSS files, and external JavaScript are not unusual for high-profile Web destinations. Loading all those individual files mostly takes time because of all the overhead of separately requesting them and waiting for the TCP sessions HTTP runs over to probe the network capacity and ramp up their transmission speed. Browsers can either send requests to the same server over one session, in which case small files can get stuck behind big ones, or set up parallel HTTP/TCP sessions where each must ramp up from minimum speed individually. With all the extra features and cookies, an HTTP request is often almost a kilobyte in size, and takes precious dozens of milliseconds to transmit. In an attempt to avoid these issues, SPDY uses a single SSL-encrypted session between a browser and a client, and then compresses all the request/response overhead. The requests, responses, and data are all put into frames that are multiplexed over the one connection. This makes it possible to send a higher-priority small file without waiting for the transfer of a large file that's already in progress to terminate. Compressing the requests is helpful in typical ADSL/cable setups, where uplink speed is limited. For good measure, unnecessary and duplicated headers in requests and responses are done away with. SPDY also includes real server push and a "server hint" feature.

In addition to a specification of the protocol, we have developed a SPDY-enabled Google Chrome browser and open-source web server. In lab

tests, we have compared the performance of these applications over HTTP and SPDY, and have observed up to 64% reductions in page load times in SPDY. We hope to engage the open source community to contribute ideas, feedback, code, and test results, to make SPDY the next-generation application protocol for a faster web

Background: 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 othertransport 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 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.

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.

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.

Optional data compression. HTTP uses optional compression encodings for data. Content should always be sent in a compressed format. 

Goals for SPDY :

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. Our preliminary results have come close to this target

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. We 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 withoutthe 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.

Initial Results :

Initial Results - Testing Methods :

3 major variables on the network o Packet Loss o Bandwidth o Round-Trip-Time

• Looking at any one configuration is anecdotal, need to look at a spectrum of data.

• Our test content includes:

• high-fidelity copies of top-25 web pages. o includes exact HTTP headers, compression, etc.

• Packet loss simulators stink (random loss is not realistic) o We don't have a good model. o We don't have a good simulator.

Spdy data:

Overall network efficiency of SPDY compared to HTTP. A lot of the speed benefits of flip come from simply using the network more efficiently. Using fewer connections means fewer packets. Using more compression,means fewer bytes. Due to multiplexing, SPDY turns HTTPs many virtually half-duplex channels into a single, full duplex channel.

TEST: Download the same "top 25" pages via HTTP and SPDY Network simulates a 2Mbps DSL link, 0% packet loss.

When used loading our top-25 web pages, SPDY sent 40% fewer packets and 15% fewer bytes than the same pages loaded over HTTP.

Here is a graph of SPDY and HTTP, measuring the top-25 web pages as the packet loss rate varies. Packet loss is an area ripe for more research; generally we believe global worldwide packet loss is ~1 to 1.5%. Some areas are better, and some areas are worse.

Initial Results: Header Compression

On low-bandwidth links, headersare surprisingly costly. Headers alone can cost more than 1s of latency.

Initial Results: Page Load Time top-25:

Initial Results: Page Load Time :

Deployment: Process of Elimination :

•Hoping to avoid changing the lower-level transport o Much easier "burden of proof" o Works with existing infrastructure • Available transports: o TCP, UDP are possible. o SCTP not an option due to NAT. • UDP o We'd have to re-engineer TCP features. • That leaves us with TCP. o Only two ports available universally Port 80? And port 443?

Deployment: Port 80 :• Should be our first choice.• Except HTTP runs on port 80.• Proxies and intermediates make for

a treacherous environment.o HTTP/1.1 1999 - Pipelining still not deployedo Compression negotiation• WebSockets Data Shows that using HTTP over a nonstandardport is less tampered with than port 80.o Success rate: HTTP (port 80) 67% HTTP (port 61985) 86% HTTPS (port 443) 95%

Deployment: Port 443 :• Port 443 runs SSL/TLS.o Added benefit of server authentication & encryption• Handshake is extensible:• But isn't TLS too slow?o CPU issues are minoro CPU for bulk encryption is near-zero cost.o TLS does increase bandwidth by 2-3%Mitigated by SPDY better compression.o Round Trip Times are significanto SSL requires 2 or 1 RTs for the handshake Can we reduce to 1 or 0 RTs?SSL Handshakes :• Top-25 pages• ~23% benefit SSL• ~14% benefit withSSL• Naively we thoughtSSL had onehandshake per pageload.• It actually has onehandshake per"wave

It's not the bandwidth• Let's see an example:o Fix RTT at 60ms, 0% packet loss, vary bandwidtho Fix bandwidth at 5Mbps, 0% loss, vary RTT

Latency (page load time) decreases as the bandwidth increases. Note the

diminishing returns.

Viewed another way, here is the percent latency reduction for each Mbps of bandwidth added.

Increasing from 5Mbps to 10Mbps is ~5% benefit to page load time.

With a 60ms RTT, effective bandwidth taps out at about 1.6Mbps

. Now we vary the RTT for a fixed bandwidth.

Reducing RTT, always helps reduce PLT.

Viewed another way, here is the percentageimprovement for each 20ms of RTT reduced.

Effective bandwidth is better for low RTT

Here is a graph of SPDY and HTTP, measuring the top-25 web pages as the packet loss rate varies. Packet loss is an area ripe for more research; generally we believe global worldwide packet loss is ~1 to 1.5%. Some areas are better, and some areas are worse.

Here is a graph of SPDY and HTTP average page load times as the RTT (round-trip time) varies. RTT can be as low as 5-10ms for high speed networks, or 500ms for some mobile or distant networks. Satellite links, known for their high throughput, still have high latency, and can have RTTs of 150ms or more. Generally, a 20ms RTT is great, 50ms RTT is not too shabby, and a 115ms RTT is about average.

SPDY implementation: what they’ve built

This is what we have built: A high-speed, in-memory server which can serve both HTTP and SPDY

responses efficiently, over TCP and SSL. We will be releasing this code as open source in the near future.

A modified Google Chrome client which can use HTTP or SPDY, over TCP and SSL. The source code is at http://src.chromium.org/viewvc/chrome/trunk/src/net/spdy/. (Note that code currently uses the internal code name of "flip"; this will change in the near future.)

A testing and benchmarking infrastructure that verifies pages are replicated with high fidelity. In particular, we ensure that SPDY preserves origin server headers, content encodings, URLs, etc. We will be releasing our testing tools, and instructions for reproducing our results, in the near future

NEW STEP CHALLENGES AND CONCLUSION :

Our initial results are promising, but we don't know how well they represent the real world. In addition, there are still areas in which SPDY could improve. In particular:

Bandwidth efficiency is still low. Although dialup bandwidth efficiency rate is close to 90%, for high-speed connections efficiency is only about ~32%.

SSL poses other latency and deployment challenges. Among these are: the additional RTTs for the SSL handshake; encryption; difficulty of caching for some proxies. We need to do more SSL tuning.

Our packet loss results are not conclusive. Although much research on packet-loss has been done, we don't have enough data to build a realistic model model for packet loss on the Web. We need to gather this data to be able to provide more accurate packet loss simulations.

SPDY single connection loss recovery sometimes underperforms multiple connections. That is, opening multiple connections is still faster than losing a single connection when the RTT is very high. We need to figure out when it is appropriate for the SPDY client to make a new connection or close an old connection and what effect this may have on servers.

The server can implement more intelligence than we have built in so far. We need more research in the areas of server-initiated streams,

obtaining client network information for prefetching suggestions, and so on.

So should we all praise Google and switch to SPDY forthwith? Not quite yet. With the mandatory SSL encryption and gzip compression, SPDY will hit server and client CPUs much harder than traditional HTTP. Of course HTTP also runs over SSL in many cases, but there's also lots of content out there that doesn't need encryption. Making SSL mandatory is a strange move that has the potential to increase the number of people who don't bother getting a proper certificate for their server, meaning that users will become even more blas� about ignoring the resulting security warnings. This, in turn, would pave the way for more man-in-the-middle attacks

On small devices, SSL slows down the communication significantly, and because it can't be cached, SSL-protected sites are often slower on big machines as well. The extra CPU cycles also mean that more servers are needed to handle the same number of clients

It also looks like this protocol is designed by Web people, rather than network people. How the IETF applications area will respond to this effort is a big unknown. For instance, one thing that isn't mentioned in theprotocol specification is how a browser knows that it should set up a SPDY connection rather than an HTTP connection. Are we going to see SPDY:// in URLs rather than HTTP:// ? That wouldn't work with browsers that don't support the new protocol

It's for reasons like this that the IETF isn't a big fan of replacing protocols wholesale. It's much more in line with the IETF way of doing things to add the new features proposed in SPDY to a new—but backward-compatible—version of HTTP. Designing a new protocol that does everything better than an existing protocol usually isn't the hard part. The real difficulty comes in providing an upgrade path that allows all the Internet users to upgrade to the new protocol in their own time such that everything keeps working at every point along that path.

This is something the SPDY developers recognize. There are proposals for running HTTP over SCTP, a protocol similar to TCP, but with the ability to multiplex several data streams within a single session. That would have some of the same advantages as SPDY. Unfortunately, most home gateways don't know about SCTP and can only handle TCP and UDP, so HTTP over SCTP would

face a long, uphill battle, not unlike IPv6, but without the ticking clock that counts down the available IPv4 addresses

That said, it's good to see interest in improving the underlying technologies that power the Web, and Google should be applauded for taking the discussion in a new direction. There's still a lot to be done in this space

ABSTRACT

Google want to reduce page load times on the Web, and decided to build a protocol for it. After a relentless hard work engineers are able to design a protocol which is able to lessen the page load time on the web. The protocol was coined by name as “SPDY (SPeeDY). Traditionally we are using HTTP over TCP protocol to transfer a web page on net. But the page load event is little bit cumbersome on today world due to proliferation of sophisticated net users. To mitigate the PLT is the motivation behind SPDY protocol. Here the reduction of page load time done by multiplexing string, compressing request and response header, prioritization of the client request, using server push and server hint. In addition to a specification of the protocol, Google have developed a SPDY-enabled Google Chrome browser and open-source web server. In lab tests, they have compared the performance of these applications over HTTP and SPDY, and have observed up to 64% reductions in page load times in SPDY. That said, it's good to see interest in improving the underlying technologies that power the Web, and Google should be applauded for taking the discussion in a new direction. There's still a lot to be done in this space we hope to engage the open source community to contribute ideas, feedback, code, and test results, to make SPDY the next-generation application protocol for a faster web

Submitted by

ACKNOWLEGMENT

I take this opportunity to express my

hearty thanks to all those who individually

as well as collectively helped me in this

successful completion of this seminar.

I am indebted to Mr. N.K Kamilla, HOD,

Computer science and engineering & other

faculty members for giving me an

opportunity to learn and do this seminar .If

not for the above mentioned people my

seminar never have been completed

successfully. I once again extend my

sincere thanks to all of them.

Submitted by