Nginx-nginx-1.18.0 がコンパイルされると、デフォルトでどのモジュールが含まれますか? nginx-1.18.0 にはどのようなモジュールと構成ステートメントがあり、それらの機能は何ですか?

私自身が書いた Nginx に関連するいくつかの重要なブログ投稿
詳細については、リンクをご覧ください。https://blog.csdn.net/ wenhao_ir /article/details/135023881

01-Nginx-nginx-1.18.0 のコンパイル時にデフォルトで含まれるモジュールを確認するにはどうすればよいですか?

コンパイル構成オプションのデフォルト設定を確認したい場合は、次の 2 つのコマンドを実行できます。

モジュールの追加と削除を手動で設定せずにコンパイルを構成します。

./configure --prefix=/usr/local/nginx

それからコンパイルします

make

コンパイルが完了すると、次の図に示すように、どのモジュールがコンパイルされたかが表示されます。

コンパイルされたターゲット ファイルの名前は、configure で使用されるモジュール名とは異なる場合があることに注意してください。
たとえば、モジュール http_geo の場合、configure help コマンドではその名前は http_geo_module ですが、最終的にコンパイルされるターゲット ファイルの名前は実際には ngx_http_geo_module.o です。テストしたところ、このモジュールを含めたくない場合は、次のコマンドが必要です。

--without-http_geo_module

これは、コンパイルされたターゲット ファイルの名前と、configure で使用されるモジュール名が異なる可能性があることを完全に示しています。

完全な情報は次のとおりです。

objs/src/core/nginx.o \
objs/src/core/ngx_log.o \
objs/src/core/ngx_palloc.o \
objs/src/core/ngx_array.o \
objs/src/core/ngx_list.o \
objs/src/core/ngx_hash.o \
objs/src/core/ngx_buf.o \
objs/src/core/ngx_queue.o \
objs/src/core/ngx_output_chain.o \
objs/src/core/ngx_string.o \
objs/src/core/ngx_parse.o \
objs/src/core/ngx_parse_time.o \
objs/src/core/ngx_inet.o \
objs/src/core/ngx_file.o \
objs/src/core/ngx_crc32.o \
objs/src/core/ngx_murmurhash.o \
objs/src/core/ngx_md5.o \
objs/src/core/ngx_sha1.o \
objs/src/core/ngx_rbtree.o \
objs/src/core/ngx_radix_tree.o \
objs/src/core/ngx_slab.o \
objs/src/core/ngx_times.o \
objs/src/core/ngx_shmtx.o \
objs/src/core/ngx_connection.o \
objs/src/core/ngx_cycle.o \
objs/src/core/ngx_spinlock.o \
objs/src/core/ngx_rwlock.o \
objs/src/core/ngx_cpuinfo.o \
objs/src/core/ngx_conf_file.o \
objs/src/core/ngx_module.o \
objs/src/core/ngx_resolver.o \
objs/src/core/ngx_open_file_cache.o \
objs/src/core/ngx_crypt.o \
objs/src/core/ngx_proxy_protocol.o \
objs/src/core/ngx_syslog.o \
objs/src/event/ngx_event.o \
objs/src/event/ngx_event_timer.o \
objs/src/event/ngx_event_posted.o \
objs/src/event/ngx_event_accept.o \
objs/src/event/ngx_event_udp.o \
objs/src/event/ngx_event_connect.o \
objs/src/event/ngx_event_pipe.o \
objs/src/os/unix/ngx_time.o \
objs/src/os/unix/ngx_errno.o \
objs/src/os/unix/ngx_alloc.o \
objs/src/os/unix/ngx_files.o \
objs/src/os/unix/ngx_socket.o \
objs/src/os/unix/ngx_recv.o \
objs/src/os/unix/ngx_readv_chain.o \
objs/src/os/unix/ngx_udp_recv.o \
objs/src/os/unix/ngx_send.o \
objs/src/os/unix/ngx_writev_chain.o \
objs/src/os/unix/ngx_udp_send.o \
objs/src/os/unix/ngx_udp_sendmsg_chain.o \
objs/src/os/unix/ngx_channel.o \
objs/src/os/unix/ngx_shmem.o \
objs/src/os/unix/ngx_process.o \
objs/src/os/unix/ngx_daemon.o \
objs/src/os/unix/ngx_setaffinity.o \
objs/src/os/unix/ngx_setproctitle.o \
objs/src/os/unix/ngx_posix_init.o \
objs/src/os/unix/ngx_user.o \
objs/src/os/unix/ngx_dlopen.o \
objs/src/os/unix/ngx_process_cycle.o \
objs/src/os/unix/ngx_linux_init.o \
objs/src/event/modules/ngx_epoll_module.o \
objs/src/os/unix/ngx_linux_sendfile_chain.o \
objs/src/core/ngx_regex.o \
objs/src/http/ngx_http.o \
objs/src/http/ngx_http_core_module.o \
objs/src/http/ngx_http_special_response.o \
objs/src/http/ngx_http_request.o \
objs/src/http/ngx_http_parse.o \
objs/src/http/modules/ngx_http_log_module.o \
objs/src/http/ngx_http_request_body.o \
objs/src/http/ngx_http_variables.o \
objs/src/http/ngx_http_script.o \
objs/src/http/ngx_http_upstream.o \
objs/src/http/ngx_http_upstream_round_robin.o \
objs/src/http/ngx_http_file_cache.o \
objs/src/http/ngx_http_write_filter_module.o \
objs/src/http/ngx_http_header_filter_module.o \
objs/src/http/modules/ngx_http_chunked_filter_module.o \
objs/src/http/modules/ngx_http_range_filter_module.o \
objs/src/http/modules/ngx_http_gzip_filter_module.o \
objs/src/http/ngx_http_postpone_filter_module.o \
objs/src/http/modules/ngx_http_ssi_filter_module.o \
objs/src/http/modules/ngx_http_charset_filter_module.o \
objs/src/http/modules/ngx_http_userid_filter_module.o \
objs/src/http/modules/ngx_http_headers_filter_module.o \
objs/src/http/ngx_http_copy_filter_module.o \
objs/src/http/modules/ngx_http_not_modified_filter_module.o \
objs/src/http/modules/ngx_http_static_module.o \
objs/src/http/modules/ngx_http_autoindex_module.o \
objs/src/http/modules/ngx_http_index_module.o \
objs/src/http/modules/ngx_http_mirror_module.o \
objs/src/http/modules/ngx_http_try_files_module.o \
objs/src/http/modules/ngx_http_auth_basic_module.o \
objs/src/http/modules/ngx_http_access_module.o \
objs/src/http/modules/ngx_http_limit_conn_module.o \
objs/src/http/modules/ngx_http_limit_req_module.o \
objs/src/http/modules/ngx_http_geo_module.o \
objs/src/http/modules/ngx_http_map_module.o \
objs/src/http/modules/ngx_http_split_clients_module.o \
objs/src/http/modules/ngx_http_referer_module.o \
objs/src/http/modules/ngx_http_rewrite_module.o \
objs/src/http/modules/ngx_http_proxy_module.o \
objs/src/http/modules/ngx_http_fastcgi_module.o \
objs/src/http/modules/ngx_http_uwsgi_module.o \
objs/src/http/modules/ngx_http_scgi_module.o \
objs/src/http/modules/ngx_http_memcached_module.o \
objs/src/http/modules/ngx_http_empty_gif_module.o \
objs/src/http/modules/ngx_http_browser_module.o \
objs/src/http/modules/ngx_http_upstream_hash_module.o \
objs/src/http/modules/ngx_http_upstream_ip_hash_module.o \
objs/src/http/modules/ngx_http_upstream_least_conn_module.o \
objs/src/http/modules/ngx_http_upstream_random_module.o \
objs/src/http/modules/ngx_http_upstream_keepalive_module.o \
objs/src/http/modules/ngx_http_upstream_zone_module.o \
objs/ngx_modules.o \

以下は、Nginx にデフォルトで含まれるモジュールです。

02-Nginx に手動で追加できるモジュールと追加できないモジュールを確認する方法

次のコマンドを使用できます。

./configure --help

手動で追加できるモジュールと追加できないモジュールを確認します。
注: リストされている情報で、「with」で始まるか、「without」で始まるかは、デフォルトで含まれるかどうかを示すものではなく、このモジュールが頻繁に追加されるかどうかを示すだけです。これは単なる追加であり、もちろん文法の例です。

実行./configure --helpコマンドの結果は次のとおりです:

./configure --help

[root@geoiptest03 nginx-1.18.0]# ./configure --help

  --help                             print this message

  --prefix=PATH                      set installation prefix
  --sbin-path=PATH                   set nginx binary pathname
  --modules-path=PATH                set modules path
  --conf-path=PATH                   set nginx.conf pathname
  --error-log-path=PATH              set error log pathname
  --pid-path=PATH                    set nginx.pid pathname
  --lock-path=PATH                   set nginx.lock pathname

  --user=USER                        set non-privileged user for
                                     worker processes
  --group=GROUP                      set non-privileged group for
                                     worker processes

  --build=NAME                       set build name
  --builddir=DIR                     set build directory

  --with-select_module               enable select module
  --without-select_module            disable select module
  --with-poll_module                 enable poll module
  --without-poll_module              disable poll module

  --with-threads                     enable thread pool support

  --with-file-aio                    enable file AIO support

  --with-http_ssl_module             enable ngx_http_ssl_module
  --with-http_v2_module              enable ngx_http_v2_module
  --with-http_realip_module          enable ngx_http_realip_module
  --with-http_addition_module        enable ngx_http_addition_module
  --with-http_xslt_module            enable ngx_http_xslt_module
  --with-http_xslt_module=dynamic    enable dynamic ngx_http_xslt_module
  --with-http_image_filter_module    enable ngx_http_image_filter_module
  --with-http_image_filter_module=dynamic
                                     enable dynamic ngx_http_image_filter_module
  --with-http_geoip_module           enable ngx_http_geoip_module
  --with-http_geoip_module=dynamic   enable dynamic ngx_http_geoip_module
  --with-http_sub_module             enable ngx_http_sub_module
  --with-http_dav_module             enable ngx_http_dav_module
  --with-http_flv_module             enable ngx_http_flv_module
  --with-http_mp4_module             enable ngx_http_mp4_module
  --with-http_gunzip_module          enable ngx_http_gunzip_module
  --with-http_gzip_static_module     enable ngx_http_gzip_static_module
  --with-http_auth_request_module    enable ngx_http_auth_request_module
  --with-http_random_index_module    enable ngx_http_random_index_module
  --with-http_secure_link_module     enable ngx_http_secure_link_module
  --with-http_degradation_module     enable ngx_http_degradation_module
  --with-http_slice_module           enable ngx_http_slice_module
  --with-http_stub_status_module     enable ngx_http_stub_status_module

  --without-http_charset_module      disable ngx_http_charset_module
  --without-http_gzip_module         disable ngx_http_gzip_module
  --without-http_ssi_module          disable ngx_http_ssi_module
  --without-http_userid_module       disable ngx_http_userid_module
  --without-http_access_module       disable ngx_http_access_module
  --without-http_auth_basic_module   disable ngx_http_auth_basic_module
  --without-http_mirror_module       disable ngx_http_mirror_module
  --without-http_autoindex_module    disable ngx_http_autoindex_module
  --without-http_geo_module          disable ngx_http_geo_module
  --without-http_map_module          disable ngx_http_map_module
  --without-http_split_clients_module disable ngx_http_split_clients_module
  --without-http_referer_module      disable ngx_http_referer_module
  --without-http_rewrite_module      disable ngx_http_rewrite_module
  --without-http_proxy_module        disable ngx_http_proxy_module
  --without-http_fastcgi_module      disable ngx_http_fastcgi_module
  --without-http_uwsgi_module        disable ngx_http_uwsgi_module
  --without-http_scgi_module         disable ngx_http_scgi_module
  --without-http_grpc_module         disable ngx_http_grpc_module
  --without-http_memcached_module    disable ngx_http_memcached_module
  --without-http_limit_conn_module   disable ngx_http_limit_conn_module
  --without-http_limit_req_module    disable ngx_http_limit_req_module
  --without-http_empty_gif_module    disable ngx_http_empty_gif_module
  --without-http_browser_module      disable ngx_http_browser_module
  --without-http_upstream_hash_module
                                     disable ngx_http_upstream_hash_module
  --without-http_upstream_ip_hash_module
                                     disable ngx_http_upstream_ip_hash_module
  --without-http_upstream_least_conn_module
                                     disable ngx_http_upstream_least_conn_module
  --without-http_upstream_random_module
                                     disable ngx_http_upstream_random_module
  --without-http_upstream_keepalive_module
                                     disable ngx_http_upstream_keepalive_module
  --without-http_upstream_zone_module
                                     disable ngx_http_upstream_zone_module

  --with-http_perl_module            enable ngx_http_perl_module
  --with-http_perl_module=dynamic    enable dynamic ngx_http_perl_module
  --with-perl_modules_path=PATH      set Perl modules path
  --with-perl=PATH                   set perl binary pathname

  --http-log-path=PATH               set http access log pathname
  --http-client-body-temp-path=PATH  set path to store
                                     http client request body temporary files
  --http-proxy-temp-path=PATH        set path to store
                                     http proxy temporary files
  --http-fastcgi-temp-path=PATH      set path to store
                                     http fastcgi temporary files
  --http-uwsgi-temp-path=PATH        set path to store
                                     http uwsgi temporary files
  --http-scgi-temp-path=PATH         set path to store
                                     http scgi temporary files

  --without-http                     disable HTTP server
  --without-http-cache               disable HTTP cache

  --with-mail                        enable POP3/IMAP4/SMTP proxy module
  --with-mail=dynamic                enable dynamic POP3/IMAP4/SMTP proxy module
  --with-mail_ssl_module             enable ngx_mail_ssl_module
  --without-mail_pop3_module         disable ngx_mail_pop3_module
  --without-mail_imap_module         disable ngx_mail_imap_module
  --without-mail_smtp_module         disable ngx_mail_smtp_module

  --with-stream                      enable TCP/UDP proxy module
  --with-stream=dynamic              enable dynamic TCP/UDP proxy module
  --with-stream_ssl_module           enable ngx_stream_ssl_module
  --with-stream_realip_module        enable ngx_stream_realip_module
  --with-stream_geoip_module         enable ngx_stream_geoip_module
  --with-stream_geoip_module=dynamic enable dynamic ngx_stream_geoip_module
  --with-stream_ssl_preread_module   enable ngx_stream_ssl_preread_module
  --without-stream_limit_conn_module disable ngx_stream_limit_conn_module
  --without-stream_access_module     disable ngx_stream_access_module
  --without-stream_geo_module        disable ngx_stream_geo_module
  --without-stream_map_module        disable ngx_stream_map_module
  --without-stream_split_clients_module
                                     disable ngx_stream_split_clients_module
  --without-stream_return_module     disable ngx_stream_return_module
  --without-stream_upstream_hash_module
                                     disable ngx_stream_upstream_hash_module
  --without-stream_upstream_least_conn_module
                                     disable ngx_stream_upstream_least_conn_module
  --without-stream_upstream_random_module
                                     disable ngx_stream_upstream_random_module
  --without-stream_upstream_zone_module
                                     disable ngx_stream_upstream_zone_module

  --with-google_perftools_module     enable ngx_google_perftools_module
  --with-cpp_test_module             enable ngx_cpp_test_module

  --add-module=PATH                  enable external module
  --add-dynamic-module=PATH          enable dynamic external module

  --with-compat                      dynamic modules compatibility

  --with-cc=PATH                     set C compiler pathname
  --with-cpp=PATH                    set C preprocessor pathname
  --with-cc-opt=OPTIONS              set additional C compiler options
  --with-ld-opt=OPTIONS              set additional linker options
  --with-cpu-opt=CPU                 build for the specified CPU, valid values:
                                     pentium, pentiumpro, pentium3, pentium4,
                                     athlon, opteron, sparc32, sparc64, ppc64

  --without-pcre                     disable PCRE library usage
  --with-pcre                        force PCRE library usage
  --with-pcre=DIR                    set path to PCRE library sources
  --with-pcre-opt=OPTIONS            set additional build options for PCRE
  --with-pcre-jit                    build PCRE with JIT compilation support

  --with-zlib=DIR                    set path to zlib library sources
  --with-zlib-opt=OPTIONS            set additional build options for zlib
  --with-zlib-asm=CPU                use zlib assembler sources optimized
                                     for the specified CPU, valid values:
                                     pentium, pentiumpro

  --with-libatomic                   force libatomic_ops library usage
  --with-libatomic=DIR               set path to libatomic_ops library sources

  --with-openssl=DIR                 set path to OpenSSL library sources
  --with-openssl-opt=OPTIONS         set additional build options for OpenSSL

  --with-debug                       enable debug logging

03 - 各設定ステートメントとモジュール機能の紹介

03-001：--pid-path=PATH

--pid-path=PATHこれは Nginx 構成オプションの 1 つであり、Nginx マスター プロセスの PID ファイルのストレージ パスを指定するために使用されます。 PID ファイルには、Nginx メイン プロセスのプロセス ID (PID) が含まれています。

具体的には、--pid-path オプションを使用すると、メイン Nginx プロセスの PID ファイルが保存されるパスを指定できます。例:

./configure --pid-path=/var/run/nginx/nginx.pid

上記のコマンドは、Nginx メイン プロセスの PID ファイルを /var/run/nginx/nginx.pid ファイルに保存します。

主な機能は 2 つあります。

1. プロセス管理: PID ファイルは通常、Nginx プロセスの開始、停止、リロードなどのプロセス管理に使用されます。システム管理者は、PID ファイルを使用して Nginx メイン プロセスの現在のプロセス ID を確認し、シャットダウンや構成の再読み込みなどの操作を実行できます。

2. 監視と診断: 場合によっては、プロセス ステータスの監視やトラブルシューティングを行うために、監視ツールや診断スクリプトで Nginx メイン プロセスの PID を取得する必要がある場合があります。

予防：

• --pid-path が指定されていない場合、Nginx はデフォルトのパス (Nginx のインストールに応じて、通常は /usr/local/nginx/logs/nginx.pid または同様のパス) に PID ファイルを保存します。ディレクトリ。
• 指定されたパスが Nginx プロセスによって書き込み可能であることを確認してください。そうでない場合、Nginx は起動時に PID ファイルを作成できない可能性があります。
• 必要なときに簡単に見つけられるように、PID ファイルを管理可能なディレクトリに保存することをお勧めします。

03-002：--lock-path=PATH

--lock-path=PATHこれは Nginx 構成オプションの 1 つで、Nginx メイン プロセスによって使用されるファイル ロックのストレージ パスを指定するために使用されます。このファイル ロックは、同時に 1 つの Nginx メイン プロセスだけが実行されるようにするためのものです。

具体的には、--lock-path オプションを使用すると、Nginx メイン プロセスのロック ファイルが保存されるパスを指定できます。例:

./configure --lock-path=/var/lock/nginx.lock

上記のコマンドは、Nginx メイン プロセスのロック ファイルを /var/lock/nginx.lock ファイルに保存します。

主な機能は 2 つあります。

1. プロセス間同期: 複数のプロセスが共有リソースにアクセスする場合、ファイル ロックを通じてプロセス間の同期を実現し、同時に 1 つのプロセスだけが共有リソースを操作できるようにします。 。 Nginx では、これは主に複数のマスター プロセスが同時に起動するのを防ぐために使用されます。

2. 起動時の競合を避ける: 複数の Nginx マスター プロセスが起動しようとすると、ファイル ロックを取得しようとします。ロックを正常に取得したプロセスのみが開始を続行でき、他のプロセスは待機する必要があります。これにより、起動時の競合を回避し、1 つの Nginx プロセスのみが制御を取得できるようになります。

予防：

• --lock-path が指定されていない場合、Nginx はロック ファイルをデフォルトのパス (Nginx のインストールに応じて、通常は /usr/local/nginx/logs/nginx.lock または同様のパス) に保存します。ディレクトリ。
• 指定されたパスが Nginx プロセスによって書き込み可能であることを確認してください。そうでない場合、Nginx は起動時にロック ファイルを作成できない可能性があります。
• ロック ファイルは Nginx メイン プロセスが実行されているときにのみ存在するため、ロック ファイルの存在は Nginx メイン プロセスが実行されているかどうかを判断するために使用できます。

03-003：select_module

Nginx がオペレーティング システムなどの要素に基づいて自動的に選択を行うため、手動設定は必要ありません。

select_module は、select モジュールを有効にする Nginx のコンパイル オプションです。このモジュールにより、Nginx はイベント処理に select システム コールを使用できるようになります。

イベント処理は Nginx の非常に重要な概念であり、ネットワーク接続やタイマーなどの非同期イベントを処理するために使用されます。 select モジュールは Nginx のイベント駆動型モジュールであり、 select システム コールを使用してイベントを管理および処理します。

具体的には、select_module オプションは次のことを行います:

1. 有効select モジュール: このオプションを指定すると、コンパイル時に select モジュールのサポートを含めるよう Nginx に指示します。 。

2. イベント処理: select モジュールは、select システム コールを使用して複数のファイル記述子のステータスを監視し、ファイル記述子のいずれかが読み取り可能、書き込み可能、​​または読み取り可能であるかどうかを判断します。異常な出来事が起こります。これは、多数の同時接続を処理する場合に非常に役立ちます。

一般に、select モジュールは、高負荷および高同時実行のシナリオでは最適な選択ではないことに注意してください。これは、select モジュールが多数の場合に使用できるためです。ファイル記述子が大きいとパフォーマンスが制限される可能性があります。より高いパフォーマンス要件の場合、通常は、 (Linux の場合)、 など、より高度なイベント モデルの使用を選択します。 (BSD システムの場合) または は、より高い同時接続をサポートするイベント処理メカニズムです。 epollkqueuepoll

実際の使用では、オペレーティング システムとニーズに応じて、select だけでなく、適切なイベント モジュールを選択する必要がある場合があります。 Nginx はデフォルトでシステムに最適なイベント モジュールを選択しようとしますが、「 」ファミリーのオプションを明示的に指定することでコンパイル プロセスを制御できます。

要約すると、これら 2 つのオプションについて心配する必要はありません。Nginx はコンパイル時に選択し、Linux では通常、epoll 自動的に選択します。

03-004：poll_module

Nginx がオペレーティング システムなどの要素に基づいて自動的に選択を行うため、手動設定は必要ありません。

これはポイント03-003で理解できるので、ここでは紹介を省略します。

03-005：threads

手動で追加する必要があります。デフォルトでは含まれていません。

threadsNginx のコンパイル オプションの 1 つで、スレッドのサポートを有効にするために使用されます。 Nginx では、スレッド サポートは、サーバーが複数のスレッドを使用してリクエストを処理し、同時実行パフォーマンスを向上できることを意味します。

具体的には、threads オプションは次のことを行います:

1. スレッド サポートを有効にする: このオプションを指定すると、コンパイル時にスレッドのサポートを含めるよう Nginx に指示します。これにより、Nginx はオペレーティング システムが提供するスレッド メカニズムを利用してリクエストを処理できるようになります。

2. 同時処理: スレッド サポートにより、Nginx は複数のリクエストを同時に処理でき、各リクエストを独立したスレッドで実行できます。これは、特に多数の同時接続に直面した場合に、サーバーの同時実行パフォーマンスを向上させるのに役立ちます。

スレッド サポートは Nginx の比較的新しい機能であり、その動作はオペレーティング システムによって異なる場合があることに注意することが重要です。一部の従来の Nginx デプロイメントでは、通常、同時接続を処理するためにマルチスレッドではなくマルチプロセスが使用されます。マルチプロセス モデルは実装と保守が容易であり、多くの場合、Nginx の高パフォーマンス要件には十分です。

有効にするthreadsを選択した場合は、Nginx のバージョンがスレッドをサポートしており、オペレーティング システムで適切に構成されていることを確認してください。さらに、スレッド サポートの動作とパフォーマンスはオペレーティング システムと Nginx のバージョンによって影響を受ける可能性があるため、実際の展開前にテストとチューニングを行うことをお勧めします。

注: nginx-1.18.0 では、デフォルトではスレッド サポートが有効になっていません。有効にする必要がある場合は、設定時に指定する必要があります。

プロセスとスレッドの違いは何ですか?
プロセスとスレッドは、コンピュータ サイエンスにおける 2 つの重要な概念です。これらはコンピュータにおける実行の基本単位を表しますが、いくつかの重要な違いがあります。

1. 意味：

   • プロセス: プロセスは、プログラムの実行および独立した実行環境です。各プロセスには、コード、データ、システム リソースを含む独立したメモリ空間があります。
   • スレッド: スレッドはプロセス内の実行単位です。プロセスには複数のスレッドを含めることができ、これらのスレッドは同じメモリ空間とシステム リソースを共有しますが、独立した実行パスを持ちます。

2. 資源の配分：

   • プロセス: プロセスは、独自のメモリ空間、ファイル ハンドルなどを持つ独立したリソース ユニットです。プロセス間の通信には通常、プロセス間通信 (IPC) などの特別なメカニズムが必要です。
   • スレッド: スレッドはプロセス内のリソース共有単位です。複数のスレッドが同じデータとコンテキストを共有できます。スレッド間の通信は、同じアドレス空間を共有するため、比較的簡単です。

3. 作成と破棄のオーバーヘッド:

   • プロセス: プロセスの作成と破棄には比較的コストがかかります。各プロセスには、リソースの割り当てと解放が必要な独自の独立したメモリ空間があります。
   • スレッド: スレッドはプロセスのリソースを共有するため、スレッドの作成と破棄のコストが低くなります。新しいメモリ空間を割り当てて初期化する必要がないため、通常、スレッドはプロセスよりも速く作成されます。

4. 同時実行性:

   • プロセス: プロセスは独立して実行され、相互に影響しません。プロセス間通信には、メッセージ パッシングや共有メモリなどの追加メカニズムが必要です。
   • スレッド: スレッドは同じメモリ空間を共有するため、通信が容易になります。しかし同時に、競合状態やデッドロックなどの問題を回避するために、共有リソースをより慎重に扱う必要があります。

5. 安定性：

   • プロセス: プロセス間の分離性は高く、通常、1 つのプロセスがクラッシュしても他のプロセスには影響しません。
   • スレッド: スレッドは同じメモリ空間を共有するため、1 つのスレッドでエラーが発生するとプロセス全体がクラッシュする可能性があります。

一般に、プロセスとスレッドはオペレーティング システムで同時実行性を実装するために使用される 2 つの基本メカニズムであり、それぞれに適用可能なシナリオ、利点と欠点があります。プロセスまたはスレッドの使用の選択は、特定のアプリケーション要件と設計上の考慮事項によって異なります。

03-006：file-aio

手動設定は必要なく、Nginx が有効にするかどうかを自動的に決定します。

file-aioファイル非同期 I/O (AIO) サポートを有効にするために使用される Nginx 構成オプションです。 AIO を使用すると、Nginx がプロセスをブロックすることなくファイル操作を処理できるようになり、ファイルの読み取りおよび書き込みのパフォーマンスが向上します。

具体的には、file-aio オプションは次のことを行います:

1. ファイルの非同期 I/O を有効にする: このオプションを指定すると、コンパイル時にファイルの非同期 I/O のサポートを有効にするように Nginx に指示します。

2. パフォーマンスの向上: ファイルの非同期 I/O により、Nginx はファイルの読み取りおよび書き込み操作を実行するときに、これらの操作を待機することなく、非同期処理のためにオペレーティング システムに引き渡すことができます。完了する操作。これは、特に同時実行性が高い、ファイルが大きい、または負荷が重い状況で、ファイルを処理するときのサーバーのパフォーマンスを向上させるのに役立ちます。

このオプションを使用するための具体的なコマンドは次のとおりです。

./configure file-aio

ファイル非同期 I/O が利用できるかどうかは、オペレーティング システムのサポートによって異なることに注意してください。すべてのオペレーティング システムが AIO をサポートしているわけではなく、サポートのレベルは異なる場合があります。 file-aio オプションを使用する前に、Nginx の公式ドキュメントと関連するオペレーティング システムのドキュメントをチェックして、AIO が使用可能であり、お使いの環境で適用できることを確認することをお勧めします。

Nginx 1.18.0 バージョンでは、ファイル非同期 I/O (ファイル AIO) サポートがデフォルトで有効になっています。 これは、Nginx 1.18.0 をコンパイルするときに、追加のfile-aio構成オプションを必要とせずに、ファイル非同期 I/O のサポートがデフォルトで有効になることを意味します。

Nginx バージョン 1.18.0 では、ファイル非同期 I/O サポートがオペレーティング システムの機能に基づいて検出され、有効になります。オペレーティング システムがファイル非同期 I/O をサポートしており、Nginx がそのサポートを検出できる場合、ファイル非同期 I/O はデフォルトで有効になります。

03-007：http_ssl_module

これは手動で有効にする必要があり、デフォルトでは含まれていません。

これについては何も言うことはありません。SSL 証明書モジュールがデフォルトで有効になっていることを意味します。このモジュールにはシステムに OpenSSL ライブラリが必要であることに注意してください。ほとんどの Centos サーバーにはデフォルトで OpenSSL がインストールされています。たとえば、以下のコンパイル構成情報は、システムの OpenSSL ライブラリが使用されていることを示しています。

03-008：http_v2_module

これは手動で有効にする必要があり、デフォルトでは含まれていません。

http_v2_moduleHTTP/2 プロトコルのサポートを有効にするために使用される Nginx 構成オプションです。 HTTP/2 は HTTP プロトコルの次世代バージョンであり、多重化、ヘッダー圧縮など、パフォーマンスと効率がいくつか改善されています。

具体的には、http_v2_module オプションは次のことを行います:

1. HTTP/2 サポートを有効にする: このオプションを指定すると、コンパイル時に HTTP/2 プロトコルのサポートを有効にするように Nginx に指示します。

2. パフォーマンスの向上: HTTP/2 では多重化が導入され、複数のリクエストとレスポンスを 1 つの接続で同時に送信できるようになりました。これにより、特に待ち時間が長い環境や不安定なネットワーク環境において、ページ読み込みのパフォーマンスが向上します。

3. ヘッダー圧縮: HTTP/2 はヘッダー フィールドの圧縮をサポートしているため、リクエストと応答のサイズが削減され、ネットワーク送信コストが削減されます。

このオプションを使用するための具体的なコマンドは次のとおりです。

./configure http_v2_module

HTTP/2 には多くのパフォーマンス上の利点がありますが、特定のシナリオや構成では、いくつかの詳細に注意する必要がある場合があることに注意してください。たとえば、HTTP/2 では通常、HTTPS を使用した暗号化された送信が必要なため、SSL 関連のオプションの構成も必要になる場合があります。

全体として、HTTP/2 を有効にすることは、特に最新のブラウザーやネットワーク環境で Web サーバーのパフォーマンスを向上させる優れた方法です。

03-009：http_realip_module

これは手動で有効にする必要があり、デフォルトでは含まれていません。

http_realip_moduleReal IP モジュールを有効にするために使用される Nginx 構成オプションです。 Real IP モジュールを使用すると、Nginx はプロキシ サーバーの IP アドレスから取得するのではなく、リクエストのヘッダーからクライアントの実際の IP アドレスを抽出できます。

具体的には、http_realip_module オプションは次のことを行います:

1. 実際の IP アドレスを抽出する: Nginx がプロキシ サーバーの背後にある場合、通常はプロキシ サーバーの IP アドレスからクライアントの IP アドレスを取得します。 Real IP モジュールが有効になると、Nginx はリクエスト ヘッダーから実際のクライアント IP アドレスを抽出できるようになります。

2. 信頼できるプロキシ サーバーの設定: Real IP モジュールを使用すると、信頼できるプロキシ サーバーの IP アドレスを構成できます。これらのプロキシ サーバーからのリクエスト ヘッダーのみが信頼できるものとみなされ、実際の IP が抽出されます。

このオプションを使用するための具体的なコマンドは次のとおりです。

./configure http_realip_module

設定ファイルでは、実際の IP を抽出するリクエスト ヘッダーを Nginx に明確に伝えるために、real_ip_header や set_real_ip_from などのディレクティブも設定する必要があります。どのプロキシ サーバーの IP アドレスを信頼します。

構成例:

http {
    real_ip_header X-Forwarded-For;
    set_real_ip_from 192.168.1.0/24;  # 信任的代理服务器 IP 段
    # 其他配置...
}

上記の設定は、X-Forwarded-For リクエスト ヘッダーから実際の IP アドレスを抽出し、192.168.1.0/24 IP セグメント内のプロキシ サーバーのみを信頼することを意味します。

Real IP モジュールは、プロキシ サーバーの転送を処理する場合、特にリバース プロキシやロード バランシングなどのシナリオで非常に役立ちます。

当然のことながら、Nginx が第 1 レベルのプロキシである場合、このモジュールの機能は使用できません。

03-010：http_addition_module

不要なため、手動で有効にしないように指定する必要はありません。

http_addition_moduleHTTP 追加モジュールを有効にするために使用される Nginx 構成オプションです。このモジュールを使用すると、応答の本文にコンテンツを追加できます。通常は、サーバーから返されたコンテンツの後にデータを追加するために使用されます。

具体的には、http_addition_module オプションは次のことを行います:

1. コンテンツの動的な追加: HTTP 追加モジュールを使用すると、Nginx によって生成された応答コンテンツの末尾に追加のコンテンツを追加できます。このコンテンツは静的に生成することも、Nginx 変数を通じて動的に生成することもできます。

2. レスポンス処理: 通常、シナリオによっては、サーバーがレスポンスを生成した後に、返された HTML の最後に追加情報を追加するなど、レスポンスに追加情報を追加することが必要な場合があります。ページの著作権情報またはその他の注意事項。

このオプションを使用するための具体的なコマンドは次のとおりです。

./configure http_addition_module

設定ファイルでは、add_after_body ディレクティブを使用して追加する内容を指定できます。例:

location / {
    add_after_body "<p>Additional content</p>";
    # 其他配置...
}

上記の設定は、応答本文の末尾に <p>Additional content</p> を追加することを意味します。

HTTP 追加モジュールは、カスタマイズされたニーズを満たすために、Nginx によって生成された応答に追加コンテンツを動的に追加する便利な方法を提供します。

感想: あまり役に立たない気がします 通常、応答内容は HTML テンプレート内で生成されます。

03-011：http_xslt_module

不要なため、手動で有効にしないように指定する必要はありません。

http_xslt_moduleXSLT モジュールを有効にする Nginx 構成オプションです。 XSLT (Extensible Stylesheet Language Transformations) は、XML ドキュメントを他の形式に変換するために使用される言語で、通常は XML 形式の応答コンテンツを HTML または他の形式に変換するために使用されます。

具体的には、http_xslt_module オプションは次のことを行います:

1. XML 変換: XSLT モジュールを使用すると、XSL スタイルシートを提供することで、Nginx が XML 形式の応答コンテンツを別の形式 (通常は HTML) に変換できます。

2. 動的コンテンツ処理: XSLT を使用すると、Nginx で XML コンテンツを動的に処理できます。これは、一部のシナリオ、特にサーバーで生成された応答コンテンツが XML 形式である場合に役立つ場合があります。

このオプションを使用するための具体的なコマンドは次のとおりです。

./configure http_xslt_module

設定ファイルでは、xslt_stylesheet ディレクティブを使用して XSL スタイルシートへのパスを指定できます。例:

location / {
    xslt_stylesheet /path/to/style.xsl;
    # 其他配置...
}

上記の構成は、要求された XML 応答コンテンツが /path/to/style.xsl で定義された XSL スタイル シートを使用して変換されることを意味します。

XSLT は、特に大きな XML ドキュメントの場合、パフォーマンスに影響を与える可能性があるため、注意して使用する必要があることに注意することが重要です。通常は、JavaScript やブラウザー側の XSLT 処理など、より最新のフロントエンド テクノロジがより一般的です。

03-012：http_xslt_module=dynamic

不要なため、手動で有効にしないように指定する必要はありません。

http_xslt_module=dynamicXSLT モジュールを動的モジュールとしてロードできるようにする Nginx 構成オプションです。これは、XSLT モジュールが、Nginx のコンパイル時にバイナリに静的に含まれるのではなく、実行時に動的モジュールとしてロードされることを意味します。

具体的には、http_xslt_module=dynamic オプションは次のことを行います:

1. XSLT モジュールを動的にロードする: このオプションを使用すると、コンパイル時にモジュールを Nginx バイナリに静的にリンクするのではなく、実行時に XSLT モジュールを動的にロードするように Nginx に指示します。

2. 柔軟性: 動的読み込みにより、Nginx を再コンパイルせずに XSLT モジュールを追加または削除できるため、柔軟性が高まります。 Nginx 全体を再コンパイルしなくても、必要に応じてモジュールをロードまたはアンロードできます。

このオプションを使用するための具体的なコマンドは次のとおりです。

./configure http_xslt_module=dynamic

設定ファイルでは、xslt_stylesheet ディレクティブを使用して XSL スタイル シートへのパスを指定できますが、XSLT モジュールが正しくロードされているかどうかに注意する必要があります。 。

location / {
    xslt_stylesheet /path/to/style.xsl;
    # 其他配置...
}

XSLT モジュールが実行時に使用可能であること、および関連する XSL スタイルシートが正しく構成されていることを確認する必要があります。 XSLT モジュールが読み込まれていない場合は、Nginx のエラー ログで読み込みの問題に関する情報を確認してください。

03-013：http_image_filter_module - Nginx 画像処理

不要なため、手動で有効にしないように指定する必要はありません。

http_image_filter_module画像フィルター モジュールを有効にするために使用される Nginx 構成オプションです。このモジュールを使用すると、Nginx が実行時に画像に対してトリミング、回転、スケーリングなどの基本的な処理を実行できるようになります。

具体的には、http_image_filter_module オプションは次のことを行います:

1. 画像処理: 画像フィルター モジュールを使用すると、Nginx が画像サーバーとして使用されている場合に画像をリアルタイムで処理できます。特定のニーズを満たすためにさまざまな画像操作を実行するように構成できます。

2. 基本操作: 画像フィルタは、拡大縮小、回転、トリミングなどの基本的な画像処理命令を提供します。これらの操作は、HTTP リクエストのパラメーターを通じて指定できます。

このオプションを使用するための具体的なコマンドは次のとおりです。

./configure http_image_filter_module

設定ファイルでは、image_filter ディレクティブを使用してイメージ フィルタ モジュールを設定できます。例:

location /images/ {
    # 将请求的图像按照指定的参数进行处理
    image_filter resize 300 200;
    # 其他配置...
}

上記の設定は、/images/ パスの下で画像の幅が 300 ピクセル、高さが 200 ピクセルになるように画像をスケーリングすることを意味します。

画像フィルター モジュールは、画像処理のためのいくつかの基本機能を提供しますが、完全な画像処理ツールではなく、いくつかの基本機能を提供することに注意してください。より高度な画像処理機能が必要な場合は、専用の画像処理ツールまたはライブラリを使用する必要がある場合があります。

03-014：http_image_filter_module=dynamic

不要なため、手動で有効にしないように指定する必要はありません。

画像フィルターモジュールを動的にロードする

03-015：http_geoip_module

これは必要ないため、有効にしないように手動で指定する必要はありません。
実際に見てみたところ、このモジュールはデフォルトでは含まれていないことが分かりました。
モジュール http_geo_module との違いに特に注意してください。モジュール http_geo_module の詳細については、このページの 03- を参照してください。ブログ記事.036時間。

http_geoip_module は、GeoIP モジュールを有効にする Nginx 構成オプションです。 GeoIP モジュールを使用すると、Nginx はクライアントの IP アドレスに基づいて国、地域、都市などの地理的位置情報を取得し、この情報に基づいてカスタマイズされた処理を実行できます。
GeoIP モジュールを使用すると、Nginx は MaxMind の GeoIP データベースまたはその他のサポートされているデータ ソースを使用して、クライアントの IP アドレスに基づいて地理位置情報を取得できます。

しかし、残念ながら、GeoIP データベースは GeoIP2 にアップグレードされているため、このモジュールは役に立ちません。
GeoIP2 の使用については、私の他のブログ投稿を参照してください: https://blog.csdn.net/wenhao_ir/article/details/134927487< /a >]注: サーバー、アカウント、その他の情報が含まれるため、ハオ ホンジュン本人にのみ表示されます[

03-016：http_sub_module—替换响应内容

不要なため、手動で有効にしないように指定する必要はありません。

http_sub_moduleSubstitution モジュールを有効にするために使用される Nginx 構成オプションです。このモジュールを使用すると、Nginx が応答コンテンツ内の文字列置換を実行できるようになり、通常は応答本文のコンテンツをクライアントに返す前に変更するために使用されます。

具体的には、http_sub_module オプションは次のことを行います:

1. 文字列置換: 置換モジュールを使用すると、応答コンテンツ内で文字列置換を実行できます。文字列パターンを指定し、置換に使用する新しい文字列を指定できます。

2. コンテンツの変更: このモジュールを使用すると、テキストの置換やコンテンツの追加など、Nginx の応答本文を変更できます。

このオプションを使用するための具体的なコマンドは次のとおりです。

./configure http_sub_module

構成ファイルでは、sub_filter ディレクティブを使用して置換モジュールを構成できます。例:

location / {
    # 对响应体中的所有 "foo" 替换为 "bar"
    sub_filter "foo" "bar";
    
    # 设置替换规则
    sub_filter_once off;
    
    # 其他配置...
}

上記の設定は、すべての応答本文の「foo」を「bar」に置き換えることを意味します。 sub_filter_once off; 構成は、1 つだけではなく複数の置換が許可されることを意味します。

Substitution モジュールは通常、バックエンド サーバーから返される応答の内容を変更するためにリバース プロキシで使用されますが、他のシナリオでも同様に役立つ場合があります。文字列置換機能を使用する場合は、置換されたパターンや対象文字列が応答内容の正確性に影響を与えないよう注意する必要があります。

03-017：http_dav_modul

不要なため、手動で有効にしないように指定する必要はありません。

http_dav_moduleこれは、WebDAV (Web Distributed Authoring and Versioning) モジュールを有効にするための Nginx の構成オプションです。 WebDAV は、ファイルの共同編集とバージョン管理をサポートする HTTP プロトコルに基づく拡張機能です。

具体的には、http_dav_module オプションは次のことを行います:

1. WebDAV サポート: WebDAV モジュールを有効にすると、Nginx はファイルやディレクトリの作成、削除、変更などの WebDAV リクエストを処理できるようになります。

2. ファイル管理: WebDAV はリモート ファイル管理の方法を提供し、ユーザーが HTTP プロトコルを通じてリモート サーバー上のファイルを操作できるようにします。これは、Web ベースのファイル管理システムや共同編集システムを実装する場合に役立ちます。

このオプションを使用するための具体的なコマンドは次のとおりです。

./configure http_dav_module

構成ファイルでは、dav_methods ディレクティブを使用して許可される WebDAV メソッドを構成し、create_full_put_path ディレクティブを使用して WebDAV メソッドを自動的に作成するかどうかを構成できます。 PUT リクエストで指定された URL パス。

location /webdav/ {
    dav_methods PUT DELETE MKCOL COPY MOVE;
    create_full_put_path on;
    # 其他配置...
}

上記の設定は、/webdav/ パスで WebDAV を有効にし、PUT、DELETE、MKCOL、COPY、MOVE などの操作を許可し、PUT 操作の実行時に指定されたパスを自動的に作成することを意味します。

WebDAV モジュールは、Web ベースのファイル管理と共同編集を使用するアプリケーションのインフラストラクチャを提供します。 WebDAV を使用する場合は、適切なファイル管理と保護を確保するために、セキュリティとアクセス権の問題を考慮する必要がある場合があることに注意してください。

03-018：http_flv_module

必要な場合がありますが、デフォルトでは含まれていないため、手動で指定します。

http_flv_moduleこれは、FLV (Flash Video) モジュールを有効にするために使用される Nginx 構成オプションです。このモジュールを使用すると、Nginx が FLV ファイルを処理するときに基本的なストリーミング サポートを提供できるようになり、Flash プレーヤーをサポートする環境で FLV ビデオを再生できるようになります。

具体的には、http_flv_module オプションは次のことを行います:

1. FLV サポート: FLV モジュールを有効にすると、Nginx は FLV ファイルを静的ファイルとしてクライアントに渡すだけでなく、直接処理できるようになります。

2. ストリーミング メディアの再生: FLV モジュールは、Nginx がストリーミング メディア環境で FLV ビデオ再生サポートを提供できるようにするいくつかの機能を提供します。これは、Web ページ上で Flash Player を使用して FLV ファイルを再生する場合に便利です。

このオプションを使用するための具体的なコマンドは次のとおりです。

./configure http_flv_module

設定ファイルでは、location ディレクティブを使用して FLV モジュールの動作を設定できます。例:

location /videos/ {
    flv;
    # 其他配置...
}

上記の設定は、/videos/ パスで FLV モジュールを有効にすることを意味します。

Flash プレーヤーの使用が減少し、HTML5 によって提供されるより高度なビデオ再生サポートが提供されるため、最新の環境での FLV モジュールの使用にはいくつかの制限がある可能性があることに注意してください。より広範囲のビデオ形式と再生方法をサポートする必要がある場合は、HTML5 video タグなどの最新テクノロジーの使用を検討することをお勧めします。

03-019：http_mp4_module

これは必須であるため、デフォルトでは含まれていないため、手動で有効にする必要があります。

http_mp4_moduleMP4 モジュールを有効にするために使用される Nginx 構成オプションです。このモジュールを使用すると、Nginx が MP4 ファイルを直接処理できるようになり、ブラウザで MP4 ビデオを再生するための基本的なストリーミング機能がサポートされます。

具体的には、http_mp4_module オプションは次のことを行います:

1. MP4 サポート: MP4 モジュールを有効にすると、Nginx は MP4 ファイルを静的ファイルとしてクライアントに渡すのではなく、直接処理できるようになります。

2. ストリーミング メディアの再生: MP4 モジュールは、Nginx がストリーミング メディア環境で MP4 ビデオ再生サポートを提供できるようにするいくつかの機能を提供します。これは、HTML5 プレーヤーなどを使用して Web ページ上で MP4 ファイルを再生する場合に便利です。

このオプションを使用するための具体的なコマンドは次のとおりです。

./configure http_mp4_module

設定ファイルでは、location ディレクティブを使用して MP4 モジュールの動作を設定できます。例:

location /videos/ {
    mp4;
    # 其他配置...
}

上記の設定は、/videos/ パスで MP4 モジュールを有効にすることを意味します。

03-020：http_gunzip_module

これは必須であるため、デフォルトでは含まれていないため、手動で有効にする必要があります。

http_gunzip_moduleGzip モジュールでの解凍を有効にする Nginx 構成オプションです。このモジュールを使用すると、Nginx が Gzip 圧縮されたコンテンツを含むリクエストを解凍できるようになり、クライアントからリクエストを受信したときに処理できるようになります。

具体的には、http_gunzip_module オプションは次のことを行います:

1. クライアント リクエストの解凍のサポート: Gzip モジュールで解凍機能を有効にすると、Nginx は Gzip 圧縮コンテンツを含むクライアント リクエストを処理し、リクエスト本文を自動的に解凍して、サーバーが処理できるようにします。通常通り解凍されたデータです。

2. パフォーマンスの向上: 場合によっては、クライアントは Gzip を使用してリクエスト本文を圧縮し、転送されるデータ量を削減することがあります。解凍を有効にすると、Nginx はそのようなリクエストを処理する際のパフォーマンスを向上させることができます。

このオプションを使用するための具体的なコマンドは次のとおりです。

./configure http_gunzip_module

通常、構成ファイルで解凍を有効にするために追加の構成は必要ありません。 http_gunzip_module を有効にすると、Nginx は Gzip 圧縮されたコンテンツを含むクライアント リクエストの解凍を自動的に試みます。

server {
    listen 80;
    server_name example.com;

    location / {
        # 其他配置...
    }
}

上記の構成では、location / の追加構成は、Gzip 圧縮コンテンツを含むクライアント リクエストを自動的に処理します。

解凍機能はパフォーマンスを向上させることができますが、注意すべき潜在的なセキュリティ リスクがあるため、使用する場合は慎重に評価する必要があることに注意してください。

03-021：http_gzip_static_module

これは必須であるため、デフォルトでは含まれていないため、手動で有効にする必要があります。

http_gzip_static_moduleGzip モジュールで静的ファイル圧縮を有効にするために使用される Nginx 構成オプションです。このモジュールを使用すると、Nginx がサーバー側で静的ファイルを Gzip 圧縮して、ファイル転送サイズを削減し、ページ読み込みパフォーマンスを向上させることができます。

具体的には、http_gzip_static_module オプションは次のことを行います:

1. 静的ファイル圧縮: Gzip モジュールで静的ファイル圧縮機能を有効にすると、Nginx は静的ファイル (CSS、JavaScript、HTML など) を転送できるようになります。サーバーは次のことを実行します。 Gzip 圧縮してクライアントに送信します。

2. 転送サイズの削減: Gzip 圧縮により、特にネットワーク帯域幅が制限されている場合に、ファイル転送サイズが大幅に削減され、ページの読み込み速度が向上します。

このオプションを使用するための具体的なコマンドは次のとおりです。

./configure http_gzip_static_module

設定ファイルでgzip_static ディレクティブを使用して、静的ファイルの Gzip 圧縮を有効にできます。例:

http {
    gzip_static on;
    
    server {
        listen 80;
        server_name example.com;

        location /static/ {
            # 针对 /static/ 路径下的静态文件启用 Gzip 压缩
            gzip_static on;

            # 其他配置...
        }

        # 其他 server 配置...
    }
}

上記の設定では、gzip_static on; により静的ファイルの Gzip 圧縮が有効になり、location /static/ の下のファイルは設定に従って Gzip 圧縮されて送信されます。お客様への連絡は終了です。

静的ファイルの Gzip 圧縮を使用すると、ページの読み込みパフォーマンスが大幅に向上しますが、リアルタイム圧縮によるパフォーマンスのオーバーヘッドを避けるために、圧縮された静的ファイルがサーバー側に保存されていることを確認する必要があります。

感想: ブラウザ側で表示される静的ファイルのサイズが実際の静的ファイルのサイズより小さいのは、転送処理中に gzip 圧縮が有効になっているためです。

03-022:http_auth_request_module - 認証機能モジュール

不要なため、手動で有効にしないように指定する必要はありません。

http_auth_request_moduleAuth Request モジュールを有効にするために使用される Nginx 構成オプションです。このモジュールを使用すると、Nginx はアクセス制御を実行するときに認証リクエストを他のサービスまたはプログラムに委任できるため、より柔軟な認証メカニズムが実現します。

具体的には、http_auth_request_module オプションは次のことを行います:

1. 動的認証: Auth Request モジュールを使用すると、Nginx がユーザーの認証を担当する他のサービスまたはプログラムに認証リクエストを送信できるようになります。これにより、Nginx の組み込み基本認証やその他の認証モジュールにのみ依存するのではなく、カスタム認証ロジックを使用できるようになります。

2. 柔軟性: 認証リクエストを委任すると、OAuth 認証、LDAP、HTTP リクエストなどのさまざまな外部認証サービスを使用できるようになります。これにより、さまざまな認証ニーズに柔軟に対応できるようになります。

このオプションを使用するための具体的なコマンドは次のとおりです。

./configure http_auth_request_module

設定ファイルでは、location ディレクティブを使用して認証リクエスト モジュールを設定できます。例:

location /protected/ {
    # 发送身份验证请求到 /auth/check，由该服务进行身份验证
    auth_request /auth/check;

    # 如果身份验证成功，允许访问
    auth_request_set $auth_status $upstream_status;
    if ($auth_status = 200) {
        # 允许访问
        proxy_pass http://backend;
    }

    # 如果身份验证失败，返回 403 Forbidden
    deny all;
}

location = /auth/check {
    # 身份验证服务的配置，例如向其他服务发起身份验证请求
    # ...

    # 返回身份验证结果，200 表示验证成功，其他代码表示验证失败
    return 200;
}

上記の構成では、location /protected/ でのアクセスにより認証リクエスト モジュールがトリガーされ、認証リクエストが /auth/check パスに送信されます。認証が成功した場合 (return 200;) はアクセスが許可されますが、そうでない場合は 403 Forbidden が返されます。 /auth/check パスに対応する設定は一例であり、実際の状況に応じて具体的な認証サービスを設定する必要があります。

03-023：http_random_index_module

不要なため、手動で有効にしないように指定する必要はありません。

http_random_index_moduleRandom Index モジュールを有効にするために使用される Nginx 構成オプションです。このモジュールを使用すると、Nginx はディレクトリにアクセスするときに、従来のインデックス ファイル (index.html など) を使用する代わりに、インデックス ファイルとしてファイルをランダムに選択できます。

具体的には、http_random_index_module オプションは次のことを行います:

1. ランダム インデックス ファイル: ランダム インデックス モジュールを有効にした後、クライアントが明示的なインデックス ファイルを指定せずにディレクトリへのアクセスをリクエストすると、Nginx はディレクトリからファイルをランダムに選択します。インデックス ファイルとしてクライアントに返されます。

2. 柔軟性: これにより、固定インデックス ファイルを使用するのではなく、ディレクトリの内容を表示するより柔軟な方法が提供されます。これは、ディレクトリ内のランダムな画像、ファイルなどを表示するなど、一部のシナリオで役立つ場合があります。

このオプションを使用するための具体的なコマンドは次のとおりです。

./configure http_random_index_module

構成ファイルで、random_index ディレクティブを使用して、ランダム インデックス モジュールを有効にし、処理する必要があるファイルの種類を指定できます。例:

location /images/ {
    # 在 /images/ 路径下启用 Random Index 模块
    random_index on;
    
    # 其他配置...
}

上記の構成は、/images/ パスでランダム インデックス モジュールが有効になっていることを示しており、Nginx はこのディレクトリ内のファイルをランダムに選択し、インデックス ファイルとしてクライアントに返します。

ランダム インデックス ファイルの使用は、特に表示順序を制御する必要がある場合には、すべてのシナリオに適しているわけではないことに注意してください。一部のアプリケーション シナリオでは、index.html などの固定インデックス ファイルを使用する方が一般的です。

03-024：http_secure_link_module

不要なため、手動で有効にしないように指定する必要はありません。

http_secure_link_moduleSecure Link モジュールを有効にするために使用される Nginx 構成オプションです。 Secure Link モジュールは、リソースを不正アクセスから保護するための URL ベースのセキュリティ メカニズムを提供します。

具体的には、http_secure_link_module オプションは次のことを行います:

1. URL セキュリティ: Secure Link モジュールは、有効な署名を持つリクエストのみがリソースにアクセスできるように、署名を含む URL を作成するために使用されます。これにより、不正なアクセスやリンクの悪用が防止されます。

2. リソース保護: 安全なリンクを使用すると、署名アルゴリズムとキーを知っているクライアントのみが有効なリンクを生成できるようになり、機密リソースを不正アクセスから保護できます。

このオプションを使用するための具体的なコマンドは次のとおりです。

./configure http_secure_link_module

設定ファイルでは、secure_link ディレクティブを使用して Secure Link モジュールの動作を設定できます。例:

location /secure/ {
    # 启用 Secure Link 模块
    secure_link $arg_md5,$arg_expires;

    # 配置密钥和有效期
    secure_link_md5 "secretkey$uri$arg_expires";
    secure_link_expires +1m;

    # 其他配置...
}

上記の設定では、secure_link によって Secure Link モジュールが有効になり、署名パラメータ ($arg_md5 および $arg_expires) が設定されました。 。 secure_link_md5 ディレクティブは、キーと URI を使用して署名アルゴリズムを構成します。 secure_link_expires ディレクティブは、リンクの有効期間を構成します。

クライアントが /secure/ パスにアクセスするときは、有効な署名とタイムスタンプのパラメータを指定する必要があります。指定しないと、リソースにアクセスできません。

Secure Link モジュールは基本的なセキュリティ メカニズムを提供しますが、高度なセキュリティ要件がある一部のシナリオでは、他のより複雑なセキュリティ メカニズムと認証方法を考慮する必要がある場合があることに注意してください。

03-025:http_degradation_module - Nginx によるサーバー メモリの過剰使用を防止

http_degradation_moduleこのモジュールは、Nginx によるサーバー メモリの過剰な使用を制限するために使用され、Nginx によるサーバーのメモリ使用量が特定の値を超えた場合、204 または 404 ページを返すなどの過剰なリクエストを制限します。

このモジュールのソース コード リンク:
https://github.com/chronolaw/annotated_nginx/blob/master/nginx/src/http/modules/ngx_http_degradation_module.c

Guardian GodとNginxをインストールした後のCentos7.9の無負荷時のメモリ使用量は以下の通りです。

それの使い方：

①httpモジュールに以下のコードを記述します。

    # 限制内存最大使用为500M
    degradation sbrk=500m;

sbrk: は「set Break」の略で、通常はメモリ管理など、プロセスのアドレス空間を管理するために使用されるシステム コールを指します。この文脈では、Nginx のメモリ使用量が 500M を超えた場合、Nginx がより多くのメモリを占有し続けるように制限することを意味します。

500m: これは、Nginx で許可される最大メモリ サイズを示すパラメータです。ここで、500m は、500 メガバイトのメモリ制限が設定されていることを意味します。

②サーバーモジュールに以下のコードを記述します。

    location / {
    
    
		# 当系统资源使用达到90%时启用Degradation 模块,防止服务器过载
		degrade 204;
	}

上記のコードは、Nginx が 500M を超えるメモリを使用すると、204 ページを返すことを示しています。

03-026：http_slice_module

不要なため、手動で有効にしないように指定する必要はありません。

http_slice_moduleSlice モジュールを有効にするために使用される Nginx 構成オプションです。 Slice モジュールを使用すると、クライアントのリクエストを複数のスライスに分割し、サーバーがこれらのスライスを異なる時間または並行して処理できるようになり、リクエストの同時処理能力が向上します。

具体的には、http_slice_module オプションは次のことを行います:

1. リクエスト スライス: スライス モジュールを使用すると、大きなクライアント リクエストを複数のフラグメントに分割できます。これは、大きなファイルのアップロードや大規模なデータ ストリームを処理する場合に役立ちます。

2. 同時処理: セグメント化されたリクエスト フラグメントはサーバー上で同時に処理できるため、リクエスト処理機能が向上します。リクエスト全体の転送が完了するのを待たずに、各フラグメントを独立して処理できます。

このオプションを使用するための具体的なコマンドは次のとおりです。

./configure http_slice_module

設定ファイルでは、slice ディレクティブを使用してスライス モジュールの動作を設定できます。例:

location /upload {
    # 启用 Slice 模块
    slice;
    
    # 设置切片大小
    slice_size 1m;

    # 其他配置...
}

上記の設定では、slice; によってスライス モジュールが有効になり、slice_size によってスライス サイズが 1 MB に設定されます。クライアントは大きなファイルを 1 MB のチャンクにアップロードでき、サーバーはこれらのチャンクを同時に処理できます。

Slice モジュールは通常、大きなファイルのアップロードや大きなデータ ストリームを処理するために使用されます。 Slice モジュールを使用する場合、クライアントは、要求されたスライス範囲を指定するために Range ヘッダーをサポートし、送信する必要があることに注意してください。

03-027：http_stub_status_module-Nginx 実行ステータス監視ページ

必要な場合がありますが、デフォルトでは含まれていないため、手動で指定します。

http_stub_status_moduleスタブ ステータス モジュールを有効にするために使用される Nginx 構成オプションです。スタブ ステータス モジュールは、基本的なパフォーマンス インジケーターと Nginx サーバーの実行ステータスを監視するためのシンプルなページを提供します。

具体的には、http_stub_status_module オプションは次のことを行います:

1. パフォーマンス モニタリング: スタブ ステータス モジュールを使用すると、HTTP リクエストを通じて、接続数、リクエスト処理、リクエスト数などの Nginx サーバーのパフォーマンス インジケータを取得できます。各種ステータスコードなど

2. ステータス情報: [スタブ ステータス] ページにアクセスして、パフォーマンスの調整と監視のための Nginx ワーカー プロセスに関するステータス情報を取得します。

このオプションを使用するための具体的なコマンドは次のとおりです。

./configure http_stub_status_module

設定ファイルでは、location ディレクティブを使用して、スタブ ステータス モジュールのページ アクセス パスを設定できます。例:

server {
    listen 80;
    server_name example.com;

    location /nginx_status {
        # 启用 Stub Status 模块
        stub_status;
        
        # 允许指定 IP 地址访问 Stub Status 页面
        allow 127.0.0.1;
        deny all;
        
        # 其他配置...
    }

    # 其他 server 配置...
}

上記の設定ではlocation /nginx_status、スタブ ステータス モジュールを有効にし、ページへのアクセスを許可する IP アドレスを設定しました。 Nginx の基本的なパフォーマンス情報は、http://example.com/nginx_status にアクセスして取得できます。

[スタブ ステータス] ページのサンプル出力には、次の情報が含まれる場合があります。

Active connections: 10
server accepts handled requests
 10 10 10
Reading: 0 Writing: 1 Waiting: 9

この情報は、現在の接続数、リクエスト処理、読み取り、書き込み、待機ステータスに関する情報を提供します。これらの指標を監視して、サーバーの負荷とパフォーマンスを理解できます。運用環境では、情報漏洩を防ぐために、[スタブ ステータス] ページへのアクセスを慎重に設定する必要があることに注意してください。

03-028：http_charset_module

不要なため、手動で有効にしないように指定する必要はありません。

http_charset_module は Nginx のモジュールで、文字セット (Charset) 関連の設定を処理するために使用されます。具体的には、http_charset_module は主に、クライアントがテキスト コンテンツを正しく解析して表示できるように、サーバー応答の文字セット情報を構成するために使用されます。

http_charset_module の主な機能は次のとおりです。

1. 文字セット構成: では、サーバー応答の文字セットを構成して、テキスト コンテンツが正しい文字セットでクライアントに配信されるようにすることができます。

2. 文字セットの自動検出: サーバーがテキスト ファイルの文字セットを自動的に検出し、応答で指定するように自動文字セット検出を有効にできます。これは、複数の文字セットを受け取る多言語 Web サイトやテキスト ファイルを操作する場合に便利です。

http_charset_module を使用した構成例は次のとおりです。

http {
    charset utf-8;  # 设置默认字符集为 UTF-8

    server {
        listen 80;
        server_name example.com;

        location / {
            # 允许自动检测字符集
            charset_types text/plain text/html;
            
            # 其他配置...
        }
    }
}

上の例では:

• charset utf-8;デフォルトの文字セットは UTF-8 として設定されています。
• charset_types text/plain text/html; 文字セットの自動検出が可能なファイルの種類には、プレーン テキスト (text/plain) と HTML (text/html) が含まれます。

この構成の後、Nginx はContent-Type ヘッダーを応答に追加し、クライアントがテキスト コンテンツを正しく解析して表示できるように、対応する文字セット情報を指定します。文字セット設定は、Web サイトがさまざまなロケールでテキスト コンテンツを正しく表示するために重要です。

03-029：http_gzip_module

このモジュールは非常に特殊です。デフォルトでコンパイルされたターゲット ファイルに次のモジュールが含まれているからです。

objs/src/http/modules/ngx_http_gzip_filter_module.o

聞いてみると、ngx_http_gzip_filter_module は実際には http_gzip_module です この問題の原因は、nginx の設定ファイル内の名前がターゲット ファイルの名前と異なる可能性があるためです。

したがって、このモジュールをここに表示して含める必要はありません。

http_gzip_moduleこれは、HTTP 応答のコンテンツの Gzip 圧縮を実装するために使用される Nginx のモジュールです。 Gzip 圧縮は、特に HTML、CSS、JavaScript などのテキスト コンテンツのファイル サイズを削減し、転送速度を向上させるために使用されるテクノロジです。

http_gzip_module の主な機能は次のとおりです。

1. コンテンツ圧縮: Gzip 圧縮により、転送されるファイルのサイズが大幅に削減され、ネットワーク転送時間と帯域幅の消費が削減されます。

2. ネットワーク パフォーマンス: ファイルを圧縮すると、クライアントがリソースをダウンロードするのに必要な時間が短縮されるため、ページの読み込み速度が向上し、ユーザーの待ち時間が短縮され、ユーザー エクスペリエンスが向上します。

http_gzip_module を使用した構成例は次のとおりです。

http {
    gzip on;  # 启用 Gzip 压缩
    gzip_types text/plain text/css application/json application/javascript application/xml;  # 指定需要压缩的文件类型

    server {
        listen 80;
        server_name example.com;

        location / {
            # 其他配置...
        }
    }
}

上の例では:

• gzip on;Gzip圧縮が有効になっています。
• gzip_typestext/plain、text/css、application/json など、Gzip 圧縮が必要なファイルの種類を指定します。

この構成の後、Nginx は各応答の Content-Type をチェックし、構成されたファイル タイプに対して Gzip 圧縮を実行します。クライアントが Gzip 圧縮をサポートしている場合、サーバーは圧縮されたコンテンツをクライアントに送信します。

注: Gzip 圧縮によりパフォーマンスは向上しますが、サーバーとクライアントの間で圧縮と解凍の操作も必要となり、追加の CPU オーバーヘッドが発生する可能性があります。したがって、圧縮によるパフォーマンスの向上とサーバー リソースの消費を比較検討する必要があります。

注: モジュール http_gzip_static_module は、静的ファイルの gzip 圧縮のみを有効にします。

03-030：http_ssi_module

不要なため、手動で有効にしないように指定する必要はありません。

http_ssi_moduleサーバーサイド インクルード (SSI) 機能を処理する Nginx のモジュールです。 SSI を使用すると、動的コンテンツを HTML ページに埋め込むことができ、サーバー側で生成されたデータでページを更新できるようになります。

http_ssi_module の主な機能は次のとおりです。

1. 動的コンテンツの埋め込み: SSI を使用すると、動的に生成されたコンテンツを HTML ページに挿入でき、ページを動的に更新できます。

2. テンプレート エンジン: SSI は、HTML ページに特別な命令を挿入することによって、動的データを静的ページに埋め込む単純なテンプレート エンジンと考えることができます。

3. モジュール ディレクティブ: は、HTML ページに他のファイルのコンテンツを含めるための <!--#include --> や < a i=3 などのディレクティブを提供します。 > は出力変数に使用されます。 <!--#echo -->

http_ssi_module を使用した構成例は次のとおりです。

http {
    ssi on;  # 启用 SSI 模块

    server {
        listen 80;
        server_name example.com;

        location / {
            root /path/to/your/html/files;
            index index.html;

            # 允许 SSI 处理 HTML 文件
            ssi_types text/html;

            # 其他配置...
        }
    }
}

上の例では:

• ssi on;SSI モジュールが有効になっています。
• ssi_types text/html;HTML ファイルの SSI 処理を指定します。

次に、HTML ファイル内で SSI ディレクティブを使用して動的コンテンツを挿入できます。例えば：

<!DOCTYPE html>
<html lang="en">
<head>
    <meta charset="UTF-8">
    <meta name="viewport" content="width=device-width, initial-scale=1.0">
    <title>SSI Example</title>
</head>
<body>
    <h1>Hello, <!--#echo var="REMOTE_ADDR" -->!</h1>
    <p>The current time is: <!--#echo var="DATE_LOCAL" --></p>
</body>
</html>

上記の HTML ファイルでは、<!--#echo var="REMOTE_ADDR" --> はクライアントの IP アドレスを出力するために使用され、<!--#echo var="DATE_LOCAL" --> はサーバーの現地時間を出力するために使用されます。この動的コンテンツは、ページの読み込み時にサーバー側によって生成され、置き換えられます。

03-031：http_userid_module

不要なため、手動で有効にしないように指定する必要はありません。

http_userid_moduleNginx のモジュールであり、ユーザー ID (User ID) 関連の機能を処理するために使用されます。主な機能はリクエストのユーザー ID を追加または変更することであり、構成を通じてカスタマイズできます。

http_userid_module の主な機能は次のとおりです。

1. ユーザー ID: ユーザー リクエストのユーザー ID を追加または変更できます。ユーザーのアクセスや行動を追跡するためによく使用されます。

2. Cookie 設定: Cookie を設定してユーザー ID を保存し、ユーザーが後続のリクエストでその ID を使用できるようにすることができます。

3. 柔軟な設定: には一連の設定項目があり、必要に応じてユーザー ID の生成ルールや有効期限などをカスタマイズできます。

http_userid_module を使用した構成例は次のとおりです。

http {
    userid on;  # 启用 User ID 模块

    server {
        listen 80;
        server_name example.com;

        location / {
            # 允许 User ID 处理
            userid_mode transparent;

            # 设置 Cookie 名称和过期时间
            userid_name my_user_id;
            userid_expires 30d;

            # 其他配置...
        }
    }
}

上の例では:

• userid on;ユーザー ID モジュールが有効になりました。
• userid_mode transparent;ユーザー ID モジュールの処理モードを透過モードに設定します。つまり、ユーザー ID をリクエストに追加します。
• userid_name my_user_id; は my_user_id という名前の Cookie を設定します。
• userid_expires 30d;Cookie の有効期限は 30 日に設定されています。

この構成の後、ユーザーがサーバーにアクセスすると、Nginx はユーザー ID を生成し、Cookie を設定することによってクライアントにそれを保存します。後続のリクエストでは、クライアントはこの Cookie を保持し、サーバーはこのユーザー ID に基づいてユーザーを識別できます。

ユーザー ID の使用は、ユーザーのプライバシーを確​​実に保護するために、プライバシー ポリシーおよび関連規制に準拠する必要があることに注意してください。

http_userid_module モジュールが有効になっていない場合、Django は Cookie を処理できますか?
はい、Django 自体は、Nginx の http_userid_module モジュールが有効になっていない場合でも Cookie を処理できます。 Django フレームワークには、Nginx モジュールに依存せずにユーザー セッションと Cookie を処理するための関数が組み込まれています。

Django では、Django のrequest オブジェクトを使用して Cookie を読み取り、設定できます。簡単な例を次に示します。

from django.http import HttpResponse

def set_cookie(request):
    # 设置 Cookie
    response = HttpResponse("Cookie set!")
    response.set_cookie('my_cookie', 'cookie_value', max_age=3600)  # 设置过期时间为 1 小时
    return response

def get_cookie(request):
    # 读取 Cookie
    my_cookie_value = request.COOKIES.get('my_cookie', 'default_value')
    return HttpResponse(f"Value of my_cookie: {
      
      my_cookie_value}")

上の例では:

• set_cookie ビューは、 my_cookie という名前の Cookie を、 'cookie_value' の値と 1 時間の有効期限で設定します。
• get_cookie ビューは、my_cookie という名前の Cookie の値を読み取ります。

クライアントは、Django の URL マッピング メカニズムを通じてこれらのビューにアクセスできます。独自のニーズに応じて、パス、ドメイン、セキュリティ フラグなどの設定を含む、より複雑な Cookie 操作を実行できます。ただし、Cookie を使用する場合はプライバシーとセキュリティに注意し、関連する規制とベスト プラクティスを確実に遵守してください。

03-032：http_access_module

このモジュールはデフォルトで Nginx に含まれていますが、実際の名前は「ngx_http_access_module.o」です。
IP ホワイトリストとブラックリストを設定する必要があります。

03-033:http_auth_basic_modul - 保護されたリソースにユーザー名とパスワードを追加します

不要なため、手動で有効にしないように指定する必要はありません。

http_auth_basic_moduleこれは、HTTP Basic 認証を有効にするために使用される Nginx のモジュールです。 HTTP 基本認証は、保護されたリソースにアクセスするときにユーザーにユーザー名とパスワードの入力を要求する単純な認証メカニズムです。この情報は Base64 エンコードで送信されるため、安全でない接続を介したパスワードの送信には適していません。

http_auth_basic_module の主な機能は次のとおりです。

1. 認証: HTTP 基本認証を有効にします。これにより、ユーザーは保護されたリソースにアクセスするために有効なユーザー名とパスワードを入力する必要があります。

2. 簡単な設定: は、認証レルム (レルム) の名前とユーザー パスワード ファイルの場所を指定するための簡単な設定オプションを提供します。

http_auth_basic_module を使用した構成例は次のとおりです。

server {
    listen 80;
    server_name example.com;

    location / {
        auth_basic "Restricted Access";  # 设置认证领域的名称
        auth_basic_user_file /etc/nginx/.htpasswd;  # 指定用户密码文件的位置
        # 其他配置...
    }
}

上の例では:

• auth_basic "Restricted Access";認証レルムの名前は「制限付きアクセス」に設定されます。これは、ポップアップ認証プロンプト ボックスにユーザーに表示されるテキストです。

• auth_basic_user_file /etc/nginx/.htpasswd; は、ユーザー名とパスワードを含むパスワード ファイルの場所を指定します。パスワード ファイルの形式は username:encrypted_password です。 htpasswd コマンドを使用してこのようなファイルを生成し、パスワードのセキュリティを確保できます。

実際のアプリケーションでは、セキュリティを強化するために、HTTPS を使用してユーザー名とパスワードの送信を暗号化することをお勧めします。さらに、パスワード ファイルを定期的に更新し、強力なパスワード ポリシーを使用してユーザー パスワードのセキュリティを確保します。

03-034:http_mirror_module - 開発テストのためにクライアント リクエストを同時にミラー サーバーに転送します

不要なため、手動で有効にしないように指定する必要はありません。

http_mirror_moduleこれは Nginx のモジュールであり、クライアントから要求されたデータを指定されたサーバーにミラーリングするミラー サーバーをセットアップするために使用されます。このモジュールは通常、テスト、監視、またはその他の目的で実稼働環境でイメージのコピーを作成するために使用されます。

http_mirror_module の主な機能は次のとおりです。

1. リクエスト ミラーリング: クライアントのリクエスト データを 1 つ以上の指定されたサーバーにミラーリングし、これらのサーバーが同じリクエストを受信できるようにします。

2. 複数の用途: 監視、テスト、負荷分散シナリオで使用して、運用環境に影響を与えることなくリクエストの動作を観察できます。

http_mirror_module を使用した構成例は次のとおりです。

location / {
    mirror /mirror;
    # 其他配置...
}

location /mirror {
    internal;
    proxy_pass http://mirror_backend;
    # 其他配置...
}

上の例では:

• location /mirror ディレクティブは、クライアントによって要求されたデータを /mirror パスにミラーリングするために で使用されます。

• location /mirror は、ミラー サーバーのアドレスである proxy_pass を介してミラーリング リクエストを mirror_backend に転送します。

この構成の後、クライアントがメイン サーバーにリクエストを送信すると、リクエストされたデータは /mirror パスにミラーリングされ、proxy_pass に転送されます。 mirror_backend サーバー。

/mirror パスは通常、internal キーワードでマークされ、マスター サーバーのみがこのパスにリクエストを内部的に転送できるようにすることに注意してください。これは、ミラー要求が外部クライアントによって直接アクセスされないようにするのに役立ちます。

03-035:http_autoindex_module - ディレクトリ内にファイル リストを自動的に生成します

不要なため、手動で有効にしないように指定する必要はありません。

http_autoindex_module は、ディレクトリ インデックスを自動生成するために使用される Nginx のモジュールです。特定のファイルを指定せずにディレクトリにアクセスする場合、Nginx は http_autoindex_module を使用してディレクトリのファイル リストを自動的に生成し、ユーザーがコンテンツを参照してアクセスできるようにします。

http_autoindex_module の主な機能は次のとおりです。

1. ディレクトリ インデックス: ユーザーがブラウザを通じてディレクトリ内のファイルにアクセスできるように、ディレクトリのファイル リストを自動的に生成します。

2. カスタマイズ: 一連の設定オプションを提供し、スタイル、列数、並べ替え方法など、ディレクトリ インデックスの表示方法をカスタマイズできます。

http_autoindex_module を使用した構成例は次のとおりです。

server {
    listen 80;
    server_name example.com;

    location / {
        autoindex on;  # 启用目录索引

        # 其他配置...
    }
}

上記の例では、autoindex on; ではディレクトリのインデックス作成が有効になっています。特定のファイルではなくディレクトリにアクセスすると、Nginx はそのディレクトリのファイル リストを自動的に生成します。

autoindex ディレクティブの他の構成オプションを使用してカスタマイズすることもできます。例:

location / {
    autoindex on;  # 启用目录索引
    autoindex_exact_size off;  # 显示文件大小的约数而非精确值
    autoindex_localtime on;  # 使用本地时间而非 UTC 时间
    autoindex_header 1;  # 显示表头信息
    autoindex_columns 3;  # 指定列数
    autoindex_ignore "*.log";  # 忽略特定文件
    # 其他配置...
}

これらのオプションを使用すると、特定のニーズに合わせてディレクトリ インデックスの外観と動作を調整できます。自動生成されたカタログ インデックスは機密情報を明らかにする可能性があるため、運用環境では注意して使用する必要があることに注意してください。

03-036：http_geo_module

このモジュールもデフォルトで含まれており、含まれている場合は geo コマンドを使用できます。

configure help コマンドでの名前は http_geo_module ですが、最終的にコンパイルされるターゲット ファイルの名前は実際には ngx_http_geo_module.o であることに注意してください。私はそれを測定しました。このモジュールを含めたくない場合は、次のコマンドが必要です:

--without-http_geo_module

これは、コンパイルされたターゲット ファイルの名前と、configure で使用されるモジュール名が異なる可能性があることを完全に示しています。

このモジュールとモジュールの違いに注意してくださいhttp_geoip_module。モジュールhttp_geoip_moduleの概要については、このブログ投稿のポイント 03-015 の概要を参照してください。

Q: Nginx の geo コマンドを導入できますか?
Nginx 構成ファイルで geo ディレクティブを使用する場合、クライアントの IP アドレスまたは他の変数の値に基づいて一連の条件を定義し、以下の条件で実行できます。これらの条件に対応する操作。 geo モジュールを使用すると、クライアントの IP アドレスまたはその他の特定の値に基づく値を持つ一連の変数を作成できます。

次に、geo ディレクティブの基本構文を示します。

geo $variable {
    default value;
    CIDR_range value;
    CIDR_range value;
    ...
}

• $variable: IP アドレスまたはその他の値を保存するために使用される変数を定義します。
• default value：一致する条件が見つからなかった場合のデフォルト値を指定します。
• CIDR_range: CIDR 範囲を定義します。クライアントの IP アドレスがこの範囲に一致する場合、対応する値が使用されます。

次に、geo ディレクティブの使用方法を示す簡単な例を示します。

http {
    geo $my_country {
        default ZZ; # 默认值为 ZZ

        192.168.1.0/24 US; # 如果客户端IP在这个范围内，$my_country的值为 US
        10.0.0.0/8    AU; # 如果客户端IP在这个范围内，$my_country的值为 AU
    }

    server {
        location / {
            # 使用$my_country变量进行条件判断
            if ($my_country = US) {
                return 301 http://www.example-us.com;
            }

            if ($my_country = AU) {
                return 301 http://www.example-au.com;
            }

            # 默认情况下，重定向到一个通用站点
            return 301 http://www.example-global.com;
        }
    }
}

この例では、クライアントの IP アドレスに基づいて、$my_country 変数の値が対応する国コードに設定されます。次に、if ステートメントを通じてこの変数の値を確認し、対応する操作を実行します。 if ステートメントを使用すると、望ましくない問題が発生する可能性があるため、注意して使用してください。

geo ディレクティブは、異なる IP 範囲に基づいて異なるサービスやコンテンツを提供するなど、より複雑な条件判断に使用できます。
次に、負荷分散のための geo ディレクティブの使用例を示します。
Nginx の geo モジュールとその使用方法負荷分散を構成するには

03-037：http_map_module

不要なため、手動で有効にしないように指定する必要はありません。

http_map_moduleこれは、ある値を別の値にマッピングするマッピング関係を作成するために使用される Nginx のモジュールです。これは、構成ファイルでマッピング ルールを定義し、これらのマッピングを Nginx の他の場所で使用するための、シンプルかつ強力なメカニズムを提供します。

http_map_module の主な機能は次のとおりです。

1. 値のマッピング: では、ある値を別の値にマッピングできます。これを使用して、リクエストの処理中に変数の値を変換、名前変更、または変更できます。

2. 条件一致: マッピングは条件一致に基づくことができ、リクエストの特定の属性に基づいてマッピングを選択できます。

http_map_module を使用した構成例は次のとおりです。

http {
    map $request_method $new_method {
        default       $request_method;
        GET           "mapped_get";
        POST          "mapped_post";
        PUT           "mapped_put";
        DELETE        "mapped_delete";
    }

    server {
        listen 80;
        server_name example.com;

        location / {
            # 使用映射后的值
            add_header X-Mapped-Method $new_method;

            # 其他配置...
        }
    }
}

上の例では:

• map $request_method $new_method は、$request_method の値を $new_method にマッピングするマッピングを定義します。

• add_header X-Mapped-Method $new_method;マップされた値は要求処理で使用され、応答ヘッダーに追加されます。

実際のアプリケーションでは、http_map_module を使用して、リクエストのさまざまな属性に基づいて構成アイテムを動的に選択したり、ある変数値を別のフォームにマッピングしたりできます。これにより、必要に応じてリクエストの処理をカスタマイズする非常に柔軟な方法が提供されます。

03-038：http_split_clients_module

不要なため、手動で有効にしないように指定する必要はありません。

http_split_clients_moduleクライアントリクエストを複数のバックエンドサーバーに分散するために使用されるNginxのモジュールです。これは、IP アドレスやユーザー エージェント文字列などのクライアントの属性に基づいて、どのバックエンド サーバーにリクエストを分散するかを決定するメカニズムを提供します。

http_split_clients_module の主な機能は次のとおりです。

1. A/B テスト: を使用すると、さまざまなクライアント リクエストをさまざまなバックエンド サーバーに割り当て、さまざまな機能やページのバージョンをテストすることで、A/B テストを実装できます。

2. グレースケール リリース: は、グレースケール リリースの実装に使用されます。リクエストをさまざまなバックエンド サーバーに分散することで、新しいバージョンがテストのために少数のユーザー グループに徐々にプッシュされます。

http_split_clients_module を使用した構成例は次のとおりです。

http {
    split_clients "${remote_addr}AAA" $backend {
        20%   server1;
        80%   server2;
        *    server3;
    }

    upstream backend {
        server server1.example.com;
        server server2.example.com;
        server server3.example.com;
    }

    server {
        listen 80;
        server_name example.com;

        location / {
            proxy_pass http://$backend;
            # 其他配置...
        }
    }
}

上の例では:

• split_clients "${remote_addr}AAA" $backend は、リクエストの 20% を server1 に、80% を server2 に、残りのリクエストを < に割り当てる転送ルールを定義します。 a i=3>。 server3

• upstream backendバックエンドサーバーの実際のリストを定義します。

• proxy_pass http://$backend;オフロードされたバックエンド サーバーを使用してリクエストを処理します。

このように構成すると、リクエストはクライアントの IP アドレスに基づいてさまざまなバックエンド サーバーに分散されます。実際の構成は特定のニーズに応じて調整できることに注意してください。たとえば、オフロードは他の変数に基づいて行うことができます。

03-038：http_referer_module

このモジュールは必須ですが、デフォルトで含まれているため、手動で指定する必要はありません。

申し訳ありませんが、Nginx には http_referer_module という名前の別のモジュールがありません。ただし、http_referer という名前の変数があり、クライアント リクエストの Referer ヘッダーの値を取得するために使用されます。

Referer ヘッダーは HTTP リクエスト ヘッダーの一部であり、リクエストのソース URL を示すために使用されます。 http_referer Nginx 構成で変数を使用すると、リクエストの送信元に基づいて特定の処理や制御を実行できます。

ここでは、http_referer 変数の使用方法を示す簡単な例を示します。

server {
    listen 80;
    server_name example.com;

    location / {
        if ($http_referer ~* (google|bing|yahoo)) {
            # 如果 Referer 包含 google、bing 或 yahoo，执行某些操作
            # 这里可以添加具体的处理逻辑
        }

        # 其他配置...
    }
}

上記の例では、$http_referer 変数を使用して、リクエストのソースに「google」、「bing」、または「yahoo」が含まれているかどうかを確認して、特定のアクションを実行できます。 」。

if ディレクティブを使用すると、直感的ではない動作が発生する可能性があるため、使用する場合は注意する必要があります。 Nginx では、if ディレクティブは他のプログラミング言語とは異なり、さまざまな段階でリクエストを処理しないため、場合によっては期待どおりに動作しない可能性があります。可能であれば、特に複雑な構成では if ディレクティブの使用を避けることをお勧めします。

03-039：http_rewrite_module

このモジュールは必須ですが、デフォルトで含まれているため、手動で指定する必要はありません。

申し訳ありませんが、誤解を招く点があるようです。Nginx には without-http_rewrite_module という名前のモジュールがありません。代わりに、 rewrite 機能は ngx_http_rewrite_module モジュールによって提供されます。

ngx_http_rewrite_module モジュールは、Nginx で最も強力で一般的に使用されるモジュールの 1 つで、リクエスト URI を変更し、URL の書き換えとリダイレクトを実装できます。 rewrite ディレクティブを使用すると、カスタム ルールに従って要求された URI を変更できます。

ここでは、rewrite ディレクティブの使用方法を示す簡単な例を示します。

server {
    listen 80;
    server_name example.com;

    location /old-uri {
        rewrite ^/old-uri(.*)$ /new-uri$1 permanent;
    }

    # 其他配置...
}

上記の例では、リクエストされた URI が /old-uri で始まる場合、rewrite ディレクティブはそれを < で始まる URI にリダイレクトします。 a i =3> で始まる新しい URI。 パラメータは、HTTP 301 永続リダイレクトの使用を示します。 /new-uripermanent

rewrite ディレクティブを使用する場合は、ルールが正しく、パフォーマンスに不必要な影響を与えないよう注意する必要があることに注意してください。複雑な書き換えルールのシナリオでは、このモジュールの使用方法を深く理解する必要がある場合があります。

03-040：http_proxy_module

このモジュールは必須ですが、デフォルトで含まれているため、手動で指定する必要はありません。

http_proxy_moduleこれは Nginx のコア モジュールであり、プロキシ リクエストを他のサーバーに転送するために使用されます。これはプロキシ サーバー機能を提供し、Nginx がリバース プロキシまたはロード バランサーとして機能し、バックエンドの 1 つ以上のサーバーにリクエストを転送できるようにします。

http_proxy_module の主な機能は次のとおりです。

1. リバース プロキシ: Nginx がクライアントからリクエストを受信し、それらのリクエストをバックエンド サーバーにプロキシし、クライアントに応答を返すことを許可します。これにより、バックエンド サーバーの実際のアドレスと詳細が隠蔽され、セキュリティと保守性が向上します。

2. ロード バランシング: Nginx は、リクエストを複数のバックエンド サーバーに分散してパフォーマンスと可用性を向上させるロード バランサとして構成できます。

3. キャッシュ: を使用すると、バックエンド サーバーからの応答をキャッシュするキャッシュを設定できるため、バックエンド サーバーの負荷が軽減され、応答速度が向上します。

http_proxy_module を使用した簡単な構成例は次のとおりです。

http {
    server {
        listen 80;
        server_name example.com;

        location / {
            proxy_pass http://backend_server;
            # 其他代理配置...
        }
    }

    upstream backend_server {
        server backend1.example.com;
        server backend2.example.com;
        # 可以添加更多的后端服务器...
    }
}

上の例では:

• proxy_pass http://backend_server; は、backend_server で定義された一連のバックエンド サーバーにリクエストを転送するプロキシ バックエンド サーバーを指定します。

• upstream backend_serverバックエンド サーバー (単一サーバーまたは複数サーバー) のリストを定義します。 Nginx は、負荷分散アルゴリズムに従ってこれらのバックエンド サーバーにリクエストを分散します。

これは基本的なリバース プロキシとロード バランシングの構成例であり、キャッシュの追加、ロード バランシング アルゴリズムの設定、リクエスト ヘッダーの構成など、実際のニーズに応じて具体的な構成を調整できます。

03-041：http_fastcgi_module

このモジュールは必須ですが、デフォルトで含まれているため、手動で指定する必要はありません。

Gunicorn と通信する必要があるため、 が必要です。
http_fastcgi_module は、FastCGI プロセスと通信し、FastCGI プロトコルを通じてバックエンド アプリケーションと対話するために使用される Nginx のモジュールです。 FastCGI は、Web サーバーとしての Nginx がスタンドアロンの FastCGI プロセス (PHP-FPM、uWSGI、Gunicorn など) と通信して、動的に生成されたコンテンツを処理できるようにする通信プロトコルです。

http_fastcgi_module の主な機能は次のとおりです。

1. FastCGI プロセスと通信する: Nginx が FastCGI プロトコル経由でバックエンドの FastCGI プロセスと通信し、動的なコンテンツの生成と処理を処理できるようにします。

2. 複数のプログラミング言語をサポート: FastCGI プロトコルは汎用プロトコルであるため、http_fastcgi_module PHP や Python などの複数のプログラミング言語で使用できます。 、ルビーなど。

3. パフォーマンスと柔軟性: FastCGI プロセスはリクエストごとに新しい接続を開始せずに永続的な接続を維持できるため、FastCGI は従来の CGI よりも優れたパフォーマンスを提供します。これにより、パフォーマンスが向上し、リソースの消費が削減されます。

次に、http_fastcgi_module を使用して PHP-FPM プロセスと通信する簡単な Nginx 構成例を示します。

server {
    listen 80;
    server_name example.com;

    location / {
        try_files $uri $uri/ /index.php?$query_string;
    }

    location ~ \.php$ {
        include fastcgi_params;
        fastcgi_pass unix:/var/run/php-fpm.sock;
        fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
        fastcgi_param SCRIPT_NAME $fastcgi_script_name;
    }

    # 其他配置...
}

上の例では:

• location ~ \.php$PHP スクリプトを処理するためのロケーション ブロックを定義します。
• fastcgi_pass unix:/var/run/php-fpm.sock;PHP-FPM プロセスと通信するための FastCGI サーバー アドレスを指定します。
• fastcgi_paramスクリプト ファイル名やスクリプト名など、一部の FastCGI パラメータが設定されます。

これは基本的な構成例であり、正確な構成はバックエンド FastCGI プロセスのタイプと構成によって異なります。

03-042：http_uwsgi_module

実際、私の Nginx は Gunicorn と通信するので、おそらくこれは必要ありませんが、それは問題ではありません。とにかく、これはデフォルトで含まれているので、心配する必要はありません。

http_uwsgi_moduleこれは、uWSGI プロトコルを通じてバックエンド アプリケーションと対話するために uWSGI サーバーと通信するために使用される Nginx のモジュールです。 uWSGI は、Web サーバーと Django、Flask などのアプリケーション フレームワークを接続するために使用される通信プロトコルです。

http_uwsgi_module の主な機能は次のとおりです。

1. uWSGI サーバーとの通信: Nginx が uWSGI プロトコルを介してバックエンドの uWSGI サーバーと通信し、動的に生成されたコンテンツを処理できるようにします。

2. 複数のアプリケーション フレームワークのサポート: uWSGI プロトコルはユニバーサル プロトコルであるため、http_uwsgi_module Django、Flask などの複数のアプリケーション フレームワークで使用できます。 、ピラミッドなど。

3. パフォーマンスと柔軟性: uWSGI は、アプリケーション フレームワークとの高性能通信を提供し、永続的な接続と複数のトランスポート プロトコルをサポートして、パフォーマンスを向上させ、リソース消費を削減します。

次に、http_uwsgi_module を使用して uWSGI サーバーと通信する簡単な Nginx 構成例を示します。

server {
    listen 80;
    server_name example.com;

    location / {
        try_files $uri $uri/ @uwsgi;
    }

    location @uwsgi {
        include uwsgi_params;
        uwsgi_pass unix:/var/run/uwsgi.sock;
    }

    # 其他配置...
}

上の例では:

• location @uwsgiuWSGI サーバーと通信するためのロケーション ブロックを定義します。
• uwsgi_pass unix:/var/run/uwsgi.sock;uWSGI サーバーと通信するための uWSGI サーバーのアドレスを指定します。
• include uwsgi_params;uWSGI関連のパラメータが含まれています。

これは基本的な構成例であり、正確な構成はバックエンド uWSGI サーバーのタイプと構成によって異なります。

03-043：http_scgi_module

ほとんどの場合、これを使用することはありませんが、デフォルトで含まれているため、心配する必要はありません。

http_scgi_moduleこれは、SCGI (Simple Common Gateway Interface) サーバーと通信し、SCGI プロトコルを通じてバックエンド アプリケーションと対話するために使用される Nginx のモジュールです。 SCGI は、FastCGI に似た通信プロトコルで、Web サーバーとアプリケーション間の単純なインターフェイスを定義します。

http_scgi_module の主な機能は次のとおりです。

1. SCGI サーバーとの通信: Nginx が SCGI プロトコル経由でバックエンド SCGI サーバーと通信し、動的に生成されたコンテンツを処理できるようにします。

2. 複数のプログラミング言語のサポート: SCGI プロトコルは汎用プロトコルであるため、http_scgi_module Python や Perl などの複数のプログラミング言語で使用できます。 、など。

3. パフォーマンスと柔軟性: SCGI は、アプリケーションとの高性能通信を提供し、永続的な接続をサポートし、パフォーマンスを向上させ、リソース消費を削減します。

次に、http_scgi_module を使用して SCGI サーバーと通信する簡単な Nginx 構成例を示します。

server {
    listen 80;
    server_name example.com;

    location / {
        include scgi_params;
        scgi_pass localhost:4000;
    }

    # 其他配置...
}

上の例では:

• location /SCGI サーバーと通信するためのロケーション ブロックを定義します。
• scgi_pass localhost:4000;SCGI サーバーと通信するための SCGI サーバーのアドレスを指定します。
• include scgi_params;SCGI関連のパラメータが含まれています。

これは基本的な構成例であり、正確な構成はバックエンド SCGI サーバーのタイプと構成によって異なります。

03-044：http_grpc_module

不要なため、有効かどうかを気にする必要はありません。

http_grpc_module モジュールを使用すると、リクエストを gRPC サーバー (1.13.10) に渡すことができます。このモジュールには ngx_http_v2_module モジュールが必要です。

03-045：http_memcached_module

不要なため、有効かどうかを気にする必要はありません。

http_memcached_moduleMemcached サーバーとの通信に使用される Nginx のモジュールです。 Memcached は、データをキャッシュし、アプリケーション アクセスを高速化するために使用される高性能分散メモリ オブジェクト キャッシング システムです。

http_memcached_module の主な機能は次のとおりです。

1. Memcached サーバーとの通信: Nginx が Memcached プロトコルを通じてバックエンド Memcached サーバーと通信し、キャッシュされたデータを読み書きできるようにします。

2. キャッシュの高速化: Memcached をキャッシュ バックエンドとして使用すると、動的コンテンツの生成が高速化され、応答速度が向上します。頻繁にアクセスされるデータを Memcached にキャッシュすることで、バックエンド サーバーの負荷を軽減できます。

次に、http_memcached_module を使用して Memcached サーバーと通信する簡単な Nginx 構成例を示します。

http {
    server {
        listen 80;
        server_name example.com;

        location / {
            set $memcached_key $uri;
            memcached_pass memcached_server:11211;
            default_type text/html;
            error_page 404 = @fallback;
        }

        location @fallback {
            proxy_pass http://backend_server;
            # 其他配置...
        }
    }

    upstream backend_server {
        server backend1.example.com;
        server backend2.example.com;
        # 可以添加更多的后端服务器...
    }
}

上の例では:

• location /Memcached サーバーとの通信のためのロケーション ブロックを定義します。
• memcached_pass memcached_server:11211;Memcached サーバーと通信するための Memcached サーバーのアドレスとポートを指定します。
• set $memcached_key $uri;Memcached ストアのキーを設定します。通常は、要求された URI をキーとして使用します。
• error_page 404 = @fallback; リクエストが 404 を返したら、@fallback ロケーション ブロックにジャンプします。
• proxy_pass http://backend_server; @fallback location ブロックで、リクエストをバックエンド サーバーにプロキシします。

これは基本的な構成例であり、アプリケーションのニーズに基づいて特定の構成を調整する必要がある場合があります。

03-046：http_limit_conn_module

このモジュールは必須ですが、デフォルトで含まれているため、手動で指定する必要はありません。

http_limit_conn_moduleこれは、クライアントの同時接続数を制限するために使用される Nginx のモジュールです。これは、悪意のある攻撃を防止し、サーバーの安定性を向上させ、過剰なリクエストの圧力からバックエンド リソースを保護するのに役立ちます。

http_limit_conn_module の主な機能は次のとおりです。

1. 同時接続の制限: では、特定の IP アドレス、CIDR プレフィックス、またはその他の識別子の同時接続数に制限を設定できます。

2. 過剰なリクエストを防ぐ: 1 つのクライアントからの同時接続数を制限することで、ブルート フォース攻撃や DDoS 攻撃などの特定の悪意のある動作を防ぐことができます。

3. バックエンド リソースの保護: 同時接続数を制限すると、バックエンド サーバーが過剰な接続によって過負荷にならず、システムの信頼性とパフォーマンスが向上します。

次に、http_limit_conn_module を使用して同時接続数を制限する簡単な Nginx 構成例を示します。

http {
    limit_conn_zone $binary_remote_addr zone=addr:10m;

    server {
        listen 80;
        server_name example.com;

        location / {
            limit_conn addr 5;
            # 其他配置...
        }
    }
}

上の例では:

• limit_conn_zone $binary_remote_addr zone=addr:10m; は、IP アドレスの接続ステータス情報を保存するために addr という名前の共有メモリ領域を作成し、最大 10 MB のメモリを占有します。

• limit_conn addr 5;IP アドレスごとに最大 5 つの同時接続が許可されることを指定します。この制限を超える接続は、構成に応じて遅延または拒否されます。

これは基本的な構成例であり、特定の構成はニーズに応じて調整できます。さまざまな location ブロックにさまざまな制限を設定でき、共有メモリ領域のサイズやその他のパラメータを調整できます。

03-047：http_limit_req_module

このモジュールは必須ですが、デフォルトで含まれているため、手動で指定する必要はありません。

このモジュールについて詳細な調査を実施しました。詳細については、https://blog.csdn.net/wenhao_ir/article/details/134913876 をご覧ください。

http_limit_req_moduleリクエストのレートを制限するために使用される Nginx のモジュールです。これは、悪意のある攻撃を防止し、過剰なリクエストの圧力からサーバーを保護し、サービスの信頼性を確保するのに役立ちます。

http_limit_req_module の主な機能は次のとおりです。

1. リクエスト レートの制限: では、特定の IP アドレス、CIDR プレフィックス、またはその他の識別子に対するリクエストのレート制限を設定できます。

2. 過剰なリクエストの防止: リクエスト レートを制限することで、爆発攻撃や DDoS 攻撃などの特定の悪意のある動作を防ぐことができます。

3. バックエンド リソースの保護: リクエスト レートを制限すると、バックエンド サーバーが過剰なリクエストによって過負荷にならず、システムの信頼性とパフォーマンスが向上します。

次に、http_limit_req_module を使用してリクエスト レートを制限する簡単な Nginx 構成例を示します。

http {
    limit_req_zone $binary_remote_addr zone=req_zone:10m rate=1r/s;

    server {
        listen 80;
        server_name example.com;

        location / {
            limit_req zone=req_zone burst=5;
            # 其他配置...
        }
    }
}

上の例では:

• limit_req_zone $binary_remote_addr zone=req_zone:10m rate=1r/s; は、IP アドレスのリクエスト ステータス情報を保存するために req_zone という名前の共有メモリ領域を作成し、1 秒あたり 1 リクエストの速度で最大 10 MB のメモリを占有します。

• limit_req zone=req_zone burst=5;IP アドレスごとに 1 秒あたり 1 つのリクエストが許可されますが、最大 5 つのリクエストのバーストは許可されることを指定します。リクエスト レートが制限を超えると、構成に応じて、超過したリクエストは遅延または拒否されます。

これは基本的な構成例であり、特定の構成はニーズに応じて調整できます。さまざまな location ブロックにさまざまな制限を設定でき、共有メモリ領域のサイズやその他のパラメータを調整できます。

03-048：http_empty_gif_module

不要なため、有効かどうかを気にする必要はありません。

http_empty_gif_moduleNginx の公式モジュールではありませんが、一般的なカスタム モジュールまたはトリックです。通常、1x1 ピクセルの透明な GIF 画像を作成するために使用され、軽量の「応答」として使用されます。

この技術は通常、追跡または統計目的で Web ページで使用されます。その原理は、クライアントに非常に小さく透明な GIF 画像をリクエストさせることで、サーバーは、ユーザーが特定のページにアクセスしたり、電子メールを開いたりするなど、リクエストに関連する情報を記録できるというものです。

このトリックを使用する可能性のある Nginx 構成の例を次に示します。

server {
    listen 80;
    server_name example.com;

    location /tracking-pixel.gif {
        empty_gif;
        # 其他配置...
    }

    # 其他配置...
}

この例では、クライアントが /tracking-pixel.gif パスをリクエストすると、empty_gif ディレクティブは Nginx に透明な 1x1 ピクセルの GIF 画像を返すように指示します。通常はこれです。画像は空であり、実際のコンテンツはありません。このリクエストの目的は通常、ページの外観に影響を与えることなくクライアントのアクティビティを記録することです。

empty_gif ディレクティブは標準の Nginx モジュールではなく、Nginx 構成で使用されるカスタム ディレクティブであることに注意してください。この手法は、1x1 ピクセルの透明な GIF 画像を返す場所を構成することで実装できます。実際、実際の 1x1 ピクセルの透明 GIF 画像を直接使用でき、必ずしもモジュールやディレクティブを通じて実装する必要はありません。

03-049：http_browser_module

不要なため、有効かどうかを気にする必要はありません。

ブラウザ モジュールの主な機能は、http リクエスト ヘッダーの「User-Agent」の値とブラウザの特徴的な文字に基づいて古いブラウザと新しいブラウザを判断し、後続のリクエスト処理ロジックに対応する変数を生成することです。 。 使用。
詳細については、https://zhuanlan.zhihu.com/p/355305327 を参照してください。

03-050：http_upstream_hash_module

不要なため、有効かどうかを気にする必要はありません。

http_upstream_hash_moduleハッシュアルゴリズムに基づいて負荷分散を提供するNginxのモジュールです。これにより、リクエストの特定の属性 (クライアント IP、URI など) に基づいて、バックエンド サーバーのセット内の特定のサーバーにリクエストを分散できます。

http_upstream_hash_module の主な機能は次のとおりです。

1. ハッシュ アルゴリズムの負荷分散: ハッシュ アルゴリズムを通じて、特定の属性 (クライアント IP、URI など) をバックエンド サーバーのセット内の特定のサーバーにマッピングします。実装します。リクエストの負荷分散。

2. セッションの永続性: ハッシュ アルゴリズムを使用すると、同じ属性に対して同じハッシュ値を生成できるため、同じリクエストを同じバックエンド サーバーにルーティングできます。これは、特定のクライアントとのセッション状態を維持するのに役立ちます。

次に、ハッシュ ロード バランシングにhttp_upstream_hash_moduleを使用した簡単な Nginx 構成例を示します。

http {
    upstream backend {
        hash $request_uri consistent;
        server backend1.example.com;
        server backend2.example.com;
        server backend3.example.com;
        # 可以添加更多的后端服务器...
    }

    server {
        listen 80;
        server_name example.com;

        location / {
            proxy_pass http://backend;
            # 其他配置...
        }
    }
}

上の例では:

• hash $request_uri consistent; は、要求された URI をハッシュのキー属性として使用して、ハッシュ アルゴリズムを構成します。 consistent キーワードは、コンシステント ハッシュ アルゴリズムの使用を示します。

• upstream backend複数のサーバーを含むバックエンド サーバー グループが定義されています。

• proxy_pass http://backend; は、backend という名前のバックエンド サーバー グループにリクエストをプロキシし、ハッシュ アルゴリズムに基づいてバックエンド サーバーを選択します。

これは基本的な構成例であり、ハッシュのキー属性として他の属性を選択するなど、ニーズに応じて特定の構成を調整できます。

03-051：http_upstream_ip_hash_module

不要なため、有効かどうかを気にする必要はありません。

http_upstream_ip_hash_moduleクライアント IP アドレスに基づいてハッシュ ロード バランシングを提供する Nginx のモジュールです。このモジュールを使用すると、同じ IP アドレスからのリクエストを同じバックエンド サーバー セット内の同じサーバーに分散できます。これにより、同じクライアントからのリクエストが同じバックエンド サーバーにルーティングされるようになり、特定のクライアントのセッション状態を維持するのに役立ちます。

http_upstream_ip_hash_module の主な機能は次のとおりです。

1. IP アドレス ハッシュ ロード バランシング: クライアント IP アドレスは、ハッシュ アルゴリズムを通じて一連のバックエンド サーバー内の特定のサーバーにマッピングされ、IP アドレス ベースのロード バランシングを実現します。 。

2. セッションの永続性: ハッシュ アルゴリズムを使用すると、同じクライアント IP アドレスで同じハッシュ値を生成できるため、同じクライアント IP からのリクエストが同じバックエンド サーバーにルーティングされます。 。これは、特定のクライアントとのセッション状態を維持するのに役立ちます。

次に、http_upstream_ip_hash_module を使用して IP アドレス ハッシュ ロード バランシングを行う簡単な Nginx 構成例を示します。

http {
    upstream backend {
        ip_hash;
        server backend1.example.com;
        server backend2.example.com;
        server backend3.example.com;
        # 可以添加更多的后端服务器...
    }

    server {
        listen 80;
        server_name example.com;

        location / {
            proxy_pass http://backend;
            # 其他配置...
        }
    }
}

上の例では:

• ip_hash;クライアント IP アドレスをハッシュのキー属性として使用する IP アドレス ハッシュ アルゴリズムが設定されています。

• upstream backend複数のサーバーを含むバックエンド サーバー グループが定義されています。

• proxy_pass http://backend; は、backend という名前のバックエンド サーバー グループにリクエストをプロキシし、IP アドレス ハッシュ アルゴリズムに基づいてバックエンド サーバーを選択します。

これは基本的な構成例であり、特定の構成はニーズに応じて調整できます。この方法は通常、セッション状態を維持するために、同じクライアント IP からの要求が同じバックエンド サーバーにルーティングされるようにする必要があるシナリオで使用されます。

03-052:http_upstream_least_conn_module - 接続数に基づいた負荷分散

不要なため、有効かどうかを気にする必要はありません。

http_upstream_least_conn_moduleこれは、最小接続数に基づいて負荷分散を提供する Nginx のモジュールです。このモジュールは、負荷分散を実現するために、現在の接続数が最も少ないバックエンド サーバーに新しいリクエストを分散します。

http_upstream_least_conn_module の主な機能は次のとおりです。

1. 最小接続数のロード バランシング: 各バックエンド サーバーへの現在の接続数を追跡することで、現在の接続数が最も少ないサーバーに新しいリクエストが分散され、最小接続数が実現されます。負荷分散の。

2. 動的適応: このアルゴリズムは、バックエンド サーバーの負荷に自動的に適応して、リクエストがサーバー間でより均等に分散されるようにすることで、全体的なパフォーマンスを向上させることができます。

次に、http_upstream_least_conn_module を使用して最小接続数の負荷分散を行う簡単な Nginx 構成例を示します。

http {
    upstream backend {
        least_conn;
        server backend1.example.com;
        server backend2.example.com;
        server backend3.example.com;
        # 可以添加更多的后端服务器...
    }

    server {
        listen 80;
        server_name example.com;

        location / {
            proxy_pass http://backend;
            # 其他配置...
        }
    }
}

上の例では:

• least_conn;最小限の接続数で負荷分散アルゴリズムを構成します。

• upstream backend複数のサーバーを含むバックエンド サーバー グループが定義されています。

• proxy_pass http://backend; は、backend という名前のバックエンド サーバー グループにリクエストをプロキシし、最小接続アルゴリズムに基づいてバックエンド サーバーを選択します。

これは基本的な構成例であり、特定の構成はニーズに応じて調整できます。この方法は、接続の過負荷を避けるために、接続数が少ないサーバーに要求を確実に分散する必要があるシナリオでよく使用されます。

03-053：http_upstream_random_module

不要なため、有効かどうかを気にする必要はありません。

前のモジュールと同様に、これは負荷分散に関連しています。実はNginxをリバースプロキシとして利用する際に使えそうな機能です。

03-054：http_upstream_keepalive_module

不要なため、有効かどうかを気にする必要はありません。

前のモジュールと同様に、これは負荷分散に関連しています。実はNginxをリバースプロキシとして利用する際に使えそうな機能です。

03-056：http_upstream_zone_module

不要なため、有効かどうかを気にする必要はありません。

前のモジュールと同様に、これは負荷分散に関連しています。実はNginxをリバースプロキシとして利用する際に使えそうな機能です。

03-057：http_perl_module

不要なため、有効かどうかを気にする必要はありません。

http_perl_moduleこれは、Nginx 構成で Perl 言語で書かれたコード ブロックを使用して Nginx の機能を拡張できるようにする Nginx のモジュールです。このモジュールを通じて、Perl コードを Nginx に埋め込んで、より複雑なリクエスト処理ロジック、動的コンテンツ生成、その他の機能を実装できます。

http_perl_module の主な機能は次のとおりです。

1. 動的なリクエスト処理: により、Perl を使用してリクエストを処理し、より複雑なロジックとビジネス ルールを実装するためのコード ブロックを作成できます。

2. カスタム変数とディレクティブ: により、Perl を介して Nginx 構成構文を拡張し、カスタム変数とディレクティブを追加できます。

3. 他の Perl モジュールとの統合: http_perl_module を通じて、他の Perl モジュールを簡単に統合して、より多くの機能を実現できます。

次に、http_perl_module を使用した簡単な Nginx 構成例を示します。

http {
    perl_modules perl/lib;
    
    server {
        listen 80;
        server_name example.com;

        location / {
            perl my_handler;
            # 其他配置...
        }
    }
}

perl_require perl/lib/my_handler.pl;

sub my_handler {
    my $r = shift;
    $r->send_http_header('text/plain');
    $r->print("Hello, Perl in Nginx!");
    return OK;
}

上の例では:

• perl_modules perl/lib;Perl モジュールのストレージ パスを指定します。

• perl my_handler; は、location / の Perl コード ブロックを使用してリクエストを処理します。

• perl_require perl/lib/my_handler.pl; では、 サブルーチンの実装を含む Perl ファイル my_handler.pl が導入されています。 my_handler

• my_handlerサブルーチンでは、単純な「Hello, Perl in Nginx!」応答が Perl コードから生成されます。

これは基本的な構成例です。特定の構成とコードの実装は必要に応じて調整できます。 http_perl_module を使用する場合は、不必要な複雑さを避けるためにパフォーマンスとセキュリティに注意を払う必要があります。

03-058：--without-http

これは明らかに有効にすることができません。

Nginx 構成ステートメントの without-http は、HTTP コア モジュールを無効にするために使用される構成パラメータです。通常、./configure コマンドと一緒に使用して、Nginx をコンパイルするときに HTTP 関連のモジュールと機能を選択的に無効にして、Nginx のバイナリ サイズを削減します。

Nginx コンパイル オプションを構成する場合、./configure コマンドを使用して特定のモジュールを有効または無効にできます。 without-http を使用すると、コア HTTP モジュールやその他の HTTP サービス関連モジュールを含む、すべての HTTP 関連モジュールが無効になります。

次に、without-http 構成パラメータの使用方法を示す例を示します。

./configure --without-http
make
make install

この例では、--without-http パラメータは、HTTP モジュールをコンパイルしてインクルードしないようにビルド システムに指示します。これを使用して、TCP/UDP プロキシまたはその他の非 HTTP プロトコルのみをサポートする Nginx バイナリを構築できます。

HTTP モジュールを無効にすると、Nginx で HTTP リクエストのサポートが失われることに注意してください。そのため、この構成は、TCP プロキシ専用の Nginx インスタンスの構築など、一部の特定の使用シナリオに適しています。 HTTP リクエストをサポートする必要がある場合は、without-http を使用しないでください。

03-059：with-mail

不要なため、有効かどうかを気にする必要はありません。

with-mail は Nginx の構成パラメータの 1 つで、通常は ./configure コマンドと一緒に使用され、Nginx のコンパイル時にメール プロキシ関連の機能を有効にします。 --with-mail パラメーターを使用すると、コンパイル システムによって電子メール関連のモジュールが有効になり、Nginx がメール プロキシ サーバー (メール プロキシ) として実行できるようになります。

次に、with-mail 構成パラメータの使用方法を示す例を示します。

./configure --with-mail
make
make install

この例では、--with-mail パラメータは、ngx_mail_module などのメール サービスに関連するモジュールをコンパイルして含めるようビルド システムに指示します。これにより、Nginx は SMTP (Simple Mail Transfer Protocol) およびその他の電子メール関連プロトコルを処理できるようになります。

メール モジュールを有効にすると、メール プロキシの構成、メール トラフィックの負荷分散など、Nginx 構成でメール関連の手順とモジュールを使用できるようになります。

with-mail はコンパイル時オプションであることに注意してください。生成されるバイナリ ファイルにメール モジュールのサポートを含めるには、Nginx のコンパイル時にこのオプションを明示的に指定する必要があります。 Nginx にメール プロキシ機能が必要ない場合は、with-mail パラメータを使用しないことを選択できます。

質問: Django で書かれた Web サイトでは、ユーザーの登録時に確認コードをユーザーの電子メールに送信する必要があります。Nginx 電子メール モジュールを使用する必要がありますか?
いいえ、確認コードメールを送信するために Nginx のメール モジュールを使用する必要はありません。 Nginx は主に高機能な Web サーバーおよびリバース プロキシ サーバーであり、メール送信機能自体を処理しません。 Django アプリケーションでは、通常、確認コード電子メールの送信は、電子メール サービス プロバイダーまたはローカル メール サーバーを使用して行われます。

一般的なプロセスは次のとおりです。

1. Django 設定の構成: Django プロジェクトの設定ファイルでは、電子メール サーバー アドレス、ポート、認証情報など、電子メール送信に関連するパラメータを構成する必要があります。これは通常、 settings.py ファイル内で行われます。例:

   # settings.py
   
   EMAIL_BACKEND = 'django.core.mail.backends.smtp.EmailBackend'
   EMAIL_HOST = 'your_smtp_server.com'
   EMAIL_PORT = 587
   EMAIL_USE_TLS = True
   EMAIL_HOST_USER = '[email protected]'
   EMAIL_HOST_PASSWORD = 'your_email_password'
   

   上記の設定では SMTP プロトコルが使用されているため、実際のメール サーバー情報に置き換える必要があります。

2. Django を使用して電子メールを送信する: Django ビューまたはその他のロジックでは、Django が提供する send_mail 関数を使用して電子メールを送信できます。例:

   # views.py
   
   from django.core.mail import send_mail
   
   def send_verification_email(email, verification_code):
       subject = 'Verify Your Account'
       message = f'Your verification code is {
           
           verification_code}.'
       from_email = '[email protected]'
       recipient_list = [email]
   
       send_mail(subject, message, from_email, recipient_list)
   

   ユーザーが登録するか、確認コードを送信する必要があるsend_verification_email関数を呼び出すだけです。

3. 電子メール サービス プロバイダを選択します: SendGrid、Mailgun、SMTP.com などのサードパーティの電子メール サービス プロバイダを使用することもできます。これらのサービスは、安定した電子メール配信サービスを提供します。 、一般に信頼性とパフォーマンスが優れています。この場合、プロバイダーのドキュメントに従って Django の電子メール設定を構成し、プロバイダーの API を使用して電子メールを送信する必要があります。

つまり、Django でメール送信機能を実装するために Nginx のメールボックス モジュールを使用する必要はなく、Django またはサードパーティのメール サービス プロバイダーが提供するメール機能を通じてメール送信を完了できます。

03-060:with-stream- 非 HTTP プロトコルのトラフィックの処理

不要なため、有効かどうかを気にする必要はありません。

--with-streamこれは Nginx のコンパイル パラメーターの 1 つで、Stream モジュールを有効にするために使用されます。 Stream モジュールを使用すると、Nginx が TCP および UDP のプロキシとして機能し、データベース接続や電子メール プロトコルなどの非 HTTP プロトコル トラフィックを処理できるようになります。

--with-stream コンパイル パラメータを使用すると、コンパイル システムによって Stream モジュールが有効になり、Nginx が TCP および UDP トラフィックを処理できるようになります。このようにして、Nginx は HTTP プロトコルに限定されず、より柔軟なプロキシ機能と負荷分散機能を実装できます。

ここでは、--with-stream の使用方法を示す簡単な例を示します。

./configure --with-stream
make
make install

この例では、--with-stream パラメータは、Stream モジュールに関連する機能をコンパイルして組み込むようにビルド システムに指示します。これにより、Nginx は HTTP プロトコルだけでなく、TCP および UDP トラフィックを処理できるようになります。

Stream モジュールは、TCP または UDP プロキシを構成するための、stream ブロックなどのいくつかの構成ディレクティブを提供します。以下は、Stream モジュールを使用して TCP プロキシを実装する簡単な Nginx 構成例です。

stream {
    server {
        listen 12345;
        proxy_pass backend_server:5678;
    }
}

上記の例では、listen 12345; は Nginx がリッスンするポートを指定し、proxy_pass backend_server:5678; はバックエンド サーバーのポート 5678 にトラフィックをプロキシします。

一般に--with-stream パラメータは Nginx の Stream モジュールを有効にし、TCP および UDP トラフィックを処理できるようにし、より広範囲のプロキシおよびロード バランシング機能を提供します。

03-061：google_perftools_module

不要なため、有効かどうかを気にする必要はありません。

私の知る限りの期限 (2022 年初頭) では、google_perftools_module は公式の Nginx モジュールではなく、コミュニティが提供するサードパーティ モジュールです。このモジュールは Google パフォーマンス ツールに関連しています。

Google パフォーマンス ツールは、パフォーマンスの分析と最適化のためのオープンソース ツールのセットです。 gperftools ライブラリは、pprof (パフォーマンス プロファイリング ツール) や tcmalloc (スレッド -安全なメモリ アロケータ) など

google_perftools_module通常、Nginx と一緒に使用される Google パフォーマンス ツールは、Nginx のモジュール メカニズムを通じて Nginx に統合され、それにより Nginx ランタイム パフォーマンスの分析と監視が可能になります。

google_perftools_module の考えられる機能と効果は次のとおりです。

1. プロファイリング: pprof ツールを使用すると、Nginx の実行時のパフォーマンスを分析し、関数呼び出しの関係や CPU 使用率などを把握できます。パフォーマンスのボトルネックを特定するのに役立ちます。

2. メモリ分析: 有効にすると tcmalloc、Nginx プロセスのメモリ使用量を監視して、メモリ リークの発見やメモリ割り当ての最適化に役立てることができます。

3. スレッド セーフ メモリ割り当て: tcmalloc は、マルチスレッド環境でメモリをより効率的に割り当てることができるスレッド セーフ メモリ アロケータを提供します。

4. メモリ スタック分析: tcmalloc は、メモリ割り当ての場所を特定し、メモリ関連の問題を調査するのに役立つメモリ スタック情報を生成できます。

特定の使用法と構成は、Nginx のバージョンとモジュールのバージョンによって異なる場合があることに注意してください。 google_perftools_module を使用する場合は、公式ドキュメントまたは関連するコミュニティ リソースで最新の情報と設定例を参照することをお勧めします。

03-062：cpp_test_module

不要なため、有効かどうかを気にする必要はありません。

私の知る限りの期限 (2022 年初め) では、cpp_test_module は公式の Nginx モジュールではなく、C++ を使用して Nginx モジュールを作成する方法を示すサンプル モジュールです。このモジュールは実際の機能を提供しませんが、開発者が C++ を使用して Nginx の機能を拡張する方法を理解するのに役立つことを目的としています。

Nginx のモジュール開発では、Nginx 自体の本体が C で書かれているため、担当者は通常 C 言語を使用してモジュールを作成します。ただし、少し追加の作業を行うと、C++ で Nginx モジュールを作成し、C++ のオブジェクト指向機能やその他の機能を利用できます。

C++ を使用して Nginx モジュールを作成することに興味がある場合は、このcpp_test_module例を参照して、Nginx ソース コードのモジュール開発インターフェイスと機能を組み合わせる方法を学習できます。 C++。 Nginx 自体は C 言語に基づいているため、これはより複雑になる可能性があることに注意してください。

ここでは、cpp_test_module の使用方法を示す簡単な例を示します。

#include <ngx_config.h>
#include <ngx_core.h>
#include <ngx_http.h>

extern "C" {
    
    
    static ngx_int_t ngx_http_cpp_test_handler(ngx_http_request_t *r);
    static char *ngx_http_cpp_test(ngx_conf_t *cf, ngx_command_t *cmd, void *conf);
    static ngx_int_t ngx_http_cpp_test_init(ngx_conf_t *cf);
}

static ngx_command_t ngx_http_cpp_test_commands[] = {
    
    
    {
    
    
        ngx_string("cpp_test"),
        NGX_HTTP_LOC_CONF | NGX_CONF_NOARGS,
        ngx_http_cpp_test,
        NGX_HTTP_LOC_CONF_OFFSET,
        0,
        NULL
    },
    ngx_null_command
};

static ngx_http_module_t ngx_http_cpp_test_module_ctx = {
    
    
    NULL,                                  /* preconfiguration */
    ngx_http_cpp_test_init,                 /* postconfiguration */
    NULL,                                  /* create main configuration */
    NULL,                                  /* init main configuration */
    NULL,                                  /* create server configuration */
    NULL,                                  /* merge server configuration */
    NULL,                                  /* create location configuration */
    NULL                                   /* merge location configuration */
};

ngx_module_t ngx_http_cpp_test_module = {
    
    
    NGX_MODULE_V1,
    &ngx_http_cpp_test_module_ctx,         /* module context */
    ngx_http_cpp_test_commands,            /* module directives */
    NGX_HTTP_MODULE,                       /* module type */
    NULL,                                  /* init master */
    NULL,                                  /* init module */
    NULL,                                  /* init process */
    NULL,                                  /* init thread */
    NULL,                                  /* exit thread */
    NULL,                                  /* exit process */
    NULL,                                  /* exit master */
    NGX_MODULE_V1_PADDING
};

static ngx_int_t ngx_http_cpp_test_handler(ngx_http_request_t *r) {
    
    
    // 处理请求的逻辑
    ngx_http_send_header(r);
    ngx_http_output_filter(r, NULL);
    return NGX_OK;
}

static char *ngx_http_cpp_test(ngx_conf_t *cf, ngx_command_t *cmd, void *conf) {
    
    
    ngx_http_core_loc_conf_t *clcf;

    clcf = ngx_http_conf_get_module_loc_conf(cf, ngx_http_core_module);
    clcf->handler = ngx_http_cpp_test_handler;

    return NGX_CONF_OK;
}

static ngx_int_t ngx_http_cpp_test_init(ngx_conf_t *cf) {
    
    
    // 模块初始化逻辑
    return NGX_OK;
}

これは単なる例にすぎません。実際には、C++ Nginx モジュールの作成には、メモリ管理、例外処理、リンクの問題などの適切な処理など、より複雑な問題が含まれる場合があります。実際のプロジェクトでは、Nginx のモジュール開発インターフェイスと C++ 機能を詳しく調べる必要がある場合があります。特定の質問やニーズがある場合は、公式ドキュメントや関連リソースを参照することをお勧めします。

03-063：--add-module=PATH

これは、サードパーティまたはカスタマイズされたモジュールを追加するためのものです。これは、他のブログ投稿で geoip2 モジュールをインストールするために使用したものです。
詳細については、https://blog.csdn.net/wenhao_ir/article/details/134951013 を参照してください。

03-064：--with-compat

長い間考えた結果、このモジュールは最初から有効にするのではなく、サードパーティのモジュールを追加するときに互換性がなくなった場合に有効にする必要があると思います。

--with-compatNginx 構成パラメータの 1 つで、Nginx のコンパイル時に互換性モジュールを有効にするために使用されます。このパラメータは通常、古いバージョンの Nginx モジュールとサードパーティ モジュールを新しいバージョンの Nginx にコンパイルして、新しいバージョンでのモジュールの互換性を確保するために使用されます。

Nginx を新しいバージョンにアップグレードすると、一部のモジュールが新しいバージョンと互換性がなくなるという問題が発生する可能性があります。この問題を解決するために、Nginx は古いバージョンのモジュールとの互換性を確保する --with-compat パラメータを提供します。

ここでは、--with-compat の使用方法を示す簡単な例を示します。

./configure --with-compat
make
make install

--with-compat パラメータを使用すると、ビルド システムは、古いバージョンの Nginx のバイナリ モジュールとの互換性をできる限り維持しようとします。こうすることで、モジュールを変更したり再コンパイルしたりすることなく、新しいバージョンの Nginx で古いバージョンのモジュールを使用できます。

--with-compat は特定の互換性サポートを提供しますが、すべてのモジュールに完全な互換性があるわけではないことに注意してください。場合によっては、新しいバージョンの Nginx で動作するように特定のモジュールを適応または更新する必要がある場合があります。

全体的に、--with-compat はモジュールの互換性を向上させるための便利なオプションですが、これを使用する場合は、関連する公式ドキュメントとモジュールのアップデート情報を確認して、モジュールの互換性を適切に管理することをお勧めします。

03-065：--with-pcre

次の図に示すように、Nginx はデフォルトでこのパラメーターを有効にし、システム内の pcre ライブラリを検索するため、このパラメーターを明示的に指定する必要はありません。

--with-pcreNginx の構成パラメータの 1 つで、PCRE (Perl 互換正規表現) ライブラリのサポートを有効にするために使用されます。 PCRE は正規表現を処理するためのライブラリであり、Perl 正規表現構文と互換性があり、強力な正規表現関数を提供します。

Nginx のコンパイル時に --with-pcre パラメータを使用すると、コンパイル システムによって PCRE ライブラリがリンクされ、Nginx が構成ファイル内で PCRE 正規表現を使用できるようになります。このように、Nginx 構成で強力な正規表現機能を使用して、URL マッチング、リダイレクト、マッピング、その他の操作を実行できます。

ここでは、--with-pcre の使用方法を示す簡単な例を示します。

./configure --with-pcre
make
make install

この例では、--with-pcre パラメータは、Nginx のコンパイル時に PCRE ライブラリのサポートを有効にするようにコンパイル システムに指示します。

Nginx 構成ファイルでは、正規表現を使用してリクエストを照合し、処理できます。例えば：

location ~ /images/ {
    # 匹配以 /images/ 开头的 URL
    # 其他配置...
}

この例では、~ は正規表現マッチングを使用することを意味し、/images/ は正規表現であり、マッチングは /images/

一般に、--with-pcre パラメータは PCRE 正規表現ライブラリのサポートを有効にするために使用され、Nginx が設定や処理に正規表現をより柔軟に利用できるようになります。

03-066：--with-zlib=DIR

このパラメータは前のパラメータと同じです--with-pcre。次の図に示すように、Nginx はシステム内の zlib ライブラリも検索するため、明示的に指定する必要はありません。 :

--with-zlib=DIRこれは、Nginx の構成パラメーターの 1 つであり、zlib ライブラリのインストール パスを指定するために使用されます。 zlib はデータ圧縮および圧縮解除用のオープンソース ライブラリであり、転送効率を向上させるために Web サーバーを含む多くのアプリケーションで広く使用されています。

--with-zlib=DIR パラメータを使用して Nginx をコンパイルする場合は、zlib ライブラリのインストール パスを指定する必要があります。これは、Nginx をビルドするときに指定されたパスで zlib ライブラリを検索し、それを Nginx バイナリにリンクするようにビルド システムに指示します。

ここでは、--with-zlib=DIR の使用方法を示す簡単な例を示します。

./configure --with-zlib=/path/to/zlib
make
make install

この例では、/path/to/zlib は zlib ライブラリのインストール パスです。 --with-zlib パラメーターを使用すると、指定したパスで zlib ライブラリを検索するようにビルド システムに指示できます。

Nginx の zlib の主な目的は、HTTP 応答を圧縮して送信データのサイズを削減し、Web サイトの読み込み速度を向上させることです。クライアントが圧縮をサポートしている場合、Nginx は zlib を使用して応答を gzip または圧縮し、それをクライアントに送信し、クライアントがそれを解凍します。これは、Nginx 設定の gzip 関連ディレクティブを介して制御できます。

通常、--with-zlib=DIR パラメータは、zlib ライブラリのサポートを有効にし、zlib ライブラリのインストール パスを指定するために使用されます。これにより、実行時に zlib の圧縮および解凍機能を使用するために、Nginx がコンパイル時に zlib ライブラリに対して正しくリンクできるようになります。

03-067：--with-libatomic

不要なため、有効かどうかを気にする必要はありません。

個人的には、以下で説明するように、Centos7.9 システムではコンパイラーがアトミック操作の組み込みサポートを提供しているため、通常の状況ではこのパラメーターを明示的に指定する必要はないため、これは必要ないと思います。 。

--with-libatomicNginx の構成パラメータの 1 つで、libatomic ライブラリのサポートを有効にするために使用されます。 libatomic はアトミック操作用のライブラリであり、マルチスレッド プログラムで共有データに対する安全な操作を保証するために使用できるいくつかのアトミック操作関数を提供します。

マルチスレッド環境では、複数のスレッドが同時に共有データにアクセスして変更すると、競合状態が発生し、データの不整合やその他の問題が発生する可能性があります。 libatomic は、共有データに対する操作がロックを必要とせずに確実にアトミックであることを保証するアトミック操作を提供し、競合状態を回避します。

--with-libatomic パラメータを指定して Nginx をコンパイルすると、libatomic ライブラリがリンクされ、Nginx で libatomic によって提供されるアトミック操作が使用されます。これは、一部の同時実行パフォーマンスの最適化、特にマルチコア システム上で実行される同時実行性の高い Nginx インスタンスにとって有益です。

ここでは、--with-libatomic の使用方法を示す簡単な例を示します。

./configure --with-libatomic
make
make install

この例では、--with-libatomic パラメータは、Nginx のコンパイル時に libatomic ライブラリのサポートを有効にするようコンパイル システムに指示します。

一部のシステムでは、コンパイラがアトミック操作の組み込みサポートをすでに提供しているため、すべてのシステムで libatomic サポートを明示的に有効にする必要があるわけではないことに注意してください。特定の状況では、--with-libatomic の使用が Nginx のパフォーマンスにプラスの影響を与える可能性がありますが、一般的にはこのパラメータを明示的に指定する必要はありません。 Nginx をコンパイルする前に、システムのドキュメントまたは関連するコンパイル オプションを確認して、libatomic を明示的に有効にする必要があるかどうかを理解することをお勧めします。

Q: Centos7.9 はアトミック操作をサポートしますか?
CentOS 7.9 はアトミック操作をサポートしますが、これは使用するハードウェアとコンパイラによって異なります。最新の x86_64 アーキテクチャでは、一般的に使用される GCC コンパイラーは、追加のライブラリ サポートを必要とせずに、ハードウェア命令を使用してアトミック操作を提供します。

CentOS 7.9 の GCC バージョンは比較的古い 4.8.5 ですが、x86_64 でのアトミック操作は引き続きサポートされています。したがって、一般的な使用では、--with-libatomic を明示的に有効にする必要はありません。

Nginx のコンパイル時にアトミック操作に関連する問題が発生した場合は、まずデフォルト設定を使用してみることをお勧めします。これは、ほとんどの場合、GCC は自動的にハードウェア サポートを使用してアトミック操作を提供するためです。デフォルト設定の使用に問題がある場合は、--with-libatomic パラメータを使用して libatomic サポートを有効にすることを検討してください。

Nginx をコンパイルする前に、システムにインストールされている GCC バージョンを確認し、GCC を新しいバージョンに更新する必要があるかどうかを検討できます。一般に、GCC の新しいバージョンでは、パフォーマンスが向上し、いくつかの新機能が提供されます。

03-068：--with-openssl=DIR

次の図に示すように、Nginx はシステムにアクセスして openssl ライブラリを検索するため、このパラメーターを明示的に指定する必要はありません。

--with-openssl=DIRこれは Nginx の構成パラメータの 1 つで、OpenSSL ライブラリのインストール パスを指定するために使用されます。 OpenSSL は、ネットワーク通信を暗号化し、安全なデータ送信を提供するために一般的に使用される Secure Sockets Layer (SSL) および Transport Layer Security (TLS) プロトコルを提供するオープン ソース ツールキットです。

--with-openssl=DIR パラメータを使用して Nginx をコンパイルする場合は、OpenSSL ライブラリのインストール パスを指定する必要があります。これは、Nginx をビルドするときに指定されたパスで OpenSSL ライブラリを検索し、それを Nginx バイナリにリンクするようにビルド システムに指示します。

ここでは、--with-openssl=DIR の使用方法を示す簡単な例を示します。

./configure --with-openssl=/path/to/openssl
make
make install

この例では、/path/to/openssl は OpenSSL ライブラリのインストール パスです。 --with-openssl パラメータを使用すると、指定したパスで OpenSSL ライブラリを検索するようにビルド システムに指示できます。

Nginx における OpenSSL の主な用途は、HTTPS トラフィックの暗号化と復号化です。 Nginx 構成ファイルで SSL/TLS 構成を有効にすると、Nginx は OpenSSL によって提供される暗号化アルゴリズムを使用してデータ送信のセキュリティを保護します。

一般に、--with-openssl=DIR パラメータは OpenSSL ライブラリのサポートを有効にし、OpenSSL ライブラリのインストール パスを指定します。これにより、Nginx はコンパイル時に OpenSSL ライブラリに適切にリンクし、実行時に暗号化および復号化機能を使用できるようになります。

03-069：--with-debug

不要なため、有効かどうかを気にする必要はありません。

--with-debugNginx の構成パラメータの 1 つで、Nginx のコンパイル時にデバッグ情報を有効にするために使用されます。このパラメーターを使用すると、Nginx はバイナリにさらに多くのデバッグ情報を含めるようになり、問題が発生した場合のトラブルシューティングとデバッグが容易になります。

ここでは、--with-debug の使用方法を示す簡単な例を示します。

./configure --with-debug
make
make install

--with-debug パラメータを使用すると、ビルド システムには Nginx バイナリに追加のデバッグ情報が含まれます。この情報には変数名、行番号などが含まれており、デバッガでのコード実行の特定の状況を分析するのに役立ちます。

実稼働環境では、バイナリのサイズが増加し、パフォーマンスにも影響を与える可能性があるため、Nginx でデバッグ モードを有効にすることは通常推奨されません。運用環境では、--with-debug パラメータを指定しない通常の構成でコンパイルする必要があります。

開発環境またはトラブルシューティングが必要な場合、--with-debug パラメータを使用すると、開発者が問題を特定して解決するのに役立つ詳細なデバッグ情報が提供されます。

一般に、--with-debug パラメータは、トラブルシューティングや必要に応じてデバッグするために Nginx をコンパイルするときにデバッグ情報を含めるために使用されます。