「SPDY」の版間の差分

提供: セキュリティ
移動: 案内、 検索
行1: 行1:
−
[[SPDY]] とは、[[HTTP/2.0|HTTP 2.0]]の起草になった通信プロトコルです。
+
[[SPDY]] とは、[[HTTP/2|HTTP 2.0]]の起草になった通信プロトコルです。[[SPDY]]を用いることで、ウェブページのロードを高速化できます。
  
 
'''読み方'''
 
'''読み方'''
行6: 行6:
  
 
== 概要 ==
 
== 概要 ==
 +
HTTP/1系のプロトコルでは、仕様によりボトルネックを多く抱えていました。[[SPDY]]をセッションレイヤーに組み込むことにより、HTTPを速くします。
 +
 
* [[ウェブブラウザ]]のサイトの読み込み時間を短縮する
 
* [[ウェブブラウザ]]のサイトの読み込み時間を短縮する
 
* ウェブコンテンツの変更を必要としない
 
* ウェブコンテンツの変更を必要としない
 
* 既存の[[Webサーバ]]との互換性を維持できる
 
* 既存の[[Webサーバ]]との互換性を維持できる
  
 +
== HTTPの通信のボトルネック ==
 +
* １回のコネクションにつき、１つのリクエストしか送信できない
 +
* リクエストがクライアントからしか開始できない
 +
* リクエストヘッダとレスポンスヘッダが圧縮できず、サイズが大きい
 +
* ヘッダが冗長である
 +
* データ圧縮が強制ではない
 +
=== 並列TCPコネクションの問題点 ===
 +
HTTP/1の実装のボトルネックの１つは、並列処理のためのTCPの複数のコネクションです。
 +
# 接続により発生するラウンドトリップタイム
 +
# [[スロースタート]]
 +
# クライアントの１つのサーバに対する複数接続の制限
 +
 +
1 は、[[3ウェイ・ハンドシェイク]]のパケットの往復のことです。並列実行のために、このパケットがネットワークに流れます。
 +
 +
2 の[[スロースタート]]の問題は、[[TCP]]のウィンドウサイズが十分に大きくなるまでに時間がかかることです。ウィンドウサイズは、通信が進むにつれて、サイズが大きくなります。しかし、並列コネクションで通信する場合、ウィンドウサイズが十分に大きくなる前にデータの送受信が完了してしまいます。単一のコネクションで、ウィンドウサイズが大きい状態で通知んするほうがパケットの往復する数を減らすことができます。並列で接続している場合、それぞれのコネクションは、小さいウィンドウサイズで送受信することになるので、パケットの数が増えてしまいます。
 +
 +
3 は、サーバのコネクション（リソース）を使いきらないように、クライアントが１つのサーバあたりの接続性を抑制しているため、並列数が一定以上上げられない、ということになります。
 +
== HTTP 1.1 ==
 +
HTTP 1.0の問題がHTTP 1.1で解決されています。
 +
* Keep Aliveにより、接続を使いまわすことができます。
 +
* Keep Alive の問題は、同時に複数のリクエストが送信できないことです。現在送信中のHTTPリクエストに対するHTTPのレスポンスが返ってくるまで、次のリクエストが送信できません。
 +
* アクセスの多いサイトでは、Keep Aliveをオンにしていると接続を使いきってしまい、新しく接続してきたクライアントの接続を受け入れられなくなるため、十分なリソースがないと Keep Alive が使えないケースがあります。
 +
== piplining ==
 +
pipliningは、HTTPレスポンスの受信の失敗や受信の遅延により、pipline上の他のHTTPリクエストやレスポンスの送受信が失敗か、遅延を引き起こしてしまいます。
 +
並列のリクエストのいずれかが失敗すると、TCPコネクションの接続確立からやり直す必要があります。
 +
== SPDYの特徴 ==
 
* [[SPDY]]は、バイナリプロトコルであるため、HTTPヘッダデータのサイズを小さくできます。
 
* [[SPDY]]は、バイナリプロトコルであるため、HTTPヘッダデータのサイズを小さくできます。
 
* ストリームベースの多重化により、GETに対して、コンテンツを複数並列で返すことができます。
 
* ストリームベースの多重化により、GETに対して、コンテンツを複数並列で返すことができます。
 +
* クライアントは、リクエストに優先度がつけられます。
 +
* ヘッダは、デフォルトで圧縮され、不要なヘッダは削除されます。
 
* コンテンツをブラウザにキャッシュし、ヒットしないときだけサーバに取りに行きます。
 
* コンテンツをブラウザにキャッシュし、ヒットしないときだけサーバに取りに行きます。
 +
* サーバプッシュ通信をサポートします。
 +
 +
 +
[[SPDY]]では、TCPコネクション上に複数の論理的なストリームを構築します。それぞれのストリームは独立し、リクエストの順番とレスポンスの順番に制約はありません。
 +
ストリームの制御には、データを含まない専用のコントロールフレームを用います。それぞれのコントロールフレームは、Stream-IDを持ち、このIDにより、各ストリームは区別されます。
 +
データ本体は、データフレームとして送信されます。
 +
 +
[[SPDY]]は、ストリームのライフサイクルの管理のために３つのコントロールフレームを定義しています。
 +
; SYN_STREAM:新しいストリームを開きます。
 +
; SYN_REPLY: リモートアックノレッジメント
 +
; RST_STREAM:ストリームを閉じます。
 +
 +
== ネットワークの層とプロトコルの対応 ==
 +
[[SPDY]]は、セッション層にあたります。
 +
{|class="wikitable"
 +
|+ ネットワークの層とプロトコル
 +
! 層
 +
! プロトコル
 +
|-
 +
| アプリケーション層
 +
| HTTP
 +
|-
 +
| セッション層
 +
| SPDY
 +
|-
 +
| プレゼンテーション層
 +
| SSL
 +
|-
 +
| トランスポート層
 +
| TCP
 +
|}
  
 
== SPDYの環境 ==
 
== SPDYの環境 ==
行30: 行91:
 
* [[nginx]]
 
* [[nginx]]
 
** nginx 1.6ではSPDY 3.1に対応
 
** nginx 1.6ではSPDY 3.1に対応
 +
* Jetty 7.6.2と8.1.2以降
  
 
== SPDYに対応したサーバにコマンドラインでアクセスする方法 ==
 
== SPDYに対応したサーバにコマンドラインでアクセスする方法 ==
行37: 行99:
 
$ spdycat -v https://www.google.com/
 
$ spdycat -v https://www.google.com/
 
</syntaxhighlight>
 
</syntaxhighlight>
 +
== SPDYのバージョン ==
 +
=== spdy/4 ===
 +
=== spdy/3.1 ===
 +
* セッション単位のフロー制御が可能
 +
=== spdy/2 ===
 +
=== spdy/1 ===
  
 
== インストール ==
 
== インストール ==

2014年11月15日 (土) 14:21時点における版

SPDY とは、HTTP 2.0の起草になった通信プロトコルです。SPDYを用いることで、ウェブページのロードを高速化できます。

読み方

SPDY
すぴーでぃー, えすぴーでぃーわい

概要

HTTP/1系のプロトコルでは、仕様によりボトルネックを多く抱えていました。SPDYをセッションレイヤーに組み込むことにより、HTTPを速くします。

  • ウェブブラウザのサイトの読み込み時間を短縮する
  • ウェブコンテンツの変更を必要としない
  • 既存のWebサーバとの互換性を維持できる

HTTPの通信のボトルネック

  • １回のコネクションにつき、１つのリクエストしか送信できない
  • リクエストがクライアントからしか開始できない
  • リクエストヘッダとレスポンスヘッダが圧縮できず、サイズが大きい
  • ヘッダが冗長である
  • データ圧縮が強制ではない

並列TCPコネクションの問題点

HTTP/1の実装のボトルネックの１つは、並列処理のためのTCPの複数のコネクションです。

  1. 接続により発生するラウンドトリップタイム
  2. スロースタート
  3. クライアントの１つのサーバに対する複数接続の制限

1 は、3ウェイ・ハンドシェイクのパケットの往復のことです。並列実行のために、このパケットがネットワークに流れます。

2 のスロースタートの問題は、TCPのウィンドウサイズが十分に大きくなるまでに時間がかかることです。ウィンドウサイズは、通信が進むにつれて、サイズが大きくなります。しかし、並列コネクションで通信する場合、ウィンドウサイズが十分に大きくなる前にデータの送受信が完了してしまいます。単一のコネクションで、ウィンドウサイズが大きい状態で通知んするほうがパケットの往復する数を減らすことができます。並列で接続している場合、それぞれのコネクションは、小さいウィンドウサイズで送受信することになるので、パケットの数が増えてしまいます。

3 は、サーバのコネクション（リソース）を使いきらないように、クライアントが１つのサーバあたりの接続性を抑制しているため、並列数が一定以上上げられない、ということになります。

HTTP 1.1

HTTP 1.0の問題がHTTP 1.1で解決されています。

  • Keep Aliveにより、接続を使いまわすことができます。
  • Keep Alive の問題は、同時に複数のリクエストが送信できないことです。現在送信中のHTTPリクエストに対するHTTPのレスポンスが返ってくるまで、次のリクエストが送信できません。
  • アクセスの多いサイトでは、Keep Aliveをオンにしていると接続を使いきってしまい、新しく接続してきたクライアントの接続を受け入れられなくなるため、十分なリソースがないと Keep Alive が使えないケースがあります。

piplining

pipliningは、HTTPレスポンスの受信の失敗や受信の遅延により、pipline上の他のHTTPリクエストやレスポンスの送受信が失敗か、遅延を引き起こしてしまいます。 並列のリクエストのいずれかが失敗すると、TCPコネクションの接続確立からやり直す必要があります。

SPDYの特徴

  • SPDYは、バイナリプロトコルであるため、HTTPヘッダデータのサイズを小さくできます。
  • ストリームベースの多重化により、GETに対して、コンテンツを複数並列で返すことができます。
  • クライアントは、リクエストに優先度がつけられます。
  • ヘッダは、デフォルトで圧縮され、不要なヘッダは削除されます。
  • コンテンツをブラウザにキャッシュし、ヒットしないときだけサーバに取りに行きます。
  • サーバプッシュ通信をサポートします。


SPDYでは、TCPコネクション上に複数の論理的なストリームを構築します。それぞれのストリームは独立し、リクエストの順番とレスポンスの順番に制約はありません。 ストリームの制御には、データを含まない専用のコントロールフレームを用います。それぞれのコントロールフレームは、Stream-IDを持ち、このIDにより、各ストリームは区別されます。 データ本体は、データフレームとして送信されます。

SPDYは、ストリームのライフサイクルの管理のために３つのコントロールフレームを定義しています。

SYN_STREAM
新しいストリームを開きます。
SYN_REPLY
リモートアックノレッジメント
RST_STREAM
ストリームを閉じます。

ネットワークの層とプロトコルの対応

SPDYは、セッション層にあたります。

ネットワークの層とプロトコル
層 プロトコル
アプリケーション層 HTTP
セッション層 SPDY
プレゼンテーション層 SSL
トランスポート層 TCP

SPDYの環境

SPDYを使用するには、SPDYに対応したWebサーバとウェブブラウザが必要です。 ChromeやFirefoxなどのブラウザは、SPDYに対応しています。 Apache HTTP Serverは、 Apache mod spdyを組み込むことで利用できます。

SPDYに対応しているWebサーバ, プロキシ を挙げます。

SPDYに対応したサーバにコマンドラインでアクセスする方法

SPDYに対応したサーバにコマンドでアクセスするには、spdylayで提供されるspdycatを利用します。curlコマンドライクにアクセスできます。 

$ spdycat https://www.google.com/
$ spdycat -v https://www.google.com/

SPDYのバージョン

spdy/4

spdy/3.1

  • セッション単位のフロー制御が可能

spdy/2

spdy/1

インストール

ツール

関連項目

「https://kaworu.jpn.org/security/index.php?title=SPDY&oldid=2400」から取得