Written on 28 January 2014, 12:09pm
Tagged with: Google, HTTP, SPDY, web
SPDY is one of the things that keeps me busy 🙂 The people from Akamai came up with a nice video explaining how Google’s SPDY experimental protocol leads to defining the next version of HTTP.
The current HTTP 1.1 exists since 1999 (and hardly changed since 1996)
1. HTTP headers
– SPDY offers header compression (with HTTP 1.1 only the HTTP content is compressed)
– SPDY will avoid sending HTTP headers with every single request
2. Parallel requests
– HTTP 1.1 pipelining: multiple requests on a single connection; but the response must come in the same order they were requested. Browsers open like 6 concurrent connection for every host
– SPDY – true multiplexing: send as many requests as you want at once; get responses in whatever order (even in pieces). All this, over a single SPDY connection.
But this requires prioritization. SPDY leaves the decision to the server, but SPDY allows the client to mark priority requests (ex JS, CSS).
3. Server Push and Server Hint
The server can push data to the client – if the client previously established a SPDY connection.
This can be also used for sending assets to the client (ex CSS). To avoid unnecessary pushing of cached data, SPDY provides Server Hint (a suggestion to the client).
– HTTPS needs to be used to hide SPDY
– Multiplexing happens on a per host basis (so if content comes from multiple hosts, SPDY improvements are not so visible)
– Limited browser support
SPDY pushed the IETF to define the next version of HTTP: HTTP 2.0 is expected in 2014.
See more: http://www.chromium.org/spdy/spdy-whitepaper
Update, 9 February 2015: Hello HTTP/2, Goodbye SPDY