ロード バランシング ———> リバース プロキシを介して実現
nginxリバースプロキシの7層プロキシと4層プロキシ
7 層のプロキシ:
7 層プロキシで最も一般的に使用されるリバース プロキシ メソッドは、nginx 設定ファイルの http モジュールでのみ設定でき、メソッド名は「アップストリーム」モジュールとして定義する必要があります。サーバー モジュールには記述できないことに注意してください。または位置モジュール内で。
同時に、上流モジュールは http モジュール内の独立したモジュールです。
7 層プロキシ: プロキシは http リクエストとレスポンスです
7 層プロキシの動作原理:
クライアント --> http リクエスト --> 7 層プロキシ (プロキシ サーバー上) --> プロキシ サーバーは http を転送し、内部サーバーのセット (Web クラスター) にリクエストします --> クライアントはサーバーがはまだリクエスト内部サーバーの時代であり、内部サーバーの IP はプロキシ サーバーを通じて隠蔽されます。
実際には、プロキシ サーバーにアクセスし、リクエストがプロキシに送信され、プロキシがそれを Web サーバーに転送し、Web サーバーが応答します—————実際に Web サーバーが応答します
レイヤ 4 プロキシ
4 層プロキシは tcp/ip プロトコルに基づいており、プロトコル層のプロキシ転送方式は IP アドレスとポート番号に基づいて負荷分散された転送を実現できます。4 層プロキシは、プロトコル層の URL 情報を取得できません。 http リクエストですが、処理できるのは tcp/udp データ パケットのみです 転送、トラフィック転送、設定メソッドの名前: ストリーム; ストリームは http モジュールで設定できません、グローバル モジュールで設定され、独立したモジュールに属します
4 層プロキシと 7 層プロキシの違い (強調!!)
1. 7 層プロキシは http リクエストを使用しますが、4 層プロキシは tcp/udp パケットを使用してトラフィックを転送します。
7 層プロキシ: http リクエスト。リクエストを詳細に分析して処理できます。例: フロー制御、コンテンツ フィルタリング。
4 層プロキシ: フロー制御なし、コンテンツ フィルタリングなし。
4 層プロキシは通常、次のような場合に適しています。 大量の接続要求を処理する必要があるシナリオ
7 層プロキシは通常、リクエストの正確な処理と制御のシーンに適しています。
実際の業務では4層プロキシと7層プロキシを併用可能
2. 4 層エージェントの速度は、7 層エージェントの速度よりも高速です。
理由：
(1): 4 層プロキシはトラフィック転送用であり、リクエストの分析と制御ができないため、高速である必要があります
(2): 4 層エージェントはカーネルを使用し、カーネルはトラフィックを高速に転送します。
レイヤ 7 プロキシは比較的遅い
理由：
(1): 7 層プロキシがリクエストを処理および解析するため、時間がかかります。
(2): 7 層プロキシはユーザー モード、アクセス制御、トラフィック処理であるため、速度が遅い
7層プロキシにより、より高いサービスとより高いユーザーエクスペリエンスを提供可能
フォワードプロキシとリバースプロキシ
フォワードプロキシ:
モジュール proxy_pass はプロキシ サーバーのアクセス アドレスを設定します。このモジュールは location モジュールにのみ記述できます。
リバースプロキシ:
クライアントはプロキシ サーバーにアクセスし、プロキシ サーバーはリクエストまたはトラフィックをバックエンド サーバーに転送します。バックエンド Web サーバーは複数存在しますが、ユーザーは最終的にどのサーバーにアクセスするかわかりません。
リバース プロキシの役割: 負荷分散、高可用性、拡張性、および保守性の向上。
職場でリバースプロキシを実行するにはどうすればよいですか?
リバースプロキシ --> ロードバランシング
アップストリーム: http、リバース プロキシに基づくロード バランシング
特徴：
1. httpリクエストの負荷分散方法
2. キャッシュなし
3. 負荷分散アルゴリズム:
(1) デフォルトのアルゴリズム：ポーリング（rr）; リクエストはバックエンドサーバーに順番に割り当てられます ポーリングアルゴリズムは、複数の Web サーバーが同様の処理能力を持っている場合に使用されます。デフォルトのアルゴリズムは省略できます。
(2) 重み付けアルゴリズム: ポーリング アルゴリズムに基づいて、さまざまな Web サーバーに重み付けを行うことで、より強力な処理能力を持つサーバーにより多くのリクエストを割り当てることができます (注: 重み付けは設定されていますが、フォールの結果が常に正確であるとは限りません)。
(3) ip_hash: IP アドレスに基づいてハッシュ値を計算します. ip_hash アルゴリズムを使用した後、セッションの安定性を確保するために、同じクライアントのリクエストは同じバックエンド サーバーに割り当てられます。変更されると、ハッシュ値が再計算され、要求されたサーバーも変更される可能性があります
(4) 最小接続数: minimum_conn; ポーリング、機能: 現在の接続数が最も少ないバックエンド Web サーバーにリクエストを送信します。これは、バックエンド サーバーがタスクの処理に異なる時間がかかり、タスクの処理に時間がかかる状況に適しています。すべてのリクエストが集中しているため、より強力な処理能力を持つバックエンド サーバーでは、least_conn アルゴリズムが加重ラウンドロビン アルゴリズムと組み合わせて使用されます。
(5) url_hash: URI アドレスに基づいてハッシュ値を計算します url_hash アルゴリズムを使用すると、同じリクエストの URI が同じバックエンド サーバーに割り当てられます
負荷分散アルゴリズムの使用シナリオ:
小規模シナリオ: 同時実行の量が少なく、デフォルトのアルゴリズムが該当する条件を満たすことができます。
バックエンド Web サーバーの処理能力は、差分、重み付けラウンドロビン、最小接続数と組み合わせて使用できます。
大規模な同時実行: ip_hash、url_hash; 最初のリクエストの後、ローカル キャッシュが生成され、ハッシュ アルゴリズムにより、リクエストされたバックエンド Web サーバーは変更されないため、アクセス速度とローカル キャッシュが向上します。にアクセスされます。バックエンドサーバーのリクエスト容量を減らす
注意点：
ip_hash: バックエンドサーバーの数が変わると、要求されるサーバーが変わる可能性があります
uri_hash: リクエストされたアドレスが変更されると、リクエストされたサーバーも変更される可能性があります