Nettyフレームワークを使用してJavaで全二重接続をシミュレートするために、Webブラウザーで採用されているものと同様の手法を使用してHTTPトンネルを実装しようとしています。実世界のHTTPプロキシが存在する場合に機能するようにこれを実装したいと思います。ライブラリの依存関係に関する不要なオーバーヘッドを回避し、サーブレットAPIが全二重httpトンネルの使用パターンに適合しないため、サーブレットコンテナを使用せずにこれを実行しようとしています。
HTTPプロキシがHTTPプロトコルの潜在的な使用法を「破る」ことを課すいくつかの制限を知っています。
- HTTPパイプラインは、クライアントとプロキシ間の接続を超えて尊重されない場合があります。つまり、クライアントが複数のパイプライン要求をプロキシにディスパッチした場合でも、プロキシは単一の要求を送信し、応答を待ってから次の要求を送信する場合があります。
- チャンクされたエンコーディングは、同様の方法でプロキシ間の接続を超えて尊重されない場合があります。サーバーは応答をチャンクで送り返しますが、プロキシは終了チャンクを待ってから、完全なデチャンクされた応答をクライアントにディスパッチします。
- 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プロキシとステートフルインスペクティングファイアウォールの癖を説明する優れたリソースを知っている人はいますか？