導入

Nginx は、主にクライアントとサーバーのリクエストの分散を処理する Web サーバーであり、高性能のリバースプロキシサーバーです。

フォワードプロキシとリバースプロキシ

プロキシは、サーバーとクライアントの間にある仮想的なサーバー層で、クライアントのリクエストを受信してサーバーに転送し、サーバーの応答をクライアントに転送します。
フォワードプロキシとは、クライアントが最初にリクエストをプロキシサーバーに送信し、そのリクエストをプロキシサーバー経由でサーバーに転送することを意味します。弊社でよく利用するVPNはプロキシサーバーですが、海外のWebサイトに接続するためには、クライアントは外部ネットワークに接続できるサーバーをプロキシとして利用する必要があり、クライアントはプロキシサーバーに接続することができます。

リバースプロキシはフォワードプロキシとは異なり、フォワードプロキシはクライアントをプロキシし、リバースプロキシはサーバーをプロキシします。複数のサーバーを分散配置している場合、クライアントがアクセスするIPアドレスを同一のWebサイトとするためには、リバースプロキシが必要です。

リバースプロキシ [proxy_pass]
いわゆるリバースプロキシは非常に単純で、実際には、ロケーション設定のルートをproxy_passに置き換えることができます。
ルートの説明は、Nginx によって返される静的リソースであり、
proxy_pass の説明は、Tomcat へのプロキシなど、転送する必要がある動的リクエストです。
負荷分散 [アップストリーム]
上記のリバースプロキシでは、proxy_pass で Tomcat のアドレスを指定していますが、当然ながら Tomcat のアドレスは 1 つしか指定できないので、負荷分散を実現するために複数の Tomcat を指定したい場合はどうすればよいでしょうか。
まず、アップストリームを通じて Tomcat のグループを定義し、ロードポリシー (IPHASH、重み付き引数、最小接続数)、ヘルスチェックポリシー (Nginx はこの Tomcat グループのステータスを監視できます) などを指定します。
次に、proxy_pass を上流で指定された値に置き換えます。

nginx.confの基本設定

画像.png

main                                # 全局配置
worker_processes  2;  ## 默认1，一般建议设成CPU核数1-2倍
error_log  logs/error.log; ## 错误日志路径
pid  logs/nginx.pid; ## 进程id

  events {
    
    							# nginx工作模式配置
    # 使用epoll的I/O 模型处理轮询事件。
    # 可以不设置，nginx会根据操作系统选择合适的模型
    use epoll;
    
    # 工作进程的最大连接数量, 默认1024个
    worker_connections  2048;
    
    # http层面的keep-alive超时时间
    keepalive_timeout 60;
    
    # 客户端请求头部的缓冲区大小
    client_header_buffer_size 2k;
  }

http {
    
                                    # http设置
  #引入外部配置，提高可读性，避免单个配置文件过大
  include       mime.types;
  default_type  application/octet-stream;
  
  include mime.types;  # 导入文件扩展名与文件类型映射表
  default_type application/octet-stream;  # 默认文件类型
  
  # 日志格式及access日志路径
  log_format   main '$remote_addr - $remote_user [$time_local]  $status '
  '"$request" $body_bytes_sent "$http_referer" '
  '"$http_user_agent" "$http_x_forwarded_for"';
  access_log   logs/access.log  main;
  
  #使用高效文件传输，提升传输性能。启用后才能使用tcp_nopush，是指当数据表累积一定大小后才发送，提高了效率。
  sendfile        on;						
  #tcp_nopush     on;
  #设置客户端与服务端请求的超时时间，保证客户端多次请求的时候不会重复建立新的连接，节约资源损耗。
  keepalive_timeout  65;

# ===========================静态文件管理配置======================================
# 开启gzip压缩功能
     gzip on;
     
     # 设置允许压缩的页面最小字节数; 这里表示如果文件小于10k，压缩没有意义.
     gzip_min_length 10k; 
     
     # 设置压缩比率，最小为1，处理速度快，传输速度慢；
     # 9为最大压缩比，处理速度慢，传输速度快; 推荐6
     gzip_comp_level 6; 
     
     # 设置压缩缓冲区大小，此处设置为16个8K内存作为压缩结果缓冲
     gzip_buffers 16 8k; 
     
     # 设置哪些文件需要压缩,一般文本，css和js建议压缩。图片视需要要锁。
     gzip_types text/plain text/css application/json application/x-javascript text/xml application/xml application/xml+rss text/javascript; 
# ===========================静态文件管理配置======================================

# 正常的正向静态代理
  server {
    
    
    listen       80;		# 监听端口
    server_name  localhost;	# ip、域名

  # 转发动态请求到web应用服务器
    location / {
    
    			# 请求路由映射，匹配拦截
      root   html;		# 请求位置
      index  index.html index.htm; # 首页位置
    }
    location /manage {
    
    
      root /ctp-manage-ui/dist;
      index index.html;
      try_files $uri $uri/ /manage/index.html;
    }

# 注意维护新增微服务，gateway 路由前缀
		location ~* ^/(code|auth|admin|gen|inst|order) {
    
    
		   proxy_pass http://127.0.0.1:9999;
		   #proxy_set_header Host $http_host;
		   proxy_connect_timeout 15s;
		   proxy_send_timeout 15s;
		   proxy_read_timeout 15s;
		   proxy_set_header X-Real-IP $remote_addr;
		   proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
		   proxy_set_header X-Forwarded-Proto http;
		}

# 使用expires选项开启静态文件缓存，10天有效
     location ~ ^/(images|javascript|js|css|flash|media|static)/  {
    
    
       root    /var/www/big.server.com/static_files;
       expires 10d;
     }
  }

# =============================简单反向代理=============================================

# 超时设置

# 该指令设置与upstream服务器的连接超时时间，这个超时建议不超过75秒。
 proxy_connect_timeout 60;
 
 # 该指令设置应用服务器的响应超时时间，默认60秒。
 proxy_read_timeout 60；
 
 # 设置了发送请求给upstream服务器的超时时间
 proxy_send_timeout 60;
 
 # max_fails设定Nginx与upstream服务器通信的尝试失败的次数。
 # 在fail_timeout参数定义的时间段内，如果失败的次数达到此值，Nginx就认为服务器不可用。
 
	server {
    
    
     listen       88;
     server_name  domain2.com www.domain2.com;
     access_log   logs/domain2.access.log  main;
    
     # 转发动态请求到web应用服务器
     location / {
    
    
       proxy_pass      http://127.0.0.1:8000;
       deny 192.24.40.8;  # 拒绝的ip
       allow 192.24.40.6; # 允许的ip   
     }
     
     # 错误页面
     error_page   500 502 503 504  /50x.html;
         location = /50x.html {
    
    
             root   html;
         }
   }

}

# =====================负载均衡 server=================================================
	server {
    
    
     listen          80;
     server_name     big.server.com;
     access_log      logs/big.server.access.log main;
     
     charset utf-8;
     client_max_body_size 10M; # 限制用户上传文件大小，默认1M
 
     location / {
    
    
       # 使用proxy_pass转发请求到通过upstream定义的一组应用服务器
       proxy_pass      http://backend_server;
       proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
       proxy_set_header Host $http_host;
       proxy_redirect off;
       proxy_set_header X-Real-IP  $remote_addr;
     }
     
   }

# 负载均衡
   upstream backend_server {
    
    
     server 192.168.0.1:8000 weight=5; # weight越高，权重越大
     server 192.168.0.2:8000 weight=1;
     server 192.168.0.3:8000;
     server 192.168.0.4:8001 backup; # 热备
   }

	
}

位置

場所に文字が存在するかどうかは影響しません。つまり、/homepage/ は /homepage と同じです。

location = / {
    
    
  # 精确匹配/，主机名后面不能带任何字符串 /
  [ configuration A ]
}
location / {
    
    
  # 匹配所有以 / 开头的请求。
  # 但是如果有更长的同类型的表达式，则选择更长的表达式。
  # 如果有正则表达式可以匹配，则优先匹配正则表达式。
  [ configuration B ]
}
location /documents/ {
    
    
  # 匹配所有以 /documents/ 开头的请求，匹配符合以后，还要继续往下搜索。
  # 但是如果有更长的同类型的表达式，则选择更长的表达式。
  # 如果有正则表达式可以匹配，则优先匹配正则表达式。
  [ configuration C ]
}
location ^~ /images/ {
    
    
  # 匹配所有以 /images/ 开头的表达式，如果匹配成功，则停止匹配查找，停止搜索。
  # 所以，即便有符合的正则表达式location，也不会被使用
  [ configuration D ]
}

URLのマッチング方法と優先度

文字一致ルールの優先度が段階的に下がります

= 完全一致 1
^~ は文字列 2 で始まります
~ 大文字と小文字を区別する通常の一致 3
~* 大文字と小文字を区別しない通常の一致 4
!~ 大文字と小文字を区別する正規表現の不一致 5
!~* 大文字と小文字を区別しない正規表現 6 の不一致
/ ユニバーサルマッチ。あらゆるリクエストが 7 にマッチします。

ルートとエイリアスの違い

root: 連結 (ロケーションのカスタム名) alias: エイリアス (ロケーションのカスタム名)
画像.png root: /Users/admin/www**/h5**/index.html
プレフィックスがない場合、root はエイリアスと同じで、root は一般的に使用されます ;
プレフィックスがある場合、プレフィックス名がディレクトリパスの最後の部分と一致する場合は root を使用し、一致しない場合はエイリアスを使用する必要があります。

エイリアスは「/」で終わる必要があります。そうでない場合、エイリアスはファイルとみなされ、対応するディレクトリが見つかりません。ルートは「/」のオプションです。

履歴モード

location /h5 {
    
    
  root /Users/admin/www/;
  index index.html;
  try_files $uri $uri/ /h5/index.html;
}

この構文は次のことを意味します。

try_files の後、複数のファイルパスと最後の URI を内部ジャンプとして定義できます。ファイルパスはエイリアスとルート命令とともに構築されます。
複数のファイルが要求され、最初に見つかったファイルが要求されます。
ファイルが「/」で終わると、ディレクトリが存在するかどうかがチェックされます。
ファイルが見つからない場合は、最後の URI を使用して内部ジャンプリクエストを作成します。
変数の解釈

try_files の構文が修正されました

$uri はホームファイルを指します (IP アドレスの後ろのパス。127.0.0.1/index/a.png の場合は、index/a.png を指します)。
$uri/ はホームフォルダー
/index.htmlを指します。 ip/index.html アドレス開始リクエスト

例:

try_files $uri $uri/ /h5/index.html を定義しました。ルートは /Users/admin/www;
uri と uri という 2 つのファイルが定義されています。アクセスパスはtesthistory.com/h5/about、$uriは /h5/about です。ルートディレクトリが見つからず、$url/ が対応するディレクトリを見つけられないため、root を追加します。
ファイルが見つからない場合は、内部的に /h5/index.html にジャンプします。これは、内部的にtesthistory.com/h5/index.htをリクエストするのと同じです。

try_files $uri $uri/ /index.html;
次の 2 つのファイル/フォルダーを解析してみます (IP の背後にあるパスがファイルであるかフォルダーであるかを自動的に識別します)、 $u r i /$ uri/、
解決された場合は最初のものを返し、
解決されていない場合は 127.0.0.1/index.html へのリクエストジャンプを開始します (ルートは実数でなければなりません。そうでない場合はエラーが報告されます)

リクエストの転送とリダイレクト

# 转发动态请求
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请求重定向到https请求
server {
    
    
  listen 80;
  server_name Domain.com;
  return 301 https://$server_name$request_uri;
}

リクエストの転送でもリダイレクトでも、Nginx が提供するグローバル変数である $ 記号で始まる変数を使用しました。それらの具体的な意味は次のとおりです。

$args, 请求中的参数;
 $content_length, HTTP请求信息里的"Content-Length";
 $content_type, 请求信息里的"Content-Type";
 $document_root, 针对当前请求的根路径设置值;
 $document_uri, 与$uri相同;
 $host, 请求信息中的"Host"，如果请求中没有Host行，则等于设置的服务器名;
 $limit_rate, 对连接速率的限制;
 $request_method, 请求的方法，比如"GET"、"POST"等;
 $remote_addr, 客户端地址;
 $remote_port, 客户端端口号;
 $remote_user, 客户端用户名，认证用;
 $request_filename, 当前请求的文件路径名
 $request_body_file,当前请求的文件
 $request_uri, 请求的URI，带查询字符串;
 $query_string, 与$args相同;
 $scheme, 所用的协议，比如http或者是https，比如rewrite ^(.+)$ $scheme://example.com$1 redirect;
 $server_protocol, 请求的协议版本，"HTTP/1.0"或"HTTP/1.1";
 $server_addr, 服务器地址;
 $server_name, 请求到达的服务器名;
 $server_port, 请求到达的服务器端口号;
 $uri, 请求的URI，可能和最初的值有不同，比如经过重定向之类的。

ファイルダウンロードサーバー

server {
 listen 80 default_server;
 listen [::]:80 default_server;
 server_name  _;
 
 location /download {    
     # 下载文件所在目录
     root /usr/share/nginx/html;
     
     # 开启索引功能
     autoindex on;  
     
     # 关闭计算文件确切大小（单位bytes），只显示大概大小（单位kb、mb、gb）
     autoindex_exact_size off; 
     
     #显示本机时间而非 GMT 时间
     autoindex_localtime on;   
             
     # 对于txt和jpg文件，强制以附件形式下载，不要浏览器直接打开
     if ($request_filename ~* ^.*?\.(txt|jpg|png)$) {
         add_header Content-Disposition 'attachment';
     }
 }
}

Nginx 構成 HTTPS

# 负载均衡，设置HTTPS
 upstream backend_server {
     server APP_SERVER_1_IP;
     server APP_SERVER_2_IP;
 }
 
 # 禁止未绑定域名访问，比如通过ip地址访问
 # 444:该网页无法正常运作，未发送任何数据
 server {
     listen 80 default_server;
     server_name _;
     return 444;
 }
 
 # HTTP请求重定向至HTTPS请求
 server {
     listen 80;
     listen [::]:80;
     server_name your_domain.com;
     
     location / {
         proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
         proxy_set_header X-Forwarded-Proto $scheme;
         proxy_set_header Host $http_host;
         proxy_redirect off;
         proxy_pass http://backend_server; 
      }
     
     return 301 https://$server_name$request_uri;
 }
 
 server {
     listen 443 ssl http2;
     listen [::]:443 ssl http2;
     server_name your_domain.com;
 
     # ssl证书及密钥路径
     ssl_certificate /path/to/your/fullchain.pem;
     ssl_certificate_key /path/to/your/privkey.pem;
 
     # SSL会话信息
     client_max_body_size 75MB;
     keepalive_timeout 10;
 
     location / {
         proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
         proxy_set_header X-Forwarded-Proto $scheme;
         proxy_set_header Host $http_host;
         proxy_redirect off;
         proxy_pass http://django; # Django+uwsgi不在本机上，使用代理转发
     }
 
 }

nginxロードバランシング

アップストリームはバックエンドサーバーのアドレスリストを指定し、サーバーで応答リクエストをインターセプトし、アップストリームで構成されたサーバーリストにリクエストを転送します。

// 默认情况下采用的是轮询策略，将所有客户端请求轮询分配给服务端
upstream balanceServer {
    
    
    server 10.1.22.33:12345;
    server 10.1.22.34:12345;
    server 10.1.22.35:12345;
}

server {
    
    
    server_name  fe.server.com;
listen 80;
location /api {
    
    
    proxy_pass http://balanceServer;
        }
}

ポーリング (デフォルト)
各リクエストは時間順に異なるバックエンドサーバーに 1 つずつ割り当てられます。
Weight Weight
は重みを表します。デフォルトは 1 です。重みが大きいほど、より多くのクライアントが割り当てられます。
画像.png
ip_hash
各リクエストは、 access ip を使用すると、各アクセスクライアントが固定バックエンドサーバーにアクセスできるようになり、セッション損失の問題を解決できます。

nginxの一般的なコマンド

# 启动nginx
start nginx
# 快速关闭Nginx，可能不保存相关信息，并迅速终止web服务
nginx -s stop
# 平稳关闭Nginx，保存相关信息，有安排的结束web服务
nginx -s quit
# 因改变了Nginx相关配置，需要重新加载配置而重载
nginx -s reload
# 重新打开日志文件
nginx -s reopen
# 为 Nginx 指定一个配置文件，来代替缺省的
nginx -c filename
# 不运行，而仅仅测试配置文件。nginx 将检查配置文件的语法的正确性，并尝试打开配置文件中所引用到的文件
nginx -t
#  显示 nginx 的版本
nginx -v
# 显示 nginx 的版本，编译器版本和配置参数
nginx -V
# 格式换显示 nginx 配置参数
2>&1 nginx -V | xargs -n1
2>&1 nginx -V | xargs -n1 | grep lua

質問：

Nginx はどのようにしてホットデプロイメントを実現しますか?

ホットデプロイメントとは、構成ファイル nginx.conf が変更された後、Nginx を停止したりリクエストを中断したりすることなく、構成ファイルが有効になることを意味します。

Nginxのマスターワーカーモード

画像.png
Nginxを起動した後、実際にポート80でSocketサービスを起動して監視を行っていますが、図のように

MasterプロセスとWorkerプロセスが関わるNginxの役割は何でしょうか？
構成ファイル nginx.conf を読んで確認する; ワーカープロセスを管理する;
ワーカープロセスの役割は何ですか?
各ワーカープロセスは、接続とリクエストを処理するために (スレッドの切り替えを避けるために) スレッドを維持します。ワーカープロセスの数は、一般に CPU の数 (プロセスの切り替えに有利) に関連する構成ファイルによって決定されることに注意してください。構成ワーカープロセス。
解決策 1:
構成ファイル nginx.conf を変更した後、メインプロセスマスターは、更新された構成情報をワーカープロセスにプッシュする責任を負い、ワーカープロセスは情報を受信した後、プロセス内のスレッド情報を更新します。(少し不安定)
オプション 2: (nginx -s reload reload)
構成ファイル nginx.conf を変更した後、新しいワーカープロセスを再生成します。もちろん、リクエストは新しい構成で処理され、新しいリクエストは引き渡される必要があります。新しいワーカープロセスは、古いワーカープロセスと同様に、前のリクエストが処理された後に単に強制終了します。
Nginx は 2 番目のソリューションを使用してホットデプロイメントを実現します。

Nginx がダウンしている場合はどうすればよいですか?

Keepalived+Nginx で高可用性を実現
Keepalived は高可用性ソリューションで、主にサーバーの単一障害点を防ぐために使用され、Nginx
Keepalived+Nginx と連携して高可用性を実現することで Web サービスの高可用性を
実現できます。Nginx を直接ヒットしないでください。最初に Keepalived (これはいわゆる仮想 IP、VIP) を渡す必要があります。2
番目: Keepalived は、Nginx の生存ステータスを監視できる必要があります (ユーザー定義のスクリプトを提供し、Nginx のステータスを定期的に確認します)。処理し、重みを変更し、Nginx フェイルオーバーを有効にします)

分散セッション共有の問題

画像.png

解決：

nginx の IP ハッシュ:

  - 这样同一个客户端每次的请求都会被同一个服务器处理，配置简单，不⼊侵应⽤，不需要额外修改代码

欠点:
- サーバーが再起動され、セッションが失われます
- 一点に高負荷がかかる危険性がある
- 単一障害点の問題

セッション共有、セッション集中管理（redis）

画像.png

知らせ：

別名: left / : ありとなしの違い

画像.png

参考文献:

nginx設定リファレンス

https://zhuanlan.zhihu.com/p/372610935
https://blog.csdn.net/qq_34817440/article/details/121501802

OSI 7 層モデル

7 層モデル。OSI (Open System Interconnection) とも呼ばれます。参照モデルは、コンピュータまたは通信システム間の相互接続のために国際標準化機構 (ISO) によって開発された標準システムであり、一般に OSI 参照モデルまたは 7 層モデルとして知られています。
これは 7 層の抽象的なモデル本体であり、一連の抽象的な用語や概念だけでなく、特定のプロトコルも含まれています。
画像.png

TCP/IP 4層モデル

TCP/IP プロトコルは、OSI アーキテクチャをある程度参照します。OSI モデルには 7 層ありますが、複雑であるため、TCP/IP プロトコルでは 4 層に簡略化されています。
画像.png

nginxバージョン2023の最新詳細紹介

導入

フォワードプロキシとリバースプロキシ

nginx.confの基本設定

位置

URLのマッチング方法と優先度

ルートとエイリアスの違い

履歴モード

変数の解釈

try_files の構文が修正されました

リクエストの転送とリダイレクト

ファイルダウンロードサーバー

Nginx 構成 HTTPS

nginxロードバランシング

nginxの一般的なコマンド

質問：

Nginx はどのようにしてホットデプロイメントを実現しますか?

Nginxのマスターワーカーモード

Nginx がダウンしている場合はどうすればよいですか?

分散セッション共有の問題

解決：

nginx の IP ハッシュ:

セッション共有、セッション集中管理（redis）

知らせ：

別名: left / : ありとなしの違い

参考文献:

nginx設定リファレンス

OSI 7 層モデル

TCP/IP 4層モデル

おすすめ

nginxバージョン2023の最新詳細紹介

導入

フォワードプロキシとリバースプロキシ

nginx.confの基本設定

位置

URLのマッチング方法と優先度

ルートとエイリアスの違い

履歴モード

変数の解釈

try_files の構文が修正されました

リクエストの転送とリダイレクト

ファイルダウンロードサーバー

Nginx 構成 HTTPS

nginxロードバランシング

nginxの一般的なコマンド

質問：

Nginx はどのようにしてホット デプロイメントを実現しますか?

Nginxのマスターワーカーモード

Nginx がダウンしている場合はどうすればよいですか?

分散セッション共有の問題

解決：

nginx の IP ハッシュ:

セッション共有、セッション集中管理（redis）

知らせ：

別名: left / : ありとなしの違い

参考文献:

nginx設定リファレンス

OSI 7 層モデル

TCP/IP 4層モデル

おすすめ

Nginx はどのようにしてホットデプロイメントを実現しますか?