Google seeks interwebs speed boost with TCP tweak
10 lines of code deliver '12 per cent jolt'
Velocity Google vice president of engineering Urs Hölzle has warned that unless we update the internet's underlying protocols, any improvements to network bandwidth will be wasted.
"It's very clear that the network speed itself will increase," Hölzle said today during a keynote speech at the internet-infrastructure obsessed Velocity conference in Santa Clara, California. "It's conceivable that [in the next several years] the average network speed worldwide will grow by a factor of three, from 1.8Mbps to 5.4Mbps. However, if you don't fix the protocols, we will not be able to exploit that extra bandwidth."
According to Google's internal tests, the average webpage is 320KB. With the user's average bandwidth at 1.8 Mbps, Hölzle says, load times should be around 1.4 seconds. But in reality, according to Google tests, the average load time is closer to 5 seconds. The problem, Hölzle reckons, is not the network. The problem is the protocols - as well as the browser.
But Google – if you hadn't noticed – is pushing speed in all sorts of other areas as well. Hölzle says the company's goal is to achieve 100 millisecond load times on Chrome, and this will only come with improvements to the net's underlying protocols.
"We want you to be able to get from one page to another as quickly as you turn the page on a book," he says.
Simply by making "some very modest changes" to the aging TCP protocol, Google has been able to boost the speed of its image search engine by 18 per cent, without any changes to the site itself. On average, the company believes, such TCP tweaks can provide a 12 per cent speed boost. Google has published a paper on its TCP work, available here (PDF). According to Hölzle, this update – which involves increasing TCP's initial congestion window – would involve a change of about 10 lines of code.
Meanwhile, as previously announced, Google is developing a new application protocol it calls SPDY, pronounced, yes, "speedy." The project is meant to reduce web latency via improvements like multiplexed streams, request prioritization, and HTTP header compression. In the past, Google has said that with SPDY, it sees "up to" a 55 per cent improvement when downloading the web's top 25 sites over simulated home connections, and according Hölzle, the protocol can reduce packet count by 40 per cent and byte count by 15.
SPDY creates a session between the HTTP application layer and the TCP transport layer. It is not an http replacement, though it uses an HTTP-like request-response setup.
"SPDY replaces some parts of HTTP, but mostly augments it," reads a Google FAQ. "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."
According to Hölzle, on low-bandwidth links, headers are "surprisingly costly." Headers alone, he says, can cost more than a second of latency. But with SDPY's header compression, Google has seen a latency reduction of 85 per cent. This alone means a 45 to 1142 ms improvement in page loads.
Hölzle also points to Google's efforts to improve DNS – the company now runs its own public DNS service, and it has proposed changes to the protocol, hoping to improve the way the protocol maps web users to particular data centers – and he trumpeted Mountain View's work to improve the secure sockets layer (SSL) protocol.
Of course, as it seeks to update the net's protocols, Google is pushing for added bandwidth as well. As Hölzle mentions, the company is working to test 1Gbps fiber networks in certain American cities – though it says it has no intention of joining the last-mile business.
In any event, Mountain View is obsessed with speed. After all, at Google, a faster web translates to more cash. According to Hölzle, Google co-founder Larry Page tells his product managers that speed is a product's most important feature. Everything else is secondary. ®
Sponsored: Becoming a Pragmatic Security Leader