SPDY

Last updated

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.

Contents

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]

History

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, 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]

Protocol versions

SPDY is a versioned protocol. SPDY control frames contain 15 dedicated bits to indicate the version of protocol used for the current session. [23]

Design

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.

Relation to HTTP

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.

Protocol support

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.

Client (browser) support and usage

Server support and usage

As of May 2021, 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, most SPDY-enabled websites use nginx, with the LiteSpeed web server coming second. [59]

See also

Related Research Articles

<span class="mw-page-title-main">HTTPS</span> Extension of the HTTP communications protocol to support TLS encryption

Hypertext Transfer Protocol Secure (HTTPS) is an extension of the Hypertext Transfer Protocol (HTTP). It uses encryption for secure communication over a computer network, and is widely used on the Internet. In HTTPS, the communication protocol is encrypted using Transport Layer Security (TLS) or, formerly, Secure Sockets Layer (SSL). The protocol is therefore also referred to as HTTP over TLS, or HTTP over SSL.

Transport Layer Security (TLS) is a cryptographic protocol designed to provide communications security over a computer network. The protocol is widely used in applications such as email, instant messaging, and voice over IP, but its use in securing HTTPS remains the most publicly visible.

The Online Certificate Status Protocol (OCSP) is an Internet protocol used for obtaining the revocation status of an X.509 digital certificate. It is described in RFC 6960 and is on the Internet standards track. It was created as an alternative to certificate revocation lists (CRL), specifically addressing certain problems associated with using CRLs in a public key infrastructure (PKI). Messages communicated via OCSP are encoded in ASN.1 and are usually communicated over HTTP. The "request/response" nature of these messages leads to OCSP servers being termed OCSP responders.

<span class="mw-page-title-main">HTTP pipelining</span>

HTTP pipelining is a feature of HTTP/1.1, which allows multiple HTTP requests to be sent over a single TCP connection without waiting for the corresponding responses. HTTP/1.1 requires servers to respond to pipelined requests correctly, with non-pipelined but valid responses even if server does not support HTTP pipelining. Despite this requirement, many legacy HTTP/1.1 servers do not support pipelining correctly, forcing most HTTP clients to not use HTTP pipelining.

Datagram Transport Layer Security (DTLS) is a communications protocol providing security to datagram-based applications by allowing them to communicate in a way designed to prevent eavesdropping, tampering, or message forgery. The DTLS protocol is based on the stream-oriented Transport Layer Security (TLS) protocol and is intended to provide similar security guarantees. The DTLS protocol datagram preserves the semantics of the underlying transport—the application does not suffer from the delays associated with stream protocols, but because it uses UDP or SCTP, the application has to deal with packet reordering, loss of datagram and data larger than the size of a datagram network packet. Because DTLS uses UDP or SCTP rather than TCP, it avoids the "TCP meltdown problem", when being used to create a VPN tunnel.

<span class="mw-page-title-main">HTTP compression</span> Capability that can be built into web servers and web clients

HTTP compression is a capability that can be built into web servers and web clients to improve transfer speed and bandwidth utilization.

The Online Certificate Status Protocol (OCSP) stapling, formally known as the TLS Certificate Status Request extension, is a standard for checking the revocation status of X.509 digital certificates. It allows the presenter of a certificate to bear the resource cost involved in providing Online Certificate Status Protocol (OCSP) responses by appending ("stapling") a time-stamped OCSP response signed by the CA to the initial TLS handshake, eliminating the need for clients to contact the CA, with the aim of improving both security and performance.

Server Name Indication (SNI) is an extension to the Transport Layer Security (TLS) computer networking protocol by which a client indicates which hostname it is attempting to connect to at the start of the handshaking process. The extension allows a server to present one of multiple possible certificates on the same IP address and TCP port number and hence allows multiple secure (HTTPS) websites to be served by the same IP address without requiring all those sites to use the same certificate. It is the conceptual equivalent to HTTP/1.1 name-based virtual hosting, but for HTTPS. This also allows a proxy to forward client traffic to the right server during TLS/SSL handshake. The desired hostname is not encrypted in the original SNI extension, so an eavesdropper can see which site is being requested. The SNI extension was specified in 2003 in RFC 3546.

<span class="mw-page-title-main">Google Chrome</span> Web browser developed by Google

Google Chrome is a cross-platform web browser developed by Google. It was first released in 2008 for Microsoft Windows, built with free software components from Apple WebKit and Mozilla Firefox. Versions were later released for Linux, macOS, iOS, and also for Android, where it is the default browser. The browser is also the main component of ChromeOS, where it serves as the platform for web applications.

HTTP Strict Transport Security (HSTS) is a policy mechanism that helps to protect websites against man-in-the-middle attacks such as protocol downgrade attacks and cookie hijacking. It allows web servers to declare that web browsers should automatically interact with it using only HTTPS connections, which provide Transport Layer Security (TLS/SSL), unlike the insecure HTTP used alone. HSTS is an IETF standards track protocol and is specified in RFC 6797.

<span class="mw-page-title-main">WebSocket</span> Computer network protocol

WebSocket is a computer communications protocol, providing full-duplex communication channels over a single TCP connection. The WebSocket protocol was standardized by the IETF as RFC 6455 in 2011. The current API specification allowing web applications to use this protocol is known as WebSockets. It is a living standard maintained by the WHATWG and a successor to The WebSocket API from the W3C.

HTTP/2 is a major revision of the HTTP network protocol used by the World Wide Web. It was derived from the earlier experimental SPDY protocol, originally developed by Google. HTTP/2 was developed by the HTTP Working Group of the Internet Engineering Task Force (IETF). HTTP/2 is the first new version of HTTP since HTTP/1.1, which was standardized in RFC 2068 in 1997. The Working Group presented HTTP/2 to the Internet Engineering Steering Group (IESG) for consideration as a Proposed Standard in December 2014, and IESG approved it to publish as Proposed Standard on February 17, 2015. The HTTP/2 specification was published as RFC 7540 on May 14, 2015.

Application-Layer Protocol Negotiation (ALPN) is a Transport Layer Security (TLS) extension that allows the application layer to negotiate which protocol should be performed over a secure connection in a manner that avoids additional round trips and which is independent of the application-layer protocols. It is used to establish HTTP/2 connections without additional round trips.

In computer networking, TCP Fast Open (TFO) is an extension to speed up the opening of successive Transmission Control Protocol (TCP) connections between two endpoints. It works by using a TFO cookie, which is a cryptographic cookie stored on the client and set upon the initial connection with the server. When the client later reconnects, it sends the initial SYN packet along with the TFO cookie data to authenticate itself. If successful, the server may start sending data to the client even before the reception of the final ACK packet of the three-way handshake, thus skipping a round-trip delay and lowering the latency in the start of data transmission.

CRIME is a security vulnerability in HTTPS and SPDY protocols that utilize compression, which can leak the content of secret web cookies. When used to recover the content of secret authentication cookies, it allows an attacker to perform session hijacking on an authenticated web session, allowing the launching of further attacks. CRIME was assigned CVE-2012-4929.

QUIC is a general-purpose transport layer network protocol initially designed by Jim Roskind at Google, implemented, and deployed in 2012, announced publicly in 2013 as experimentation broadened, and described at an IETF meeting. QUIC is used by more than half of all connections from the Chrome web browser to Google's servers. Microsoft Edge and Firefox support it. Safari implements the protocol, however it is not enabled by default.

POODLE is a security vulnerability which takes advantage of the fallback to SSL 3.0. If attackers successfully exploit this vulnerability, on average, they only need to make 256 SSL 3.0 requests to reveal one byte of encrypted messages. Bodo Möller, Thai Duong and Krzysztof Kotowicz from the Google Security Team discovered this vulnerability; they disclosed the vulnerability publicly on October 14, 2014. On December 8, 2014 a variation of the POODLE vulnerability that affected TLS was announced.

DNS over HTTPS (DoH) is a protocol for performing remote Domain Name System (DNS) resolution via the HTTPS protocol. A goal of the method is to increase user privacy and security by preventing eavesdropping and manipulation of DNS data by man-in-the-middle attacks by using the HTTPS protocol to encrypt the data between the DoH client and the DoH-based DNS resolver. By March 2018, Google and the Mozilla Foundation had started testing versions of DNS over HTTPS. In February 2020, Firefox switched to DNS over HTTPS by default for users in the United States.

<span class="mw-page-title-main">HTTP/3</span> Version of the HTTP network protocol

HTTP/3 is the third major version of the Hypertext Transfer Protocol used to exchange information on the World Wide Web, complementing the widely-deployed HTTP/1.1 and HTTP/2. Unlike previous versions which relied on the well-established TCP, HTTP/3 uses QUIC, a multiplexed transport protocol built on UDP. On 6 June 2022, IETF published HTTP/3 as a Proposed Standard in RFC 9114.

Version history for TLS/SSL support in web browsers tracks the implementation of Transport Layer Security protocol versions in major web browsers.

References

  1. 1 2 3 4 5 "SPDY: An experimental protocol for a faster web". Chromium Developer Documentation. Retrieved 2009-11-13.
  2. 1 2 "HTTP/2 Frequently Asked Questions". http2.github.io.
  3. Elkhatib, Yehia; Tyson, Gareth; Welzl, Michael (2014). 2014 IFIP Networking Conference. pp. 1–9. CiteSeerX   10.1.1.698.2343 . doi:10.1109/IFIPNetworking.2014.6857089. ISBN   978-3-901882-58-6. S2CID   13841087.
  4. Podjarny, Guy. "Not as SPDY as You Thought". Archived from the original on 12 October 2012. Retrieved 12 October 2012.
  5. Abdelsalam, Ahmed; Celandroni, Nedo; Collina, Matteo; Cruickshank, Haitham; Fairhurst, Gorry; Ferro, Erina; Gotta, Alberto; Luglio, Michele; Roseti, Cesare (2015-07-01). "A deep analysis on future web technologies and protocols over broadband GEO satellite networks". International Journal of Satellite Communications and Networking. 33 (5): 451–472. doi:10.1002/sat.1120. ISSN   1542-0981.
  6. "Permissions: Our trademarks". Google. Retrieved 2015-02-23.
  7. "SPDY frequently asked questions". The Chromium Projects. Retrieved 2015-02-23. We wanted a name that captures speed. SPDY, pronounced "SPeeDY", captures this and also shows how compression can help improve speed.
  8. "SPDY Protocol on IETF" . Retrieved 2012-02-08.
  9. Nottingham, Mark. "First draft of HTTP/2". HTTP Working Group Mailing List. Retrieved 2 December 2012.
  10. Nottingham, Mark. "What's next for HTTP" . Retrieved 2012-03-31.
  11. "Fwd: [new-work] WG Review: Hypertext Transfer Protocol Bis (httpbis)".
  12. "HTTPbis Working Group Start To Consider HTTP/2.0". InfoQ. 2012-04-28. Retrieved 2012-08-09.
  13. "SPDY on Google servers?" . Retrieved 2012-02-28.
  14. 1 2 "Mozilla Bug 528288 - Implement SPDY protocol".
  15. "Opera: Built-in support for the SPDY protocol" . Retrieved 2012-11-06.
  16. "IE11 SPDY/3 confirmed". 2013-06-25. Retrieved 2013-06-25.
  17. "Apple — Press Info — Apple Announces OS X Yosemite". 2 June 2014. Retrieved 2014-06-02.
  18. Chris Bentzel & Bence Béky (9 February 2015). "Hello HTTP/2, Goodbye SPDY".
  19. Béky, Bence (February 11, 2016). "Transitioning from SPDY to HTTP/2" . Retrieved February 12, 2016.
  20. 1 2 Marshall, Scott (2019-01-25). "Removing Legacy SPDY Protocol Support". WebKit. Retrieved 2019-03-07.
  21. "Transitioning from SPDY to HTTP/2". Chromium Blog. Retrieved 2022-02-05.
  22. "1287132 - Disable SPDY 3.1". bugzilla.mozilla.org.
  23. 1 2 SPDY Protocol - Draft 2: "Currently, the only valid string is "spdy/2" (spdy/1 isn't implemented anywhere anymore)".
  24. "Module ngx_http_spdy_module". Nginx.org. Retrieved 2014-06-03.
  25. 1 2 "Firefox Beta Notes — Desktop". 2014-02-06. Retrieved 2014-02-07.
  26. "Issue 303957 - chromium — Make Chrome support only SPDY/3 and above — An open-source project to help move the web forward. - Google Project Hosting". 2013-10-03. Retrieved 2014-02-19.
  27. 1 2 3 OpenLiteSpeed 1.1 (With SPDY!) Retrieved 2013-08-12.
  28. 1 2 "SPDY Protocol — Draft 3" . Retrieved 25 August 2012.
  29. 1 2 "Firefox 15 — Release Notes" . Retrieved 3 September 2012.
  30. "SPDY Protocol — Draft 3.1" . Retrieved 17 November 2013.
  31. 1 2 "Firefox Notes Desktop". 2014-02-04. Retrieved 2014-02-05.
  32. 1 2 OpenLiteSpeed 1st Web Server to Support SPDY/3.1! Retrieved 2014-1-10.
  33. NGINX Announces Support for SPDY/3.1 Retrieved 2014-02-04.
  34. F5 Bigip 11.6.0 Release Notes Retrieved 2015-03-10.
  35. "Upcoming SPDY/4 changes to bring it more in sync with the HTTP/2 draft" . Retrieved 27 February 2014.
  36. "A 2x Faster Web". Official Google Chromium Blog. 2009-11-11. Retrieved 2009-11-13.
  37. Iljitsch van Beijnum (2009-11-12). "SPDY: Google wants to speed up the web by ditching HTTP". Ars Technica. Retrieved 2009-11-13.
  38. Mirko Lindner (13 November 2009). "Google stellt HTTP-Alternative SPDY vor" (in German). Retrieved 2011-10-21.
  39. NPN protocol and explanation about its need to tunnel SPDY over HTTPS.
  40. "ImperialViolet - NPN and ALPN". www.imperialviolet.org. Retrieved 2021-06-08.
  41. Openssl 1.0.1 changelog.
  42. TLS Next Protocol Negotiation. Section: Implementations Archived 2012-07-30 at the Wayback Machine .
  43. Chromium SPDY client implementation.
  44. Chromium: SPDY proxy examples Archived 2017-09-19 at the Wayback Machine .
  45. List of Chromium Command Line Switches.
  46. Bentzel, Chris; Béky, Bence (February 9, 2015). "Hello HTTP/2, Goodbye SPDY". Chromium Blog. Retrieved 9 February 2015.
  47. "Google Groups". groups.google.com.
  48. "HTTP/2 and SPDY indicator". Add-ons for Firefox. Mozilla. 2014-11-26. Retrieved 2015-02-12.
  49. David Honneffer, Documentation Specialist. "Opera: Opera 12.10 Changelog".
  50. "WebGL, SPDY/3, New Dev Tools, & More Confirmed For IE11 In Win 8.1". Microsoft News.
  51. "IE11 Changes". Microsoft.
  52. "Microsoft Releases Internet Explorer 11 for Windows 7". 2013-11-07.
  53. "Google not loading first time in IE11 via a web proxy on Windows 8.1? Turn off SPDY support. | The Angry Technician". Angrytechnician.wordpress.com. 2014-01-16. Retrieved 2014-02-19.
  54. Rob Trace; David Walp (October 8, 2014). "HTTP/2: The Long-Awaited Sequel". Microsoft. Retrieved 8 October 2014.
  55. Ryan Paul (28 September 2011). "Amazon's Silk Web browser adds new twist to old idea" . Retrieved 2011-10-21.
  56. "What's New in Foundation Networking" (PDF). Apple inc. Retrieved 2014-07-07.
  57. "Usage of SPDY for websites". w3techs.com. Retrieved 2021-05-04.
  58. "Usage of web servers for websites". w3techs.com. Retrieved 2016-07-26.
  59. 1 2 "Distribution of Web Servers among websites that use SPDY" . Retrieved 2021-05-04.
  60. 1 2 "HTTP/2 Supported in Open Source NGINX 1.9.5 - NGINX". 22 September 2015.
  61. spdy-dev mailing list: SPDY on Google servers?.
  62. Google Speeds Up Web-Page Downloads with SPDY Protocol - Cloud Computing - News & Reviews. eWeek.com (2011-06-20). Retrieved on 2013-11-21.
  63. "Research Blog: A 2x Faster Web". Research Blog.
  64. Ido Safruti (2011-06-15). "From Fast to SPDY — Velocity 2011".
  65. "Google Groups".
  66. Twitter Adopts SPDY Archived 2012-03-11 at the Wayback Machine .
  67. Jetty Feature SPDY.
  68. "indutny/node-spdy · GitHub". Github.com. Retrieved 2012-05-10.
  69. Fedor Indutny (2012-01-24). "What the $%@! is SPDY — blog.nodejitsu.com — scaling node.js applications one callback at a time". blog.nodejitsu.com. Retrieved 2012-05-10.
  70. "mod-spdy — Apache SPDY module — Google Project Hosting" . Retrieved 2012-05-10.
  71. "libspdy". daniel.haxx.se. 2011-10-18. Retrieved 2012-05-10.
  72. "Welcome to Twitter — Login or Sign up".
  73. "mod_spdy — mod_spdy — Google Developers" . Retrieved 2012-05-10.
  74. F5 Helps Organizations Improve User Experience and Simplify Management with First Integrated SPDY Gateway | About F5 | F5 Networks Archived 2012-06-11 at the Wayback Machine . F5.com (2012-05-08). Retrieved on 2013-11-21.
  75. "Announcing SPDY draft 2 implementation in nginx". Nginx. 2012-06-15. Retrieved 2012-06-16.
  76. Beaver, Doug. "HTTP2 Expression of Interest". W3C. Retrieved 15 July 2012.
  77. Finley, Klint. "Facebook Makes Itself a Bit More SPDY". Wired. Retrieved 18 March 2013.
  78. "Just enabled #SPDY for all http://WordPress.com/ -hosted sites". 2012-08-28. Retrieved 2012-08-28.{{cite web}}: External link in |title= (help)
  79. DSM 5.0 beta
  80. John Graham-Cumming (2014-02-17). "Staying up to date with the latest protocols: SPDY/3.1 | CloudFlare Blog". Blog.cloudflare.com. Retrieved 2014-02-19.
  81. Justin Dorfman. "Now Serving: SPDY 3.1". blog.maxcdn.com. Retrieved 2014-05-20.
  82. "Open sourcing our NGINX HTTP/2 + SPDY code". 2016-03-13. Retrieved 2016-08-05.
  83. Ghedini, Alessandro; Lalkaka, Rustam (26 September 2019). "HTTP/3: the past, the present, and the future". The Cloudflare Blog. Retrieved 16 January 2020.