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 not an acronym. [6]
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). [7] The first draft of HTTP/2 used SPDY as the working base for its specification draft and editing. [8] The IETF working group for HTTPbis has released the draft of HTTP/2. [9] SPDY (draft-mbelshe-httpbis-spdy-00) was chosen as the starting point. [10] [11]
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, [12] Mozilla Firefox, [13] Opera, [14] Amazon Silk, Internet Explorer, [15] and Safari [16] 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. [17] 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. [18]
On January 25, 2019, Apple announced that SPDY would be deprecated in favor of HTTP/2, and would be removed in future releases. [19]
Google removed SPDY support in Google Chrome 51 which was released in 2016. [20] Mozilla removed it in Firefox 50. [21] Apple has deprecated the technology in macOS 10.14.4 and iOS 12.2. [19]
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. [22]
The goal of SPDY is to reduce web page load time. [35] This is achieved by prioritizing and multiplexing the transfer of web page subresources so that only one connection per client is required. [1] [36] TLS encryption is nearly ubiquitous in SPDY implementations, and transmission headers are gzip- or DEFLATE-compressed by design [27] (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. [37]
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) [38] or Application-Layer Protocol Negotiation (ALPN) [39] thus browser and server support depends on the HTTPS library.
OpenSSL 1.0.1 or greater introduces NPN. [40] Patches to add NPN support have also been written for NSS and TLSLite. [41]
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. [44] 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. [45] 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. [46] network.http.spdy.enabled
variable in about:config
. [13] Firefox 15 added support for SPDY 3. [28] Firefox 27 has added SPDY 3.1 support. [30] Firefox 28 has removed support of SPDY 2. [24] about:networking
(or the HTTP/2 and SPDY indicator add-on) [47] shows if a website uses SPDY.As of May 2021 [update] , approximately 0.1% of all websites support SPDY, [56] in part due to transition to HTTP/2. In 2016, NGINX and Apache [57] were the major providers of SPDY traffic. [58] In 2015, NGINX 1.9.5 dropped SPDY support in favor of HTTP/2. [59]
Some Google services (e.g. Google Search, Gmail, and other SSL-enabled services) use SPDY when available. [60] Google's ads are also served from SPDY-enabled servers. [61]
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. [58]
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.
This is a comparison of both historical and current web browsers based on developer, engine, platform(s), releases, license, and cost.
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.
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
Google Chrome is a 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.
WebSocket is a computer communications protocol, providing a simultaneous two-way communication channel over a single Transmission Control Protocol (TCP) connection. The WebSocket protocol was standardized by the IETF as RFC 6455 in 2011. The current 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 initial 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, Firefox, and Safari support it.
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. In May 2020, Chrome switched to DNS over HTTPS by default.
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.
We wanted a name that captures speed. SPDY, pronounced "SPeeDY", captures this and also shows how compression can help improve speed.