HTTP 2.0 and Domain-Sharding

HTTP 2.0 (which is based on SPDY) improves latency and throughput through multiplexing of requests and responses onto one single TCP connection. The header and the data of one request/response cycle is represented by a stream which will be divided into several frames. Streams can have different priorities so that critical resources for rendering (e.g CSS files) can be sent earlier than lower prioritized resources (e.g. images).

The following figure shows an example of a HTTP 2.0 connection flow which multiplexes 6 streams:

       | --> [6] --------[5]-[5]-> | 
Client |                           | Server
       | <-- [1] [4] [2] [4] [2]-- |

Advantages of multiplexing

The multiplexing reduces perceived latency and allows constructs like server push of resources. In addition the browser doesn't have to open up several TCP connections for one origin. With HTTP 2.0 only one TCP connection per origin is needed. As a result only one connection is affected by the TCP "slow start" algorithm. (TCP connections speed up if the network is capable enough, see TCP Congestion Control). The TCP connection will be long-lived and so it is likely that it will reach its full speed (more precisely: its maximum congestion window size).

Domain sharding still useful ?

The Domain sharding technique was used to maximize the amount of parallel TCP connections. Most browers open up six TCP connections per origin. With domain sharding this limit can be increased. But due to the multiplexing technique of HTTP 2.0 this performance optimization doesn't make sense for a HTTP 2.0 connection. It actually might decrease performance on a HTTP 2.0 connection, because the browser has to perform additional DNS requests and manage more TCP connections.

Further reading: