Nginx の主なアプリケーションシナリオは何ですか?-Nginx-php.cn

Nginx でできること

1. リバースプロキシ

2. 負荷分散

3.HTTP サーバー (動的および静的分離を含む)

4. フォワードプロキシ上記は、Nginx がサードパーティモジュールに依存せずに処理できることがわかっているものです。ここでは、各機能の実行方法について詳しく説明します

リバースプロキシ

リバースプロキシは、Nginx が行う最も一般的なものであるはずです。リバースプロキシとは何ですか? 以下は、Baidu Encyclopedia に記載されています: リバースプロキシ (リバースプロキシ) メソッドは、プロキシサーバーを使用して、受け入れを行うことを指します。プロキシサーバーは、インターネットからの接続要求を受信し、その要求を内部ネットワーク上のサーバーに転送し、サーバーから得られた結果をインターネット上の接続要求をしてきたクライアントに返すという仕組みですが、このときプロキシサーバーはリバースプロキシサーバーとして動作し、外の世界。簡単に言うと、実サーバーは外部ネットワークから直接アクセスできないため、プロキシサーバーが必要になりますプロキシサーバーは外部ネットワークからアクセスでき、実サーバーと同じネットワーク環境にあります。サーバーとポートが同じである可能性もありますが、単に異なるだけです。リバースプロキシを実装する簡単なコードを以下に貼り付けます

server {
       listen       80;                                                        
       server_name  localhost;                                              
       client_max_body_size 1024M;

       location / {
           proxy_pass http://localhost:8080;
           proxy_set_header Host $host:$server_port;
       }
   }

ログイン後にコピー

設定ファイルを保存して Nginx を起動します。これにより、localhost にアクセスするときは、localhost:8080

負荷分散

にアクセスするのと同じになります。

負荷分散も Nginx の一般的に使用される機能です。負荷分散とは、Web サーバー、FTP サーバー、エンタープライズキーアプリケーションサーバー、その他のミッションクリティカルなサーバーなどの複数のオペレーティングユニットに実行を割り当てることを意味します。共同で作業タスクを完了します。簡単に説明すると、サーバーが2台以上ある場合、リクエストを指定されたサーバーにランダムに振り分けてルールに従って処理するというもので、負荷分散の設定では一般にリバースプロキシの設定も同時に必要となり、リバースプロキシを経由して負荷分散に移行します。プロキシ。 Nginx は現在、3 つの組み込みの負荷分散戦略と、一般的に使用される 2 つのサードパーティ戦略をサポートしています。

1. RR (デフォルト)

各リクエストは時系列に 1 つずつ異なるバックエンドサーバーに割り当てられ、バックエンドサーバーがダウンした場合には自動的に排除できます。

簡単な構成

upstream test {
       server localhost:8080;
       server localhost:8081;
   }
   server {
       listen       81;                                                        
       server_name  localhost;                                              
       client_max_body_size 1024M;

       location / {
           proxy_pass http://test;
           proxy_set_header Host $host:$server_port;
       }
   }

ログイン後にコピー

負荷分散のコアコードは

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

ログイン後にコピー

ここでは2台のサーバーを構成しています。もちろん実際には1台のサーバーですが、ポートが異なります。 8081 サーバーが存在しないためアクセスできませんが、http://localhost にアクセスするとデフォルトで http://localhost:8080 にジャンプします。サーバーの状態を自動的に判断しますサーバーにアクセスできない（サーバーがダウンしている）場合は、このサーバーにジャンプしないため、サーバーがダウンして使用に影響を与える状況も回避できます Nginx はデフォルトで RR を使用しているため、詳細な設定が必要です。

2. 重み

ポーリング確率を指定します。重みはアクセス率に比例し、バックエンドサーバーのパフォーマンスが不均一な場合に使用されます。たとえば、

upstream test {
       server localhost:8080 weight=9;
       server localhost:8081 weight=1;
   }

ログイン後にコピー

の場合、通常、10 回のうち 1 回のみ 8081 にアクセスされ、9 回は 8080

3 にアクセスされます。ip_hash

上記 2 つの方法では、次のリクエストが来たときにリクエストが別のサーバーに分散される可能性があるという問題があり、プログラムがステートレスでない (データを保存するためにセッションを使用する) 場合、大きな問題が発生します。 , ログイン情報がセッションに保存されている場合、別のサーバーにジャンプするときに再度ログインする必要があります。顧客が 1 つのサーバーにのみアクセスする必要があることが多いため、ip_hash を使用する必要があります。ip_hash の各リクエストは、アクセス IP のハッシュ結果は、各訪問者がバックエンドサーバーに固定的にアクセスできるように割り当てられるため、セッションの問題を解決できます。

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

ログイン後にコピー

4. 公正 (サードパーティ)

リクエストはバックエンドサーバーの応答時間に応じて割り当てられ、応答時間の短いリクエストが最初に割り当てられます。

upstream backend {
       fair;
       server localhost:8080;
       server localhost:8081;
   }

ログイン後にコピー

5. url_hash (サードパーティ)

アクセスされた URL のハッシュ結果に応じてリクエストを振り分け、各 URL が同じバックエンドサーバーに誘導されるようにするとより効果的です。バックエンドサーバーがキャッシュされている場合。アップストリームにハッシュステートメントを追加します。サーバーステートメントには重みなどの他のパラメーターを記述することはできません。使用されるハッシュアルゴリズムは Hash_method です。

upstream backend {
       hash $request_uri;
       hash_method crc32;
       server localhost:8080;
       server localhost:8081;
   }

ログイン後にコピー

上記の 5 つの負荷分散方法は、さまざまな状況での使用に適しています。実際の状況に応じて選択できますどのストラテジーモードを使用するかですが、fair と url_hash は使用する前にサードパーティ製モジュールをインストールする必要がありますこの記事では主に Nginx でできることを紹介しているため、Nginx にサードパーティ製モジュールをインストールすると、この記事では紹介しません

HTTP Server

Nginx自体も静的リソースサーバーなので、静的リソースしかない場合にはNginxをサーバーとして利用することができます。静的リソースを静的リソースから分離することも現在非常に人気があり、これは Nginx を通じて実現できます。まず、静的リソースサーバーとしての Nginx を見てみましょう。

  server {
       listen       80;                                                        
       server_name  localhost;                                              
       client_max_body_size 1024M;


       location / {
              root   e:\wwwroot;
              index  index.html;
          }
   }

ログイン後にコピー

这样如果访问http://localhost 就会默认访问到E盘wwwroot目录下面的index.html，如果一个网站只是静态页面的话，那么就可以通过这种方式来实现部署。动静分离动静分离是让动态网站里的动态网页根据一定规则把不变的资源和经常变的资源区分开来，动静资源做好了拆分以后，我们就可以根据静态资源的特点将其做缓存操作，这就是网站静态化处理的核心思路

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;  
       }  
   }

ログイン後にコピー

这样我们就可以吧HTML以及图片和css以及js放到wwwroot目录下，而tomcat只负责处理jsp和请求，例如当我们后缀为gif的时候，Nginx默认会从wwwroot获取到当前请求的动态图文件返回，当然这里的静态文件跟Nginx是同一台服务器，我们也可以在另外一台服务器，然后通过反向代理和负载均衡配置过去就好了，只要搞清楚了最基本的流程，很多配置就很简单了，另外localtion后面其实是一个正则表达式，所以非常灵活

正向代理

正向代理，意思是一个位于客户端和原始服务器(origin server)之间的服务器，为了从原始服务器取得内容，客户端向代理发送一个请求并指定目标(原始服务器)，然后代理向原始服务器转交请求并将获得的内容返回给客户端。客户端才能使用正向代理。当你需要把你的服务器作为代理服务器的时候，可以用Nginx来实现正向代理，但是目前Nginx有一个问题，那么就是不支持HTTPS，虽然我百度到过配置HTTPS的正向代理，但是到最后发现还是代理不了，当然可能是我配置的不对，所以也希望有知道正确方法的同志们留言说明一下。

resolver 114.114.114.114 8.8.8.8;
   server {
       
       resolver_timeout 5s;

       listen 81;

       access_log  e:\wwwroot\proxy.access.log;
       error_log   e:\wwwroot\proxy.error.log;

       location / {
           proxy_pass http://$host$request_uri;
       }
   }

ログイン後にコピー

resolver是配置正向代理的DNS服务器，listen 是正向代理的端口，配置好了就可以在ie上面或者其他代理插件上面使用服务器ip+端口号进行代理了。