問題タブ [http2]

http://www.chromium.org/spdy/http2で、Chrome が HTTP2.0 を使用できることがわかりました。しかし、chrome を使用して gRPC サーバーからデータを取得するにはどうすればよいでしょうか?

Chrome バージョン 41.0.2272.104 (64 ビット) からのネットワーク リクエストを調べていたところ、Google アナリティクスのコレクション エンドポイントへのリクエストに好奇心をそそられました。

認識できないヘッダーがいくつかあります: :authority:, :method:, :path:,:scheme:

:authority:HostHTTP 1.xのヘッダーを置き換えるようですが、ヘッダーで:method:はなく HTTP 動詞であると予想されます

Chrome の HAR エクスポートは、HTTP バージョンを「不明」と報告します - http://pastebin.com/1LjRVeHbを参照してください

どうしたの？

ほとんどのブラウザは HTTP/2 をサポートしており、一部のサーバーもサポートしています。

たとえば、Akamai は HTTP/2 テストページ ( https://http2.akamai.com/ ) を提供しています。Chromeでこのページにアクセスしてページに移動するchrome://net-internals/#spdyと、プロトコル h2-14 (HTTP/2 ドラフト 14) がリストされています。しかし、アカマイのページでコンソールを開いてwindow.chrome.loadTimes()プロパティを入力すると、 wasFetchedViaSpdyis true. どうしてこれなの？Akamai のページは SPDY ではなく HTTP/2 ですよね？

私が理解できないもう 1 つのことは、このチュートリアル ( https://www.gatherdigital.co.uk/blog/how-to-setup-http-2-support/527 ) です。それは言います：

「HTTP/2 サポート (nginx、apache、plesk) のセットアップ方法 [...] まあ、HTTP/2 ではありませんが、まだ mod_spdy です。」

この HTTP/2 "over" SPDY とは何ですか? 私の質問の理由は、どのページがどのプロトコルを使用しているかを測定したいからです。

SPDY の場合、PushStrategy を実装し、それを登録してリソースをプッシュする必要があります。

HTTP2 のサポートはどうですか?

HTTP 応答でリンク ヘッダーを読み取る nginx のアイデアが気に入っています: https://nghttp2.org/blog/2015/02/10/nghttp2-dot-org-enabled-http2-server-push/

ありがとう！

HTTP/2 仕様では、クライアントがキャンセルした場合、PUSH_PROMISE フレームで識別されたリソースはプッシュされないことが示されています。

ブラウザーは、既にキャッシュにあるリソースを検出すると、このリソースのプッシュをキャンセルする必要があります。ただし、ブラウザがそれを検出する方法がわかりません。フレームは、etag や最終更新日などの追加情報を提供して、ブラウザがキャッシュ エントリを削除する必要があるかどうか、またはプッシュをキャンセルできるかどうかを検出できるようにしますか?

可能であれば、一部の帯域幅を節約できます。ただし、サーバー プッシュはクライアント キャッシュの最適化を損なうようです。

いくつか調査した結果、Tomcat での HTTP/2 サポートに関するリソースが見つからないことに驚きました。8.0 の変更ログは、SPDY の実験的サポートを示しており、wiki はサポートされている仕様 ( http://wiki.apache.org/tomcat/Specifications ) として HTTP/2 を参照していますが、それに関するチュートリアルは見つかりません。

Tomcat で HTTP/2 を有効にすることがすでに可能かどうか知っていますか? 答えが「はい」の場合、どうすればそれを行うことができますか?

ブラウザと Google の間の HTTP 交換の一部を調べていたところ、この質問が表示されました。

つまり、私のブラウザ (Firefox 36.0.4) は HTTP/1.1 リクエストを作成し、Google は HTTP/2.0 で応答しています。要求されたプロトコルで応答しようとはしません。HTTP/2.0 仕様の多くがすでに SPDY を介してでたらめな方法で実装されていることは承知していますが、これはクライアントとの不十分な交渉のように思えます。

ヘッダーでプロトコルを宣言する目的は、サーバーがクライアントへの応答方法を決定できるようにすることだと思いました。これは、次の 3 つの方法のいずれかです。

1.クライアントがサーバーの優先プロトコルを要求したため、サーバーは通常どおり要求を続行します。

2.クライアントは、サーバーがサポートする別のプロトコル バージョンを要求しました。サーバーは要求プロトコルで応答しますが、優先プロトコルを示すアップグレード ヘッダーが含まれています。クライアントは、サーバーが 101 Switching Protocols 応答を送信し、優先プロトコルに切り替える時点でアップグレードを要求することができます。

3.クライアントがサポートされていない、または古いプロトコルを要求した場合、サーバーはアップグレード ヘッダーでサポートされているプロトコル (優先順位の降順) を含む 426 Upgrade Required 応答を送信します。クライアントは、サポートされているプロトコルを使用して要求を繰り返す必要があります。

4.クライアントは、完全にサポートされていないメジャー プロトコル バージョンを再要求しました。たとえば、サーバーは HTTP/1.x のみをサポートしていますが、HTTP/2.x です。サーバーが 505 HTTP Version Not Supported で応答する

Google とのやり取りはこれを行っていません。これは悪い習慣ですか、それとも何か不足していますか?

ランダムに選択された例:

jetty で SSL 経由の HTTP/2 コネクタを有効にしました。ブラウザに接続しようとすると、「ERR_SSL_PROTOCOL_ERROR」エラーが発生します。HTTP/1.1 コネクタに切り替えると、すべて正常に動作します。

これが私のjetty構成ファイルです：

jetty-server、http2-server、および jetty-alpn-server アーティファクト バージョン 9.3.0.M1 を使用しています。追加する依存関係はありますか? 私はJDK7を使用しています。

ありがとう