ご存じのように、SPDYプロトコルはHTTPの改良版であり、多くの場合、TCPを介したデータ伝送の速度を大幅に向上させます。 Chrome（2011年1月以降）およびFirefox（ 4日前 ）ではデフォルトで有効になっています。
Martin Nilssonは、Opera MiniやOpera Turboを含め、OperaがHTTPを介したデータ転送の最適化を長年行ってきたため、さまざまなSPDY最適化手法を評価できると指摘しています。
Operaの概要は3つの部分で構成されています。 最初の部分では、SPDYの概念的な機能を分析し、各機能の有用性について簡単に評価します。 2番目の部分はプロトコルのバイナリ実装の評価を提供し、3番目の部分はSPDYを改善するためのOperaの提案を含みます。 会社の複数の部門の従業員がレポートの準備に参加したため、Opera Softwareプログラマーの集合的な創造性の産物と呼ぶことができます。
したがって、すべてのHTTPセマンティクスをSPDYに変換できますが、トランスポートプロトコルSPDYはTCP上で動作し、HTTPを置き換えます。 以下は、OperaがSPDYで使用される最適化方法について考えていることです。
1.パイプラインとキューの処理順序。 これらは、HTTPパフォーマンスを大幅に改善する2つの非常に重要な概念です。 パイプラインの概念はHTTP 1.1に登場し、Operaはこのソリューションの普及に懸命に取り組みました。 残念ながら、多くのハードウェアメーカーはHTTP 1.1を正しく実装できていません。 キュー処理の順序により、低速パケットが高速パケットをブロックするときのパイプラインストッパーの問題が解消されます。これは、リクエストヘッダーをパケットヘッダーに追加することでHTTPで簡単に実装できます。
2.多重化により、新しい接続を開かずに、単一のTCP接続で重要度の低い要求/応答よりも重要な要求/応答を処理できます。 SPDY実装にはフレームサイズの仕様はありません。 SPDYはプッシュをサポートしているため、理論的にはサーバーの主導で新しい接続を開くことができます。
3.受信バッファのサイズを決定することによるフロー制御。 SPDY仕様は、この最適化方法が解決すべき問題を示していません。 これらの問題は、それほど根本的でない方法で解決できるようです。
4. zlibを使用してヘッダーを圧縮します。 表は、さまざまな方法による圧縮中の平均リクエストサイズを示しています。
HTTP 821.1 HTTP zlib 543.5 辞書497.0を使用したHTTP圧縮 SPDY 913.7 SPDY zlib 606.5 辞書517.0を使用したSPDY圧縮
5.非同期ヘッダー。 HEADERSフレームを使用すると、各側で要求または応答に追加のヘッダーを設定できますが、重要なヘッダーが最後の場合、これにより問題が発生する可能性があります。 この機能により、SPDYはインジェクションタイプ攻撃に対してより脆弱になります。
6.サーバー側からプッシュします。 プロトコルは、サーバーが以前に受信した要求の後にのみプッシュできることを示しています。これにより、この機能は役に立たなくなります。たとえば、新しいRSS要素をプッシュする場合、ブロードキャストコンテンツのサイズを制御したり、機能を完全に無効にするメカニズムもありません。 顧客はこの情報を受け入れるか無視するかを選択できますが、費用がかかり無駄なチャネルの無駄になる可能性があります。
SPDYの改善として、Operaは以下を提供します。
- 必要なSETTINGSフレームを、常に最初に来るバージョンと接続パラメーターで設定します。
- 統計に基づいて、可能な場合は各フィールドのサイズの合理的な範囲を確立し、必要に応じて変更します。
- SPDY内にカスタムHTTPフレームをインストールする
- キーと値のペアのリストのより良い構造を開発します。
- クライアント側では、サーバーからプッシュ経由で受信するデータを制御する必要があります。
- 現在のフロー制御を削除し、一時停止に置き換えます（優先度が動的に変更される可能性があります）。
- 辞書を使用して見出しを圧縮しないでください;利点はほとんどありません。
- 非同期ヘッダーのルールを設定してHTTPヘッダーの書き換えを禁止し、受信者はどのヘッダーが生成されるかを事前に知っていました。
IETF HTTP-WGメーリングリストでのSPDYレビューおよびディスカッションの完全版