figure 5. head-of-line blocking in httP pipelining; a large resource blocks subsequent smaller resources (left), and a slow-to-generate resource blocks subsequent resources (right).
figure 6. Request multiplexing and prioritization in sPDY; resources are sent in chunks over independent streams that can be interleaved and prioritized.
on the role of Web encryption and pragmatism in handling real-world deployment constraints have led to primarily SSL-encrypted implementations. Mike Belshe, SPDY co-au-thor, 7 and Patrick McManus, principal SPDY implementer for Firefox, have expressed their interest in seeing the Web transition to a "secure by default" model. 5, 18 Proponents of encrypted SPDY say SSL is no longer computationally expensive16 and its security benefits outweigh its communication overhead.
The pragmatic reason for deploying SPDY over SSL (port 443) rather than HTTP (port 80) is that transparent HTTP proxies between the client and the server handle HTTP upgrades unreliably. 13 Transparent HTTP proxies do not modify encrypted traffic on SSL port 443 (as they do on port 80) and so should not interfere with newer protocols like SPDY. The rationale for choosing port 443 over an arbitrary port number is that port 443 appears to traverse firewalls more effectively13 (see Figure 9).
SPDY relies on the next-protocol negotiation (NPN) 17 SSL extension to upgrade the SSL connection to the SPDY protocol. NPN is currently an Internet Engineering Task Force Internet Draft and implemented in OpenSSL23; NPN also allows negotiation of other competing future protocols. SSL implementations that do not currently support NPN simply ignore the request to upgrade the protocol, retaining backward compatibility.