Nginx は高性能の HTTP およびリバースプロキシ Web サーバーであり、メールの IMAP/POP3/SMTP サービスも提供します。Nginx は REST (Representational State Transfer) スタイルに基づいており、REST はプレゼンテーション層の状態転送とも呼ばれます。REST スタイルは HTTP プロトコルに基づいています. HTTP プロトコルはステートレスプロトコルとも呼ばれます. HTTP プロトコルの 7 つの一般的なアクションがあります: GET, POST, PUT, PATCH, DELETE, HEAD, OPTIONS. リソースの変更は、リソースの作成、変更、クエリ、削除などのプロセス。

公式サイト：nginx：ダウンロード

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

フォワードプロキシ: フォワードプロキシサーバーは、クライアントとターゲットサーバーの間に配置され、ターゲットサーバーからリソースを取得するために、クライアントがプロキシサーバーに要求を送信し、ターゲットサーバーを指定して、プロキシサーバーが要求を転送します。ターゲットサーバーに送信し、クライアントに返されたコンテンツを取得します。クライアントはフォワードプロキシを使用できます。

リバースプロキシ: リバースプロキシサーバーはクライアントとターゲットサーバーの間に配置されますが、クライアントにとっては、リバースプロキシサーバーはターゲットサーバーと同等です。つまり、クライアントはリバースプロキシサーバーに直接アクセスしてリソースを取得できます。ターゲットサーバー。クライアントはターゲットサーバーのアドレスを知る必要はなく、クライアントで設定を行う必要もありません。リバースプロキシサーバーは通常、Web アクセラレーションとして使用できます。つまり、リバースプロキシを Web サーバーのフロントエンドマシンとして使用して、ネットワークとサーバーの負荷を軽減し、アクセス効率を向上させます。

② プロジェクトでよく使われるNginxのアーキテクチャ図

③Nginxのメリット

a. zlib、PCRE、および OpenSSL を除く独自の関数ライブラリを持ち、標準モジュールはシステム C ライブラリ関数のみを使用します

b. 占有するメモリが少ない (3W の同時接続では、開始された 10 個の nginx プロセスが約 150M のメモリを消費します)

c. 高い同時実行能力 (5W の同時接続をサポートし、実稼働環境で 2 ～ 3W の同時接続に到達可能) シンプルな構成、オープンソース、無料の価格

d. 帯域幅を節約します (GZIP 圧縮転送をサポートします。ローカルキャッシュを閲覧するために HEAD ヘッダーを追加できます)。

e. Rewriter リライトをサポートします (異なるドメイン名と URL に従って、HTTP 要求を異なるバックエンドサーバーグループに分割できます)。

二、NGINXのインストール

1.ダウンロード

nginx 公式 Web サイトから適切なバージョンの nginx を選択してローカルにダウンロードし、ファイルアップロードツールを使用して Linux サーバーにアップロードします。

ダウンロードパス: /data/nginx-1.16.1.tar.gz

2.解凍する

解凍: tar -zxvf nginx-1.16.1.tar.gz

chown -R root:root nginx-1.16.1/ —— (所有者のパーミッションを変更することをお勧めします)

ディスク容量のサイズに応じて、nginx のインストールパスを決定します: /data/nginx

3. コンパイル

[root@hjr23 ~]# cd /data/nginx-1.16.1

[root@hjr23 nginx-1.16.1]# ./configure --prefix=/data/nginx --nginx インストールパス

--with-http_gzip_static_module

--with-http_stub_status_module

--with-http_ssl_module ——nginxのHTTPSアクセス方式を実現するために追加が必要なモジュール

--with-pcre

--with-file-aio

--with-http_realip_module

--add-module=/data/nginx-module-vts-master - nginx モニタリングを実現するには、モジュールを追加する必要があります

## デプロイされた nginx サーバーにモジュールを追加する必要がある場合は、再コンパイルして make を実行し (make install を実行しないでください。実行しないと、以前のインストールが上書きされます)、コンパイルされた nginx を上書きします nginx can:

cd /データ/nginx/sbin

mv nginx nginx_bak

cp /data/nginx-1.16.1/objs/nginx /data/nginx/sbin/

4. インストール

[root@hjr23 nginx-1.16.1]#make

[root@hjr23 nginx-1.16.1]#make install

または同時に実行: make && make install

##nginx のコンパイルおよびインストールプロセス中にいくつかの依存パッケージが欠落している場合は、実際の状況に応じて依存パッケージをインストールできます.上記の構成パラメーターモジュールに従って、依存パッケージをインストールする必要があります。

yum -y install gcc zlib zlib-devel pcre pcre-devel openssl openssl-devel

nginx サービスを表示します。

ll /data/nginx/

3.NGINXの起動

1.手動起動

[root@hjr23 nginx]# /data/nginx/sbin/nginx - 開始

[root@hjr23 nginx]# /data/nginx/sbin/nginx -s reload ——重载

[root@hjr23 nginx]# /data/nginx/sbin/nginx -s stop ——停止

[root@hjr23 nginx]# /data/nginx/sbin/nginx -V - nginx のバージョンを表示

プロセスとポートを表示: ps -ef | grep nginx

netstat -anp | grep プロセス ID

## nginx.conf の構成情報:

worker_processes 8

nginx サーバーは 9091 と 9092 をリッスンします

2. システムサービス開始

> nginx サービスをシステムサービスに追加し、起動時に自動的に開始するように設定します

[root@centos7-min7 システム]# cat /etc/systemd/system/nginx.service

[ユニット]

説明=nginx

After=network.target

[サービス]

タイプ=フォーク

#PIDFile=/md5/nginx/logs/nginx.pid

ExecStart=/md5/nginx/sbin/nginx

ExecReload=/md5/nginx/sbin/nginx -s リロード

ExecStop=/md5/nginx/sbin/nginx -s 停止

再起動=失敗時

RestartSec=5

#PrivateTemp=真

[インストール]

WantedBy=マルチユーザー.ターゲット

systemctl デーモン-リロード

systemctl start nginx.service

systemctl enable nginx.service

リブート

systemctl ステータス nginx.service

四、NGINXの設定

1.Nginxの基本設定

# vi /data/nginx/conf/nginx.conf —— nginx 設定ファイル

ユーザールート;

worker_processes 8; ——CPU コア数 lscpu

イベント {

worker_connections 8192; —— 8*1024=8192

}

http {

server_tokens off; —— nginx のバージョンを外部から隠す

mime.types を含めます。

vhost_traffic_status_zone;

vhost_traffic_status_filter_by_host on; ——nginx監視用に設定された情報

default_type アプリケーション/オクテットストリーム;

log_format main '{"time_local":"$time_local","request":"$request","http_host": "$http_host", "source_addr": "$http_x_forwarded_for", "http_code": "$status"," bytes_sent": "$bytes_sent","hostname":"$hostname", "player_id":"$upstream_http_player_id","request_body":"$request_body","remote_addr":"$remote_addr"}'; ——nginx日志打印配置

access_log ログ/access.log メイン;

sendfile オン;

#tcp_nopush on;

キープアライブ_タイムアウト 65;

#gzip オン;

##server{ - ヘッダー攻撃の処理

## リッスン 9091 デフォルト。

＃＃サーバーの名前 _;

## 500 を返します。

##}

サーバー {

#9092を聞く;

＃サーバーの名前 ****;

#charset koi8-r;

#access_log ログ/host.access.log メイン;

# サーバーエラーページを静的ページ /50x.html にリダイレクト

error_page 500 502 503 504 /50x.html;

場所 = /50x.html {

ルート html;

}

2.Nginxは動的サービスを転送します

クライアントは、Nginx によって転送されたサービスにアクセスします。

http{

上流管理者{

server 192.168.0.72:8083 weight=5; ——負荷割合

}

サーバー {

9091 ssl をリッスンします。

サーバー名 ****.com;

ssl_certificate /data/nginx/ssl/***.cer;

ssl_certificate_key /data/nginx/ssl/***.pem;

ssl_session_cache 共有:SSL:1m;

ssl_session_timeout 5m;

ssl_ciphers HIGH:!aNULL:!MD5;

ssl_prefer_server_ciphers on;

#運営側

場所/管理者{

proxy_set_header X-Real-IP $remote_addr;

proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;

proxy_set_header ホスト $http_host;

proxy_set_header X-Nginx-Proxy true;

proxy_pass http://admins/admin;

proxy_redirect オフ;

}

3. Nginx が静的リソースを転送する

クライアントから要求された静的リソースは、Nginx に渡すことができます。ただし、Nginx は Nginx サーバー上の静的リソースのみを転送できます。

動的と静的の分離: ①静的リソースをnginxプロキシサーバーに配置します

② 静的ファイルを別のドメイン名に分割し、別のサーバーに配置する (主な推奨ソリューション)

4.NginxはHTTPSアクセス方式をサポート

Nginx は HTTPS プロトコル転送サービスをサポートしており、SSL 証明書が必要です. 正式な証明書を申請するか、自分で証明書を生成できます. 本番環境では正式な証明書が必要です.

①SSL証明書とキーファイルを生成する

opensslを使用してhttps証明書とキーファイルを生成する

mkdir /usr/local/nginx/conf/ssl

#サーバー証明書キーファイルserver.keyを作成します。

openssl genrsa -des3 -out server.key 2048 --------------(1qaz@WSX3edc)

#サーバー証明書用のアプリケーションファイルserver.csrを作成します。

openssl req -new -key server.key -out server.csr

#サーバーキーファイルのバックアップ

cp server.key server.key.org

#ファイルのパスワードを削除

openssl rsa -in server.key.org -out server.key

#証明書ファイルserver.crtの生成

openssl x509 -req -days 3650 -in server.csr -signkey server.key -out server.crt

②nginx.confを修正

サーバー {

9092 ssl をリッスンします。

サーバー名 ****.com;

ssl_certificate /data/nginx/ssl/***.cer; ——SSL証明書

ssl_certificate_key /data/nginx/ssl/***.pem; ——SSL キー

ssl_session_cache 共有:SSL:1m;

ssl_session_timeout 5m;

ssl_ciphers HIGH:!aNULL:!MD5;

ssl_prefer_server_ciphers on;

場所/ステータス {

vhost_traffic_status_display;

vhost_traffic_status_display_format html;

}

5. Nginxログ印刷リクエストのヘッダーパラメータ

①LuaJITをインストール

lua (www.lua.org) は、他のアプリケーションに組み込むために開発されたスクリプト言語です。luajit (www.luajit.org) は、ランタイムコンパイル用の lua Just-In-Time 変換です。nginx は、LuaJIT が提供する関数を使用してリクエストヘッダーパラメーターを取得します。

1.LuaJIT をインストールする

wget http://luajit.org/download/LuaJIT-2.0.5.tar.gz

タール -zxvf LuaJIT-2.0.5.gz && cd LuaJIT-2.0.5

make && make install PREFIX=/usr/local/luajit

#2 つの環境変数をインポートする

export LUAJIT_LIB=/usr/local/luajit/lib

export LUAJIT_INC=/usr/local/luajit/include/luajit-2.0

2. ngx_devel_kit と lua-nginx-module をダウンロードします

wget https://github.com/simplresty/ngx_devel_kit/archive/v0.3.1rc1.tar.gz

tar -xzvf ngx_devel_kit-0.3.1rc1.tar.gz

wget https://github.com/openresty/lua-nginx-module/archive/v0.10.14rc3.tar.gz

タール -xzvf v0.10.14rc3.tar.gz

3. nginx ソースデータディレクトリに入り、nginx を再コンパイルします。

./configure --prefix=/usr/local/nginx --with-http_stub_status_module --with-http_ssl_module --with-threads --with-stream --add-module=/root/nginx_modules/lua-nginx-module- 0.10.14rc3 --add-module=/root/nginx_modules/ngx_devel_kit-0.3.1rc1

作る

[root@sjjy03 nginx-1.16.1]# cp objs/nginx /usr/local/nginx/sbin/

[root@gp-master sbin]# ./nginx

./nginx: 共有ライブラリの読み込み中にエラーが発生しました: libluajit-5.1.so.2: 共有オブジェクトファイルを開けません: そのようなファイルやディレクトリはありません

vi /etc/ld.so.conf

新しい /usr/local/luajit/lib を追加します

ファイルを保存し、ldconfig を実行します。

②nginx.confの設定を修正

1. http の access.log のログ形式をカスタマイズする{}

log_format log_req_resp '$remote_addr - $remote_user [$time_local] "$request" $status $body_bytes_sent "$http_referer" "$http_user_agent" $request_time '

'req_header:"$req_header" resp_header:"$resp_header" - $server_name - $server_port - $server_protocol ';

2. http リクエストヘッダーとリターンヘッダーを取得する

3. httpsリクエストヘッダーとリターンヘッダーを取得する

6. Nginx アンチ DoS 攻撃、CC 攻撃

DoS とは Denial of Service の略、つまり Denial of Service であり、DoS を引き起こす攻撃行為を DoS 攻撃と呼び、コンピュータやネットワークを正常なサービスを提供できなくすることを目的としています。最も一般的な DoS 攻撃は、コンピューターネットワークのブロードバンド攻撃と接続性攻撃です。

DoS 攻撃とは、ネットワークプロトコルの実装の欠陥に対する意図的な攻撃、または残忍な手段による攻撃対象のリソースの残忍な枯渇を指し、標的のコンピュータまたはネットワークが通常のサービスまたはリソースへのアクセスを提供できないようにすることを目的としています。、その結果、ターゲットシステムサービスシステムが応答を停止します。これらのサービスリソースには、ネットワーク帯域幅、ファイルシステム容量、開いているプロセス、または許可された接続が含まれます。この種の攻撃はリソースの不足につながります。コンピューターの処理速度がどれほど速くても、メモリ容量が大きくても、ネットワーク帯域幅がどれほど速くても、この種の攻撃の結果は避けられません。

ほとんどの DoS 攻撃は依然としてかなりの帯域幅を必要とし、個々のハッカーが高帯域幅のリソースを使用することは困難です。この欠点を克服するために、DoS 攻撃者は分散攻撃を開発します。攻撃者は、ツールを使用して大量のネットワーク帯域幅を収集し、同じターゲットに対して同時に多数の攻撃要求を開始する.これがDDoS (分散型サービス拒否) 攻撃です.

攻撃者は、プロキシサーバーを使用して、被害者のホストに向けた正当な要求を生成し、DDOSとカモフラージュ: CC (Challenge Collapsar) を実現します。

実技試験参考：https://www.cnblogs.com/wpjamer/p/9030259.html

五、Nginxのログセグメンテーション

[root@hjr23 ログ] # 猫 nginx_log.sh

#!/ビン/バッシュ

##ログファイル格納ディレクトリの設定

LOG_HOME="/data/nginx/logs"

## バックアップファイル名

LOG_NAME_BAK="$(date -d 昨日 +%Y%m%d%H%M)".access.log

## ログファイルの名前を変更

mv ${LOG_HOME}/access.log ${LOG_HOME}/${LOG_NAME_BAK}.log

## ログを再度開くように nginx マスタープロセスにシグナルを送る

##USR シグナルの説明 USR1 は通常、アプリケーションに構成ファイルをリロードするように指示するためにも使用されます。

kill -USR1 `cat /data/nginx/logs/nginx.pid`

##crontab -l

##crontab -e

##0 2 * * * エクスポート DISPLAY=:0; sh /data/nginx/logs/nginx_log.sh

#find ${LOG_NAME} -type f -mtime +30 ".log" -exec rm -rf {}\;

/data/nginx/logs/ を見つけます -type f -mtime +30 | grep ".log.log" | xargs rm -rf {};

タイミングタスクの実行は crond サービスに依存します

》nginxログの一般的な統計分析コマンド

IP 関連の統計

統計 IP 訪問 (独立した IP 訪問の数):

awk '{print $1}' access.log | 並べ替え -n | ユニーク | トイレ -l

一定期間の IP 訪問を確認します (ポイント 4-5):

grep "2017/04/07:0[4-5]" access.log | awk '{print $1}' | ソート | ユニーク -c| 並べ替え -nr | トイレ -l

最も訪問された上位 100 の IP を表示します。

awk '{print $1}' access.log | 並べ替え -n |uniq -c | 並べ替え -rn | 頭 -n 100

100 回以上の訪問がある IP を表示:

awk '{print $1}' access.log | sort -n |uniq -c |awk '{if($1 >100) print $0}'|sort -rn

アクセス頻度でソートされた、IP の詳細なアクセスステータスをクエリします。

grep '127.0.01' access.log |awk '{print $7}'|sort |uniq -c |sort -rn |head -n 100

ページアクセス統計

最も頻繁にアクセスされるページ (TOP100) を表示:

awk '{print $7}' access.log | 並べ替え |uniq -c | 並べ替え -rn | 頭 -n 100

最も頻繁にアクセスされるページを表示します ([php ページを除く] (TOP100):

grep -v ".php" access.log | awk '{print $7}' | 並べ替え |uniq -c | 並べ替え -rn | 頭 -n 100

アクセス数が 100 を超えるページを表示:

猫のアクセスログ | カット -d ' ' -f 7 | 並べ替え |uniq -c | awk '{if ($1 > 100) print $0}' | 以下

最も訪問されたページである最新の 1000 レコードを表示します。

tail -1000 access.log |awk '{print $7}'|sort|uniq -c|sort -nr|less

1 秒あたりのリクエスト数の統計

1 秒あたりのリクエスト数をカウントし、top100 の時点 (秒までの精度)

awk '{print $4}' access.log |cut -c 14-21|sort|uniq -c|sort -nr|head -n 100

1 分あたりの統計

1分間あたりのリクエスト数をカウントし、top100の時点（分単位まで正確）

awk '{print $4}' access.log |cut -c 14-18|sort|uniq -c|sort -nr|head -n 100

1 時間ごとのリクエスト統計

1 時間あたりのリクエスト数をカウントし、top100 の時点 (時間単位で正確)

awk '{print $4}' access.log |cut -c 14-15|sort|uniq -c|sort -nr|head -n 100

パフォーマンス分析

$request_time を nginx ログの最後のフィールドに追加します

転送時間が 3 秒を超えるページを一覧表示し、最初の 20 を表示します

cat access.log|awk '($NF > 3){print $7}'|sort -n|uniq -c|sort -nr|head -20

PHPのページリクエスト時間が3秒を超えたページを一覧表示し、出現回数をカウントして最初の100ページを表示

cat access.log|awk '($NF > 3 && $7~/\.php/){print $7}'|sort -n|uniq -c|sort -nr|head -100

現在の TCP 接続数を表示する

netstat -タン | grep "確立されました" | grep ":80" | トイレ -l

tcpdump を使用してポート 80 へのアクセスを盗聴し、誰が最も高いかを確認します。

tcpdump -i eth0 -tnn dst ポート 80 -c 1000 | awk -F"." '{print $1"."$2"."$3"."$4}' | ソート | ユニーク -c | 並べ替え -nr

六、Nginxの監視

Nginx は nginx-module-vts モジュールを通じて nginx の特定のインデックスデータを取得し、Prometheus は nginx-vts-exporter コンポーネントを通じて nginx 情報を収集します。

nginx-module-vts モジュールをインストールする

GitHub - vozlt/nginx-module-vts: Nginx 仮想ホストトラフィックステータスモジュール —— (ダウンロードする zip パッケージを選択)
nginx をコンパイルしてインストールする

./configure --prefix= /data/nginx --with-http_gzip_static_module --with-http_stub_status_module --with-http_ssl_module --with-pcre --with-file-aio --with-http_realip_module --add -module=/ data/nginx-module-vts

作る

cd /データ/nginx/sbin

mv nginx nginx_bak

cp /data/nginx-1.16.1/objs/nginx /data/nginx/sbin/

nginx.conf ファイルを変更する

http{

vhost_traffic_status_zone;

vhost_traffic_status_filter_by_host on;

場所/ステータス {

vhost_traffic_status_display;

vhost_traffic_status_display_format html;

}

b. nginx-vts-exporter をインストールします

cat /etc/systemd/system/nginx-vts-exporter.service

[ユニット]

説明=nginx_exporter

After=network.target

[サービス]

タイプ=シンプル

ユーザー=ルート

ExecStart=/data/nginx-vts-exporter/nginx-vts-exporter -nginx.scrape_uri= https://****:9092 /status/format/json

再起動=失敗時

[インストール]

WantedBy=マルチユーザー.ターゲット

##systemctl enable nginx-vts-exporter

##systemctl start nginx-vts-exporter

c. Nginx 監視パネルを表示する

https://****:9091/status

nginx 監視パネルnginx-vts-exporter 2949 をgrafana にインポートし、パネルを表示します

d. トラフィック監視ツール iftop

[root@centos7-vpn opt]# yum install flex byacc libpcap ncurses ncurses-devel libpcap-devel

[root@centos7-vpn opt]# rpm -ivh iftop-1.0-0.pre3.el7.rf.x86_64.rpm

[root@centos7-vpn opt]# iftop -i ens33

e. プロジェクトのログ管理

> root ユーザーによってデプロイされたプロジェクト

[root@hjr24 ログ]# 猫 /data/logs/log.sh

#!/ビン/バッシュ

バックアップ='/データ/ログ'

${backup} を検索 -type f -mtime +10 -exec rm -rf {} \;

[root@hjr24 ログ]# crontab -l

0 5 * * * /usr/sbin/ntpdate -u cn.pool.ntp.org

0 22 * * * sh /data/logs/log.sh

10 22 * * * sh /data/logs/log.sh

> 通常のユーザーによってデプロイされたプロジェクト

[hjrypt@hjr25 ログ]$ cat log.sh

#!/ビン/バッシュ

バックアップ='/データ/ログ'

${backup} を検索 -type f -mtime +10 -exec rm -rf {} \;

[root@hjr25 ログ]# crontab -u hjrypt -e

[hjrypt@hjr25 ログ]$ crontab -l

00 20 * * * sh /data/logs/log.sh

7、Nginx の高い同時実行性 (負荷分散)

1. Nginxの高並行性の原則

多数のユーザーがブラウザ経由でプログラムへのアクセスリクエストを送信します. Nginx は最初にユーザーのリクエストを受信し、負荷分散戦略に従って別のサーバー上のプログラムにリクエストを転送します. 適切なユーザーブラウザに転送されます.

写真のように:

2. Nginx の高同時実行性の役割

Nginx の高同時実行機能は、多数のユーザーが同時にプログラムにアクセスするという問題に対して「水平的」なソリューションを提供しますが、プログラム処理要求によって消費されるリソースと応答速度は、実稼働シナリオのニーズを満たすことができません。具体的な方法は、負荷分散戦略を採用し、プログラムを複数の異なるマシンに展開し、マシンのパフォーマンスに応じて要求の負荷を分散することです。Nginx は負荷に応じてユーザーリクエストをマシンに転送します. 複数のマシンが受信したリクエストを同時に並行して処理し、処理して結果を返すことで、リクエストの応答速度が向上し、サーバーリソースの枯渇やサーバーへのクラッシュなどの重大な問題が回避されます。ある程度。

3. Nginx の高同時実行最適化

① Linux カーネルの最適化

/etc/sysctl.conf で関連するパラメータを調整します

②nginxの最適化

Nginx 構成ファイル nginx.conf で関連するパラメーターを調整します。

worker_processes = CPU コア数 * 2

worker_rlimit_nofile = (ulimit -n) ワーカープロセスが開くことができるファイルハンドルの最大数

イベント{

epoll を使用します。

worker_connections 65535; プロセスごとに許可される接続の最大数

multi_accept on;

}

③サーバーのCPUとメモリを拡張する

4. Nginx の高い同時実行性とリソース要件

単位時間あたりの nginx の最大同時実行数 (keepalive_timeout) C

C=worker_processes * worker_connections/2

および 1 秒あたりの同時実行数 CS

CS=worker_processes * worker_connections/(2* keepalive_timeout)

ロードバランシングで使用される最小サーバーリソースは、プロダクションアクティビティの最大同時実行数に基づいて計算できます。

5. Nginx 負荷分散の構成

a. 負荷分散構成

http{

上流のドッカー{

サーバー 192.168.20.77:9000 重量 = 1;

サーバー 192.168.20.78:9000 重量 = 2;

}

サーバー {

聞く 8081;

サーバー名 192.168.20.77;

位置 / {

proxy_pass http://dockers;

proxy_redirect オフ;

}

...

}

b. 負荷分散戦略

1. ポーリング方法

2.加重ポーリング方式（加重が異なります）

http{

上流のトムキャット{

サーバー tomcat-01:8080 重量 = 1;

サーバー tomcat-02:8080 重量 = 1;

server tomcat-02:8080 weight=2; 負荷率が高いほど、より多くのリクエストを受信して処理します

}

3. 送信元アドレスハッシュ方式

取得したクライアントの IP アドレスに基づいて、ハッシュ関数を介して数値が計算され、その値を使用してサーバーリストのサイズが計算されます。得られた結果は、クライアントが要求するサーバーのシリアル番号です。アクセス。サーバーリストが変更されていない場合、同じ IP を持つクライアントが同じサーバーにアクセスするため、セッションの問題を解決できます。

上流のトムキャット{

ip_hash;

サーバー tomcat-01:8080 重量 = 1;

サーバー tomcat-02:8080 重量 = 1; }

4、接続方法の最小数

バックエンドサーバーの現在の接続状態に応じて、接続のバックログが最も少ないサーバーを動的に選択して現在の要求を処理し、バックエンドサービスの利用効率を可能な限り向上させます。

上流のトムキャット{

少なくとも_conn;

サーバー tomcat-01:8080 重量 = 1;

サーバー tomcat-02:8080 重量 = 1; }

5・フェア

ページサイズと読み込み時間に応じてインテリジェントに負荷分散を行い、サーバーの対応時間に応じて応答時間が短いものを優先します

Nginx自体は fair をサポートしていないため、upstream_fair モジュールをインストールする必要があります

上流のトムキャット{

公平;

サーバー tomcat-01:8080 重量 = 1;

サーバー tomcat-02:8080 重量 = 1; }

6、url_hash

訪問した URL のハッシュ結果に従ってリクエストを分散し、各 URL がバックエンドサーバーに送信されるようにします。

Nginx自体はハッシュをサポートしていないため、nginxのハッシュパッケージをインストールする必要があります

上流のトムキャット{

ハッシュ $request_uri;

サーバー tomcat-01:8080 重量 = 1;

サーバー tomcat-02:8080 重量 = 1; }

8、Nginx の高可用性

1. Keepalived の動作原理

レイヤ 3、4、および 5 は、IP/TCP プロトコルスタックの IP レイヤ、TCP レイヤ、およびアプリケーションレイヤで機能します。原則は次のとおりです。

Layer3: Keepalived が Layer3 モードで動作する場合、Keepalived は定期的にサーバーグループ内のサーバーに ICMP パケットを送信します (つまり、私たちが通常使用する Ping プログラムです). サービスの IP アドレスが非アクティブであることが判明した場合、Keepalived はreport This server fails and removes it from the server farm. この状況の典型的な例は、サーバーが不正にシャットダウンされた場合です。サーバーが正常に動作しているかどうかの基準として、サーバーのIPアドレスが有効かどうかを利用するのがLayer3のやり方です。

Layer4：Layer3のやり方がわかればLayer4は簡単です。Layer4 は、主に TCP ポートの状態に基づいて、サーバーが正常に動作しているかどうかを判断します。たとえば、Web サーバーのサービスポートは通常 80 です。Keepalived がポート 80 が開始されていないことを検出すると、Keepalived はこのサーバーをサーバーグループから削除します。

Layer5: Layer5 は、指定された URL に対して HTTP GET を実行します。HTTP GET の結果は、MD5 アルゴリズムを使用して合計されます。この合計が期待値と一致しない場合、テストは正しくなく、サーバーはサーバープールから削除されます。このモジュールは、同じサービスに対して複数の URL フェッチチェックを実装します。この機能は、複数のアプリケーションサーバーをホストするサーバーを使用している場合に便利です。この機能を使用すると、アプリケーションサーバーが正常に動作していることを確認できます。MD5 ダイジェストは、genhash ユーティリティ (keepalived パッケージに含まれています) を使用して生成されます。

注: 2 つの nginx サービスを同じマシンで開始できますが、keepalived を使用して ng の高可用性を実現することはできません。keepalived には少なくとも 2 台のマシンが必要です。

2.キープアライブ機能

Keepalived の機能は、サーバーの状態を検出することであり、Web サーバーがダウンしたり、作業に失敗した場合、Keepalived はそれを検出して、障害のあるサーバーをシステムから削除し、他のサーバーを使用してサーバーの作業を置き換えます。 Keepalived は、作業が正常になるとサーバーをサーバーグループに自動的に追加します. これらのすべてのタスクは、手動の介入なしで自動的に完了します. 手動作業が必要なのは、障害のあるサーバーを修復することです.

高同時実行指標:

① 応答時間：システムがリクエストに応答するまでの時間

②スループット：単位時間あたりに処理されるリクエスト数

③QPS：1秒あたりのレスポンスリクエスト数

インターネット分散アーキテクチャ設計、システムの同時実行性を向上させる方法:

1. 垂直拡張 (スタンドアロンハードウェアのパフォーマンスの向上 | スタンドアロンアーキテクチャのパフォーマンスの向上)

2. 横展開（サーバー増設）

同時実行性が高い場合、Nginx は現在の制限方法を構成します. 最初の 2 つの方法は、クライアントにのみ使用できます (つまり、単一 IP の現在の制限)

1、limit_conn_zone

2、limit_req_zone

3、ngx_http_upstream_module

3. キープアライブをインストールする

keepalived アドレスをダウンロード: Linux 用 Keepalivedまたは Yum から直接インストール: yum install keepalived -y

Keepalived のすべての機能は、keepalived.conf ファイルを構成することによって実装されます。

cd /opt/

tar -zxvf keepalived-2.0.20.tar.gz -C /opt/

chown root:root keepalived-2.0.20

cd キープアライブ-2.0.20

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

メイク && メイクインストール

Keepalived を Linux システムサービスとしてインストールします。

mkdir /etc/keepalived

構成ファイルをコピーします。

cp /usr/local/keepalived/etc/keepalived/keepalived.conf /etc/keepalived/

keepalived スクリプトファイルをコピーします。

cp /usr/local/keepalived/etc/sysconfig/keepalived /etc/sysconfig/

cp /opt/keepalived-2.0.20/keepalived/etc/init.d/keepalived /etc/init.d/ -----解凍したインストールパッケージからコピー

ln -s /usr/local/keepalived/sbin/keepalived /sbin/

ln -s /usr/local/keepalived/sbin/keepalived /usr/sbin/

chkconfig keepalived on | systemctl enable keepalived.service ----------ブートを再起動に設定

systemctl start キープアライブ

systemctl ステータスキープアライブ

4.キープアライブを構成する

もう 1 つ注意すべき点は、keepalived は起動時に構成ファイルの構文が正しいかどうかをチェックしないため、構成ファイルを記述する際には注意が必要であり、間違って記述しないようにする必要があります。そうしないと、予期しない現象が発生する可能性があります。

NGINX のアクティブおよびスタンバイの自動再起動を構成します。

構成ファイルを変更します: vim /etc/keepalived/keepalived.conf

1 ) マスター NGINX 構成を変更する

global_defs {

router_id node7 #ホスト名

#vrrp_strict ——これをコメントアウトする必要があります。VIP は ping を通過できます

}

vrrp_script chk_nginx{

スクリプト「/etc/keepalived/nginx_check.sh」

interval 2 #nginx のステータスを 2 秒ごとにチェック

weight -20 #priority 失敗時に 20 を引く

秋 3

上昇 2

}

vrrp_instance VI_1 {

状態マスター

interface ens33 # VIP のネットワークインターフェイスをバインドします

virtual_router_id 51 #仮想ルーターのID番号、運用系ノードと待機系ノードの設定は同じ

priority 100 #ノードの優先度、0 ～ 254、MASTER は BACKUP よりも高い

advert_int 1 #マルチキャスト情報送信間隔、運用系と待機系の設定は同じ

authentication { #検証情報のプライマリノードとセカンダリノードの設定が一致していることを確認します

auth_type PASS

auth_pass 1111

}

virtual_ipaddress {

#192.168.200.16

#192.168.200.17

192.168.20.10/24 #プライマリノード 192.168.20.77 スタンバイノード 192.168.20.78

}

track_script{

chk_nginx #nginx 生存状況検出スクリプト

}

2 ）バックアップNGINX構成を変更します

global_defs {

router_id node8 #ホスト名

#vrrp_strict ——これをコメントアウトする必要があります。VIP は ping を通過できます

}

vrrp_script chk_nginx{ - MASTER と同じ

スクリプト「/etc/keepalived/nginx_check.sh」

interval 2 #nginx のステータスを 2 秒ごとにチェック

weight -20 #priority 失敗時に 20 を引く

秋 3

上昇 2

}

vrrp_instance VI_1 {

状態のバックアップ

インターフェースens33

virtual_router_id 51

プライオリティ 90

advert_int 1

認証 {

auth_type PASS

auth_pass 1111

}

virtual_ipaddress {

192.168.20.10/24

}

track_script{

chk_nginx #nginx 生存状況検出スクリプト

}

5. Nginx サービスの検出

nginx_check.shスクリプトは、2 台のマシンの/etc/keepalived/フォルダーにコピーされます。

実行権限を付与します: chmod +x /etc/keepalived/nginx_check.sh

#!/ビン/バッシュ

A=`ps -C nginx --no-header | wc -l`

[ $A -eq 0 ]; の場合

/usr/local/nginx/sbin/nginx #nginx を再起動してみてください

sleep 2 # 2 秒間スリープ

if [ `ps -C nginx --no-header | wc -l` -eq 0 ];その後

systemctl stop keepalived #起動に失敗しました。keepalived サービスを強制終了します。vip を他のバックアップノードに移行する

フィ

2台のマシンのnginxを起動した後。両方のマシンでキープアライブを開始します

/usr/local/nginx/sbin/nginx

systemctl start キープアライブ

keepalivedを開始できませんでした。ログレコードを確認してください: vi /var/log/messages ps -ef | grepnginx ps -ef | grepkeepalived

2 台のマシンのip aコマンドを見ると、仮想IPが表示されます。Keepalived を閉じずにテストし、NGINX を強制終了してから、再起動するかどうかを観察します。Keepalivedを閉じ、NGINX を強制終了してから、再起動するかどうかを確認します。

systemctl start keepalived を使用して、MASTER マシンと BACKUP マシンで keepalived サービスを開始します。

ng マスターマシンとバックアップマシンは次のように構成されます。

サーバー {

80を聞いてください。

サーバー名 192.168.20.10; —— VIP

ng サービスがハングアップすると、MASTER 上の keepalived が生きている限り、MASTER 上の nginx をプルアップします. ng が起動しない場合、MASTER 上の keepalived は自動的に切断され、 BACKUP でサポートされている BACKUP の keepalived 外部サービスを引き続き提供します。

###

同じマシンで 2 つの nginx サービスを有効にする

[root@node7 keepalived]# 猫 nginx_check.sh

#!/ビン/バッシュ

A8081=`netstat -anp | grep 8081 | awk '{print $7}'`

B8081=${A8081%%/*}

エコー $B8081

ng1=`ps -C $B8081 --ヘッダーなし | wc -l`

[ $ng1 -eq 0 ];その後

/usr/local/nginx/sbin/nginx #nginx1 を再起動してみてください

フィ

A8082=`netstat -anp | grep 8082 | awk '{print $7}'`

B8082=${A8082%%/*}

ng2=`ps -C $B8082 --ヘッダーなし | wc -l`

[ $ng2 -eq 0 ];その後

/usr/local/nginx2/sbin/nginx #nginx2 を再起動してみてください

フィ

9. Nginx は CC 攻撃を処理します

1. CC 攻撃原理

攻撃者は、プロキシサーバーを使用して、被害者のホストに向けた正当な要求を生成し、DDOSとカモフラージュ: CC (Challenge Collapsar) を実現します。

2. CC 攻撃の種類

CC 攻撃には、直接攻撃、プロキシ攻撃、ボットネット攻撃の 3 種類があり、直接攻撃は主に、重大な欠陥のある Web アプリケーションを対象としています. 一般的に、プログラムに問題があり、比較的まれに作成されている場合に発生します. ボットネット攻撃は DDOS 攻撃に少し似ています. Web アプリケーションレベルから防御することはできないため、プロキシ攻撃は CC です. 攻撃者は通常、たとえば 100 個のプロキシなどのプロキシサーバーのバッチを操作し、各プロキシは 10 個のプロキシを送信しますこれにより、WEB サーバーは同時に 1000 の同時リクエストを受信し、エージェントから返されたデータが自身の帯域幅をブロックすることを回避するために、リクエストの送信後すぐにエージェントとの接続を切断します。別のリクエストを開始できません. この時点で, WEB サーバーはこれらのリクエストに応答するプロセスをキューに入れます, そして同じことがデータベースサーバーにも当てはまります. このようにして, 通常のリクエストは最後に処理されます.カフェテリアで食事をする場合、通常は 10 人未満が並んでいます. 前に 1000 人が挿入されている場合、順番が来る可能性は非常に低くなります. このとき、ページが非常に遅く開くか、白い画面が表示されます.現れる。

3. スローアタックと Apache アンチスローアタック

この攻撃の基本原理は次のとおりです。HTTP アクセスを開く任意の HTTP サーバーに対して、最初に接続を確立し、比較的長いコンテンツ長を指定してから、1 バイトを 1 バイトで送信するなど、非常に低速でパケットを送信します。 -10s 、切断せずに接続を維持します。クライアントがそのような接続を確立し続けると、サーバーで利用可能な接続が少しずついっぱいになり、サービス拒否が発生します。

CC 攻撃と同様に、Web サーバーが Web サービスを開いている限り、それはターゲットになる可能性があります.HTTP プロトコルは、要求を受信する前に要求の内容を検証しないため、Web アプリケーションに使用可能なフォームがない場合でも、、この攻撃は同様に効果的です。

クライアント側で大量の無駄な接続をシングルスレッド方式で確立し、継続的にパケットを送信し続けるのは非常に安価です。実際のテストでは、通常の PC で 3000 以上の接続を確立できます。これは、通常の Web サーバーにとって致命的な打撃となります。分散 DoS のためのブロイラーの群れの組み合わせは言うまでもありません。

この攻撃の単純な使用法、サービス拒否の結果、および回避機能を備えた攻撃方法を考慮すると、このタイプの攻撃はヒットし、多くの攻撃者の研究および利用の対象となっています。

最も一般的に使用されるスロー攻撃ツールは、Slowhttptest と Slowloris です。

スロー攻撃の分類:

① スローヘッダー: HTTP ヘッダーには Web アプリケーションが使用する重要な情報が含まれているため、Web アプリケーションは HTTP 要求を処理する前にすべての HTTP ヘッダーを受信する必要があります。攻撃者はこれを利用して HTTP リクエストを開始し、HTTP ヘッダーを継続的に送信して、サーバー接続とメモリリソースを消費します。パケットキャプチャデータを見ることができます。攻撃しているクライアントは、サーバーとの TCP 接続を確立した後、30 秒ごとに HTTP ヘッダーをサーバーに送信します。Web サーバーが \r\n を 2 回連続して受信しない場合、次のように見なされます。クライアントは Finish ヘッダーを送信せず、クライアントがデータを送信するのを待ち続けます。

② スローボディ：攻撃者は、Content-Length ヘッダー値が大きい HTTP POST リクエストを送信し、クライアントが大量のデータを送信すると Web サーバーまたはプロキシに思わせます。サーバーはデータを受信できるように接続を維持しますが、攻撃側のクライアントは毎回少量のデータしか送信しないため、接続が維持され、サーバーの接続とメモリリソースが消費されます。パケットキャプチャデータから、攻撃しているクライアントがサーバーとの TCP 接続を確立した後、完全な HTTP ヘッダーを送信し、POST メソッドの Content-Length が大きく、10 秒ごとにランダムなパラメーターを送信することがわかります。サーバーは、対応する Content-Length 本文を受信していないため、クライアントがデータを送信するのを待ち続けます。

③ 低速読み取り: クライアントはサーバーとの接続を確立し、HTTP リクエストを送信します. クライアントは完全なリクエストをサーバーに送信し、この接続を維持します. 非常に低速でレスポンスを読み取ります. 例えば, クライアントはデータを読み取るために、Zero Window をサーバーに送信することにより、サーバーはクライアントがビジーであると誤って判断し、接続がタイムアウトするまでバイトを読み取らないため、サーバーの接続とメモリリソースを消費します。パケットキャプチャデータを見ることができます. クライアントがデータをサーバーに送信した後、サーバーが応答を送信すると、クライアントから ZeroWindow プロンプトを受け取り (データを受信するためのバッファーがないことを示します)、サーバーはZeroWindowProbe パケットをクライアントに連続的に送信し、クライアントがデータを受信できるかどうかを尋ねます。

スロー攻撃は、主にスレッドベースアーキテクチャのサーバーの特性を利用しており、この種のサーバーは、新しい接続ごとにスレッドを開き、HTTP ヘッダー全体が受信されるのを待ってから接続を解放します。たとえば、Apache にはこの不完全な接続を待機するためのタイムアウトがあります (デフォルトは 300 秒) が、クライアントから送信されたデータが受信されると、タイムアウトはリセットされます。このため、攻撃者はタイムアウトの直前に文字を送信するだけでタイムアウトを延長できるため、攻撃者は簡単に接続を維持できます。クライアントは、複数の接続を開くためにいくつかのリソースしか必要としません。これにより、サーバー上の多くのリソースが消費されます。

Apache および httpd は、スロー攻撃に対して脆弱なスレッドベースのアーキテクチャを採用していることが確認されています。また、nginx や lighttpd などの別の種類のイベントベースのサーバーは、速度が遅いため簡単には攻撃されません。

低速攻撃から Apache サーバーを保護する 3 つの方法

mod_reqtimeout

Apache2.2.15 以降、このモジュールはデフォルトで含まれており、ユーザーはクライアントから HTTP ヘッダーと HTTP ボディを受信する際のタイムアウトと最小レートを構成できます。クライアントが構成された時間内にヘッダーまたは本文データを送信できない場合、サーバーは 408 REQUEST TIME OUT エラーを返します。構成ファイルは次のとおりです。

< IfModule mod_reqtimeout.c >

RequestReadTimeout ヘッダー=20-40、MinRate=500 本体=20、MinRate=500

< /IfModule >

mod_qos

Apache のサービス品質管理モジュールであり、ユーザーはさまざまな粒度の HTTP 要求のしきい値を構成できます。構成ファイルは次のとおりです。

< IfModule mod_qos.c >

/# 最大 100000 の異なる IP からの接続を処理します

QS_ClientEntries 100000

/# IP ごとに 50 接続のみ許可

QS_SrvMaxConnPerIP 50

/# アクティブな TCP 接続の最大数を 256 に制限

最大クライアント数 256

/# 180 (70%) の TCP 接続が占有されている場合、キープアライブを無効にします

QS_SrvMaxConnClose 180

/# 要求/応答の最小速度 (遅いクライアントがサーバーをブロックすることを拒否し、何も要求せずに接続を開いたままにします)

QS_SrvMinDataRate 150 1200

< /IfModule >

mod_security

オープンソースの WAF モジュールには、スローアタック保護に特化したルールがあり、構成は次のとおりです。

SecRule RESPONSE_STATUS "@streq 408" "フェーズ:5,t:なし,nolog,pass, setvar:ip.slow_dos_counter=+1, expirevar:ip.slow_dos_counter=60, id:'1234123456'"

SecRule IP:SLOW_DOS_COUNTER "@gt 5" "フェーズ:1,t:なし,ログ,ドロップ,

msg:「スロー DoS アラートが多数発生したため、クライアント接続が切断されました」、id:「1234123457」

従来の交通清掃装置は、主にしきい値方式による CC 攻撃から保護しており、顧客が一定期間内にしきい値を超えて多くの訪問を要求した場合、清掃装置は検証コードまたは JS コードを返します。この保護方法の基礎は、攻撃者がボットで DDoS ツールを使用して多数の http 要求をシミュレートすることです. このツールは通常、JS などのコードはもちろん、サーバーから返されたデータを解析しません. そのため、クリーニングデバイスが HTTP リクエストを傍受すると、特殊な JavaScript コードを返し、通常のユーザーのブラウザはそれを処理して使用に影響を与えずに通常どおりジャンプしますが、攻撃プログラムは空きスペースを攻撃します。

スロー攻撃の場合、検証コードまたは JS コードを返すことで部分的な効果を得ることができます。ただし、スロー攻撃の特性に応じて、次の防御方法を支援できます。 1. 期間内のパケット数をカウントします。TCP 接続の場合、HTTP 要求パケットのパケット数が多すぎたり少なすぎたりする問題があります. サイクル内のパケット数が非常に少ない場合は、攻撃が遅い可能性があります. ファイル数が非常に多い場合は、攻撃が遅くなる可能性があります. CC 攻撃の可能性があります。2. HTTP 要求ヘッダーの最大許容時間を制限します。最大許容時間を超えて、データ転送が完了していない場合は、スローアタックである可能性があります。

4.NginxはCC攻撃を防ぎます

Nginxの構成

$binary_remote_addr は、クライアントの IP アドレスを示します

zone はリーキーバケットの名前を示します

rate は、nginx がリクエストを処理する速度を示します

バーストはピーク値を意味します

nodelay は、レートが設定を超えた場合に、リクエストの処理を遅らせるか、クライアントに直接 503 を返すかを示します。

詳細については、公式ドキュメントを参照してください: Module ngx_http_limit_req_module

Nginx には、クライアントリクエストを制限できる 2 つのモジュールがあり、リクエストの頻度が制限に達すると、インターセプトして 503 ステータスコードを返します。これら 2 つのモジュールにより、特定の攻撃保護効果を達成できます。

1. ngx_http_limit_conn_module:同時接続数を制限します。つまり、同時接続数を制限します

2. ngx_http_limit_req_module: ngx_http_limit_conn_module よりも高い優先度で、一定期間内のリクエスト数を制限します

ab モックリクエストをインストールする

ここでは、リクエストを生成するための小さなツール Apache Benchmark が必要です。

abをインストール

ダウンロード - The Apache HTTP Server Project下载 ab（Apache Benchmark）

[root@centos7-vpn opt]# tar -zxvf httpd-2.4.46.tar.gz

[root@centos7-vpn opt]# chown -R root.root httpd-2.4.46

[root@centos7-vpn httpd-2.4.46]# ./configure

APR (Apache ポータブルランタイムライブラリ) をインストールします。

[root@centos7-vpn opt]# tar -zxvf apr-1.4.5.tar.gz

[root@centos7-vpn opt]# chown root.root apr-1.4.5

[root@centos7-vpn apr-1.4.5]# ./configure && make && make install

APR をインストールした後、HTTPD を再度インストールしようとすると、APR-util not found というメッセージが表示されます

インストールAPR-util （Apache Portable Runtime Utility ライブラリ）

[root@centos7-vpn opt]# wget http://archive.apache.org/dist/apr/apr-util-1.3.12.tar.gz

インストール ( APRのビルドパスを指定する必要があります。これはインストールパスではなく、APRパッケージを解凍して生成されたパスであることに注意してください)

[root@centos7-vpn opt]# tar -zxvf apr-util-1.3.12.tar.gz

[root@centos7-vpn opt]# chown -R root.root apr-util-1.3.12

[root@centos7-vpn apr-util-1.3.12]# ./configure --with-apr=/opt/apr-1.4.5

[root@centos7-vpn apr-util-1.3.12]# make && make install

APRとAPR-util の両方が正常にインストールされ、 HTTPサービスをインストールできるようになりました。

インストール後、ab test ツールはHTTPDのデフォルトのインストールパス/binの下にあります。

[root@centos7-vpn httpd-2.4.46]# ./configure

[root@centos7-vpn httpd-2.4.46]# make && make install

http://192.168.16.40:8090/

Apache ab の圧力テスト

スループットレート (1 秒あたりの要求) の
概念: サーバーの同時処理能力の定量的な説明. 単位は reqs/s で、一定数の同時ユーザーの下で単位時間あたりに処理される要求の数を表します. 一定数の同時ユーザーの下で、単位時間あたりに処理できるリクエストの最大数は、最大スループットレートと呼ばれます。
計算式: リクエストの総数 / これらのリクエストを処理して完了するのにかかった時間、つまり、
1 秒あたりのリクエスト = リクエストの完了 / テストにかかった時間

同時接続数（同時接続数）の
概念：ある瞬間にサーバーが受け付けるリクエストの数、簡単に言えばセッションです。

同時ユーザー数 (Concurrency Level) の
概念: この概念と同時接続数の違いに注意してください. ユーザーは同時に複数のセッションを生成することができます, つまり接続数.

平均ユーザーリクエスト待機時間 (リクエストあたりの時間) の
計算式: すべてのリクエストを完了するのにかかる時間 / (リクエストの総数 / 同時ユーザー数)、つまり、リクエスト
あたりの時間 = テストにかかる時間 / (完全なリクエスト / 同時実行レベル)

サーバーの平均リクエスト待ち時間 (リクエストごとの時間: すべての同時リクエスト全体)
計算式: すべてのリクエストを完了するのにかかった時間/リクエストの総数、つまり、
所要時間/テストの完全なリクエスト
を見ることができ、スループットの逆数です。
同時に、= 平均ユーザーリクエスト待機時間 / 同時ユーザー数、つまり、
リクエストあたりの時間 / 同時実行レベル

[root@centos7-vpn bin]# ./ab –help

[root@centos7-vpn nginx]# ./ab -t 30 -c 1 http://192.168.16.40:8090/

これは ApacheBench、バージョン 2.3 <$Revision: 1879490 $> です。

The Apache Software Foundation にライセンス供与 (http://www.apache.org/)

ベンチマーク 192.168.16.40 (しばらくお待ちください)

5000件の依頼を完了

10000 件のリクエストを完了しました

15000 件のリクエストを完了しました

20000 件のリクエストを完了しました

25000 件のリクエストを完了しました

30000 件のリクエストを完了しました

35000 件のリクエストを完了しました

40000 件のリクエストを完了しました

45000 件のリクエストを完了しました

50000 件のリクエストを完了しました

サーバーソフトウェア: nginx/1.18.0

サーバーのホスト名: 192.168.16.40

サーバーポート: 8090

ドキュメントパス: /

ドキュメントの長さ: 612 バイト

同時実行レベル: 1

テストにかかった時間: 9.272 秒

完全なリクエスト: 50000

失敗したリクエスト: 49989

(接続: 0、受信: 0、長さ: 49989、例外: 0)

非 2xx 応答: 49989

合計転送: 34401727 バイト

HTML 転送: 24701298 バイト

1 秒あたりのリクエスト数: 5392.40 [#/秒] (平均)

リクエストあたりの時間: 0.185 [ms] (平均)

リクエストあたりの時間: 0.185 [ms] (すべての同時リクエストの平均)

転送速度: 3623.20 [Kbytes/sec] 受信

接続時間 (ミリ秒)

最小平均[+/- sd] 中央値最大

接続: 0 0 0.0 0 1

処理: 0 0 0.1 0 11

待機中: 0 0 0.1 0 11

合計: 0 0 0.1 0 11

特定の時間 (ミリ秒) 内に処理されたリクエストの割合

50% 0

66% 0

75% 0

80% 0

90% 0

95% 0

98% 0

99% 0

100% 11 (最長の要求)

10. Nginxは特定のIPアドレスへのアクセスを禁止します

NGINXのインストールと操作に関する注意事項

1.NGINXの紹介

二、NGINXのインストール

1.ダウンロード

2.解凍する

3. コンパイル

4. インストール

3.NGINXの起動

1.手動起動

2. システムサービス開始

四、NGINXの設定

1.Nginxの基本設定

2.Nginxは動的サービスを転送します

3. Nginx が静的リソースを転送する

4.NginxはHTTPSアクセス方式をサポート

5. Nginxログ印刷リクエストのヘッダーパラメータ

6. Nginx アンチ DoS 攻撃、CC 攻撃

五、Nginxのログセグメンテーション

六、Nginxの監視

7、Nginx の高い同時実行性 (負荷分散)

1. Nginxの高並行性の原則

2. Nginx の高同時実行性の役割

3. Nginx の高同時実行最適化

4. Nginx の高い同時実行性とリソース要件

5. Nginx 負荷分散の構成

a. 負荷分散構成

b. 負荷分散戦略

8、Nginx の高可用性

1. Keepalived の動作原理

2.キープアライブ機能

3. キープアライブをインストールする

4.キープアライブを構成する

1 ) マスター NGINX 構成を変更する

2 ）バックアップNGINX構成を変更します

5. Nginx サービスの検出

9. Nginx は CC 攻撃を処理します

1. CC 攻撃原理

2. CC 攻撃の種類

3. スローアタックと Apache アンチスローアタック

4.NginxはCC攻撃を防ぎます

10. Nginxは特定のIPアドレスへのアクセスを禁止します

おすすめ