PDF version of this report
You must have Adobe Acrobat reader to view, save, or print PDF files. The reader
is available for free
download.
ARCHIVED REPORT:
Web Protocol SPDY & Likely Impact
Docid: 00021375
Publication Date: 1511
Report Type: TUTORIAL
Preview
In February 2015, Google announced its intentions to fade
our support for SPDY in Chrome by early 2016. This archived report provides a brief history of SPDY, a network protocol developed
by Google to reduce Internet latency and improve Internet performance by
enabling concurrent, interleaved data streams across a single TCP
(Transmission Control Protocol) connection. SPDY – pronounced "SPeeDY" – formed the foundation of the HTTP
2.0 specification.
Google engineer Chris Bentzel
said, "We’re happy to have contributed to the open standards process that led to
HTTP/2, and hope to see wide adoption given the broad industry engagement on
standardization and implementation. We also look forward to further advancements
in fundamental Internet protocols that lead to a faster and more secure Internet
for everyone."1 Analyst Frederic Lardinois adds, "The company (Google) now
recommends that server developers follow its
path and focus solely on HTTP/2, as well as on
ALPN, the
HTTP/2 version of the
Transport Layer Security
protocol that enables secure https
connections today. Google’s servers will likely
support SPDY quite a bit longer than its
browser, but in the long run, it will likely
completely shut of SPDY support there, too."2
Report Contents:
Executive Summary
[return to top of this report]
With more than two decades of service as the world’s "information
superhighway," the Internet is
long overdue for a major overhaul.
Related Faulkner Reports |
Enterprise Checklist for IPv6 Readiness Tutorial |
The process began with the introduction of Internet Protocol version 6 (IPv6)
– the planned next generation of the Internet Protocol that provides easier
administration, an expanded addressing scheme, and tighter security. IPv6,
which is still being implemented, promises the increased capacity necessary to
establish the "Internet of Things" where virtually every electromechanical
device will be assigned an IP address and made Internet accessible.
The next target for Internet improvement is the HyperText Transfer (HTTP)
network protocol. The goal is to minimize Internet latency
and speed up the "web experience" for users; in other words, to make the
Internet faster by creating an improved HTTP. HTTP 2.0, this new protocol
currently under discussion by the Internet
Engineering Task Force (IETF)3, would be the first new version of HTTP since HTTP 1.1 was
described in 1999.
The initial draft of HTTP 2.0, published in November 2012, is based
upon and, in fact, is almost identical to
SPDY – a network
protocol developed by Google to reduce Internet latency. As applied to
networking, "latency" represents the amount of time it takes a data
packet to travel from source to
destination and is, thus, a measure of network speed. SPDY reduces latency
by enabling concurrent, interleaved data streams across a single Transmission
Control Protocol (TCP) connection.4
Importantly, SPDY does not replace HTTP; it mostly augments it.
Description
[return to top of this report]
SPDY reduces latency
by enabling concurrent, interleaved data streams across a single Transmission
Control Protocol (TCP) connection.5
As illustrated in
Figure1, this is accomplished within the Application Layer by adding a special
framing
layer (SPDY) between the HTTP layer and the Transport Layer Security (TLS)
layer. The usual HTTP GET and POST message formats remain the same;
however, SPDY specifies a new, highly optimized framing format for encoding and transmitting the
data.
Figure 1. SPDY Vs. HTTP
Source: CUBRID
Within this new architecture, SPDY achieves lower latency via the following:
Multiplexed Streams
SPDY allows for
unlimited concurrent streams over a single TCP connection. Because
requests are interleaved on a single channel, the efficiency of TCP
is much higher: fewer network connections need to be made, and
fewer, but more densely packed, packets are issued.
Request Prioritization
Although unlimited
parallel streams solve the serialization problem, they introduce
another one: if bandwidth on the channel is constrained, the
client may block requests for fear of clogging the channel. To
overcome this problem, SPDY implements request priorities: the
client can request as many items as it wants from the server, and assign a
priority to each request. This prevents the network channel from being congested
with non-critical resources when a high priority request is pending.
HTTP Header Compression
SPDY compresses request and response HTTP headers, resulting in
fewer packets and fewer bytes transmitted.
Server-Initiated Streams
An
optionally activated feature, server-initiated streams can be used to deliver content to the
client without the client needing to ask for it.6
Current
View
[return to top of this report]
SPDY Support
Any new protocol – indeed, any innovation – needs adherents. Importantly, Google itself (along with its sister sites like YouTube), Facebook,
and Twitter support SPDY.
Supported browsers include:
- Chrome
- Firefox
- Opera
- Internet Explorer 11 (IE11) – Windows 8
only.7
Apple announced that Safari 8 will support SPDY, meaning all major browsers
should support SPDY by the end of 2014.
SPDY Security
The US National Institute of Standards and Technology (NIST) reminds us
that SPDY must be secure to be successful.
The NIST-administered National Vulnerability Database (NVD) – the official US
government repository of standards based vulnerability management data – has
posted 11 SPDY-related warnings. Two are rated HIGH CVSS severity:
CVE-2014-0088: The SPDY implementation in
the ngx_http_spdy_module module in nginx 1.5.10 before 1.5.11, when running on a
32-bit platform, allows remote attackers to execute arbitrary code via a crafted
request. (4/29/2014)
CVE-2010-3729: The SPDY protocol
implementation in Google Chrome before 6.0.472.62 does not properly manage
buffers, which might allow remote attackers to execute arbitrary code via
unspecified vectors. (10/5/2010)
SPDY Delivers
In the latest tests, SPDY demonstrated a significant performance improvement
over HTTP.
In November 2013, a
trio of Google engineers – Ilya Grigorik, Hasan Khalil,
and Roberto Peon – reported a median speed increase of between 23 and 43
percent when using SPDY instead of standard HTTP. Their exercises
incorporated a cross-section of Google functions including Google Drive,
Google Maps, Google News, and Google Sites. Google News benefited the
most, a 43 percent gain. Other functions clustered around the 25 percent
improvement level.8
Outlook
[return to top of this report]
Google Gains
In evaluating Google’s development and promotion
of SPDY, analyst Gregg Keizer asserts that the SPDY investment represents money
well spent. "Google’s success in promoting SPDY – and pushing
it as the foundation of [HTTP 2.0] … has been a win for the company,
particularly its revenue driver, search. The faster pages load, Google believes,
the more that people will access its services."9
SPDY Goals
According to Google, the high-level goals for SPDY
are:
- To target a 50 percent reduction in page load time.
- To
minimize deployment complexity. SPDY uses TCP as the underlying
transport layer, so requires no changes to existing networking
infrastructure. - To avoid
the need for any changes to content by website authors. The only changes
required to support SPDY are in the client user agent and web server
applications. - To bring
together like-minded parties interested in exploring protocols as a way
of solving the latency problem.
Specific technical goals include:
- To allow many concurrent HTTP requests to run across a
single TCP session. - To reduce the bandwidth currently used by HTTP by
compressing headers and eliminating unnecessary headers. - To define a protocol that is easy to implement and
server-efficient, reducing the complexity of HTTP
by cutting down on edge cases and defining easily parsed
message formats. - To make SSL the underlying transport
protocol, for better security and compatibility with
existing network infrastructure. Although SSL does introduce
a latency penalty, we believe that the long-term future of
the web depends on a secure network connection. In addition,
the use of SSL is necessary to ensure that communication
across existing proxies is not broken. - To enable the server to initiate
communications with the client and push data to the client
whenever possible.10
Note: Since the articulation of
these goals in 2009, SSL has
been superseded by the newer, but very similar, Transport Layer
Security (TLS) protocol; TLS 1.0 is effectively SSL version 3.1.
Recommendations
[return to top of this report]
Utilize SPDY in "Challenged" Environments
According to one
analysis, "SPDY offers maximum improvement (over HTTPS) when operating in challenged environments. Stream multiplexing is at the heart of SPDY’s performance, allowing it to deal with low bandwidth and high delay situations far better than HTTPS. This feature minimizes the number of round trips required to fetch resources. It also facilitates more disciplined congestion control, allowing SPDY to outshine HTTP on low bandwidth links."11
Help with SPDY Development
Concerning the on-going development of SPDY, Google welcomes comments and
suggestions aimed at improving the SPDY specification. All enterprises
that rely on high-speed Internet should consider contributing to SPDY.
Study Enhancements to TCP
Google’s efforts to reduce Internet latency are focused on HTTP. Research should also be conducted – by Google or others – to determine if the
Transport Layer (TCP) could be modified to reduce latency.12
Organizations like NIST are well positioned to lead such a program.
References
1 Chris Bentzel. "Hello
HTTP/2, Goodbye SPDY."
Chromium Blog. February
9, 2015.
2 Frederic Lardinois. "Google Starts
Fading Out SPDY Support In Favor Of HTTP/2 Standard." AOL Inc.
February 9, 2015.
3 Gregg Keizer. "Google Trumpets Chrome’s SPDY
Gains." Computerworld. November 21, 2013.
4
Speed Up the Web with New Protocol." The
November 12, 2009.
5 Ibid.
6 "SPDY: An Experimental Protocol for a Faster Web." The Chromium
Projects.
7 Gregg Keizer. "Google Trumpets Chrome’s SPDY
Gains." Computerworld. November 21, 2013.
8 Ibid.
9 Ibid.
10 "SPDY: An Experimental Protocol for a Faster Web." The Chromium
Projects.
11 Yehia Elkhatib, Gareth Tyson and Michael Welzl. "Can SPDY Really Make the Web Faster?"
IFIP. 2014:9.
12 "SPDY: An Experimental Protocol for a Faster Web."
The Chromium Projects.
Web
Links
[return to top of this report]
Chromium Projects:
http://www.chromium.org/
CUBRID: http://www.cubrid.org/
Google: http://www.google.com/
Internet Engineering Task Force: http://www.ietf.org/
US National Institute of Standards and Technology: http://www.nist.gov/
About the Author
[return to top of this report]
James G. Barr is a leading business continuity analyst
and business writer with more than 30 years’ IT experience. A member of
"Who’s Who in Finance and Industry," Mr. Barr has designed,
developed, and deployed business continuity plans for a number of Fortune 500
firms. He is the author of several books, including How to Succeed in
Business BY Really Trying, a member of Faulkner’s Advisory Panel, and a
senior editor for Faulkner’s Security Management Practices. Mr.
Barr can be reached via e-mail at jgbarr@faulkner.com.
[return to top of this report]