Lately there is a lot of talk about the SPDY protocol (pronounced as Speedy). The recent launch of Firefox 13 with SPDY available by default is very welcomed. Though created by Google, a lot of large entities (amazon, twitter, mozilla etc.) are interested in this protocol. Google has submitted this as a draft to IETF as the next gen replacement Http. Even microsoft is interested and they have also submitted a parallel proposal, which is very much inspired by SPDY.
Now that I have built up the interest on SPDY as the next gen http (hopefully), you might ask: "What is wrong with HTTP? Why should I care?"
Problem with HTTP
HTTP has served us well for a long time and in many ways it was never conceived to be used. Today the content which flows through the internet is very rich with images, dynamic scripts, videos. Some of HTTP's early decisions are not good enough any more in terms of performance. For example
- One request per connection at a time - Everything a server has to send to the client comes in a serial manner - send one and then the other and then the next. Too slow. Browsers circumvent this by creating parallel connections to the server (creating new connections is not cheap at all).
- Request always initiated by client only - HTTP works by the principle that client initiates the request and the server responds to it. Even if the server knows that the client would need these resources, it can't really do much about it (neither pushing content nor providing hints).
- HTTP Headers keep sending redundant information and that too in uncompressed form.
In comes the SPDY
SPDY as the name suggest is a protocol aimed at changing the performance aspect of HTTP. It preserves the application usage aspect of HTTP and tries to solve the performance issues. It sits on top TCP and provides a session layer. It tries to:
- work with many concurrent HTTP requests in a single TCP session/connection in the form of streams. A new frame format helps doing this
- reduce bandwidth usage by using compressed headers and removing unnecessary headers
- create server initiated streams (push or hint)
Another thing to note is that SPDY stays at the application protocol (HTTP is one) layer and does not move into the transport (TCP) layer. This is not because there is no optimization possible at that level. It is more to do with the fact that such changes would need the entire internet infrastructure to change and that will make the protocol a non-starter in terms of its acceptance.
SPDY also prefers to work with SSL. This does cost on performance, but the idea is to promote a more secure way of interaction between client and server.
Google has worked on implementing this protocol and testing it extensively. Their browser (guess which one) supports it and their server infrastructure supports it as well. That itself is a good testing bed for SPDY. A lot of details about their testing is provided in the SPDY white-paper if you interested to check out.
Of course other companies are getting involved as well as I mentioned before.
The SPDY project page refers to a lot of frameworks and server software that support SPDY. Some interesting ones are
- Netty (contributed by twitter)
- node js
There are lot more servers and libraries supporting it - please refer the project page mentioned above.
SPDY is already there in the wild now. It makes the web interaction faster for consumers/producers like us. It has picked the interest of other big entities who are trying to improve it further. Google itself is very much involved and is doing a lot of testing. It also wants to involve the open community on it. May be its time we get to know more about it and contribute to it in whatever way we can.