リバースプロキシおよびロードバランサーとしてのTCPプロキシ

ガイド, 月-0620225分で読める

トランスポート制御プロトコル(TCP)プロキシは、OSI(Open System Interconnection)モデルのTCPレイヤで動作する。TCPプロキシサーバは、クライアントと宛先サーバ間の中間プロキシである。 クライアントはTCPプロキシサーバとの接続を確立し、TCPプロキシサーバは宛先サーバとの 接続を確立する。TCP

トランスポート制御プロトコル(TCP)プロキシは、OSI(Open System Interconnection)モデルのTCPレイヤで動作する。TCPプロキシサーバーは、クライアントと宛先サーバーの間の 中間プロキシである。 

クライアントはTCPプロキシサーバーとの接続を確立し、TCPプロキシサーバーは宛先サーバーとの接続を確立する。TCPプロキシサーバは、ネットワークアドレスに基づいて接続を制限するサービスにアクセスするために、サーバとクライアントの両方の役割を果たす。

一部のウェブページは内部マシンからのみアクセス可能で、他の場所からアクセスするとアクセスが拒否されたというエラーメッセージが表示されます。ただし、内部マシンのプロキシを使用することで、インターネット上のどこからでもウェブブラウザからこのページを閲覧することができます。

ウェブサーバーは、プロキシを実行しているマシン上のクライアントにデータを提供していると考える。しかし、プロキシはデータをネットワークから実際のクライアントに転送する。 

プロキシサーバーは、複数のクライアントからのコネクションを受け入れ、 複数のコネクションを使ってサーバーに転送する。クライアントまたはサーバーはそのコネクション上でデータを読み書きしなければならず、プロキシサーバーへの操作を拒否してプロキシサーバーをハングさせてはならない。

OSIモデル - プレビュー

OSIモデルは、コンピュータネットワークのプロセスを概念化したものである。OSIモデルには7つの層がある:

  • 物理層
  • データリンク層
  • ネットワーク層
  • トランスポート層
  • セッション層
  • プレゼンテーション層
  • アプリケーション層

トランスポート・レイヤーは、ネットワークを介してデータを転送する役割を担っている。TCPとUDP(User Datagram Protocol)という2つの異なるプロトコルを使用する。TCPは一般的にデータ転送に使用され、このプロトコルはデータの送信方法を指示する。TCPはメッセージをセグメントに分割し、送信元から送信先へ送信する。

ソケット接続

通常、データの塊を送信する送信者と受信者がいる。送信者と受信者は同時に異なるマシンと通信しているので、プロキシは通信している送信者と受信者の間にソケット接続を確立する。

ソケットは、IPとポート番号を使用した両者間の論理接続である。プロキシは送信側と受信側でソケット接続を確立する。IPアドレスとポート番号で構成されるソケットアドレスは、送信側と受信側の通信で一意である。

一意のソケットアドレスは、データ転送が並行して行われ、パケットが互いに衝突しないことを保証する。

TCPレイヤーでのプロキシの実装

TCPプロキシは、受信トラフィックを受け取り、送信ソケットを開いて、受信トラフィックを宛先サーバーに送る。TCPプロキシはクライアントとサーバーの間でデータを移動させるが、データを理解しないため、データを変更することはできない。

このレイヤーのプロキシは、レシーバーがバックエンドサーバーに接続しようと するIPアドレスとポート番号にアクセスできる。サーバーがリクエストをリッスンするためにポート番号3306を使う場合、 プロキシはこのレイヤーでそれを実装し、このポートでもリッスンする。 

プロキシはそのポートをリッスンし、メッセージをサーバーにリレーする。TCPプロキシは、1つのホストとポートの組み合わせを通して、ソケットを介したコネクションを作成する。

トランスポートレイヤーでプロキシを実装することは、そのレイヤーがデータ 転送のみに責任を持つため、軽量で高速である。

プロキシはメッセージをやり取りする媒体として機能し、メッセージを読むことはできない。これらのプロキシは、ネットワークを監視し、パブリックネットワークから内部ネットワークを隠し、サーバーの過負荷を防ぐために接続をキューに入れ、接続を制限するのに役立ちます。MYSQLやPostgresへのデータベーストラフィックなど、TCP上で通信するサービスの負荷分散に最適なソリューションです。

リバースプロキシとしてのTCPプロキシ

リバースプロキシは、クライアントからのリクエストを受け取り、それを 満たすことができるサーバに転送し、サーバの応答をクライアントに返します。サーバやアプリケーションが一つしかない場合でも、リバースプロキシ を配備することができます。

リバースプロキシは、ネットワーク上の他のユーザーから公開されています。サイトのネットワークの端に実装され、ウェブブラウザやモバイルアプリからのリクエストを受け付ける。 

TCPプロキシをリバースプロキシとして実装すると、次のような利点がある:

セキュリティ - ネットワークのセキュリティが向上する。悪意のあるクライアントはバックエンド・サーバーにアクセスできない。脆弱性を悪用するために直接アクセスすることはできない。

DDOS攻撃の防止 - バックエンドサーバーはリバースプロキシによって保護され、分散型サービス拒否(DDOS)から保護されます。

トラフィックの制御 - 特定のクライアントIPアドレスからのトラフィックを拒否したり(ブラックリスト)、クライアントからの接続数を制限することができます。

拡張性と柔軟性 - クライアントにはリバースプロキシのアドレスしか見えないため、バックエンドの設定を柔軟に変更できます。サーバーの負荷分散を図るため、トラフィック量の変化に合わせてサーバーの台数を増減できます。

ウェブ・アクセラレーション - リクエスト・クライアントのレスポンス生成にかかる時間を短縮します。 

圧縮 - TCPプロキシがクライアントに戻る前に応答することで、ネットワーク経由でデータを送信するために必要な帯域幅を削減します。

暗号化 - ネットワーク上のクライアントとサーバー間のトラフィックは暗号化が必要である。暗号化のプロセスは計算量が多く、クライアントとサーバーにオーバーヘッドをかける。リバースプロキシが暗号化と復号化を行うことで、バックエンドサーバはクライアントへのサービスのみに専念することができます。

キャッシュ - リバースプロキシは、クライアントにそれを提供する前に、 リクエストのコピーをそのローカルシステムに保存する。リバースプロキシは、リクエストをサーバーに転送(forward)し、 クライアントが再度リクエストしたときに同じものを取得する代わりに、 キャッシュからリクエストに応答する。 

ロードバランサーとしてのTCPプロキシ

ロードバランサーは、複数のサーバーがある場合にトラフィックを管理するプロキシである。ロードバランサはサーバーを効率的に動かし、トラフィックが多いときにサーバーを拡張することができる。ロードバランサーは、サーバー間でトラフィックを分散し、クライアントからの元の接続を中断することなく、健全なバックエンドサーバーに直接ルーティングします。

TCPプロキシはダイレクトサーバーリターンを使って、健全なバックエンドサーバーからの応答をロードバランサーではなく直接クライアントに送る。バックエンドサーバーはセキュアソケットレイヤー(SSL)トラフィックを終了させ、ロードバランサーは終了させない。 

セッションの親和性

クライアントとサーバー間のTCPトラフィックは、セッション・アフィニティに対応している。セッション・アフィニティとは、クライアントが健全で能力がある限り、同じバックエンドサーバーにリクエストを送信できることである。 

モニターサーバー

TCPプロキシは、バックエンドサーバの準備状態を定期的に監視することで、バックエンドサーバの 健全性チェックを行う。バックエンドサーバーがトラフィックを処理できない場合、それは不健康なノードであり、サーバーは他の健康なバックエンドサーバーにトラフィックをリダイレクトする。

TCPプロキシは、ロードバランサーとして動作するとき、以下の特性を示す:

非同期動作 - TCPプロキシは非同期動作をする。これは、あるクライアントが突然 ソケットからプロキシへの読み込みを停止しても、他のクライアントはプロキシ を介したサービスの中断に気づかないことを意味する。

他のプロトコルのサポート - TCPプロキシはHTTPのほか、FTPなど他のアプリケーション・レイヤー・プロトコルもサポートしている。

リバースプロキシとして動作する - ユーザーは、TCPプロキシを、実装場所に基づくリバースプロキシとして使用することができる。サーバー側では、クライアントからユーザーへのトラフィックを制御する。 

ウィンドウ・スケール・オプション

TCP受信ウィンドウとは、レシーバが接続中にバッファリングできるデータ量を バイト単位で表したものである。レシーバは通信を開始する前にウィンドウサイズを更新し、確認応答を待つ必要がある。 

送信側はウィンドウ・サイズに基づいてデータを送信する。Windows TCP/IPスタックの設計は、変化するデータサイズに適応し、より大きなウィンドウサイズを使用する。送信者は送信するたびに、前の送信で使われたものより大きなウィンドウ・サイズを使う。

最大セグメントサイズ(MSS)を調整することでウィンドウサイズを変更できるので、ウィンドウサイズは固定ではない。クライアントとサーバは、接続のセットアップ中に MSS をネゴシエートします。受信ウィンドウを MSS の増分に調整することで、一括データ送信時に使用されるフルサイズの TCP セグメントの割合が増えます。

受信ウィンドウサイズは以下の方法で決定される:

接続が確立すると、クライアントはMSSに基づいて受信ウィンドウ・サイズを調整する。ウィンドウ・スケーリング・オプションが使用されていない限り、ウィンドウ・サイズはMSSの4倍、最大64Kに調整される。

よくある質問

1.リバースプロキシはロードバランシングプロキシとどう違うのか?

リバースプロキシ負荷分散プロキシ
リバースプロキシは、クライアントとサーバーの間に実装される仲介アプリケーションである。ロードバランシングプロキシは、複数のバックエンドサーバにトラフィックを均等かつ効率的に分散する。
リバースプロキシは、クライアントが元のサーバーと直接通信しないようにすることで、ウェブサーバーのセキュリティを強化する。複数のバックエンドサーバーがあり、ネットワーク停止やDDoS攻撃の際には、ロードバランシングプロキシがトラフィックを代替サーバーに迂回させることができるため、サイトの停止を防ぐことができる。
プロセス- ユーザーがHTTPリクエストを行う。- リバースプロキシがそれを受け取る。- リバースプロキシはユーザのリクエストを許可または拒否する。- 許可された場合、リバースプロキシはリクエストをサーバに転送する。- 拒否された場合、リバースプロキシはクライアントにエラーメッセージを 送る。- サーバは対応する応答をリバースプロキシに送る。リバースプロキシは サーバの応答をクライアントに転送(forward)する。ロードバランサーはバックエンドサーバー群の中の一つのサーバーにリクエストを送る。選択されたサーバーはロードバランサーにレスポンスを送り返す。
オープンソースのリバースプロキシの例としては、NGINXApache HTTP ServerApache Traffic Serverがある。負荷分散アルゴリズムの例として、HashRoundRobinPower of Two Choicesがある。

2.HTTPプロキシとTCPプロキシの違い。

HTTPプロキシTCPプロキシ
非武装地帯(DMZ)では、バックエンドサーバーを保護するために、ロードバランサーやパブリックIPプロバイダーとして使用される。クライアントとサーバー間のTCPコネクションのリバースプロキシとして使用される。
HTTP リクエスト/レスポンスを作成します。TCP ソケット接続を開き、それを介してデータを移動する。
HTTPプロキシはホストアドレスを読み取り、適切なホストに接続する。TCPプロキシはデータを理解できないので、データを変更しない。
HTTPだけでなく、HTTPSやFTPリクエストにも対応できる。TCPの他に、HTTPとFTPリクエストにも対応できる。

最終的な感想

TCPプロキシはリバースプロキシとして、またロードバランサとしても動作する。どちらのタイプのアプリケーションもクライアントとサーバーの間に存在し、前者からのリクエストを受け付け、後者からのレスポンスを配送する。

リバースプロキシとロードバランサが同じように聞こえ、混乱を招くことがあります。いつ、そしてなぜウェブサイトにそれらを配置するのかを探ることは、あなたがそれを理解する助けになるでしょう。

データ収集は膨大な作業であり、既存のビジネスや新興企業にとって重要である。市場動向、競合他社の分析、顧客の嗜好など、意思決定を行うために必要なプロセスだ。 

ProxyScrapeは、ウェブサイトから大量のデータを収集するためのプレミアムプロキシ、レジデンシャルプロキシ、専用プロキシを提供しています。プロキシの組み合わせは自由自在で、価格設定もお手頃です。新しく導入されたプロキシ、その使用方法、ProxyScrape が提供する利点に関する詳細については、当ブログをチェックしてください。