SPDY: An experimental protocol for a faster web HTTP/2

 

http://www.chromium.org/spdy/spdy-whitepaper

https://en.wikipedia.org/wiki/SPDY

Internet protocol suite
Application layer
Transport layer
Internet layer
Link layer

SPDY (pronounced "speedy")[1] is a deprecated open-specification networking protocol that was developed primarily at Google for transporting web content.[1] 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.[2][3][4] The name "SPDY" is a trademark[5] of Google and is not an acronym.[6]

Throughout the process, the core developers of SPDY have been involved in the development of HTTP/2, including both Mike Belshe and Roberto Peon. In February 2015, Google announced that following the recent final ratification of the HTTP/2 standard, support for SPDY would be deprecated, and that support for SPDY would be withdrawn.[7] Google removed SPDY support in Google Chrome 51. Mozilla removed it in Firefox 50.[8]

History[edit]

As of July 2012, the group developing SPDY stated publicly that it was working toward standardisation (available as an Internet Draft).[9] The first draft of HTTP/2 used SPDY as the working base for its specification draft and editing.[10]

Implementations of SPDY exist in Chromium,[11] Mozilla Firefox,[12] Opera,[13] Amazon Silk, Internet Explorer,[14] and Safari,[15] with the implementations for Chromium and Firefox being open source software.

In February 2015, Google announced its plans to remove support for SPDY in favor of HTTP/2. 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/2 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.[16]

On February 11, 2016, Google announced that Chrome would no longer support SPDY and NPN after May 15, 2016, the anniversary of RFC 7540.[17]

Design[edit]

The goal of SPDY is to reduce web page load time.[18] This is achieved by prioritizing and multiplexing the transfer of web page subresources so that only one connection per client is required.[1][19]TLS encryption is nearly ubiquitous in SPDY implementations, and transmission headers are gzip- or DEFLATE-compressed by design[20] (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.[21]

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[edit]

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.

The IETF working group for HTTPbis has released the draft of HTTP/2.[22] SPDY (draft-mbelshe-httpbis-spdy-00) was chosen as the starting point.[23][24]

Protocol support[edit]

Ambox current red.svg
This section needs to be updated. Please update this article to reflect recent events or newly available information. (December 2015)

For use within HTTPS, SPDY needs the TLS extension Next Protocol Negotiation (NPN),[25] thus browser and server support depends on the HTTPS library.

OpenSSL 1.0.1 or greater introduces NPN.[26] Patches to add NPN support have also been written for NSS and TLSLite.[27]

SPDY is scheduled to switch from NPN to Application-Layer Protocol Negotiation (ALPN) before the end of 2014.[28]

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.

Protocol versions[edit]

SPDY is a versioned protocol. In its control frames there are 15 dedicated bits to indicate the version of the session protocol.[citation needed]

  • Version 1: version 1 of the SPDY protocol is not used anymore.[29]
  • Version 2: soon to be discontinued. Nginx supports SPDY/2 in versions prior to 1.5.10.[30] Firefox 28 and recent versions of Chrome drop support for it.[31][32] OpenLiteSpeed 1.1 and up support SPDY/2.[33]
  • Version 3: SPDY v3 introduced support for flow control, updated the compression dictionary, and removed wasted space from certain frames, along with other minor bug fixes.[20]Firefox supports SPDY v3 in Firefox 15.[34] OpenLiteSpeed 1.1 and up support SPDY/3.[33]
  • Version 3.1: SPDY v3.1 introduced support for session-layer flow control, and removed the CREDENTIALS frame (and associated error codes).[35] Firefox 27 has added SPDY 3.1 support.[36] OpenLiteSpeed 1.2.7 introduces SPDY/3.1 support.[37] Nginx 1.5.10 supports SPDY/3.1.[38] F5 BIGIP 11.6 supports SPDY/3.1.[39]
  • Version 4.0: SPDY v4 alpha3 is more closely aligned with the HTTP/2 draft; it has a new stream flow control and error codes unified with the HTTP/2 draft.[40]

Client (browser) support and usage[edit]

  • Google Chrome/Chromium.[41][42] SPDY sessions in Chrome can be inspected via the URI: 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.[43] 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.[44] 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.[45]
  • Firefox supports SPDY 2 from version 11, and default-enabled since 13 and later. (Also SeaMonkey version 2.8+.) SPDY protocol functionality can be (de)activated by toggling the network.http.spdy.enabled variable in about:config.[12] Firefox 15 added support for SPDY 3.[34] Firefox 27 has added SPDY 3.1 support.[36] Firefox 28 has removed support of SPDY 2.[31] about:networking (or the HTTP/2 and SPDY indicator add-on)[46] shows if a website uses SPDY.
  • Opera browser added support for SPDY as of version 12.10.[47]
  • Internet Explorer 11 added support for SPDY version 3,[48][49] but not for the Windows 7 version.[50] A problem experienced by some users of Windows 8.1 and Internet Explorer 11 is that on initial loading, Google says "Page not found" but on reloading, it is fine. One fix for this is to disable SPDY/3 in Internet Options > Advanced.[51] After version 11, IE will drop the support of SPDY, as it will adopt HTTP/2.[52]
  • Amazon's Silk browser for the Kindle Fire uses the SPDY protocol to communicate with their EC2 service for Web pages rendering.[53]
  • Safari 8 and third-party applications in OS X 10.10 and iOS 8 adds support for SPDY 2, 3 and 3.1.[54]

Server support and usage[edit]

As of July 2016, approximately 7.1% of all websites support SPDY.[55] Fielded versions of the two most popular web servers, NGINX and Apache,[56] are the major providers of SPDY traffic.[57] although the latest version of NGINX has now removed SPDY support.[58] This compares with an adoption rate of 8.1% for the newer HTTP/2 protocol, which as of 2016 had overtaken the adoption of SPDY.[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:

  • In November, 2009, Google announced SPDY as an internal project to increase the speed of the web.[62]
  • In September, 2010, Google releases SPDY in Chrome for all versions of Chrome 6.[63]
  • In January, 2011, Google deployed SPDY across all Google services.[64]
  • In March 2012, Twitter enabled SPDY on its servers, at the time making it the second largest site known to deploy SPDY.[65]
  • In March 2012, the open source Jetty Web Server announced support for SPDY in version 7.6.2 and 8.1.2,[66] while other open source projects were working on implementing support for SPDY, like node.js,[67][68] Apache (mod_spdy),[69] curl,[70] and nginx.[71]
  • In April 2012 Google started providing SPDY packages for Apache servers which led some smaller websites to provide SPDY support.[72]
  • In May 2012 F5 Networks announced support for SPDY in its BIG-IP application delivery controllers.[73]
  • In June 2012 NGINX, Inc. announced support for SPDY in the open source web server Nginx.[74]
  • In July 2012 Facebook announced implementation plans for SPDY.[75] By March 2013 SPDY was implemented by some of their public web servers.[76]
  • In August 2012 WordPress.com announced support for SPDY (using nginx) across all their hosted blogs.[77]
  • In June 2013, LiteSpeed Technologies announced support for SPDY/2 and SPDY/3 on OpenLiteSpeed, their open source HTTP server.[33] Support for SPDY/3.1 was announced November 2013.[37]
  • In January 2014, Synology announced SPDY is included in the new DSM 5.0.[78]
  • In February 2014, CloudFlare using nginx announced automatic support for SPDY v3.1 for all customers with SSL/TLS certificates.[79]
  • In May 2014, MaxCDN using nginx announced support for SPDY v3.1 via customers' Pull Zone settings and their API.[80]
  • In October 2014, Yahoo shows support of SPDY on the Yahoo Homepage — www.yahoo.com [81]
  • In September 2015, the latest version of the Nginx web server dropped SPDY support in favour of HTTP/2[58]
  • In May 2016, CloudFlare releases patches to Nginx web server, the patches supports HTTP/2 and SPDY simultaneously.[82]

According to W3Techs, as of July 2016, most SPDY-enabled websites use nginx, with the LiteSpeed web server coming second.[57]

 

posted @ 2017-11-11 01:06  papering  阅读(322)  评论(0)  编辑  收藏  举报