Performance evaluation of SPDY over high latency channels

When HyperText Transfer Protocol (HTTP) 1.0 was defined, web pages were almost entirely static plain text documents. In the last years web pages have grown in terms of complexity, but HTTP has remained basically the same. One of its main disadvantages is the connection overhead, i.e., each HTTP request potentially triggers a new Transfer Control Protocol (TCP) connection. In addition, every time a web browser performs a new request, it needs to wait for its completion before starting a new one. In other words, latency is not its main goal. HTTP 1.1 tries to solve these problems by introducing persistent connections and request pipelining; these two features improve the overall performance in some cases, but they are not a panacea. A number of workarounds and proposals have been developed in order to mitigate such problems: resource inlining, assets concatenation, resource splitting over multiple servers, etc. Each method has its own pros and cons, but the root of the problem resides in the HTTP architecture. SPDY is an experimental protocol developed at Google aiming at over- come some of the limitations that HTTP exposed in years of Internet. Unfortunately the aforementioned workarounds are slowing the SPDY adoption. For example, one of the goals of SPDY is to avoid multiple con- nections by multiplexing HTTP requests over a single TCP stream and this cannot be done if resources are split over multiple domains. So it is not clear if the new features will bring benefits also for that sites that follow these old patterns.