問題タブ [spdy]

iOS および Android 用の Facebook Javascript SDK を使用して、HTML5 + Cordova (Phonegap) でモバイル アプリケーションを開発しています。私はこのように実装します:

AndroidとiOで数か月間、昨日までAndroidで動作しました。APIへの呼び出しが行われ、コールバック関数が呼び出されない場合、エラーが発生します。

Eclipse の LogCat からのエラーは次のとおりです。

02-26 12:27:10.526: W/chromium(22379): external/chromium/net/spdy/spdy_session.cc:1246: [0226/122710:WARNING:spdy_session.cc(1246)] Spdy コントロール フレームを解析できませんでしたヘッダ。02-26 12:27:10.526: D/chromium(22379): 不明なクロム エラー: -337 02-26 12:27:10.526: W/chromium(22379): 外部/クロム/ネット/spdy/spdy_session.cc: 1058: [0226/122710:WARNING:spdy_session.cc(1058)] 無効なストリーム 1 のデータ フレームを受信しました 02-26 12:27:10.526: W/chromium(22379): external/chromium/net/spdy/spdy_session.cc :1058: [0226/122710:WARNING:spdy_session.cc(1058)] 無効なストリーム 1 のデータ フレームを受信しました

クエリFacebook（プロトコルspdyを使用）を呼び出すときのAndroidブラウザChromiumのエラーのようです

誰にもアイデアがありますか？

ありがとうございました ！

Rails アプリがあり、Google SPDY プロトコルのサポートを設定したいと考えています。しかし、SPDYパッチを使用してNginxをインストールし、仮想ホストでspdyを有効にすると、nginxを再起動できなくなり、代わりに次のエラーがスローされます。

最新のnginx 1.3.13をspdyパッチでコンパイルしました。ここでは、インストールの手順について言及しています

エラーなしで正常にコンパイルされます。結果 0f nginx -V は次のようになります

私の /etc/nginx/site-enabled 構成には

結局、この正常なインストール nginx は、サイト対応ファイルのサーバー ブロックの spdy パラメータで再起動しません。

助言がありますか？ここで何かが欠けていると確信していますが、わかりません。

Windows AzureがSPDYプロトコルをサポートしているか（またはサポートする予定があるか）誰かが知っていますか？何も見つからなかったので、まだサポートされていないと思います...

Sun Jvm で動作する代替手段を知っていますか? Open Jdk を使用できないため、Sun Jvm で動作する代替の NPN ライブラリを探しています。

SPDYは、キープアライブ接続を介したhttp多重化とは異なり、HTTPパイプリングとSPDYを使用したHTTP多重化の違いだけでなく、http ：//www.guypo.com/technical/not-as-spdy-as-you-thought /。

私自身の経験では、どちらもpingよりもほんの数ミリ秒多いことに気づきました。

私は何かが足りないのですか？これを使用してhttp://www.howtoforge.com/using-mod_spdy-with-apache2-on-ubuntu-12.10をインストールしました。見逃した設定はありますか？

そのため、SSL リクエスト / レスポンス用に nginx + spdy を実行しています。

すべてうまくいきます。

残念ながら、spdy は現時点では SSL のみです。

現在、私たちのサービスはかなり ajax を多用しています。

要求が ssl ハンドラーに送信され、ssl ハンドラーがそれらを必要な場所にリバース プロキシするように、必要な変更をかなり迅速に行うオプションがあります。

spdy は本当にそんなにスピードアップしますか? chrome / 最新の firefox が ajax リクエストを ssl ハンドラーに送信し、ssl ハンドラーが必要な場所にリバース プロキシを送信するようにするのに、おそらく数時間かかることは価値がありますか?

ノート：

a) これは、ホワイト リストに登録されているブラウザーの選択されたグループに対してのみアクティブになります (例: chrome latest / firefox latest)。かなり単純な js の変更があります。

b) はい、ホワイト リストに記載されているこれらのブラウザーで http -> https ajax リクエストを作成する方法を知っています。

c) かなり広範なテストから、nginx + spdy の組み合わせは非常にうまく機能します。はい、この時点でわずかにアルファ/ベータであることはわかっています。私たちが喜んで取る小さなリスク。

d) 私たちのサービスは 90% 以上の ajax です。最初のエントリのみが非 ajax 経由で提供され、他のすべての「ページ ビュー」は ajax 経由で処理されます。したがって、これにより、ユーザーの大部分のサブセットの処理速度が大幅に向上する可能性があります。

ありがとう。

Web サーバーで独自の SPDY サポート実装を開発しようとしています。SPDY は、Web ページの読み込みの待ち時間を短縮するための Google の実験的なプロトコルです。クライアント/サーバーの対話は、クライアントとサーバー間の「フレーム」と呼ばれる SPDY 情報単位の双方向交換である「ストリーム」を介して行われます。これらのフレームの一部にはヘッダー ブロックが含まれており、このブロックは常に圧縮されています。「ヘッダーブロック」を解凍するために次の関数（WebサーバーはCで記述されています）を使用しています。圧縮/解凍アルゴリズムはdeflateであるため、zlibが方法です：

}

SPDY セッション (TCP 接続に対応) の各フレームのストリーム内の各フレームに同じコンプレッサー/デコンプレッサーを再利用するための SPDY 仕様のアドバイス。このように、すべてのヘッダー ブロックは、辞書を使用して内部状態が既に "ウォーム" されている z_stream によって脅かされます。 （SPDY仕様にも含まれます）。ディクショナリの設定と z_stream の初期化は成功しました。最初のブロックの解凍は正常に機能し、2 番目のフレーム ブロックの解凍は失敗しました。

rv = インフレート (デコンプ、Z_SYNC_FLUSH);

戻り値は -3 (Z_DATA_ERROR)、decomp->msg は「不正なヘッダー チェック」に設定されます。inflate が zlib ヘッダーを見つけられないように思えます。データの圧縮と解凍は、Google の仕様で提案されているように、Z_SYNC_FLUSH で deflate() と inflate() を呼び出すことによって行われます。これを chromium (実際にテストに使用するブラウザー) のソース コードで確認しました。最初のブロック (解凍に成功) は次のとおりです。

2番目のブロック（私を怒らせている）は次のとおりです。

どちらもZ_SYNC_FLUSHトレーラー ( 00FF) を認識できますが、2 番目のフレームの先頭に適切なヘッダーがあるかどうかを確認できません。私の質問: 2 番目の圧縮コンテンツは実際にはヘッダーなしですか? そして、この場合、どの方法でこのストリームを解凍できますか?

以下のコメントで簡単に説明したように、エラーは inflateReset() 呼び出しにありました。これは、00FF トレーラーを使用して取得したコンプレッサーとデコンプレッサー間の同期が壊れるためです。最後に、コードの正しいバージョンは次のようになります。

詳細については、http ://www.bolet.org/~pornin/deflate-flush.htm を参照してください。

http://dev.chromium.org/spdy/spdy-whitepaperでSPDYホワイトペーパーを読むと、それをサポートすることでHTTPレイテンシーが改善されるようです。しかし、私はいくつかの主張についてはっきりしていません。

1）「HTTPは一度に1つのリソースしかフェッチできないため（HTTPパイプラインは役立ちますが、FIFOキューのみを強制します）、500ミリ秒のサーバー遅延により、追加の要求にTCPチャネルを再利用できません。」-この500msの数値はどこから来たのですか？

2）「SPDYの遅延の節約は、パケット損失率の増加に比例して増加し、2％で最大48％のスピードアップになることを発見しました。」-しかし、すべての要求を単一のTCP接続に配置することは、輻輳制御がすべての要求を遅くすることを意味しませんが、複数の接続がある場合、1つのTCPストリームは遅くなりますが、他の人は遅くなりませんか？

3）「[パイプライン処理を使用]ストリーム内の何かの処理の遅延（行頭での長い要求またはパケット損失のいずれか）は、ストリーム全体を遅延させます。」-これは、パケット損失がSPDYを使用してストリーム全体を遅延させないことを意味します。なぜだめですか？

jetty9 を使用して spdy プロキシ サーバーを起動しました。

jetty-spdy-proxy.xml:

http/1.1 ローカルホスト http/1.1 127.0.0.1 9090

8080 8443

このサーバーは正常に起動しました。

私の考えでは、このプロキシ サーバーは spdy を http に変換し、それをターゲット サーバーにプロキシできます。

Javaクライアント（ブラウザではなく）でプロキシサーバーと通信する方法がわからないため、今はテストできません。私は自分の問題をグーグルで検索しましたが、何も見つかりませんでした。ここに何か提案はありますか?