Internet protocol suite |
---|
Application layer |
Transport layer |
Internet layer |
Link layer |
SPDY (pronounced "speedy") [1] is an obsolete open-specification communication protocol developed for transporting web content. [1] SPDY became the basis for HTTP/2 specification. However, HTTP/2 diverged from SPDY and eventually HTTP/2 subsumed all usecases of SPDY. [2] After HTTP/2 was ratified as a standard, major implementers, including Google, Mozilla, and Apple, deprecated SPDY in favor of HTTP/2. Since 2021, no modern browser supports SPDY.
Google announced SPDY in late 2009 and deployed in 2010. SPDY manipulates HTTP traffic, with particular goals of reducing web page load latency and improving web security. SPDY achieves reduced latency through compression, multiplexing, and prioritization, [1] although this depends on a combination of network and website deployment conditions. [3] [4] [5] The name "SPDY" is a trademark [6] of Google and is not an acronym. [7]
HTTP/2 was first discussed when it became apparent that SPDY was gaining traction with implementers (like Mozilla and nginx), and was showing significant improvements over HTTP/1.x. After a call for proposals and a selection process, SPDY was chosen as the basis for HTTP/2. Since then, there have been a number of changes, based on discussion in the Working Group and feedback from implementers. [2]
As of July 2012 [update], the group developing SPDY stated publicly that it was working toward standardisation (available as an Internet Draft). [8] The first draft of HTTP/2 used SPDY as the working base for its specification draft and editing. [9] The IETF working group for HTTPbis has released the draft of HTTP/2. [10] SPDY (draft-mbelshe-httpbis-spdy-00) was chosen as the starting point. [11] [12]
Throughout the process, the core developers of SPDY have been involved in the development of HTTP/2, including both Mike Belshe and Roberto Peon.
Chromium, [13] Mozilla Firefox, [14] Opera, [15] Amazon Silk, Internet Explorer, [16] and Safari [17] expressed support for SPDY at the time.
In February 2015, Google announced that following ratification of the HTTP/2 standard, support for SPDY would be deprecated, and that support for SPDY would be withdrawn. [18] On May 15, 2015, HTTP/2 was officially ratified as RFC 7540.
On February 11, 2016, Google announced that Chrome would no longer support SPDY after May 15, 2016, the one-year anniversary of RFC 7540 which standardized HTTP/2. [19]
On January 25, 2019, Apple announced that SPDY would be deprecated in favor of HTTP/2, and would be removed in future releases. [20]
Google removed SPDY support in Google Chrome 51 which was released in 2016. [21] Mozilla removed it in Firefox 50. [22] Apple has deprecated the technology in macOS 10.14.4 and iOS 12.2. [20]
This section needs to be updated. The reason given is: SPDY was removed from all major implementations in favor of HTTP/2.(February 2022) |
SPDY is a versioned protocol. SPDY control frames contain 15 dedicated bits to indicate the version of protocol used for the current session. [23]
The goal of SPDY is to reduce web page load time. [36] This is achieved by prioritizing and multiplexing the transfer of web page subresources so that only one connection per client is required. [1] [37] TLS encryption is nearly ubiquitous in SPDY implementations, and transmission headers are gzip- or DEFLATE-compressed by design [28] (in contrast to HTTP, where the headers are sent as human-readable text). Moreover, servers may hint or even push content instead of awaiting individual requests for each resource of a web page. [38]
SPDY requires the use of SSL/TLS (with TLS extension ALPN) for security but it also supports operation over plain TCP. The requirement for SSL is for security and to avoid incompatibility when communication is across a proxy.
SPDY does not replace HTTP; it modifies the way HTTP requests and responses are sent over the wire. [1] This means that all existing server-side applications can be used without modification if a SPDY-compatible translation layer is put in place.
SPDY is effectively a tunnel for the HTTP and HTTPS protocols. When sent over SPDY, HTTP requests are processed, tokenized, simplified and compressed. For example, each SPDY endpoint keeps track of which headers have been sent in past requests and can avoid resending the headers that have not changed; those that must be sent are compressed.
This section needs to be updated.(December 2015) |
For use within HTTPS, SPDY requires the TLS extension Next Protocol Negotiation (NPN) [39] or Application-Layer Protocol Negotiation (ALPN) [40] thus browser and server support depends on the HTTPS library.
OpenSSL 1.0.1 or greater introduces NPN. [41] Patches to add NPN support have also been written for NSS and TLSLite. [42]
Security Support Provider Interface (SSPI) from Microsoft have not implemented the NPN extension to its TLS implementation. This has prevented SPDY inclusion in the latest .NET Framework versions. Since SPDY specification is being refined and HTTP/2 is expected to include SPDY implementation one could expect Microsoft to release support after HTTP/2 is finalized.
chrome://net-internals/#events&q=type:SPDY_SESSION%20is:active
. There is a
command-line switch for Google Chrome (--
enable-websocket-over-spdy
) which enables an early, experimental implementation of
WebSocket over SPDY.
[45] SPDY protocol functionality can be (de)activated by toggling "Enable SPDY/4" setting on local chrome://flags
page. Chromium is expected to remove support for SPDY and Next Protocol Negotiation in early 2016, in favor of
HTTP/2 and
ALPN.
[46] Starting with version 40.x in Feb 2015 Chrome has already dropped support for SPDY/3 and only supports SPDY/3.1 going forward. This has caused Apache websites to be without SPDY support when visited from Google Chrome.
[47]network.http.spdy.enabled
variable in
about:config
.
[14] Firefox 15 added support for SPDY 3.
[29] Firefox 27 has added SPDY 3.1 support.
[31] Firefox 28 has removed support of SPDY 2.
[25] about:networking
(or the HTTP/2 and SPDY indicator add-on)
[48] shows if a website uses SPDY.As of May 2021 [update], approximately 0.1% of all websites support SPDY, [57] in part due to transition to HTTP/2. In 2016, NGINX and Apache [58] were the major providers of SPDY traffic. [59] In 2015, NGINX 1.9.5 dropped SPDY support in favor of HTTP/2. [60]
Some Google services (e.g. Google Search, Gmail, and other SSL-enabled services) use SPDY when available. [61] Google's ads are also served from SPDY-enabled servers. [62]
A brief history of SPDY support amongst major web players:
According to W3Techs, as of May 2021 [update], most SPDY-enabled websites use nginx, with the LiteSpeed web server coming second. [59]
We wanted a name that captures speed. SPDY, pronounced "SPeeDY", captures this and also shows how compression can help improve speed.
Internet protocol suite |
---|
Application layer |
Transport layer |
Internet layer |
Link layer |
SPDY (pronounced "speedy") [1] is an obsolete open-specification communication protocol developed for transporting web content. [1] SPDY became the basis for HTTP/2 specification. However, HTTP/2 diverged from SPDY and eventually HTTP/2 subsumed all usecases of SPDY. [2] After HTTP/2 was ratified as a standard, major implementers, including Google, Mozilla, and Apple, deprecated SPDY in favor of HTTP/2. Since 2021, no modern browser supports SPDY.
Google announced SPDY in late 2009 and deployed in 2010. SPDY manipulates HTTP traffic, with particular goals of reducing web page load latency and improving web security. SPDY achieves reduced latency through compression, multiplexing, and prioritization, [1] although this depends on a combination of network and website deployment conditions. [3] [4] [5] The name "SPDY" is a trademark [6] of Google and is not an acronym. [7]
HTTP/2 was first discussed when it became apparent that SPDY was gaining traction with implementers (like Mozilla and nginx), and was showing significant improvements over HTTP/1.x. After a call for proposals and a selection process, SPDY was chosen as the basis for HTTP/2. Since then, there have been a number of changes, based on discussion in the Working Group and feedback from implementers. [2]
As of July 2012 [update], the group developing SPDY stated publicly that it was working toward standardisation (available as an Internet Draft). [8] The first draft of HTTP/2 used SPDY as the working base for its specification draft and editing. [9] The IETF working group for HTTPbis has released the draft of HTTP/2. [10] SPDY (draft-mbelshe-httpbis-spdy-00) was chosen as the starting point. [11] [12]
Throughout the process, the core developers of SPDY have been involved in the development of HTTP/2, including both Mike Belshe and Roberto Peon.
Chromium, [13] Mozilla Firefox, [14] Opera, [15] Amazon Silk, Internet Explorer, [16] and Safari [17] expressed support for SPDY at the time.
In February 2015, Google announced that following ratification of the HTTP/2 standard, support for SPDY would be deprecated, and that support for SPDY would be withdrawn. [18] On May 15, 2015, HTTP/2 was officially ratified as RFC 7540.
On February 11, 2016, Google announced that Chrome would no longer support SPDY after May 15, 2016, the one-year anniversary of RFC 7540 which standardized HTTP/2. [19]
On January 25, 2019, Apple announced that SPDY would be deprecated in favor of HTTP/2, and would be removed in future releases. [20]
Google removed SPDY support in Google Chrome 51 which was released in 2016. [21] Mozilla removed it in Firefox 50. [22] Apple has deprecated the technology in macOS 10.14.4 and iOS 12.2. [20]
This section needs to be updated. The reason given is: SPDY was removed from all major implementations in favor of HTTP/2.(February 2022) |
SPDY is a versioned protocol. SPDY control frames contain 15 dedicated bits to indicate the version of protocol used for the current session. [23]
The goal of SPDY is to reduce web page load time. [36] This is achieved by prioritizing and multiplexing the transfer of web page subresources so that only one connection per client is required. [1] [37] TLS encryption is nearly ubiquitous in SPDY implementations, and transmission headers are gzip- or DEFLATE-compressed by design [28] (in contrast to HTTP, where the headers are sent as human-readable text). Moreover, servers may hint or even push content instead of awaiting individual requests for each resource of a web page. [38]
SPDY requires the use of SSL/TLS (with TLS extension ALPN) for security but it also supports operation over plain TCP. The requirement for SSL is for security and to avoid incompatibility when communication is across a proxy.
SPDY does not replace HTTP; it modifies the way HTTP requests and responses are sent over the wire. [1] This means that all existing server-side applications can be used without modification if a SPDY-compatible translation layer is put in place.
SPDY is effectively a tunnel for the HTTP and HTTPS protocols. When sent over SPDY, HTTP requests are processed, tokenized, simplified and compressed. For example, each SPDY endpoint keeps track of which headers have been sent in past requests and can avoid resending the headers that have not changed; those that must be sent are compressed.
This section needs to be updated.(December 2015) |
For use within HTTPS, SPDY requires the TLS extension Next Protocol Negotiation (NPN) [39] or Application-Layer Protocol Negotiation (ALPN) [40] thus browser and server support depends on the HTTPS library.
OpenSSL 1.0.1 or greater introduces NPN. [41] Patches to add NPN support have also been written for NSS and TLSLite. [42]
Security Support Provider Interface (SSPI) from Microsoft have not implemented the NPN extension to its TLS implementation. This has prevented SPDY inclusion in the latest .NET Framework versions. Since SPDY specification is being refined and HTTP/2 is expected to include SPDY implementation one could expect Microsoft to release support after HTTP/2 is finalized.
chrome://net-internals/#events&q=type:SPDY_SESSION%20is:active
. There is a
command-line switch for Google Chrome (--
enable-websocket-over-spdy
) which enables an early, experimental implementation of
WebSocket over SPDY.
[45] SPDY protocol functionality can be (de)activated by toggling "Enable SPDY/4" setting on local chrome://flags
page. Chromium is expected to remove support for SPDY and Next Protocol Negotiation in early 2016, in favor of
HTTP/2 and
ALPN.
[46] Starting with version 40.x in Feb 2015 Chrome has already dropped support for SPDY/3 and only supports SPDY/3.1 going forward. This has caused Apache websites to be without SPDY support when visited from Google Chrome.
[47]network.http.spdy.enabled
variable in
about:config
.
[14] Firefox 15 added support for SPDY 3.
[29] Firefox 27 has added SPDY 3.1 support.
[31] Firefox 28 has removed support of SPDY 2.
[25] about:networking
(or the HTTP/2 and SPDY indicator add-on)
[48] shows if a website uses SPDY.As of May 2021 [update], approximately 0.1% of all websites support SPDY, [57] in part due to transition to HTTP/2. In 2016, NGINX and Apache [58] were the major providers of SPDY traffic. [59] In 2015, NGINX 1.9.5 dropped SPDY support in favor of HTTP/2. [60]
Some Google services (e.g. Google Search, Gmail, and other SSL-enabled services) use SPDY when available. [61] Google's ads are also served from SPDY-enabled servers. [62]
A brief history of SPDY support amongst major web players:
According to W3Techs, as of May 2021 [update], most SPDY-enabled websites use nginx, with the LiteSpeed web server coming second. [59]
We wanted a name that captures speed. SPDY, pronounced "SPeeDY", captures this and also shows how compression can help improve speed.