問題タブ [http2]

HTTP/2 の立ち上げに関する記事を読んでいました。HTTP/2はSPDY（スピーディー）プロトコルをベースとしており、「ヘッダーフィールドの圧縮」と「多重化」を利用することで、HTTP/1.1よりも高速なブラウジング速度を実現できるとのことでした。これらの用語はどのように正確に機能しますか?

HTTP/1.1 ではリクエストが「次々に」処理されると信じるべきですか?

http2 RST_STREAM の新機能について読みました:

HTTP/2 は RST_STREAM フレームを追加して、クライアントが気が変わることを可能にします。ブラウザーがページから移動した場合、またはユーザーがダウンロードをキャンセルした場合、その帯域幅をすべて無駄にすることなく、新しい接続を開く必要がなくなります。

これを行うにはどうすればよいですか?ブラウザでこれを行うにはどうすればよいですか?コードに変更はありますか?

2 月 26 日、Google は gRPC を発表しました: http://googledevelopers.blogspot.com.br/2015/02/introducing-grpc-new-open-source-http2.html

その投稿で、彼らは次のように述べています:「Google の内部では、HTTP/2 への長期的な取り組みの一環として、gRPC エンドポイントを介してほとんどのパブリック サービスを公開するために gRPC を使用し始めています。

gRPC を使用してパブリック API を公開し始めている場合...アプリケーション間の内部通信に何を使用しているのでしょうか?

アプリ間の内部通信にも gRPC を使用することに特定の問題はありますか?

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 です。

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