[14] [DFN[[[SPDY]]]] は、旧来の [[HTTP]] にかわる新たな[[転送プロトコル]]として [[Google]] が開発したものでした。主要な [[Webブラウザー]]が実装していました。 [[SPDY]] の改訂版は [[HTTP/2]] となっており、現在 [[SPDY]] は[[廃止]]されています。 * 代替 [26] [[HTTP/2]] を使えます。 * 仕様書 [REFS[ - [12] [CITE@en[RFC 7301 - Transport Layer Security (TLS) Application-Layer Protocol Negotiation Extension]] ([TIME[2014-10-12 15:39:49 +09:00]] 版) ]REFS] * プロトコル [11] [[TLS]] [[ALPN]] のプロトコルとしては、各版について次の値が定義されています。 [FIG(list)[ - 0x73 0x70 0x64 0x79 0x2f 0x31 ([CODE[[[spdy/1]]]]) [SRC[>>12]] - 0x73 0x70 0x64 0x79 0x2f 0x32 ([CODE[[[spdy/2]]]]) [SRC[>>12]] - 0x73 0x70 0x64 0x79 0x2f 0x33 ([CODE[[[spdy/3]]]]) [SRC[>>12]] ]FIG] [24] 他に [CODE[[[spdy/3.1]]]] という値も使われています。 [TIME[2015-08-04T09:58:07.000Z]] * URL [16] [[SPDY]] (over [[HTTPS]]) は、 [[HTTPS]] と同じ [CODE(URI)@en[[[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] [CITE[SPDY: An experimental protocol for a faster web (Chromium Developer Documentation)]] ([TIME[2009-11-14 10:19:42 +09:00]] 版) [2] [CITE[SPDY Protocol (Chromium Developer Documentation)]] ([TIME[2009-11-14 10:19:42 +09:00]] 版) [3] [CITE@ja[グーグルが高速プロトコル「SPDY」をChromeブラウザで有効化。Gmailなどで利用を開始していた - Publickey]] ([TIME[2011-04-12 19:47:46 +09:00]] 版) [4] [CITE@en[draft-mbelshe-httpbis-spdy-00 - SPDY Protocol]] ( ([TIME[2012-02-26 13:42:32 +09:00]] 版)) [5] [CITE[IRC logs: freenode / #whatwg / 20120327]] ( ([TIME[2012-04-09 21:35:50 +09:00]] 版)) [6] [CITE@en[787492 – Combining SPDY, HTTP URLs, and TLS client certificates leads to a vulnerability]] ( ([TIME[2014-09-19 14:51:18 +09:00]] 版)) [7] [CITE[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]] ( ([TIME[2014-09-19 14:51:47 +09:00]] 版)) [8] [CITE[SPDY Protocol - The Chromium Projects]] ( ([TIME[2014-11-01 00:36:56 +09:00]] 版)) [9] [CITE[SPDY - The Chromium Projects]] ( ([TIME[2014-11-01 00:36:56 +09:00]] 版)) [10] [CITE[TLSとSPDYの間でGoogle Chromeがハマった脆弱性(CVE-2014-3166の解説) - ぼちぼち日記]] ( ([TIME[2014-11-02 11:03:14 +09:00]] 版)) [13] [CITE@en[Chromium Blog: Hello HTTP/2, Goodbye SPDY]] ( ([TIME[2015-02-10 03:03:41 +09:00]] 版)) [FIG(quote)[ [FIGCAPTION[ [20] [CITE@ja[LINE Developer Conferenceまとめリポート(前編):世界制覇をもくろむLINE――ベールを脱いだプラットフォームの全体像とは (3/3) - @IT]] ([TIME[2015-05-11 18:46:50 +09:00]] 版) ]FIGCAPTION] > LINEのクライアントとサーバー間は、HTTPを拡張して高速化を図ったプロトコルである「SPDY」をベースに通信を行っている。なぜSPDYの仕様をそのまま使っていないかというと、LINEサーバーの場合は、通信の相手はLINEアプリしかなく、UserAgentは1種類に限定される。UserAgentが未知の状態でサーバーがリクエストを受け付ける場合、どのプロトコルで相手と通信するかを最初に決めなければならないが、LINEサーバーの場合は、そうした処理を省略することによって通信の高速化を図っている。 ]FIG] [15] [CITE@en[mbelshe/SPDY-Specification at gh-pages]] ([TIME[2015-12-03 01:34:51 +09:00]] 版) [FIG(quote)[ [FIGCAPTION[ [25] [CITE[API Deprecations and Removals in Chrome 51 | Web Updates - Google Developers]] ( ([TIME[2016-08-03 01:42:01 +09:00]])) ]FIGCAPTION] > Support for HTTP/2 is widespread enough that SPDY/3.1 support can be dropped. ]FIG]