問題タブ [http2]

CouchDB API には、HTTP 経由でアクセスできます。デザインとドキュメントの CRUD 操作は、単純なリクエストで実現できます。

ただし、パフォーマンスに関して人々が提起する懸念は、HTTP2 プロトコルを採用することで緩和される可能性があります。

私はこれを考えるのに一線を画していますか？

このイニシアチブに考えや方向性があるかどうか誰か知っていますか?

顧客の要求に応じて、既存のエンタープライズ アプリを HTTP 2.0 に移行する実験を行っています。アプリは ASP.NET フォーム認証を使用し、HTTP 2.0 対応のブラウザーとサーバー (Windows Server Tech Preview) を使用して HTTPS 経由でアクセスすると、ログイン アクション中に認証が成功したように見え、要求された URL にリダイレクトされますが、その後サーバーが応答します。ログイン URL へのリダイレクトを伴う次の要求。Application_BeginRequest にいくつかの診断ログを追加した後、認証 Cookie が要求に存在することがわかりましたが、FormsAuthentication.Decrypt() でチケットを復号化しようとすると、Cookie に base-64 以外の文字があることを示す例外がスローされます。これは、HTTP 2.0 ヘッダー圧縮と関係があると思われます。しかし、これは IIS によって透過的に処理されるべきであり、コードが実行されるまでにヘッダーが解凍されているはずだと思っていたでしょう。他の誰かがこれを経験し、回避策を知っていますか? 何かを省略した場合は、追加情報を提供させていただきます。

販売している製品/サービスの静的なランディング ページを運営しており、AdWords などを使用して宣伝しています。当然のことながら、ページの読み込み速度は、コンバージョンを最大化するための大きな要因です。

HTTP/2 の利点:

1. データはより圧縮されます。
2. サーバー プッシュを使用すると、要求なしですべてのリソースを一度に送信できます。これには、base64 インライン イメージ、スプライトなどを置き換えるなど、多くの利点があります。
3. 単一の接続で多重化すると、読み込み時間が大幅に短縮されます。

HTTP/2 の短所:

1) ロード速度を遅くする必須の TLS。

だから私は引き裂かれました。一方で、HTTP/2 には多くの改善点があります。一方で、不必要な TLS を避け続け、引き続き base64/スプライトを使用してリクエストを減らす方が速いかもしれません。

合計ページ サイズは ~1MB です。

それは価値があるでしょうか？

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 とのやり取りはこれを行っていません。これは悪い習慣ですか、それとも何か不足していますか?

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