Nginx+クロスドメインソリューションの基本的な紹介

その他 2022-04-20 02:00:00 訪問数: null

著者：Whale Teng FE出典：HangSengLIGHTクラウドコミュニティ

Nginxの紹介

Nginxは、ロシアのプログラマーIgor Sysoevによって開発された高性能httpサーバー/リバースプロキシサーバーおよび電子メール（IMAP / POP3）プロキシサーバーです。主な機能は次のとおりです。

  • リバースプロキシ
  • 負荷分散
  • HTTPサーバー

現在、実行中のNginxサーバーのほとんどは、サービスクラスターのシステムアーキテクチャとしてその負荷分散機能を使用しています。

機能説明

上記では、Nginxの3つの主要な機能を紹介しました。それぞれの機能の役割について話しましょう。

1.リバースプロキシ

リバースプロキシを導入する前に、まずフォワードプロキシの概念を理解しましょう。

たとえば、周杰倫のツアーを見ようとしていますが、公式チャンネルのチケットが売り切れているので、友達Aに社内でチケットを購入してもらうと、思い通りにチケットを手に入れることができます。このプロセスでは、フレンドAはフォワードプロキシとして機能します。つまり、クライアント（あなた）がサーバー（チケット販売者）にリクエストを送信するためのプロキシとして機能しますが、サーバー（チケット販売者）は誰が開始したかを知りません。ソースリクエスト、プロキシサービス（フレンドA）がそれ自体からリクエストしたことだけを知っています。

この例から、リバースプロキシについて理解しましょう。たとえば、10086または10000からの電話を受けることがよくありますが、電話をかける人は毎回異なります。これは、10086がチャイナモバイルの交換機番号であり、内線がユーザーに電話をかけるためです。 。交換機エージェントを介して番号が表示される場合、この時点でクライアント（あなた）は誰が要求を開始したかを知ることはできませんが、プロキシサービス（交換機）がそれ自体からそれを要求したことだけを知っています。

公式の説明では、リバースプロキシ方式とは、プロキシサーバーを使用してインターネット上の接続要求を受け入れ、その要求を内部ネットワーク上のサーバーに転送し、サーバーから取得した結果を上の接続要求に返すことを指します。インターネットこのとき、プロキシサーバーは外界へのリバースプロキシサーバーとして機能します。

リバースプロキシを実装するための簡単なNginx構成コードを貼り付けましょう。

server {  
    listen       80;                                                   
    server_name  localhost;                                         
    client_max_body_size 1024M;
  
    location / {
        proxy_pass http://localhost:8080;
        proxy_set_header Host $host:$server_port;
    }
}

その中で、http：// localhost：8080はアンチプロキシのターゲットサーバーであり、80はNginxがクライアントアクセスに公開するポートです。

2.負荷分散**

負荷分散とは、その名前が示すように、サービス負荷を複数のサーバーユニットにバランスよく分散して、Webサイトやアプリケーションなどのサービスのパフォーマンスと信頼性を向上させることです。2つのシステムトポロジを比較してみましょう。1つ目は、負荷分散のないトポロジです。

1.png

以下は、負荷分散が設計されたトポロジです。

無題の図面2.png

図2からわかるように、ユーザーはロードバランサーにアクセスし、ロードバランサーはリクエストをバックエンドサーバーに転送します。この場合、サービスCが失敗した後、ユーザーアクセスの負荷はサービスAとサービスBに分散されます。システムのクラッシュは回避されます。図1でこのような障害が発生した場合、システムは確実に直接クラッシュします。

負荷分散アルゴリズム

負荷分散アルゴリズムは、バックエンド上のどの正常なサーバーが選択されるかを決定します。一般的に使用されるいくつかのアルゴリズム：

  • ラウンドロビン：最初のリクエストのリストで最初のサーバーを選択し、最後までリストを順番に下に移動してから、ループします。
  • 最小接続（最小接続）：最初に、接続数が最も少ないサーバーを選択します。これは、一般セッションが長い場合に推奨されます。
  • ソース：リクエストソースのIPのハッシュに基づいて転送するサーバーを選択します。このようにして、特定のユーザーが同じサーバーにある程度接続できるようにすることができます。

アプリケーションが状態を処理する必要があり、ユーザーが以前と同じサーバーに接続できるようにする必要がある場合。アソシエーションは、ソースアルゴリズムを介して、またはスティッキーセッションを使用して、クライアントのIP情報に基づいて作成できます。

負荷分散も、その役割を果たすためにリバースプロキシ機能と連携する必要があります。

3.HTTPサーバー

上記の2つの機能に加えて、Nginxは静的リソースサーバーとしても使用できます。たとえば、SSR（Server Side Render）を使用しない純粋なフロントエンドリソースは、Nginxに依存してリソースホスティングを実現できます。静的リソースサーバーを実装する構成を見てみましょう。

server {
    listen       80;                                                 
    server_name  localhost;                                       
    client_max_body_size 1024M;
  
    location / {
        root   e:\wwwroot;
        index  index.html;
    }
}

root構成は、特定のリソースが格納されているルートディレクトリであり、index構成は、ルートディレクトリにアクセスするときのデフォルトファイルです。

動的および静的分離

動的および静的分離は、NginxがHttpサーバーとして使用する重要な概念でもあります。動的および静的分離を理解するには、まず動的リソースとは何か、静的リソースとは何かを理解する必要があります。

  • 動的リソース：JSP、SSRレンダリングページなど、サーバーからリアルタイムで取得する必要のあるリソースコンテンツ。リソースコンテンツは、異なる時間にアクセスされると変化します。
  • 静的リソース：JS、CSS、Imgなど、異なる時間にアクセスしてもリソースのコンテンツは変更されません。

Nginxは静的リソースサーバーとして使用できますが、動的リソースをホストできないため、動的および静的分離が必要なシナリオがある場合、静的リソースと動的リソースのアクセスポリシーを分割する必要があります。

upstream test{  
    server localhost:8080;  
    server localhost:8081;  
}   

server {  
    listen       80;  
    server_name  localhost;  
  
    location / {  
        root   e:\wwwroot;  
        index  index.html;  
    }  
  
    # 所有静态请求都由nginx处理，存放目录为html  
    location ~ \.(gif|jpg|jpeg|png|bmp|swf|css|js)$ {  
        root    e:\wwwroot;  
    }  
  
    # 所有动态请求都转发给tomcat处理  
    location ~ \.(jsp|do)$ {  
        proxy_pass  http://test; 
    }  
  
    error_page   500 502 503 504  /50x.html;  
    location = /50x.html {  
        root   e:\wwwroot;  
    }  
}

この構成から、クライアントがさまざまなタイプのリソースにアクセスすると、Nginxは、完全なリソースサーバーのニーズを満たすために、クライアントをタイプに応じて独自の静的リソースサービスまたはリモート動的リソースサービスに自動的に割り当てることが大まかに理解できます。 。関数。

構成の紹介

1.基本的な紹介

Nginxの機能について説明した後、Nginxの構成ファイルを簡単に紹介しましょう。フロントエンドの人として、Nginxを使用することは、基本的に構成を変更することです-> Nginxを起動/ウォームリスタートし、Nginxに関連する日常の作業のほとんどを行うことができます。

ここでは、Nginxのデフォルト構成、つまり、Nginxがインストールされた後のデフォルトのnginx.confファイルの内容を確認します。


#user  nobody;
worker_processes  1;

#error_log  logs/error.log;
#error_log  logs/error.log  notice;
#error_log  logs/error.log  info;

#pid        logs/nginx.pid;


events {
    worker_connections  1024;
}


http {
    include       mime.types;
    default_type  application/octet-stream;
  
    #log_format  main  '$remote_addr - $remote_user [$time_local] "$request" '
    #                  '$status $body_bytes_sent "$http_referer" '
    #                  '"$http_user_agent" "$http_x_forwarded_for"';
  
    #access_log  logs/access.log  main;
  
    sendfile        on;
    #tcp_nopush     on;
  
    #keepalive_timeout  0;
    keepalive_timeout  65;
  
    #gzip  on;
  
    server {
        listen       80;
        server_name  localhost;
  
        #charset koi8-r;
  
        #access_log  logs/host.access.log  main;
  
        location / {
            root   html;
            index  index.html index.htm;
        }
  
        #error_page  404              /404.html;
  
        # redirect server error pages to the static page /50x.html
        #
        error_page   500 502 503 504  /50x.html;
        location = /50x.html {
            root   html;
        }
  
        # proxy the PHP scripts to Apache listening on 127.0.0.1:80
        #
        #location ~ \.php$ {
        #    proxy_pass   http://127.0.0.1;
        #}
  
        # pass the PHP scripts to FastCGI server listening on 127.0.0.1:9000
        #
        #location ~ \.php$ {
        #    root           html;
        #    fastcgi_pass   127.0.0.1:9000;
        #    fastcgi_index  index.php;
        #    fastcgi_param  SCRIPT_FILENAME  /scripts$fastcgi_script_name;
        #    include        fastcgi_params;
        #}
  
        # deny access to .htaccess files, if Apache's document root
        # concurs with nginx's one
        #
        #location ~ /\.ht {
        #    deny  all;
        #}
    }
  
  
    # another virtual host using mix of IP-, name-, and port-based configuration
    #
    #server {
    #    listen       8000;
    #    listen       somename:8080;
    #    server_name  somename  alias  another.alias;
  
    #    location / {
    #        root   html;
    #        index  index.html index.htm;
    #    }
    #}
  
  
    # HTTPS server
    #
    #server {
    #    listen       443 ssl;
    #    server_name  localhost;
  
    #    ssl_certificate      cert.pem;
    #    ssl_certificate_key  cert.key;
  
    #    ssl_session_cache    shared:SSL:1m;
    #    ssl_session_timeout  5m;
  
    #    ssl_ciphers  HIGH:!aNULL:!MD5;
    #    ssl_prefer_server_ciphers  on;
  
    #    location / {
    #        root   html;
    #        index  index.html index.htm;
    #    }
    #}
  
}

対応する構造は大まかに次のとおりです。

...              #全局块

events {         #events块
    ...
}

http      #http块
{
    ...   #http全局块
        server        #server块
        { 
        ...       #server全局块
            location [PATTERN]   #location块
            {
            ...
        }
        location [PATTERN] 
            {
            ...
        }
    }
    server
        {
        ...
    }
    ...     #http全局块
}

上記のコードブロックの対応する機能は次のとおりです。

  • グローバルブロック：Nginxにグローバルに影響するディレクティブを構成します。一般に、Nginxサーバーを実行しているユーザーグループ、Nginxプロセスのpidストレージパス、ログストレージパス、構成ファイルの紹介、および生成が許可されているワーカープロセスの数があります。
  • イベントブロック：構成は、Nginxサーバーまたはユーザーへのネットワーク接続に影響します。プロセスごとの接続の最大数があり、接続要求を処理するために選択されるイベント駆動型モデル、複数のネットワーク接続を同時に受け入れることができるかどうか、および複数のネットワーク接続のシリアル化が有効になっています。
  • httpブロック：複数のサーバーをネストし、プロキシ、キャッシュ、ログ定義、およびその他のほとんどの機能とサードパーティモジュールの構成を構成できます。ファイルの紹介、mimeタイプの定義、ログのカスタマイズ、sendfileを使用してファイルを転送するかどうか、接続のタイムアウト時間、単一接続要求の数など。
  • サーバーブロック：仮想ホストの関連パラメーターを構成します。1つのhttpに複数のサーバーが存在する場合があります。
  • ロケーションブロック：リクエストのルーティングとさまざまなページの処理を構成します。

各コードブロックの詳細な構成については、Nginxのドキュメントを参照してください

2.Nginxはクロスドメインの問題を解決します

以下に、フロントエンドのクロスドメインの問題を処理するためによく使用されるロケーションコードブロックを示します。読者の観点から、クロスドメインの問題を解決するためにNginxを理解して使用します。

location /cross-server/ {
    set $corsHost $http_origin;
    set $allowMethods "GET,POST,OPTIONS";
    set $allowHeaders "broker_key,X-Original-URI,X-Request-Method,Authorization,access_token,login_account,auth_password,user_type,tenant_id,auth_code,Origin, No-Cache, X-Requested-With, If-Modified-Since, Pragma, Last-Modified, Cache-Control, Expires, Content-Type, X-E4M-With, usertoken";
  
    if ($request_method = 'OPTIONS'){
        add_header 'Access-Control-Allow-Origin' $corsHost always;
        add_header 'Access-Control-Allow-Credentials' true always;
        add_header 'Access-Control-Allow-Methods' $allowMethods always;
        add_header 'Access-Control-Allow-Headers' $allowHeaders;
        add_header 'Access-Control-Max-Age' 90000000;
        return 200;
    }
  
    proxy_hide_header Access-Control-Allow-Headers;
    proxy_hide_header Access-Control-Allow-Origin;
    proxy_hide_header Access-Control-Allow-Credentials;
    add_header Access-Control-Allow-Origin $corsHost always;
    add_header Access-Control-Allow-Methods $allowMethods always;
    add_header Access-Control-Allow-Headers $allowHeaders;
    add_header Access-Control-Allow-Credentials true always;
    add_header Access-Control-Expose-Headers *;
    add_header Access-Control-Max-Age 90000000;
  
    proxy_pass http://10.117.20.54:8000/;
    proxy_set_header        Host   $host:443;
    proxy_set_header        X-Forwarded-For         $remote_addr;
    proxy_redirect http:// $scheme://; 
  
}

set前のセクションで設定のローカル変数が使用され、次にこれらの変数が以下のさまざまな命令の構成で使用されていることlocationがわかります。各命令の機能は次のとおりです。

  • add_header：リクエストにリターンヘッダーフィールドを追加するために使用されます。ステータスコードが次の場合にのみ有効です：200、201（1.3.10）、204、206、301、302、303、304、307（1.1 .16、1.0.13）、または308（1.13.0）
  • ** proxy_hide_heade：**は、応答ヘッダーの情報を非表示にすることができます。
  • ** proxy_redirect：**プロキシサーバーから返される応答ヘッダーのロケーションヘッダーフィールドと更新ヘッダーフィールドの値を変更するように指定します。
  • ** proxy_set_header：**バックエンドサーバーに送信されるリクエストヘッダーを再定義します。
  • ** proxy_pass：**プロキシの転送サービスパス。

上記の構成は、nginx.confに直接コピーしてから、クロスドメインサービスの問題を回避するために（/cross-server/Nginxによってクライアントに公開されるパス）および（転送されるサービスパス）を変更できます。http://10.117.20.54:8000/

クロスドメインスキルサプリメント

開発環境では、Nginxを使用してクロスドメインデバッグを処理したくない場合は、Chrome構成を変更して、クロスドメインデバッグを実現することもできます。本質的に、クロスドメインはブラウザのセキュリティポリシーであるため、開始します。この問題を解決するためにブラウザから問題はより便利です。

Windowsシステム：

1. Chromeブラウザのショートカットをコピーし、ショートカットアイコンを右クリックして、図に示すように[プロパティ]を開きます。

無題の図面3.png

2.「ターゲット」--disable-web-security --user-data-dirの後に追加します。たとえば、画像の変更が完了した後、次のように追加します"C:\Program Files (x86)\Google\Chrome\Application\chrome.exe" --disable-web-security --user-data-dir。

3. [OK]をクリックしてブラウザを再度開くと、次のように表示されます。

無題の図面4.png

この時点で、クロスドメインシールド設定が変更され、このショートカットをクリックしてアクセスするページはクロスドメインルールを無視し、開発環境でサーバー側でクロスドメインを構成する手間を省きます。

Macシステム：

次のコンテンツは以下から複製されています。MacでのChromeブラウザのクロスドメインの問題を解決する

最初にフォルダを作成します。このフォルダは、セキュリティポリシーを閉じた後、ユーザー情報を保存するために使用されます。名前は任意に選択でき、場所も任意に配置できます。

5.png

フォルダを作成する

次に、コンソールを開き、次のコードを入力しますopen -n /Applications/Google\ Chrome.app/ --args --disable-web-security --user-data-dir=/Users/LeoLee/Documents/MyChromeDevUserData

6.png

セキュリティポリシーコードを閉じる

作成したフォルダのアドレス（下の図の赤い枠の領域）に応じて上記のコードを変更する必要があります。ほとんどのオンラインチュートリアルにはコードのこの部分がないため、多くのユーザーがセキュリティ戦略が失敗しました

7.png

ユーザーは自分のフォルダーアドレスに従ってコードを変更する必要があります

コードを入力してEnterキーを押すと、Chromeでウィンドウがポップアップ表示されます

8.png

Chromeポップアップ

クリックしてGoogleChromeを起動すると、以前のChromeと比較して、現時点でChromeに上記のプロンプトが表示され、使用しているモードが安全ではないことがわかります。

9.png

ブラウザの上部に余分な行があります

原則は、構成を変更することによってセキュリティポリシーをバイパスするWindowsバージョンに似ています。

{{o.name}}
{{m.name}}

おすすめ

転載: my.oschina.net/u/3620858/blog/5470980
おすすめ
大規模な言語モデルに基づくオープンソースのナレッジベースの質問と回答システムである MaxKB GitHub Star の数が 5,000 を超えました。
ランキング
短线选股的一种方法
Javaクライアントでのユーバーのリズムワークフローで睡眠時間をキャンセルし、再スケジュール
CALIPSOデータバッチダウンロード方式
LeetCode アルゴリズム再帰クラス - ソードはオファー 26 を参照します。 ツリーの部分構造
HTMLのインポート外部CSS、JavaScriptの論文
PostgreSQL 13.1、12.5、11.10、10.15、9.6.20、および9.5.24がリリースされました
アップルは、エラーメッセージがポテトに接続されていた実行する方法ポテトポテトショーをダウンロードすることができません
あなたは空腹で突然電話を切っていますか？これはテクノロジーの裏側ですか、それともテスト用の銃ですか？
VIMエディタのヒント
動的計画法の最長共通部分列（LCS）
アーカイブ
もっと
2024-05-13(8)
2024-05-12(27)
2024-05-11(31)
2024-05-10(33)
2024-05-09(30)
2024-05-08(18)
2024-05-07(34)
2024-05-06(6)
2024-05-05(0)
2024-05-04(18)

コードワールド

© 2018 codetd.com