SPDY, a Google project to try to speed up the Web, is gaining new allies interested in using it as a basis for rebuilding a fundamental Internet technolog that's remained largely unchanged since 1999.
SPDY reworks HTTP, the Hypertext Transfer Protocol by which Web browsers request Web pages and by which Web servers deliver those pages over the Internet. Every time you load a Web page, you use HTTP or its securely encrypted sibling, HTTPS. An upgrade would bring improvements to a vast number of people -- but on the flip side, making changes to something so basic and important is a laborious, sometimes contentious process.
Google launched SPDY more than two years ago, quickly making it relevant by adding it to its Chrome browser and and its own Web site. The work helped nudge Internet Engineering Task Force (IETF) into creating HTTP 2.0; the most recent version, 1.1, is now 13 years old.
SPDY hasn't carried the day yet, but it has gained traction on the real-world Internet: when Mark Nottingham, leader of the HTTP working group, opened the IETF's discussions about HTTP 2.0 in March, he called SPDY the "elephant in the room." Other formal proposals include Microsoft's HTTP Speed+Mobility, which shares some of SPDY's approach, and Network-Friendly HTTP, which tackles the issue from the perspective of intermediate software that's widely used to help smooth connections between Web browsers and Web servers.
SPDY has won over several notable players, at least as a starting point for new HTTP work, according to IETF mailing-list discussions. One particularly notable SPDY ally is Facebook. It is "implementing SPDY/v2 due to the availability of browser support and the immediate gains we expect to reap," Facebook's Doug Beaver said in a mailing list message. "We are planning to deploy SPDY widely at large scale and will share our deployment experiences as we gain them," he said, and it's not bothering with Microsoft's proposal: "There is no sizable deployment of either clients or servers, and it is missing features we feel are required," he said.
Mike Belshe, a programmer at start-up Twist, was one of the creators of SPDY in his previous job at Google. He was delighted with the Facebook endorsement, which he said the company drafted without his input. "I was flattered they had pretty much the same view that I had and Google had," he said in an interview.
SPDY offers a number of features to speed up Web communications, including compression of some data and "multiplexing" so to more efficiently use TCP (Transmission Control Protocol) connections that are burdensome to set up over a network. (SPDY doesn't actually stand for anything, but of course it's pronounced "speedy.")
Other words of support arrived from F5 Networks, which sells technology for speeding up some Web and other network operations and which announced SPDY support in May. "Because of the wide deployment of SPDY in today's browsers (particularly Chrome and Firefox) and the benefits it brings, F5 has implemented the SPDY protocol. Hence F5 expresses interest in SPDY as starting point for an HTTP/2 proposal," F5 programmer Jeroen de Borst said in a mailing list message.
Akamai, a major power that speeds delivery of Internet information through use of a massive network of servers that caches data closer to the people who need it, also has added some SPDY support. "The reason for implementing SPDY is twofold: testing a new proposal aimed to address performance needs, as well as wide adoption and support by significant number of clients/browsers -- which enables real-world testing and evaluation of the protocol," said Akamai's Stephen Ludin.
One of the big sticking points for SPDY, however, is that it uses encryption, which complicates life for companies like F5 and Akamai that inspect network data to do their jobs. Specifically, SPDY uses the SSL (Secure Sockets Layer) standard also known more formally as TLS (Transport Layer Security). Such encryption keeps user data secret from prying eyes but hurts those with intermediate network technology.
"TLS should not be a requirement: Though it certainly greatly simplifies protocol adoption while generally raising the security level, TLS will put an unnecessary and significant burden on infrastructure," Akamai's Ludin said.
Alibaba Group, a Chinese e-commerce company with several widely used Asian Web sites, endorsed SPDY, but also doesn't like the encryption requirement. Encryption certificates "are not cheap, especially for small Web sites or those located in a developing country. We are from a developing country (China), and we know this well," Joshua Zhu, a programmer at Alibab's Taobao site, said in a mailing list message. He also said the encryption means more hardware work is required and that intermediate network services for proxy and cache work are difficult to implement with encryption. "We believe it should be optional."
And F5's de Borst said, "The use of TLS is desirable...but it complicates the deployment of value-adding proxies."
But Belshe thinks TLS is not only desirable, it's an inevitability. It's desirable because users want their data protected, he said. And it's inevitable because trying to add something like SPDY over a standard unencrypted HTTP connection can cause serious problems when it's not clear that something besides ordinary HTTP 1.1 is being used. TLS, though, is clearer about what HTTP technology is being used when it sets up a connection, he said.
"If you try to run another protocol, you'll break some of the infrastructure," Belshe said, adding that Google's test data backed up the opinion. "TLS is different because it has a structured header and the contents are encrypted. By doing this, it prevents tampering by third parties and makes it much simpler to deploy new protocols."
Even though he's no longer working for Google, Belshe remains active with SPDY. "I plan to remain the SPDY author for drafts submitted to the IETF," he said. "Since leaving Google, I still meet with the Google developers regularly. I have met with Google, Firefox, Amazon, Zynga, Facebook, and other companies to discuss SPDY since my departure."
The next challenge for SPDY allies will be persuading the skeptics, some of them evidently irritated at SPDY's inroads.
"Overall, I find the design approach taken in SPDY deeply flawed," Poul-Henning Kamp, a co-author of the network-friendly HTTP proposal and writer of caching software called Varnish, said in a mailing list message. His own proposal also has shortcomings, but is a better place to start, he said. Kamp has called for more dramatic changes than any of the proposals.
"I think it would be far better to start from scratch, look at what HTTP/2.0 should actually do, and then design a simple, efficient and future-proof protocol to do just that, and leave behind all the aggregations of badly thought-out hacks of HTTP/1.1," he said.
Nottingham, though, tried to ease Kamp's concerns.
"Much of your commentary seems to assume that we're now deciding what HTTP/2.0 will be; in fact, we're choosing a starting point for further work. I have strong reason to be believe that many of the issues you raise will be discussed, and every reason to believe that what comes out will have substantial changes," Nottingham said. But he also dismissed the idea of starting from scratch.
"You advocate...going back to the drawing board and doing things from scratch. In my experience (one that I believe is shared widely), that flat-out doesn't work, and is a sure-fire recipe for either (a) failing, or (b) coming up with a committee-designed monstrosity (which is really just (a), drawn out)," he said.
The practical reality is that SPDY exists already in the real world, and the IETF must reckon with that strength in its standardization process. With Facebook, Firefox, Akamai, and Opera Software joining, Google, it's apparently proved to be compelling in the real world, not just in research papers.