Question

WWDC 2012 session 706 – Networking Best Practices explains HTTP Pipelining.

• By default its disabled on iOS
• In the talk its described it as a huge performance win.

Why might you not want to use it?

Answer 1

Implementation bugs

For pipelining to work, responses must come back in the order they were requested. A naive server implementation might just send the response as soon as it has been calculated. If multiple requests are sent in parallel, and the first request one takes longer to process (e.g. processing a larger image), then the responses will be out of order.

This is a problem for the client since HTTP is a stateless protocol, the client has no way to match the requests with the responses. It is reliant on the order the responses came back in.

A server MUST send its responses to those requests in the same order that the requests were received.

• Safari apparently used HTTP pipelining for images at least. This results in an issue where images would be swapped around.
• AFNetworking used to use pipelining, but it was pulled after a reported issue.
• All major browsers (other than Opera) have HTTP pipelining is disabled or not implemented.

Performance issues

Even if the server does properly support pipelining, performance issues can arise because all subsequent requests have to wait for the first one to be complete (Head of Line blocking).

• This article, talks about performance loss in some circumstances and a potential of denial of service attack.

• This article also suggest that pipelining isn’t a massive win.

• WWDC 2015 – Networking with NSURLSession explains head of line blocking really well. (The solution is to switch to HTTP 2 which support priorities)

So in summary the issues with HTTP pipelining are:

• Some servers & most proxies don’t support it. (Perhaps due to security / reliability / or performance concerns)
• Some servers support it incorrectly and this can lead to client bugs.
• It is not necessarily a performance win.
• Susceptible to head of line blocking