問題タブ [reverse-proxy]

私は現在、ユーザーと他の方法では見えないWebサイトとの間で基本的に応答と要求を中継するリバースプロキシの概念に取り組んでいます。したがって、基本的にユーザーはサイト、たとえばwww.myproxyportal.comにアクセスします。このサイトでは、公開されていないWebサーバーのイントラネット（internal.myproxyportal.comなど）のWebサイト（iframe内）にアクセスできます。

私は、リクエストオブジェクトを目的の場所に変換し、その応答をWebサイトに返すソリューションに取り組んできました。CSSリンク、IMGなどを除いて、うまく機能します。もちろん翻訳はできますが、リンクはinternal.myproxyportal.com/css/style.cssに移動し、外部からは機能しません。

そのようなことにどのようにアプローチするのですか？

すぐに使えるソリューションはありますか？

編集：これは私がこれまでに書いたものと非常に似ていますが、外部画像、css、javascriptなどのサポートもありません。

私はScalingRailsのスクリーンキャストに追いついてきました。高度なHTTPキャッシング（VarnishやSquidなどのリバースプロキシキャッシュを使用）をカバーするエピソード11では、Railsアプリケーション内のページ、アクション、フラグメントキャッシングの可能性をすでに使い果たした後でのみ、リバースプロキシキャッシュの使用を検討することをお勧めします。 （memcachedなども同様ですが、この質問には関係ありません）。

私が完全に理解できないのは、HTTPリバースプロキシキャッシュを使用すると、すでにページキャッシュを使用しているアプリケーションのパフォーマンスがどのように向上するかということです。問題を単純化するために、ここで単一のホストについて話していると仮定しましょう。

これは、両方の手法がどのように機能するかについての私の理解です（おそらく私は間違っています）：

• ページキャッシングでは、Railsプロセスが最初にヒットし、その後、そのリクエストのキャッシュが有効である限り、後続のリクエストのためにWebサーバーによって直接提供される静的HTMLファイルを生成します。キャッシュの有効期限が切れている場合は、Railsが再度ヒットされ、静的ファイルが再生成され、更新されたコンテンツが次のリクエストに対応できるようになります。

• HTTPリバースプロキシキャッシュを使用すると、プロキシがコンテンツが古くなっているかどうかを判断する必要がある場合に、Railsプロセスがヒットします。ETagこれは、などのさまざまなHTTPヘッダーを使用して行われますLast-Modified。コンテンツが新しい場合、RailsはHTTP 304 Not Modifiedでプロキシに応答し、プロキシはキャッシュされたコンテンツをブラウザに提供します。さらに良いのは、独自のHTTP304で応答することです。 。コンテンツが古くなっている場合、Railsは更新されたコンテンツをプロキシに提供します。プロキシはコンテンツをキャッシュしてからブラウザに提供します。

私の理解が正しければ、ページのキャッシュによってRailsプロセスへのヒットが少なくなるのではないでしょうか。コンテンツが古くなっているかどうかを判断するために行ったり来たりすることはすべてありません。つまり、リバースプロキシキャッシングよりもパフォーマンスが優れています。なぜ両方の手法を組み合わせて使用​​するのでしょうか。

Windows 2003 のポート 8085 で実行されている Java アプリケーション (Atlassian Bamboo) があります。http://bamboo:8085 としてアクセスできます。

IIRF を使用して IIS6 のリバース プロキシをセットアップしようとしているので、
http://bamboo 経由でコンテンツにアクセスできます。IPを正しく設定したようで、ステータスページを取得できます。これは私のIIRF.iniがどのように見えるかです:

しかし、IE で http://bamboo と入力すると、「ページを表示できません」というメッセージが表示されます。FF は何も返しません。Wireshark ネットワーク ダンプを作成し、「follow TCPstream」を選択したところ、正しいページが取得されているように見えます。

また、http://bamboo/favicon.ico を取得できることにも気付きました。そのため、ソリューションに非常に近い必要があります。これは Wireshark の出力です。

私たちの会社には、静的コンテンツを提供し、コメット接続をサポートするためのリバース プロキシとして現在 nginx を使用するプロジェクトがあります。長いポーリング接続を使用して、絶え間ない更新要求を取り除き、ユーザーが更新をすぐに取得できるようにします。

さて、Node.js 用にすでに多くのコードが書かれていることは知っていますが、Node.js が nginx のように静的コンテンツを提供するためのリバース プロキシとして機能するソリューションはありますか? それとも、Node.js を使用してそのようなレイヤーを迅速に開発できるフレームワークがあるのでしょうか?

サーバーが複数のデータセンターに分散しており、それぞれに異なるファイルが保存されています。ユーザーが単一のドメインを介してすべてのサーバー上のファイルにアクセスできるようにし、個々のサーバーがファイルをユーザーに直接返すようにしたいと考えています。

以下に簡単な例を示します。
1) ユーザーのブラウザーがhttp://www.example.com/files/file1.zip
を要求します。 2) 要求は、example.com の DNS A レコードに基づいてサーバー A に送信されます。
3) サーバー A はリクエストを分析し、/files/file1.zip がサーバー B に保存されていることを突き止めます。
4) サーバー A はリクエストをサーバー B に転送します
。 A.

注: ステップ 4 と 5 はユーザーに対して透過的である必要があり、単一ドメインの要件に違反するため、ユーザーにリダイレクトを送信することはできません。

私の調査によると、達成したいのは「Direct Server Return」と呼ばれ、負荷分散のための一般的なセットアップです。ハーフ リバース プロキシと呼ばれることもあります。

ステップ 4 では、MAC アドレス変換を実行してから、要求をネットワークに戻す必要があるように思われます。サーバーのネットワーク外にあるサーバーには、トンネリングが必要になります。

手順 5 では、ロード バランシング セットアップの実サーバーに従って、サーバー B を構成する必要があります。つまり、サーバー B はループバック インターフェイスでサーバー A の IP アドレスを持つ必要があり、その IP アドレスに対する ARP 要求に応答しないようにする必要があります。

私の問題は、実際にステップ4を達成する方法ですか?

レイヤー 4 で単純な負荷分散を行うためにこれを実行できるハードウェアとソフトウェアをたくさん見つけましたが、これらのソリューションは不足しており、私が必要とする種類のカスタム ルーティングを処理できません。独自のソリューションを展開する必要があるようです。

理想的には、Web サーバー レベル、つまり PHP または C#/ASP.net でルーティング/転送を行いたいと考えています。ただし、Apache や IIS などの下位レベル、またはさらに下位レベル、つまりすべての前にカスタム プロキシ サービスを配置することにはオープンです。

HTTP リクエストを受信し、それらのリクエストを Web サーバーに転送するプログラムを作成する必要があります。

図 http://img269.imageshack.us/img269/1862/h98trsly.jpg

私は Java ソケットのみを使用してこれを作成しましたが、クライアントはプログラムを Jpcap に実装する必要がありました。これが可能かどうか、またこのプロジェクトのためにどの文献を読むべきかを知りたいです。

これは、Jpcap チュートリアルの断片をつなぎ合わせて作成したものです。

どんな助けでも大歓迎です。ありがとうございました。

リバースプロキシからWebサーバーを動的にロードおよびアンロードする方法はありますか？

たとえば、100台のApacheサーバーのクラスターがあり、サーバーにパッチを適用したいとします。更新されたサーバーのプールと「更新中の」サーバーのプールがあるセットアップが必要です。リバースプロキシは、パッチが適用されているものを認識し、これらのWebサーバーから読み取られないようにしたいと思います。

リバースプロキシを構成するために構成ファイルだけを使用したくありません。

私たちは、html5WebSocketを利用する必要があるRubyonRailsアプリに取り組んでいます。現在、いわば2つの別個の「サーバー」があります。nginx+passengerで実行されるメインアプリと、Pratik NaikのCrampフレームワーク（ Thinで実行されている）を使用してWebSocket接続を処理する別個のサーバーです。

理想的には、デプロイの時期になると、Railsアプリがnginx +passengerで実行され、WebSocketサーバーがnginxの背後にプロキシされるため、WebSocketサーバーを別のポートで実行する必要はありません。

問題は、このセットアップでは、nginxがThinへの接続を早すぎて閉じているように見えることです。シンサーバーへの接続は正常に確立され、200応答コードですぐに閉じられます。私たちの推測では、nginxは、クライアントがWebSocketトラフィックの長時間実行接続を確立しようとしていることを認識していません。

確かに、私はnginx configに精通しているわけではないので、WebSocketサーバーのリバースプロキシとして機能するようにnginxを構成することも可能ですか？または、nginxが新しいWebSocketハンドシェイクのサポートを提供するのを待つ必要がありますか？アプリサーバーとWebSocketサーバーの両方がポート80でリッスンしていることが要件であるとすると、今のところnginxを使用せずにThinを別のサーバーで実行する必要があるのでしょうか。

アドバイスや提案を事前に感謝します。:)

-ジョン