Engineers rebuild HTTP as a faster Web foundation
The formal process of speeding up Hypertext Transfer Protocol is under way with proposals from Google, Microsoft, and others. There are differences -- but common ground, too.
PARIS--Engineers have begun taking the first big steps in overhauling Hypertext Transfer Protocol, a seminal standard at the most foundational level of the Web.
At a meeting of the Internet Engineering Task Force (IETF) here yesterday, the working group overseeing HTTP formally opened a dicussion about how to make the technology faster. That discussion included presentations about four specific proposals for HTTP 2.0, including SPDY, developed at Google and already used in the real world, and HTTP Speed+Mobility, developed at Microsoft and revealed Wednesday.
There are some differences in the HTTP 2.0 proposals that have emerged so far -- for example, Google's preference for required encryption contrasting with Microsoft's preference for it to be optional -- and there's another two-and-a-half months for people to submit new proposals. But notably, there also are similarities, in particular Microsoft's support for some SPDY features.
"There's a lot of overlap," said Greenbytes consultant Julian Reschke, who attended the meeting and is involved in Web standards matters. "There's a lot of agreement about what needs to be fixed."
SPDY has a big head start in the market. It's built into two browsers, Google Chrome and Amazon Silk, with Firefox adopting it in coming weeks. On the other side of the Internet connection, Google, Amazon, and Twitter are among those using SPDY on their servers. And Google has hard data showing the technology's speed benefits.
Mark Nottingham, chairman of the HTTP Working Group, acknowledged SPDY's position with a presentation slide titled "Elephant, meet Room." (PDF). But he was careful to note that SPDY hasn't carried the day.
"We'll discuss SPDY because it's here, but other proposals will be discussed too," Nottingham said in his presentation, and added, "If we do choose SPDY as a starting point, that doesn't mean it won't change."
Why change HTTP?
Rebuilding standards that touch every device on the Web is complicated, but there's one simple word at the heart of the work: speed.
Web pages that respond faster are of course nice for anybody using the Web, but there are business reasons that matter, too. Better performance turns out to lead to more time spent on pages, more e-commerce transactions, more searches, more participation.
Web developers can do a lot to improve performance by carefully optimizing their Web page code. But improving HTTP itself gives a free speed boost to everybody on top of that.
It's no coincidence, therefore, that the first item on the HTTP working group's new charter is "improved perceived performance."
SPDY's technologies for faster HTTP include "multiplexing," in which multiple streams of data can be sent over a single network connection; the ability to assign high or low priorities to Web page resources being requested from a server; and compression of "header" information that accompanies communications for resource requests and responses.
Gabriel Montenegro, who presented and helped develop Microsoft's proposal, pointed out in an interview that two of his proposal's four points adopted SPDY's approach.
Added SPDY co-creator Mike Belshe, "The Microsoft and Google proposals are almost the same." Belshe helped develop SPDY at Google but who now works at the startup Twist, where he continues to work on the technology for mobile app purposes.
One difference between the Google and Microsoft proposals is in syntax, but, Belshe said, SPDY developers are flexible on that point and the choice of compression technology.
A bigger difference is that SPDY calls for encrypted connections all the way from a Web server to the browser it's communicating with. Microsoft believes otherwise. According to its proposal:
Encryption must be optional to allow HTTP 2.0 to meet certain scenarios and regulations. HTTP 2.0 is a universal replacement for HTTP 1.X, and there are some instances in which imposing TLS is not required (or allowed). For example, a "random thought of the day" Web service has very little need for it, nor does a sensor spewing out a temperature reading every few seconds.
Belshe, though, said users care about encryption, and the fact that modern mobile phones can handle encryption means that it's feasible for other devices to use it, too. And although an encrypted channel all the way from a browser to a Web server can damage the businesses of content delivery networks, which cache data on intermediate servers to speed up Web performance, the user should come first, he said.
"Users care about privacy and security more than whether some guy can cache something in the middle," Belshe said. "Security is not free, but we can make it so it's free to users."
A third proposal, called Network-Friendly HTTP Upgrade and presented by Willy Tarreau, is designed with those intermediate network devices in mind. But that proposal, too, calls for network connection multiplexing.
It's possible the group could implement the elements where there are agreement and leave other areas aside, Reschke said. "Deploying new HTTP is expensive, but incremental improvements are better than no improvements."
And improvements will come, he expects.
"We want to standardize this," Reschke said. "It's time. It needs to happen."