Speeding up HTTP

The big overhead with protocols that run on top of TCP/IP is the number of connections they open. A modern web page has many different kind of assets (HTML, scripts, Java, GIFs, JPEGs, etc etc) from many places (the primary domain, adservers, Google+ buttons etc etc) such that when you load the front page of facebook.com you may well have opened and closed a thousand TCP connections to a dozen servers. It's amazing that it works at all, but when you consider that each connection had to not only do the three-way TCP handshake, but it also had to run TCP flow-control starting slowly and ramping up packet rate until it started to drop packets and then dropping back. When Mr Burners-Lee wrote his original http server in the early nineties there is no way he could have anticipated how the web would grow.

It seems there are several approaches to optimising this - for the past ten years there have been various attempts to re-define TCP; MUX, SMUX, and SST protocols were valiant efforts that died on the vine because they essentially break how the infrastructure works. Whatever comes after http has to work over all the same IP v.4 routers, switches and proxies. In the last year I've become aware of two projects that work and don't require funky routers etc.

1. Amazon Silk - this is embodied in the browser that comes on the colour Kindle. Essentially it is a mega-proxy that not only collects all the assets for the page but re-renders pictures etc for the smaller screen and sends the whole lot in a stream. So one connection allows the whole pre-rendered page to arrive with the assets from Double-Click and Google (and any other third-party elements in the page) pre-collected for you by Amazon. It runs of their EC2 platform and does depend on them providing the service.
2. SPDY is a Google-sponsored project that doesn't replace http but optimises it. By employing pipelining (i.e. keeping a TCP connection open for all the assets from one domain), compressing headers and marking those headers that don't change so they don't need to be re-sent it speeds up the browser by around three-fold. Further speed increases come if the web-server is able to collect the third-party assets and deliver them over the same pipeline.

As ever Steve Gibson has covered these very comprehensively in Security Now! - SN320 for Silk and SN343 for SPDY.