多くの Jetty http(s) サーバーがあり、すべて異なるファイアウォールの背後にあります。http サーバーはお客様のサイトにあります (当社の管理下ではありません)。これらのサイトのファイアウォールでポートを開くことはできません。現在、これらのサーバーは、REST 要求に応答して JSON ドキュメントのみを提供しています。
URL パラメーターまたはヘッダー値に基づいて、特定の http サーバーと対話する必要がある Web クライアントがあります。
これは、ファイアウォールを除いて、単純なプロキシ サーバーの状況のように見えます。
私が現在試みているアプローチはこれです：
リモート http サーバーからのインバウンド登録要求をリッスンする集中プロキシ サーバー (これも Jetty ベース) を用意します。登録要求は Websocket 接続の形式で行われ、リモート HTTP サーバーが利用可能である限り維持されます。登録時に、プロキシ サーバーは websocket 接続をキャプチャし、それをリソース識別子にマップします。
Web クライアントはプロキシ サーバーに接続し、URL またはヘッダーにリソース識別子を含めます。
プロキシ サーバーは、使用する適切な Websocket を決定し、要求を HTTP サーバーに渡します。したがって、リクエストとレスポンスは Websocket を経由します。応答が受信されると、Web クライアントに返されます。
したがって、これは理論的にはすべてうまくいっています-私が理解しようとしているのは次のとおりです。
a）これを達成するためのより良い方法はありますか？
b) パイプの HTTP サーバー側でプロキシを行うように Jetty をセットアップする最良の方法は何ですか?
Jetty の HttpClient を使用できると思いますが、実際にやりたいことは、Websocket から HTTP バイトを取得して、Jetty コネクタに直接パイプすることです。すべてを解析するのは意味がないようです。ローカルホストで通常のソケット接続を開き、websocket からバイトを取得して、そのように実行できると思いますが、そのように OS を介してルーティングするのはばかげているようです (私は既にHTTP サーバーの Jetty 環境内で動作しています)。 .
これは、すでに解決されている可能性のある問題のように思えます...おそらく、TCP/IPソケットの代わりにWebSocketで動作するカスタムjetty接続を使用することでしょうか?
更新: 私はこれで遊んでいたので、別のトリッキーな問題は、要求/応答の動作をどのように処理するか (そして、理想的には websocket チャネルを介した多重化をサポートすること) のようです。私が見つけた潜在的なリソースの 1 つは、Websockets の WAMP サブプロトコルです: http://wamp.ws/