HTTP Pipelining vs Domain Sharding
The other day I was reading about the benefits and new features within HTTP 2.0. One of the key features to HTTP2.0 is the ability to interleave (i.e multiplex) multiple requests and responses across a single TCP connection. Resulting in Domain Sharding being considered counterproductive. However, based on how Domain Sharding and HTTP Pipelining can issue parallel HTTP requests, this raises an interesting question,
Why use Domain Sharding over HTTP Pipeling ?
Ok, first a little history. Within HTTP versions prior to HTTP 1.1 each request was sent over a separate TCP connection. HTTP 1.1 then introduced a feature called "Keep-Alive". This allowed for multiple requests to be sent over a single connection. However only a single request could be sent at once. When the request had been served i.e the response fully received the next request could be sent. This is also known as head-of-line-blocking.
HTTP Pipeling was introduced and allowed the client to send multiple requests within a single TCP connection in parallel.
However, Pipelining was still prone to head-of-line-blocking as each response had to be completed before the next response could be sent. Below is an example,
Consider the following,
- Client sends 2 requests to the server in parallel for index.php and html.txt. index.php is received first.
- Both requests are processed. php:60ms and txt:20ms.
- Even though txt is processed first it is buffered until the php response is sent.
- The txt response is sent once the php response is complete.
Because of the head-of-line blocking issues with HTTP Pipelining, along with many servers and proxies not supporting it due to problems with implementation Pipelining is typically disabled (by default) within browsers.
Because of the limited adoption of HTTP pipelining there was still a need for further optimisation techniques within the HTTP protocol to allow for HTTP requests/responses to be sent and received in parallel.
By default browsers open a maximum of 6 connections on a per domain basis. Domain Sharding simply means that the websites assets are spread across multiple domains. In turn maximising the amount of concurrent connections opened by the browser, allowing for a greater number of parallel downloads via HTTP.
However Domain Sharding does come with its own disadvantages. Such as the additional overhead/latency introduced with a) building extra TCP connections and b) performing additional Domain Name lookups.
In essence both HTTP Pipelining and Domain Sharding allow for HTTP requests to be sent in parallel. But this is where the similarities end. With head-of-line-blocking and the limited adoption of HTTP Pipelining, Domain Sharding is the preferred choice when choosing between these 2 HTTP optimization 'techniques'.
HTTP 2 FAQ - http://http2.github.io/faq/
Oreilly HTTP Optimization - http://chimera.labs.oreilly.com/books/1230000000545/ch11.html