tions and interesting interactions with the TCP transport layer:

TCP connection proliferation in HTTP.
Prior to standardization of HTTP/1.1 in
1999, HTTP/1.0 permitted download-
ing only a single resource over a TCP
connection and only four concurrent
TCP connections to any given server.
HTTP/1.1 introduced persistent con-
nections, allowing connection reuse

figure 9. Real-world success rates of upgrading to newer protocols over various port numbers, as measured by Google chrome’s Websocket team. firewalls drop traffic on arbitrary new ports, and transparent proxies inhibit protocol upgrades over port 80.

86% of traffic works dest-port 61985

arbitrary new port
firewalls can drop traffic
on arbitrary new ports

67% of traffic works dest-port 80

standard httP port
transparent proxies often don’t
handle protocol upgrades correctly

95% of traffic works dest-port 443

standard ssl port
ssl traverses
transparent proxies
unaltered
most firewalls
permit port 443

figure 10. a sPDY gateway offers security between client and gateway regardless of the security of the destination server.

sPdY
httP
secure connection between
client and gateway, regardless
of destination server security
sPd Y gateway to httP
server remains insecure
sPd Y gateway
unencrypted.com
plaintext.org
eavesdroppable.net

for multiple resources. HTTP/1.1 concomitantly reduced maximum concurrent TCP connections from four to two, helping reduce server load and alleviate Internet congestion11 induced by proliferation of short-lived TCP connections at the time. Unfortunately, halving concurrent connections had the adverse effect of reducing download parallelism. HTTP/1.1 envisaged that the newly introduced HTTP pipelining would remedy the problem, but, as described earlier, pipelining proved difficult to implement and suffers from head-of-line blocking, as in Figure 5.

Having only two concurrent connections creates a serious performance bottleneck for modern high-speed Internet connections and complex Web sites. First, TCP slow-start, slowly ramping up usable-connection bandwidth based on number of successfully received packets, is often overly conservative in its initial bandwidth allocation. Several round trips are needed before the connection is saturated, by which time much of the content may have been downloaded already (at a slower-than-necessary rate). Second, a typical modern Web page encapsulates 10s or 100s of resources, only two of which may be requested at any given time. Without HT TP pipelining, requests cannot be queued on the server, so each new request incurs an additional round trip. Because most Web resources are small, the round-trip time to the server often dominates over the time to receive the resource from first to last byte.

Modern browsers break from the HTTP/1.1 standard by allowing six or more concurrent TCP connections to a server. This allocation largely circumvents both previously outlined problems—effective initial bandwidth becoming tcP slow-start constant 6 (rather than 2) and fewer round trips incurred due to higher request concurrency. A common practice among large Web properties (such as Facebook, Google, and Twitter) is to “shard” 24 a Web page’s resources across multiple domains (such as img1.facebook, img2.facebook, img3.facebook, and img4.facebook) to subvert browser policy and obtain greater concurrency. In a modern browser, a Web page sharded across four domains can receive 4 6 = 24 concurrent TCP connections.