質問

Netty フレームワークを使用して Java で全二重接続をシミュレートするために Web ブラウザで採用されているのと同様の手法を使用して HTTP トンネルを実装しようとしています。これを、実際の HTTP プロキシが存在する環境でも機能するような方法で実装したいと考えています。ライブラリの依存関係に関する不必要なオーバーヘッドを避けるため、またサーブレット API が全二重 http トンネルの使用パターンに適合しないため、サーブレット コンテナを使用せずにこれを実行しようとしています。

HTTP プロキシが課すいくつかの制限によって、HTTP プロトコルの潜在的な使用が「中断」されることは承知しています。

  1. HTTP パイプラインは、クライアントとプロキシ間の接続を超えて受け入れられない場合があります。つまりプロキシは、クライアントが複数のパイプライン要求をプロキシにディスパッチした場合でも、単一の要求を送信し、応答を待ってから次の要求を送信することがあります。
  2. チャンク化されたエンコーディングは、同様の方法でプロキシ間の接続を超えて受け入れられない場合があります。サーバーは応答をチャンクに分けて送り返す可能性がありますが、プロキシはチャンクから切り離された完全な応答をクライアントにディスパッチする前に、最後のチャンクを待つ場合があります。
  3. 多くの場合、HTTP CONNECT は SSL/TLS ポート (通常はポート 443) でのみ許可されるため、これを外部への自由な TCP 接続を取得する卑劣な方法として使用することはできません。

ただし、私にはよくわからないもう 1 つの可能性があります。現実世界の HTTP プロキシも、複数のクライアント間でサーバーへの永続的な接続を共有しますか?例えば:

  • クライアント A はリクエスト A1、A2、および A3 をサーバー X に送信します。
  • クライアント B はリクエスト B1 と B2 をサーバー X に送信します
  • クライアント C はリクエスト C1、C2、および C3 をサーバー X に送信します。

この場合、プロキシはサーバー X への単一の接続を開き、次の順序でメッセージを送信する可能性があります。

A1、A2、B1、C1、B2、A3、C2、C3

それとも、個々のクライアントからの順序を保持するが、インターリーブされる可能性がある同様の順序でしょうか?あるいはさらに悪いことに、プロキシがサーバーへの複数の接続を開き、接続間で各クライアントからのメッセージを分散させる可能性があります。

Connection 1: A1, C1, C2, C3
Connection 2: B1, B2, A2, A3

その場合、これらのメッセージをトンネルごとに異なるキューに逆多重化する必要があり、特定のクライアントに使用されている接続の識別に単純に頼ることができないため、私のアプローチにはさらに検討が必要です。

一般的に使用される HTTP プロキシとステートフル検査ファイアウォールの特徴について説明している優れたリソースを誰か知っていますか?

役に立ちましたか?

解決

HTTP 1.1仕様には、この段落が含まれています< em>の8.1.4実践的検討の

  

持続的接続を使用するクライアントは、彼らが特定のサーバーに維持する同時接続数を制限する必要があります。シングルユーザクライアントは、任意のサーバーまたはプロキシとの2つの以上の接続を維持すべきではありません。プロキシは、Nが同時にアクティブユーザの数であり、別のサーバまたはプロキシ、2つの* N接続まで使用すべきです。これらのガイドラインはHTTPレスポンスタイムを改善し、輻輳を回避することを意図している。

私も、現実世界のプロキシの実装はこの要件に何をすべきかわかりません。

たぶん、あなたはそれが唯一の便利なリンクだ場合でも、キャッシュチュートリアルの中で何かを見つけることができます。究極のアクションは、マーク・ノッティンガム(mnot@pobox.com)にメールを送信することかもしれません。彼は知っていない場合は、誰もしません。

他のヒント

私は、NetScalerのは、クライアント上での設定にかかわらず、キープアライブの、それとサーバとの間でキープアライブを使用するように構成することができることを知っています。

ライセンス: CC-BY-SA帰属
所属していません StackOverflow
scroll top