Webフロントエンドに必要な知識の概要

10138 ワード

専門技術サイトwww.sufaithに同期した.comは、Web開発、Nodejs、Python、Linux、IT情報など、前後の開発技術と経験の共有に専念している.
一、Nginx紹介
Nginxは高性能で軽量級のWebと逆プロキシサーバで、メモリとリソースを占有することが少なく、同時性に強いことを特徴としています.
Nginxはインストールが簡単で、配置が簡潔で、起動が迅速で便利で、ホット配置をサポートし、SSLをサポートし、高度なモジュール化の設計を持っている.
Nginxの主な機能は次のとおりです.
  • Webサーバ
  • リバースエージェント
  • 負荷等化
  • 二、運転と制御Nginx
    備考:以下のコマンドの/usr/local/nginxはnginxバイナリファイルの絶対パスであり、自分の実際のインストールパスによって異なります.
    1.起動
    /usr/local/nginx/sbin/nginx
    

    2.ログファイルを再度開く
    /usr/local/nginx/sbin/nginx -s reopen
    

    3.プロファイルの再読み込み
    /usr/local/nginx/sbin/nginx -s reload
    

    4.停止
    /usr/local/nginx/sbin/nginx -s stop
    

    5.余裕で止める
    (1)プロセス番号の表示
    ps -ef|grep nginx
    

    (2)プロセスを殺す
    kill -QUIT <   >   kill -TERM <   >
    

    6.強制停止
    pkill -9 nginx
    

    三、NginxはWebサーバーとして
    NginxはWebサーバとしてserver仮想ホストを定義し,これらの仮想ホストに特定のドメイン名やIPアドレスの要求を処理させる必要がある.各server仮想ホストはlocation命令を定義し、locationは指定したURIのセットに対してどのようにマッチングして処理するかを定義します.
    1.webサーバの基本例
    server {
      listen 80;
      server_name www.example.com;
      location / {
      root /usr/local/www;
      	index index.html;
      }    
    }
    

    パラメータの説明:
  • serverは1つの仮想ホストを表し、複数の
  • を持つことができる.
  • server_nameマッチング要求の指定ドメイン名またはIPアドレス
  • location構成要求のルーティングは、対応するURI
  • と一致する.
  • rootリソースのパス(フォルダディレクトリ)
  • を検索
  • indexデフォルト検索
  • 2.location照合規則(要求フィルタ)
    (1)構文
    server {
       location     {
       }
    }
    

    (2)location式のタイプ
  • @内部指向性(例えばerror_page, try_files
  • /汎用照合で、要求は
  • に一致します.
  • =先頭、正確な一致を表し、要求urlパスが=後の文字列と完全に等しい場合にのみ(優先度が最も高い)
  • に一致する.
  • ^~は、通常の文字マッチングを表します.接頭辞照合を使用します.マッチングに成功した場合、他のlocation
  • はマッチングされません.
  • ~先頭は大文字と小文字を区別する正則マッチング
  • を示す.
  • ~*先頭は大文字と小文字を区別しない正則マッチング
  • を示す.
    (3)location式の優先度
  • =の優先度が最も高い.一致が成功すると、他の一致は検索されません.
  • ^~タイプ式.一致が成功すると、他の一致は検索されません.
  • ~と~*の優先度はそれに次ぐ.複数のlocationの正規が一致する場合は、正規表現が最も長いものを使用します.
  • 通常の文字列マッチングタイプ.接頭辞で一致します.

  • 3.URL書き換え
    URL書き換えとは、要求されたURLが事前に定義されたルールを満たす場合、一般的な擬似静的、301リダイレクト、ブラウザリダイレクトなど、あるルールにジャンプ/指向することを意味する.
    (1)構文
    server {
       rewrite             ;
    }
    

    rewriteパラメータの説明:
  • ルール:一致するターゲットurl
  • を表す文字列または正則
  • 指向パス:ルールに一致する指向するパスであり、ルールに正則がある場合、$indexを使用して正則内のキャプチャパケット
  • を表すことができる.
  • 書き換えタイプ:
  • last:rewriteが完了したことを示し、ブラウザアドレスバーURLアドレスは
  • 変わらない.
  • break;この規則の照合が完了すると、照合を終了し、後の規則に一致しなくなり、ブラウザのアドレスバーURLアドレスは
  • 変わらない.
  • redirect:戻る302一時リダイレクト、ブラウザアドレスはジャンプ後のURLアドレス
  • を表示する.
  • permanent:301の永続的なリダイレクトを返します.ブラウザのアドレスバーには、ジャンプ後のURLアドレス
  • が表示されます.

    (2)例
    ドメイン名ジャンプ:www.aaa.にアクセスcomはwww.bbbにジャンプします.com
    server {
      listen 80;
      server_name  www.aaa.com;
      location / {
       rewrite ^/$ www.bbb.com permanent ;
      }
    }
    

    4.try_files
    try_filesとは、ファイルが存在するかどうかを順番にチェックし、最初に見つかったファイルを返すことです.すべてのファイルが見つからない場合は、最後のパラメータに内部リダイレクトします.
    (1)構文
    try_files file1 files2 ... uri
    

    パラメータの説明:
  • の最後のパラメータは、URIをロールバックし、内部500エラーが発生する必要があります.
  • は、最後のパラメータのみが内部リダイレクトを引き起こすことができ、前のパラメータは内部URIの指向のみを設定する.
  • の最後のパラメータは、名前付きlocationであってもよい.
  • 最後のパラメータ名前付きlocationでなければa r g sは自動的に保持されません.argsを保持したい場合は自動的に保持されません.argsを保持したい場合は自動的に保持されません.argsを保持したい場合は、最後のパラメータで明確に宣言する必要があります.例:
  • try_files $uri $uri/ /index.php?q=$uri&$args;
    

    (2)例
  • ファイル
  • にジャンプ
    訪問時:www.example.com/testの場合は順次検索します.html,2.htmlは存在せず、最終的には3に戻る.html
    server {
      listen 80;
      server_name www.example.com;
      root html;
      index index.html;
      location /test {
    		try_files /1.html /2.html /3.html;
    	}
    }
    
  • 変数
  • にジャンプ
    訪問時:www.example.com/testの場合は順次検索します.html,2.htmlが存在しない場合はabcという名前のlocationにジャンプします
    server {
      listen 80;
      server_name www.example.com;
      root html;
      index index.html;             
      location /test {
      	try_files /1.html /2.html @abc;
      }
      location @abc{
      	rewrite ^/(.*)$  http://www.example2.com;
      }
    }
    
  • vue-router HTML 5 Historyモードを設定する場合、nginxの構成は以下の通りです:
  • location / {
    	# URL           ,      index.html   ,        app      。
    	try_files $uri $uri/ /index.html;
    }
    

    5.Gzip構成
    server {
      #   gzip   
      gzip on;
      #   gzip   http       (HTTP/1.1, HTTP/1.0)
      gzip_http_version 1.1;
      #       (1-9),         ,    cpu     ,     4  
      gzip_comp_level 4;
      #           ,   Content-Length  
      gzip_min_length 1000;
      #            (text/html),        ( jpg、png     )
      gzip_types text/plain application/javascript text/css;
     #    gzip  ,    。    ie6      gzip(  ie      )
     gzip_disable "MSIE [1-6]\.";
    }
    

    6.https構成
    http {
      #           ,         
      ssl_session_cache   shared:SSL:10m;
      #         
      ssl_session_timeout 10m;
      server {
        listen 443;
        server_name www.example.com;
        ssl on;
        #      
        keepalive_timeout 70;
        # HSTS  
        add_header Strict-Transport-Security "max-age=31536000; includeSubDomains; preload" always;
        #     
        ssl_certificate www.example.com.crt;
        #     
        ssl_certificate_key www.example.com.key;  
        #          
        ssl_prefer_server_ciphers on;
        #   SSL  
        ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
        #     
        ssl_ciphers "EECDH+ECDSA+AESGCM EECDH+aRSA+AESGCM EECDH+ECDSA+SHA384 EECDH+ECDSA+SHA256 EECDH+aRSA+SHA384 EECDH+aRSA+SHA256 EECDH+aRSA+RC4 EECDH EDH+aRSA !aNULL !eNULL !LOW !3DES !MD5 !EXP !PSK !SRP !DSS !RC4";
        #       
        add_header X-Frame-Options DENY;
        #              
        add_header X-Content-Type-Options nosniff;
        #  XSS  
        add_header X-Xss-Protection 1;
      }
    }
    

    四、Nginxを逆プロキシサーバーとする
    server {
      listen 80;
      server_name www.example.com;
      root html;
      index index.html;  
      location /test {    
        #   host
        proxy_set_header Host $http_host;
        #   ip
        proxy_set_header X-Real-IP $remote_addr;
        #     
        proxy_set_header X-Scheme $scheme;
        #      
        proxy_pass http://localhost:3000;
      }
    }
    

    アクセスhttp://www.example.com/testするとnginxはリクエストをhttp://localhost:3000で行ないます.
    五、負荷等化としてNginx
    1.負荷バランスの紹介
    サーバクラスタでは、Nginxは、単一のサーバの圧力が大きすぎることを避けるために、ユーザからの要求を異なるサーバに転送するエージェントサーバの役割を果たします(すなわち、逆エージェント).
    ロード・バランシングは、upstreamモジュールで定義されたバックエンド・サーバのリストから1台のサーバを選択してユーザーの要求を受け入れるために使用されます.
    2.負荷等化の基本例
    (1)upstreamモジュール
    最も基本的なupstreamモジュールは次のとおりです.
    #      , server      ,my_server           。
    upstream my_server {
      server localhost:8001;
      server localhost:8002;
      server localhost:8003;
    }
    

    (2)リバースエージェント
    upstreamモジュールの構成が完了したら、指定したアクセスをサーバグループに逆プロキシします.
    server {
      listen 80;
      server_name www.example.com;
      root html;
      index index.html;
      location / {    
       #              my_server
       proxy_pass my_server;
      }
    }
    

    (3)完全構成
    http {
    	upstream my_server {
        server localhost:8001;
        server localhost:8002;
        server localhost:8003;
      }
    	server {
        listen      80;
        server_name www.example.com;
        root html;
        index index.html;
    		location / {
    			#              my_server
    			proxy_pass my_server;
    		}
    	}
    }
    

    3.ロード・バランシング・ポリシー
    (1)ポーリング(デフォルト)
    各リクエストが時間順に異なるバックエンドサーバに割り当てられていることを示します.
    upstream my_server {
       server localhost:8001;
       server localhost:8002;
    }
    

    (2)weight(重み方式)
    ポーリングポリシーに基づいてポーリングするサーバの重みを指定することを示します.デフォルトは1で、処理する要求に重みが高いほど割り当てられます.
    upstream my_server {
      server localhost:8001 weight=1;
      server localhost:8002 weight=2;
    }
    

    (3) ip_hash
    指定された負荷イコライザがクライアントIPベースの割り当て方式に従っていることを示し、この方法は同じクライアントの要求がセッションセッションセッションを保証するために同じサーバに送信されることを保証する.これにより、各訪問者がバックエンドサーバに固定的にアクセスし、sessionがサーバにまたがることができないという問題を解決できます.
    upstream my_server {
      ip_hash;
      server localhost:8001;
      server localhost:8002;
    }
    

    コメント:
  • nginxバージョン1.3.1までip_hashではウェイト(weight)が使用されます.
  • ip_hashはbackupと同時に使用できません.
  • このポリシーは、セッションなどのステータス・サービスに適しています.
  • サーバが削除する必要がある場合は、手動でdownを削除する必要があります.

  • (4) least_conn
    接続数の少ないバックエンドサーバにリクエストを転送することを示します.ポーリングアルゴリズムは、要求を各バックエンドに平均的に転送し、それらの負荷をほぼ同じにする.ただし、要求が長くかかると、バックエンドの負荷が高くなります.この場合least_connはこのようにしてより良い負荷等化効果を達成することができる.
    upstream my_server {
      least_conn;
      server localhost:8001;
      server localhost:8002;
    }
    

    (5) down
    現在のserverが負荷等化に一時的に関与していないことを示します.
    upstream my_server {
      server localhost:8001 down;
      server localhost:8002;
      server localhost:8003;
    }
    

    (6) backup
    予約したバックアップマシンを表します.他のすべての非backupマシンが故障したり忙しくなったりしたとき、backupマシンを要求するので、このマシンの圧力は最も軽いです.
    upstream my_server {
      server localhost:8001 backup;
      server localhost:8002;
      server localhost:8003;
    }