Google's SPDY: Doubles the speed of Web!

SPDY: An experimental protocol for a faster web
Google is apparently in the early stages of a research project that appears to aim as high as perhaps replacing the HTTP protocol, the fundamental technology that essentially makes the World Wide Web possible.


In a somewhat obscure post on the Chromium blog, the development branch of their Chrome browser, Google reveals they’ve been working on a new protocol dubbed SPDY for “SPeeDY” for its goal of making the web faster.

While HTTP is an “elegantly simple protocol” that has powered the web since 1996, the tone of Google’s post is almost patronizing, as if HTTP were our doddering old uncle that’s had his day and needs to be put out to pasture. Then again, Google’s hubris is perhaps warranted as one of the only companies with enough clout and resources to indeed spur on the “evolution of websites and browsers” with an entirely new protocol designed to speed up the communication between web servers and clients.

They reveal they’ve already got a prototype web server and a Chrome client with built-in SPDY support that they’ve been testing in the lab. With these tools they’ve reportedly been able to see an up to 55% speed increase in page loading, and feel like the project is now stable enough to warrant soliciting feedback from the web community. The SPDY documentation is now available, as well as the source code. Google encourages feedback on the new protocol in the Chromium Google Group.

Google:
Executive summary
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. 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.

SPDY frequently asked questions
Q: Doesn't HTTP pipelining already solve the latency problem?
A: No. While pipelining does allow for multiple requests to be sent in parallel over a single TCP stream, it is still but a single stream. Any delays in the processing of anything in the stream (either a long request at the head-of-line or packet loss) will delay the entire stream. Pipelining has proven difficult to deploy, and because of this remains disabled by default in all of the major browsers.

Q: Is SPDY a replacement for HTTP?
A: No. SPDY replaces some parts of HTTP, but mostly augments it. At the highest level of the application layer, the request-response protocol remains the same. SPDY still uses HTTP methods, headers, and other semantics. But SPDY overrides other parts of the protocol, such as connection management and data transfer formats.

Q: Why did you choose this name?
A: We wanted a name that captures speed. SPDY, pronounced "SPeeDY", captures this and also shows how compression can help improve speed.

Q: Should SPDY change the transport layer?
A: More research should be done to determine if an alternate transport could reduce latency. However, replacing the transport is a complicated endeavor, and if we can overcome the inefficiencies of TCP and HTTP at the application layer, it is simpler to deploy.

Q: TCP has been time-tested to avoid congestion and network collapse. Will SPDY break the Internet?
A: No. SPDY runs atop TCP, and benefits from all of TCP's congestion control algorithms. Further, HTTP has already changed the way congestion control works on the Internet. For example, HTTP clients today open up to 6 concurrent connections to a single server; at the same time, some HTTP servers have increased the initial congestion window to 4 packets. Because TCP independently throttles each connection, servers are effectively sending up to 24 packets in an initial burst. The multiple connections side-step TCP's slow-start. SPDY, by contrast, implements multiple streams over a single connection.

Q: What about SCTP?
A: SCTP is an interesting potential alternate transport, which offers multiple streams over a single connection. However, again, it requires changing the transport stack, which will make it very difficult to deploy across existing home routers. Also, SCTP alone isn't the silver bullet; application-layer changes still need to be made to efficiently use the channel between the server and client.

Follow me @rohhy