SPDY is an alternative to HTTP proposed by Google as a way to speed up the Web. The idea is good and the marketing, being Google, is great. Expect SPDY to replace HTTP even though the most useful feature of SPDY is already in HTTP.
SPDY is documented by Google at http://dev.chromium.org/spdy. You do not have to read any of it because it will not affect you unless you are one of the rare breed to get to say something at Internet protocol standards meetings. SPDY will not alter the way you buy equipment or build Web sites or product content. It is just another confusing thing that will creep along in the background the same way as IPv6.
The biggest speed up from SPDY is the use of data compression. Data compression is already in HTTP but is optional. SPDY makes compression compulsory. SPDY is expected to produce a speedup between 25% and 60% of which the first 40% is the result of making data compression compulsory. The remaining bit supplied by SPDY is therefore from 0% to 20%.
HTTP went from HTTP 1.0 to HTTP 1.1 without any pain. We could immediately introduce HTTP 1.2 with compulsory compression without any pain. We could also replace the current compression with the more efficient 7 Zip with little additional pain as HTTP 1.3.
SPDY introduces compression for HTTP headers as a way to speed up ADSL uploads but some parts of the headers are processed all along the network and do not fit as well with compression. Computers are now far faster than the network making data compression really useful but many network devices use cheap slow chips that would stall if they had to decompress everything all the time. Header compression is something that would creep in really slowly similar to IPv6 and should be in HTTP 1.5.
HTTP would benefit from sending multiple requests to a server in one packet. It would be an easy change. Handling multiple requests arriving in a scattered pattern would be harder to handle but is still feasible as a HTTP 1.4 improvement.
SPDY includes download hints, something we could do now in HTTP using few resources and very little change.
What if the header of your page contained a list of all the items listed in the page? My browser could almost immediately request all those items in one hit and let them download while my browser interprets the Web page. Nice idea. You could add that to current Web pages using simple header enhancements or meta tag enhancements. Meta tag enhancements would be the easiest because the 100 million Web sites using content management systems could have the meta tags automatically generated by the CMS.
SPDY includes the option for Web servers to push content to clients before the clients request it. In some theoretical circumstances that would save time but as soon as marketing managers hear about it, the Web servers will be pushing advertising down our throats far more than what they do now. We should in all circumstances keep the browser in control, not the server.
The problem with the Internet standards creators is that they issue so few updates that everyone fights to get their pet projects into a change then several unrelated changes are squashed into a standard update and everyone sufferers headaches just reading the new standards. SPDY will be easier than updating HTTP because an update to HTTP is politically equivalent to a football code introducing a new rule. Imagine European football introducing a rule that all players on both teams have to wear pink clothing. It would be argued for 100 years and never implemented.
Introducing a replacement protocol will get better support because all the network hardware companies will hide the fact that it is just a software upgrade and use the upgrade as an excuse to sell new hardware.
Is SPDY the only solution?
SPDY is not the first project to suggest improvements. There are other proposed alternatives to HTTP containing, between them, many of the SPDY suggestions. Compulsory compression was one of those topics I discussed with people many years ago and everyone agreed it should be standard with the only point left to decide is the type of compression and should we go to something more modern or more specific than what is used now.
FTP is still in use because HTTP is not as good as FTP for some uses. WebDAV, Git, and some other version control software use HTTP instead of FTP or the alternatives because HTTP is commonly available but Git etc could benefit from an alternative protocol, especially one that has upload compression and multiple requests. SPDY could initially be introduced as a special protocol for specific applications. The same applications could benefit from an enhanced FTP.
The thing stopping all those improvements is the requirement to get through firewalls. Firewalls let HTTP through. Almost everything else is a problem. Nobody wants to change their applications to use a new protocol that will be blocked by firewalls. SPDY should be killed by a good firewall because SPDY is different to HTTP. We would not have to change firewall behaviour if we started with compulsory compression because firewalls already allow compression.
Issue HTTP 1.2 to immediately make compression standard then look at the long term use of some other improvements in a way that will work through current firewall settings.