問題タブ [http-pipelining]

質問する

For questions regarding programming in ECMAScript (JavaScript/JS) and its various dialects/implementations (excluding ActionScript). Note JavaScript is NOT the same as Java! Please include all relevant tags on your question; e.g., [node.js], [jquery], [json], [reactjs], [angular], [ember.js], [vue.js], [typescript], [svelte], etc.

22 問題
Newest
Active
Bountied
318
Unanswered
0 投票する
0 に答える
521 参照

node.js - Node.jsパイプラインHTTPクライアントエージェント?

Node.js に組み込まれている HTTP クライアントは、リクエストのパイプライン処理をサポートしていないようです。しかし、バックグラウンドでパイプラインをセットアップするエージェントを作成できる可能性があることに気が付きました。応答データを本来あるべき状態に戻す際に問題が発生する可能性がありますが、おそらくエージェントはいくつかのソケット オブジェクトを偽造して、HTTP クライアントを通常どおりに動作させることができますか?

これは行われましたか？または、パイプラインをサポートするメインのドロップイン代替である代替 HTTP クライアントはありますか? （最終的にはAWS SDKで使いたいので互換性が必要です。）

0 投票する
2 に答える
8763 参照

google-chrome - 最新のブラウザでパイプラインが無効になっているのはなぜですか?

最新のブラウザーのすべてではないにしても、多くはパイプライン化された HTTP 要求を使用していません。理論的には、パイプライン処理は、Web サイトの取得に必要な往復回数を減らすことで、リクエストを高速化するはずです。

HTTP 標準によると、すべてのサーバーはパイプライン化された要求を処理する必要があるため、問題はサーバーでのサポートの欠如にあってはなりません。

クライアントがサーバーのパフォーマンスを集中的に使用する URL にできるだけ多くのパイプライン化された要求をプッシュし、受信する可能性のある応答を無視する場合のレイヤー 7 DoS 攻撃など、いくつかのセキュリティ上の懸念を見てきました。

これは、サーバーでパイプラインのサポートをオフにする (標準に違反する) 理由になりますが、クライアントでオフにする理由が見つかりません。

ただし、Android ブラウザと Chrome モバイルではデフォルトでオンになっています。

Chrome、Firefox、IE、Opera、Safari のデスクトップ (場合によってはモバイル) バージョンで、パイプライン化された HTTP リクエストを使用しないのはなぜですか? それをオフにする背後にある彼らの理由は何ですか?

0 投票する
0 に答える
133 参照

nsmutableurlrequest - NSMutableURLRequest パイプラインの混乱

同じ HTTP サーバーから大量の画像をダウンロードしたいので、そのすべてを同じ TCP 接続で実行したいと考えています。私が見つけることができるのは、NSMutableURLRequestパイプライン ( HTTPShouldUsePipelining) を有効にできることだけですが、パイプラインを有効にしたときに一緒に送信する要求をどのように認識するのかわかりません。

私はこれを試しましたが、Wireshark によると、2 つの要求と応答は別々の TCP ストリーム上にあるため、実際に要求をパイプライン処理しているようには見えません。

Strabo.com がパイプライン処理をサポートしていない場合に備えて、自分のローカル Nginx サーバーでも試してみました。

また、SDWebImageDownloaderどういうわけか HTTP パイプラインを使用していることに気付きました。複数のリクエストが同じ TCP ストリーム内で送信されていることがわかります。ただし、それらすべてを同じストリームで送信するわけではなく、それをやりたいので、カスタムダウンローダーを実装しようとしています。

0 投票する
1 に答える
803 参照

http - キープアライブ接続での HTTP クライアント要求のタイムアウト処理

HTTPキープアライブに関して、クライアント側でリクエストタイムアウトをどのように処理する必要がありますか? たとえば、次のような流れがあります。

  • クライアントは Request1 を送信します。
  • クライアントは 1 分間待機します。
  • クライアントは Request1 が失敗したと見なし、それを再送信します。つまり、新しい Request2 = Request1 を送信します。
  • サーバーは Response1 (Request1 に対する応答) で応答します。
  • クライアントはこれが Request2 への応答であると想定しますが、Request1 = Request2 であるため処理できます。
  • クライアントは Request3 を送信します。
  • サーバーは Response2 (Request2 に対する応答) で応答します。
  • クライアントは、これが Request3 への応答であると想定し、処理に失敗します。

仕様に情報が見つかりませんでした。接続がサーバーによって閉じられた場合に再試行する方法は記載されていますが、リクエストの処理に時間がかかりすぎた場合の状況については何もありません。

0 投票する
1 に答える
1179 参照

akka-http - Akka HTTP ソース ストリーミングと通常のリクエスト処理

リクエストを処理する通常の方法と比較して、ソース ストリーミングを使用する利点は何 ですか? どちらの場合も私の理解

  1. TCP 接続は再利用されます
  2. クライアントとサーバーの間にバックプレッシャーが適用されます

私が見ることができるソース ストリーミングの唯一の利点は、非常に大きな応答があり、クライアントがそれを小さなチャンクで消費することを好む場合です。

私の使用例は、非常に長いユーザー (数百万) のリストがあり、ユーザーに対して何らかのフィルタリングを実行してサブセットを返すサービスを呼び出す必要がある場合です。

現在、サーバー側ではバッチ API を公開し、クライアントではユーザーを 1000 のチャンクに分割し、Akka HTTP Host API を使用して X バッチ呼び出しを並行して行います。

HTTP ストリーミングへの切り替えを検討していますが、どのような価値があるのか​​よくわかりません。


12345678910