CASE STUDY ON

INTERNET TECHNOLOGY (SPDY PROTOCOL)

Date Of Submission

28th Feb 2011

1

SUBMITTED BY:-

SONAM K SINGH 26

JAI S KADAM 29

TO

DEPARTMENT OF INFORMATION TECHNOLOGY

KET’s V.G.VAZE COLLEGE OF SCIENCE, COMMERCE AND ARTS

MITHAGAR ROAD, MULUND (E), MUMBAI -081

PROFESSOR INCHARGE

Mrs. Poornima

2

Introduction:-

SPDY, pronounced “SPeeDY”, is an early-stage research project that is a part of effort to “make the web faster”. SPDY, is a protocol invented by Google to speed up data transfers over the Internet, instead of HTTP. It is an application-layer protocol for transporting content over the web, designed specifically for minimal latency. SPDY is Google Chrome browser enabled and open-source web server.  The initial results are very encouraging. The downloading of the top 25 websites over simulated home network connections, it has been a significant improvement in performance - pages loaded up to 55% faster. SPDY is able to handle multiple streams of data at once and prioritize on the fly. This means that if the background image of a site takes a long time to load, it doesn't stall the rest of the content from being fed to the browser. SPDY also compresses request and response data (which asks for specific content and tells a browser what to display) so that multiple requests can be sent at once using less bandwidth. In simple terms this means much faster Web applications and more responsive sites.

Goals for SPDY:-

The high-level goals for SPDY are:

To target a 50% reduction in page load time.

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.

3

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. 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, as 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.

Why there is need arise for the development of new web based protocol?

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

4

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.

Why HTTP haven’t switched to the SPDY protocol ??

 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 blast about ignoring the resulting security warnings. This, in turn, would pave the way for more man-in-the-middle attacks. 

Will this going to be happen???

No, because SPDY will create a session of sorts that resides between HTTP and the data transportation.

5

Google argues that HTTP is showing signs of age. Among the issues:

HTTP can only fetch one file from a server at a time. Modern browsers run up to six simultaneous connections, but the process is still less than ideal. To see why, load a complex Web site and watch the status-bar indicator churn through dozens or hundreds of page elements one after the other.

HTTP requests must all be initiated by the Web browser; this means servers have no choice but to sit waiting for the client

6

to ask for each individual piece. Think of that old lady counting out $9 in 5c pieces in front of you at the 7-Eleven, and you get a pretty good picture of what's going on.

HTTP isn't compressed or tokenised, with headers from between 200 bytes to 2000 bytes resulting in lots of wasted bandwidth – and severely impacted performance over modems and slower ADSL connections.

Data cannot be natively compressed using HTTP, which also has a habit of overcompensating by sending too many packet requests per channel.

SPDY design and features:-

Application

Session

Presentation

Transport

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:-

7

HTTP

SPDY

SSL

TCP

Multiplexed Stream :-

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:-

8

Rather than automatically pushing resources to the client, the server uses the X-Sub-resources 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.

SPDY Proxy Design:-

One potential use for SPDY is to provide fast, secure access to a proxy.  For instance, if we had a forward proxy which took SPDY requests from the client and could issue HTTP requests to the web, then we could leverage the benefits of SPDY over the Client->Proxy link without needing to upgrade the entire web.  Some environments where this could be particularly useful include:

Mobile networks, where RTTs are very high Public networks, where local WiFi or other protocols may be

insecure, but SPDY connections to a secure proxy could add a layer of protection.

To implement a SPDY proxy, several changes to Chromium are required:

SPDY protocol support Chromium Secure-Proxy support Tunneling of SSL connections over a SPDY proxy PAC support

SPDY Protocol Support :-

This work is largely done as part of the basic SPDY project. URLs in SPDY requests are already fully qualified and therefore need no changes to work with a proxy.  Similar to with HTTP, some slight header changes need to be made when communicating with the proxy to support proxy Authentication to a SPDY proxy.

9

Chromium Secure-Proxy support :-

Browsers today do not support secure proxies.  Although proxies can tunnel SSL, connectivity to the proxy itself is only over HTTP.  To support SPDY, we need to modify chromium to support a SSL-based proxy.

Tunneling of SSL connections over a SPDY proxy :-

The network stack today only supports a single layer of SSL to the origin server.  Once we introduce a secure proxy, we must modify the browser to be able to speak SSL to the Proxy, and then be able to tunnel another SSL stack (for end-to-end) connectivity over that.

Tunneling of SSL connections over SPDY will be similar to tunneling of SSL connections over HTTP.  We'll first issue a CONNECT request to the proxy, and when that succeeds, upgrade a SPDY stream into a tunneled SSL mode.

PAC Support :-

To support a SPDY proxy, we plan to modify Chrome's Proxy-Autoconfiguration format.  Today, FindProxyForURL() can return "PROXY proxy.foo.com" to indicate that a resource should be fetched through a proxy.  We plan to augment the format of this file so that secure proxies (potentially HTTP over SSL as well as SPDY over SSL) can be used.  To do so, FindProxyForURL() can return a string such as "HTTPS proxy.foo.com".

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

10

more compression, means fewer bytes.  Due to multiplexing, SPDY turns HTTPs many virtually half-duplex channels into a single, full duplex channel.

When used loading our top-25 web pages, SPDY sent 40% fewer packets and 15% fewer bytes than the same pages loaded over 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.

11

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.

12

13

SPDY proxy example:-

Chrome's support for talking to a SPDY proxy involves a new "HTTPS" proxy type.  When using an HTTPS proxy, Chrome will establish an SSL connection to the proxy.  If the SSL connection negotiated NPN, then Chrome will speak SPDY to the proxy. Otherwise, it will speak HTTP.  In the case of HTTP, an HTTPS proxy behaves exactly like an HTTP Proxy, except for the SSL connection to the client.  In the case of SPDY, Chrome will use the same HTTP Proxy semantics, but frame using SPDY.

The case of fetching HTTPS urls is complicated by the fact that regardless of how the client is speaking to the proxy, an SSL connection will be established (through a tunnel) to the origin server which may, or may not negotiate SPDY.  Depending on the NPN negotiations between the client and the proxy, and the client and the origin, there are actually 4 variations:

1. HTTP to proxy, HTTP to origin2. HTTP to proxy, SPDY to origin3. SPDY to proxy, HTTP to origin4. SPDY to proxy, SPDY to origin

HTTPS URL via SPDY :-

Here, a client uses an HTTPS proxy to fetch an HTTPS url. Since the client does not want the proxy to see the contents of the traffic it will send to the server, the client will establish a tunnel through the proxy, to the origin server, and will then use that tunnel to send the request.  In this example, the origin server negotiates SPDY.

14

Client HTTPS Proxy origin server

*** If an available tunnel to the origin exists, jump to step 19 *** If an available connection to the proxy exists, jump to step 9 *** Client opens TCP connection to Proxy ***

   |---------------------->|                          1) SYN                                                                 |                       |<----------------------|                          2) SYN_ACK                                                             |                       |-------------------->|                           3) ACK 

*** Client performs SSL handshake with Proxy ***

 |---------------------->|                          4) Client Hello                                                                              |<----------------------|                          5) Server Hello                                                       |                       |-------------------->|                         6) Client Key Exchange                                                 |                     |-------------------->|                         7) Client Finished                                                                           |<----------------------|                          8) Server Finished                                *** Client sends CONNECT request to Proxy via SPDY *** 

---------------------->|                          |9) CONNECT origin:443

*** Proxy connects (or reuses connection) to origin ***

|--------------------->|

                           10) SYN                                                                                         |<---------------------|

15

                          11) SYN_ACK                                    |                                                  |--------------------->|                         12) ACK       *** Proxy sends HTTP CONNECT response to client ***    <----------------------|                     13) HTTP/1.1 200 Connection Established                                              *** Client performs SSL handshake with Origin (through proxy tunnel) ***

=============================================>|   14) Client Hello                                                                                   |<=============================================|   15) Server Hello                                                                                   |=============================================>|   16) Client Key Exchange                                                                            |=============================================>|   17) Client Finished                                                                                |<=============================================|   18) Server Finished   

*** Client issues request via SPDY to origin ***

=============================================>|   19)SYN_STREAM                                        stream_id = 1                                    method = GET                                      url = /                                          host = origin *** Origin sends SPDY response to Client ***

<=============================================|   20)SYN_REPLY                                       stream_id = 1                                      status = 200 OK 

After connect response has been received, the client is free to re-use the SPDY session over the SSL tunnel to request additional HTTPS URL from the same origin server via a new SPDY stream.

16

Debugging tools used:-

Chrome

o about:net-internalsThis URL is a magic URL in Chrome which provides data about the chrome network stack.  It has been fully updated to enumerate SPDY frames and status.

Events Tab:  This tab shows network events.  Look for SPDY_SESSSION events and you can see every SPDY frame sent or received by Chrome.

SPDY Tab (Chrome 9+):  This tab shows the current state of existing, active SPDY sessions

o command line flags

Chrome has lots of command line flags to assist with altering SPDY behavior:

--use-spdy=sslForces Chrome to always use SPDY, even if not negotiated over SSL

--use-spdy=no-sslForces Chrome to always use SPDY, but without SSL

--host-resolver-rules="MAP * myspdyserver:8000"If you've got a server running SPDY, and you want content to be fetched from it, even if it doesn't match the URL you are requesting (e.g. you've cached a site and want to play it back to the browser without hitting the real-world site), this rule with alter host resolution for a set of URLs to be your simulated server.

o Chrome Inspector

The existing chrome tools for testing HTTP also work with SPDY.

17

Speed Tracer:- Speed Tracer is an extension for profiling browser internal events, network events and CPU usage.

Chromium page benchmarker:- The page benchmarker can test HTTP and SPDY urls through chrome.

Flip-in-mem-edsm-server:-The flip server is a fully implemented SPDY server or SPDY-to-HTTP gateway.  Full source is available in the chromium tree at net/tools/flip_server

Wireshark SPDY extension

Conclusion :- As SPDY is developed to overcome the problems of HTTP, there are still areas in which SPDY could improve. In particular:

18

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. SPDY need to do more SSL tuning.

The packet loss results are not conclusive. Although much research on packet-loss has been done by the developer team , they don't have enough data to build a realistic model model for packet loss on the Web. They 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 they have built in so far. They need more research in the areas of server-initiated streams, obtaining client network information for prefetching suggestions, and so on

References:-

1) http://dev.chromium.org/spdy/spdy-whitepaper2)http://www.chromium.org/spdy/spdy-proxy-examples 3)http://www.open-mike.org/entry/spdy 4)http://en.wikipedia.org/wiki/SPDY

19

5)http://www.readwriteweb.com/archives/ spdy_google_wants_to_speed_up_the_web.php

6)http://blogs.computerworld.com/15088/ google_spdy_promises_speedy_web_browsing

7)http://news.cnet.com/8301-30684_3-10396574-265.html

20