Google's SPDY protocol: A leading UK tech writer posts...

More from Adrian Bridgwater, his post this time related to Google's SPDY protocol, for which F5 has just announced a gateway for.  More about Adrian can be found at the end of this post. He can be found in many places online, including Twitter and at ComputerWeekly.com.

Thanks for contributing Adrian!

Which direction is SPDY shooting off in?

As an “experimental protocol” for faster web networking, SPDY (pronounced speedy) has been primarily developed by Google thus far. As such, the still-developing reference implementations of this technology are initially available on (unsurprisingly) Google Chrome but also on Mozilla Firefox.

TCP then HTTP then SPDY, in that order

Laid down and established to try and tackle the perennial problems associated with web page ‘load latency’ as well as general web security, SPDY’s engineering proposition (if there can be said to be such a thing) is the prioritising and multiplexing of web page sub-resources as they are transferred between web server and device/user so that only one connection per client is required.

But remember, SPDY is not meant to replace HTTP, it merely exists to modify the way the input/output of data flows travel over the Internet pipe.

The technology itself falls under the same “Let’s Make the Web Faster” banner that Google flies over initiatives such as the ‘PageSpeed’ browser extensions (in Chrome and Firefox), which allow users and/or web developers to evaluate the performance of web pages.

To ‘dogfood’ on its own data, Google says it has built a SPDY-enabled Google Chrome browser and open-source web server, which has recorded up to 64% reductions in page load times.

New infrastructure, new security concerns?

SPDY is an application layer technology; so will any fundamental procedural change at the infrastructural stratum necessarily lead forward to security concerns of any kind?

· Google asserts that only changes required to support SPDY are in the client user agent and web server applications.

· Google further explains that SPDY uses TCP as its underlying transport layer, so no changes to existing networking infrastructures are required.

So it appears, for the most part, that our security concerns can rest as they are for the time being.

After graduating from its initial gestation period inside of Chrome (and then Firefox), SPDY now shows all the signs of evolving into a fully-blown industry standard. As work carried out at the application delivery layer inside the data centre now stands to benefit from accelerated web traffic where SPDY can be brought to bear on the technology stack in question, there are (arguably) now direct benefits to be reaped both at the client end and on the server end-point.

Where do we go from here?

One might argue that our next most logical steps forward should be “baking in” support for traffic optimisation and prioritisation technologies so that networks can operate in parallel with the advantages that SPDY offers -- if, that is, we assume that Google has got it right with this new standard.

The signs so far are good.

Adrian’s bio:

Adrian Bridgwater is a freelance journalist specialising in cross platform software application development as well as all related aspects of software engineering and project management.

Adrian is a regular writer and blogger with Computer Weekly, Dr Dobbs Journal and others covering the application development landscape to detail the movers, shakers and start-ups that make the industry the vibrant place that it is.

His journalistic creed is to bring forward-thinking, impartial, technology editorial to a professional (and hobbyist) software audience around the world. His mission is to objectively inform, educate and challenge - and through this champion better coding capabilities and ultimately better software engineering.