SPDY

[14] SPDY は、旧来の HTTP にかわる新たな転送プロトコルとして Google が開発したものでした。主要な Webブラウザーが実装していました。 SPDY の改訂版は HTTP/2 となっており、現在 SPDY は廃止されています。

代替

[26] HTTP/2 を使えます。

仕様書

[12] RFC 7301 - Transport Layer Security (TLS) Application-Layer Protocol Negotiation Extension (2014-10-12 15:39:49 +09:00 版) <https://tools.ietf.org/html/rfc7301#section-6>

プロトコル

[11] TLS ALPN のプロトコルとしては、各版について次の値が定義されています。

0x73 0x70 0x64 0x79 0x2f 0x31 (spdy/1) >>12
0x73 0x70 0x64 0x79 0x2f 0x32 (spdy/2) >>12
0x73 0x70 0x64 0x79 0x2f 0x33 (spdy/3) >>12

[24] 他に spdy/3.1 という値も使われています。 2015-08-04T09:58:07.000Z

URL

[16] SPDY (over HTTPS) は、 HTTPS と同じ https: URL を使っていました。 HTTPS の代替となるプロトコルでしたから、同じ資源を参照することが期待されており、両者を区別する方法はありませんでした。

利用者インターフェイス

[17] SPDY は利用者にとって透過的に実装されており、開発者ツールを除き、旧来の HTTP が使われているのか SPDY が使われているのか判別する方法は用意されていませんでした。

相互運用性

[21] SPDY はすべての Webブラウザーや利用者エージェントが実装しているわけではないため、また実装済みでもセキュリティーなどの理由で無効にされることがあったため、 Webサーバーは従来の HTTP も同時に実装する必要がありました。また SPDY を実装していない Webサーバーやプロキシが大部分なので、利用者エージェントは従来の HTTP も同時に実装する必要がありました。

[22] こうした理由から、 SPDY を実装しなくても、 Web非互換ではありませんでした。 HTTP/2 に移行した後 SPDY を実装し続ける必要はありません。

[23] Web における新技術開発の歴史では大変珍しいパターンです。これまで一旦普及した技術を後から廃止するのは困難でした。

歴史

[18] SPDY は Chrome が最初に実装し、他の Webブラウザーも追随しました。

[19] いくつかの Webサーバーも、ネイティブもしくは追加モジュールとして SPDY に対応しました。

[1] SPDY: An experimental protocol for a faster web (Chromium Developer Documentation) (2009-11-14 10:19:42 +09:00 版) <http://dev.chromium.org/spdy/spdy-whitepaper>

[2] SPDY Protocol (Chromium Developer Documentation) (2009-11-14 10:19:42 +09:00 版) <http://dev.chromium.org/spdy/spdy-protocol>

[3] グーグルが高速プロトコル「SPDY」をChromeブラウザで有効化。Gmailなどで利用を開始していた - Publickey (2011-04-12 19:47:46 +09:00 版) <http://www.publickey1.jp/blog/11/spdychromegmail.html>

[4] draft-mbelshe-httpbis-spdy-00 - SPDY Protocol ( (2012-02-26 13:42:32 +09:00 版)) <http://tools.ietf.org/html/draft-mbelshe-httpbis-spdy-00>

[5] IRC logs: freenode / #whatwg / 20120327 ( (2012-04-09 21:35:50 +09:00 版)) <http://krijnhoetmer.nl/irc-logs/whatwg/20120327>

[6] 787492 – Combining SPDY, HTTP URLs, and TLS client certificates leads to a vulnerability ( (2014-09-19 14:51:18 +09:00 版)) <https://bugzilla.mozilla.org/show_bug.cgi?id=787492>

[7] Issue 145989 - chromium - Combining SPDY, HTTP URLs, and TLS client certificates leads to a vulnerability - An open-source project to help move the web forward. - Google Project Hosting ( (2014-09-19 14:51:47 +09:00 版)) <https://code.google.com/p/chromium/issues/detail?id=145989>

[8] SPDY Protocol - The Chromium Projects ( (2014-11-01 00:36:56 +09:00 版)) <http://dev.chromium.org/spdy/spdy-protocol>

[9] SPDY - The Chromium Projects ( (2014-11-01 00:36:56 +09:00 版)) <http://dev.chromium.org/spdy>

[10] TLSとSPDYの間でGoogle Chromeがハマった脆弱性(CVE-2014-3166の解説) - ぼちぼち日記 ( (2014-11-02 11:03:14 +09:00 版)) <http://d.hatena.ne.jp/jovi0608/20140822/1408671363>

[13] Chromium Blog: Hello HTTP/2, Goodbye SPDY ( (2015-02-10 03:03:41 +09:00 版)) <http://blog.chromium.org/2015/02/hello-http2-goodbye-spdy-http-is_9.html>

[20] LINE Developer Conferenceまとめリポート(前編):世界制覇をもくろむLINE――ベールを脱いだプラットフォームの全体像とは (3/3) - @IT (2015-05-11 18:46:50 +09:00 版) <http://www.atmarkit.co.jp/ait/articles/1404/23/news034_3.html>

LINEのクライアントとサーバー間は、HTTPを拡張して高速化を図ったプロトコルである「SPDY」をベースに通信を行っている。なぜSPDYの仕様をそのまま使っていないかというと、LINEサーバーの場合は、通信の相手はLINEアプリしかなく、UserAgentは1種類に限定される。UserAgentが未知の状態でサーバーがリクエストを受け付ける場合、どのプロトコルで相手と通信するかを最初に決めなければならないが、LINEサーバーの場合は、そうした処理を省略することによって通信の高速化を図っている。

[15] mbelshe/SPDY-Specification at gh-pages (2015-12-03 01:34:51 +09:00 版) <https://github.com/mbelshe/SPDY-Specification/tree/gh-pages>

[25] API Deprecations and Removals in Chrome 51 | Web Updates - Google Developers ( (2016-08-03 01:42:01 +09:00)) <https://developers.google.com/web/updates/2016/04/chrome-51-deprecations#remove-support-for-spdy31>

Support for HTTP/2 is widespread enough that SPDY/3.1 support can be dropped.