エンタープライズNginx Webサービスの最適化

ディレクトリ

Nginxの基本的なセキュリティの最適化
Nginxサービスのパフォーマンスの最適化
Nginxのログ関連の最適化
Nginxの画像とディレクトリの盗難防止チェーンソリューション
CDNの紹介

Nginxの基本的なセキュリティ最適化

1.パラメータを調整して、Nginxソフトウェアのバージョン情報またはソフトウェア名を非表示にします

Linux curlコマンドなど、いくつかの方法を使用して、WebサーバーソフトウェアとWebサイトで使用されているバージョン番号を確認できます。これは、犯罪者にWebサイトを攻撃する機会を与える可能性があります。すべての隠しサーバーのタイプとバージョン番号は非常に重要です。以下では、非表示にする2つの方法を紹介します

（1）Nginxソフトウェアのバージョン番号情報を非表示にするようにパラメーターを調整
する構成ファイルのserver_tokensパラメーター

######更改参数之前，使用curl查看本机搭建的服务器的信息
[root@www yum.repos.d]# curl -I 192.168.10.10
HTTP/1.1 200 OK
Server: nginx/1.16.1      ###可以看到使用的软件是Nginx，版本为1.16.1
Date: Sun, 17 Nov 2019 03:13:11 GMT
Content-Type: text/html
Content-Length: 14
Last-Modified: Sun, 17 Nov 2019 03:12:02 GMT
Connection: keep-alive
ETag: "5dd0ba82-e"
Accept-Ranges: bytes


###相关参数
涉及到的参数为server_tokens，该参数在配置文件中不存在，
但是默认他的状态是on的，我们要手动给他改成off，就不会显
示出版本信息了，server_tokens参数可以放在http模块中，可
以放在Server模块中，也可以放在location模块中

###这里我们把它放在http模块中
http{
  ...
  server_tokens off;    ###在原配置文件中添加这一句，其他配置这里就不给出了
  ...
  }


###设置之后，重启Nginx服务
[root@www yum.repos.d]# kill -HUP 22814     #使用信号平滑重启

###再次查看
[root@www yum.repos.d]# curl -I 192.168.10.10
HTTP/1.1 200 OK
Server: nginx                     ###已经隐去了版本号信息
Date: Sun, 17 Nov 2019 03:29:19 GMT
Content-Type: text/html
Content-Length: 14
Last-Modified: Sun, 17 Nov 2019 03:12:02 GMT
Connection: keep-alive
ETag: "5dd0ba82-e"
Accept-Ranges: bytes

（2）ソースコードを変更してNginxのソフトウェア名とバージョン番号を非表示にするNginxでソフトウェア名
を非表示にするには、nginxソースコードを操作する
必要があります。3つのソースファイルを順番に変更する必要があります。

[root@localhost /]# curl  -I 192.168.10.10
HTTP/1.1 200 OK
Server: nginx/1.17.5
Date: Mon, 18 Nov 2019 05:38:33 GMT
Content-Type: text/html
Content-Length: 612
Last-Modified: Mon, 18 Nov 2019 05:31:23 GMT
Connection: keep-alive
ETag: "5dd22cab-264"
Accept-Ranges: bytes


第一个文件 nginx-1.17.5/src/core/nginx.h 
修改前
#ifndef _NGINX_H_INCLUDED_
#define _NGINX_H_INCLUDED_


#define nginx_version      1017005  
#define NGINX_VERSION      "1.17.5"     ###这一行和版本号有关
#define NGINX_VER          "nginx/" NGINX_VERSION    ###这一行修改nginx为fuxiangyu

#ifdef NGX_BUILD
#define NGINX_VER_BUILD    NGINX_VER " (" NGX_BUILD ")"
#else
#define NGINX_VER_BUILD    NGINX_VER
#endif

#define NGINX_VAR          "NGINX"        ###这一行将NGINX修改为fuxiangyu
#define NGX_OLDPID_EXT     ".oldbin"


修改后
#ifndef _NGINX_H_INCLUDED_
#define _NGINX_H_INCLUDED_


#define nginx_version      1017005
#define NGINX_VERSION      "1.17.5"
#define NGINX_VER          "fuxiangyu/" NGINX_VERSION

#ifdef NGX_BUILD
#define NGINX_VER_BUILD    NGINX_VER " (" NGX_BUILD ")"
#else
#define NGINX_VER_BUILD    NGINX_VER
#endif

#define NGINX_VAR          "fuxiangyu"
#define NGX_OLDPID_EXT     ".oldbin"


第二个文件 nginx-1.17.5/src/httpngx_http_header_filter_module.c 的第49行
修改前
```python
static u_char ngx_http_server_string[] = "Server: nginx" CRLF; ###修改引号中的nginx
修改后
static u_char ngx_http_server_string[] = "Server: fuxiangyu" CRLF;


第三个文件 nginx-1.17.5/src/
修改前
#需要修改的位置在20行到30行之间
"<hr><center>" NGINX_VER "</center>" CRLF   ###修改这一行
"</body>" CRLF
"</html>" CRLF
;


static u_char ngx_http_error_build_tail[] =
"<hr><center>" NGINX_VER_BUILD "</center>" CRLF  ###修改这一行

修改后
"<hr><center>" NGINX_VER "(http://192.168.10.10)</center>" CRLF ###定义对外展示的内容
"</body>" CRLF
"</html>" CRLF
;


static u_char ngx_http_error_build_tail[] =
"<hr><center>fuxiangyu</center>" CRLF  ###此行将对外展示的Nginx名字更改为fuxiangyu



三个文件都修改完成后，再对nginx进行重新编译，安装
下面来看下效果
[root@localhost /]# curl -I 192.168.10.10
HTTP/1.1 200 OK
Server: fuxiangyu/1.17.5     ###这里已经变成了fuxiangyu而不是nginx了
Date: Mon, 18 Nov 2019 06:01:29 GMT
Content-Type: text/html
Content-Length: 612
Last-Modified: Mon, 18 Nov 2019 05:31:23 GMT
Connection: keep-alive
ETag: "5dd22cab-264"
Accept-Ranges: bytes

パラメータに基づいてNginxサーバーのパフォーマンスを最適化する

1. Nginxサービスワーカープロセスの数を最適化する
同時実行性が高く、アクセス数の多いWebサービスシナリオでは、事前に追加のNginxプロセスを開始して、迅速な応答を確保し、多数の同時ユーザー要求を処理する必要があります。

変更の原則：
サーバーをセットアップするとき、ワーカープロセスの数の初期設定はCPUコアの数と同じにすることができ、ワーカープロセスの数はそれ以上でなければなりません。これにより、サービスが最初に提供されたときに、アクセスの急激な増加による一時的な新しいプロセスの開始がありません。サービスの提供の問題については、高トラフィックと高並行性の場合、プロセスの数をCPUコアの数* 2に増やすことも検討できます。このパラメーターをCPUコアの数と一致させることに加えて、実際のビジネスに応じて特定の状況を選択する必要があります。これは、ハードディスクに保存されているデータとシステムの負荷に関連しています。CPUコアの数に設定することは、適切な初期構成です

関連する構成パラメーター

work_processes <value>  ###该参数一般放置在nginx的全局变量块中
放置位置:放在nginx的全局变量中

構成ファイルのデフォルトはautoで、通常はワークプロセスプロセスに対応する

CPUコア番号ですCPUコア番号の方法を表示

第一种方法：
[root@www nginx-1.16.1]# grep processor /proc/cpuinfo|wc -l
2

第二种方法：
执行top之后，再按1可以看到CPU核数的信息

2.異なるNginxプロセスを異なるCPUにバインドします。
デフォルトでは、Nginxの複数のプロセスが特定のCPUまたはCPUのコアで実行され、Nginxプロセスで使用されるハードウェアリソースが不均一になる可能性があります。このセクションでは、マルチコアマルチCPUのハードウェアリソースの完全かつ効果的な使用を達成するために、異なるCPU処理に異なるプロセスを割り当てる方法nginxのの目的
に関連する設定パラメータを

work_processes <value>  
worker_cpu_affinity <cpu编号> <cpu编号>
参数放置位置为nginx全局变量块处

設定は以下の通りです

#四核CPU的配置
worker_processes 4;
worker_cpu_affinity 0001 0010 0100 1000;
第一个进程绑定到编号为0的CPU核上，第二个进程绑定到编号为1的CPU核上
第三个进程绑定到编号为2的CPU核上，第四个进程绑定到编号为3的CPU核上

worker_processes 2；
worker_cpu_affinity 0101 1010；
第一个进程绑定到编号为0和2的cpu核上，第二个进程绑定到编号为1和3的cpu核上

ストレステスト後、CPU使用率は、このようなバインド後に比較的平均になることができます。

3. Nginxイベント処理モデルは、
Nginxの接続処理メカニズムを最適化します。異なるI / Oモデルは、異なるオペレーティングシステムで採用されます。Linuxでは、Nginxは、epollのI / O多重化モデルとkbsのIをFreebsdで使用します。 / O多重化モデル、/ dev /ポーリングモードのI / O多重化モデルはSolarisで使用され、icopはWindowsで使用されます

nginxイベント処理モデルの構成はイベントブロックにあります

event {
  ...
   use [kqueue|epoll|/dev/pollicop]
  ...
  }
  参数放置位置：event块中

4.
特定のサーバーパフォーマンスとプログラムのメモリ使用量に従って、Nginxシングルプロセス worker_connections によって許可されるクライアント接続の最大数の値を調整します（プロセスが開始するために使用するメモリはプログラムによって決定され
ます）このオプションパラメータは、イベントで構成されます

event {
  ...
   worker_connections 20480;
  ...
  }
  参数放置位置：event块中

5. Nginxワーカープロセスのオープンファイルの最大数を構成する

worker_rlimit_nofile 65535;
参数放置位置：全局变量块中

6.効率的なファイル転送モードをオンにする

sendfileパラメータは、効率的なファイル転送モードを有効にし、2つのコマンドtcp_nopushとtcp_nodelayを同時にオンに設定するために使用されます。これにより、ネットワークとディスクのI / Oブロッキングが防止され、Nginxの作業効率が向上します。

sendfile on|off
参数放置位置：http块，server块，location块

パラメーターの役割：sendfile（）関数をアクティブまたは非アクティブにします。sendfile（）は、2つのファイル記述子間のデータコピー関数です。このコピー操作はカーネル内にあり、「ゼロコピー」と呼ばれます。sendfile（）は、読み取り関数と書き込み関数よりもはるかに効率的です。書き込み機能は、データをアプリケーション層にコピーして動作します

VII。nginxの接続最適化パラメータ、タイムアウト接続調整
タイムアウト接続で何1.
簡単な話を。接続のグループが一定期間実質的なデータ交換を受けていない場合、この接続の存在はほとんど意味がなく、システムリソースを占有し、この接続をアクティブに切断するための時間しきい値を超えていると見なすことができます。
タイムアウト接続は一種の自己管理です、自己保護メカニズム
2.接続タイムアウトの役割
・サーバーのシステムリソース（CPU、メモリ、ディスク）を保護できる無用の接続をできるだけ早くタイムアウトに設定します
・接続が多数ある場合は、時間内に確立された接続を切断しますサーバーは接続も維持するため、サーバーリソースを削減するために長時間何もしない接続はリソースも消費します
。DOS攻撃を防ぐために、ハッカーはサーバーを無効にするために無用な接続を多数開始します
。LNMP環境では、ユーザーが動的サービスを要求した場合次に、Nginxは接続を確立し、FastCGIサービスとバックエンドMySQLサービスを要求します。このとき、このNginx接続はタイムアウトを設定するか、ユーザーが許容する時間内にデータを返すか、バックエンドサーバーがデータを返すまでしばらく待つ必要があります、特定の戦略は特定のビジネスに従って分析されるべきです。もちろん、FASTCGIサービスとMYSQLサービスにも接続に対応するタイムアウト制御があります

3.タイムアウトパラメータの設定
（1）keepalive_timeout 60;

keepalive_timeout <vaule>  ##单位为秒
参数放置位置：http块，server块，location块

クライアントが60秒間セッションを維持するためのタイムアウト期間を設定するために使用されます。この時間が経過すると、サーバーは接続
パラメーター関数を閉じます：サーバーが継続的な要求を持っている場合、キープアライブはクライアントとサーバー間の確立された接続を常に終了せずに機能させることができますキープアライブが確立された接続を使用してサービスを提供する場合、サーバーが処理要求を再確立しないようにします。
このパラメーターはキープアライブを設定します（クライアント接続が終了する前にサーバー上に留まる時間）、単位は秒です

（2）tcp_nodelay on；

tcp_nodelay on|off ##单位为秒
参数放置位置：http块，server块，location块

パラメータの役割：デフォルトでは、データが送信されると、カーネルはそれをすぐには送信せず、データパケットを形成するためにより多くのバイトを待機する場合があり、これによりI / Oパフォーマンスが向上します。ただし、一度に数バイトしか送信されないビジネスシナリオでは、このパラメーターを使用すると、クライアントの待機時間が長くなります
（3）send_timeout 25。

send_timeout <vaule>  ##单位为秒
参数放置位置：http块，server块，location块

パラメータ関数：クライアントに応答するためのタイムアウト時間を指定するために使用されます。このタイムアウトは、2つの接続アクティビティ間の時間に制限されます。この時間を超えると、クライアントにアクティビティがなく、Nginxが接続を閉じます。

8.パフォーマンスの最適化を実現するためにNgxin期限切れキャッシュを構成する
1.機能の
概要簡単に言うと、Nginx expriesの機能は、ユーザーがアクセスしたWebサイトの有効期限を設定することです。ユーザーがコンテンツに初めてアクセスすると、メモリがユーザーに保存されますブラウザーはローカルであるため、ユーザーが2回目以降にWebサイトにアクセスし続けると、ブラウザーはユーザーのブラウザーにキャッシュされているコンテンツをチェックし、キャッシュされたコンテンツが期限切れになるかクリアされるまでサーバーにダウンロードを行いません。

より深い理解：有効期限の機能は、HTTPの「Expries」および「Cache-Control」応答ヘッダーの内容をNginx構成ファイルを通じて制御できるようにすることで、ブラウザーにキャッシュできるかどうか、およびキャッシュする期間をクライアントに通知します。これらのHTTP応答ヘッダーはクライアントに必要です。最後はコンテンツの有効性と耐久性を示しています。クライアントにローカルにコンテンツキャッシュがある場合、コンテンツはサーバーからではなくキャッシュから読み取ることができます。その後、クライアントはキャッシュ内のコピーを要求して、期限切れかどうかを確認し、期限切れになってサーバーからコンテンツの更新を再取得するかどうかを決定します

2.機能の紹介
Webサイトの開発と運用において、ビデオ、画像、CSS、JS、特に画像などのWebサイト要素が変更される可能性はほとんどありません。現時点では、画像はクライアントブラウザのローカルキャッシュに365日間設定され、CSSと設定されていると言えます、JS、html、およびその他のコードは10〜30日間キャッシュされるため、ユーザーが初めてページを開いた後、対応するコンテンツはローカルブラウザの有効期限に従ってキャッシュされます。次回ユーザーが同様のページを開いたときには、重複する要素は必要ありません。ユーザーアクセスを高速化するためにダウンロードされました。ユーザーのアクセス要求とデータが削減され、サーバー側の帯域幅も大幅に節約できます。この機能は、Apacheの期限切れ機能に似ています。3
。利点
・expriesは、Webサイトの帯域幅を減らしてコストを節約できます。
・Webサイトへのユーザーアクセスの速度を加速し、ユーザーのアクセスエクスペリエンスを向上させます。
・サーバーアクセス量が減り、サーバーの負荷が減り、サーバーのコストも下がります。下がる

4.短所
キャッシュされたページまたはWebサイトのデータが更新されても、ユーザーは現時点で古いキャッシュされたコンテンツを引き続き表示する可能性があり、ユーザーエクスペリエンスに影響するため、この問題を解決するにはどうすればよいですか？
まず、頻繁に変更が必要な画像やその他のファイルについては、オブジェクトのキャッシュ時間を短縮できます。たとえば、GoogleとBaiduのホームページの画像は、多くの場合、日付の異なる休日の画像に置き換えられるため、この画像をキャッシュ期間として設定できます。一日
二、ウェブサイトの改訂または更新、キャッシュされたオブジェクトは、（サイトコードプログラム）は、サーバに名前を変更することができ
、一般的に、直接、実際には、ユーザレベルで画像を修正するために、ユーザによって変更されることはありません画像、添付ファイル、ため-site、サーバーに再送信されます。コンテンツは同じですが、新しいイメージ名
です。ウェブサイトの改訂とアップグレードにより、JS、CSS、その他の要素が変更されます。改訂中にこれらの要素の名前が変更された場合、フロントエンドCDNとユーザーはコンテンツを再キャッシュする必要があります

5.パラメータ構成

expires <value> ###可以指定时间 天，月等
参数放置位置：location块，通常匹配指定类型的文件

实例
location ~ .*\.(js|css)?$
{
  exprires 30d;
}
###匹配后缀名为js或者css的文件，在客户端缓存30天

9.パフォーマンス最適化のためのNginx gzip圧縮の構成
1.機能の
概要Nginx gzip圧縮モジュールは、圧縮ファイルのコンテンツを提供します。ユーザーが要求したコンテンツがユーザークライアントに送信される前に、Nginxサーバーはいくつかの特定の戦略に従って圧縮を実装します。Webサイトの出口の帯域幅を節約し、データ転送効率を上げるために、ユーザーのアクセスエクスペリエンスを改善します
。2.利点
・ユーザーのWebサイトエクスペリエンスを改善する：ユーザーに送信されるコンテンツが小さくなり、ページのユニットサイズへのユーザーアクセスが高速化され
ます・Webサイトの帯域幅コストを節約：データWebサイトの帯域幅とトラフィックコストを節約する圧縮伝送
3.圧縮する必要があり、圧縮する必要がないオブジェクト
・プレーンテキストコンテンツは圧縮率が高いため、html、js、css、xmlなどのプレーンテキストコンテンツを圧縮するのが最適です、shtml、その他の形式
、画像、ビデオ（ストリーミングメディア）、およびその他のファイルは、可能な限り圧縮しないでください。これらのファイルのほとんどは圧縮されているため、再圧縮しても効果が低下しないか、効果が明確でないため、費用対効果の高い圧縮ではありません。高
4.特定の構成：ここではもう与えられず、興味のある学生が自分で検索する

ログ関連の最適化

ユーザーがソフトウェアを要求すると、ほとんどのソフトウェアはユーザーのアクセスを記録し、Nginxサービスも例外ではありません。Nginxソフトウェアには現在、Apacheのようなログを分割する機能はありませんが、スクリプト、Nginx信号制御機能、またはリロードリロードを使用して、
ログの自動切断を実現できます。1.ログ切断スクリプトを構成する

1.スクリプトを実装する

log_split
#!/bin/bash
cd /application/nginx/logs    #进入nginx存放日志的目录下
/bin/mv www_access.log www_access_$(date +%F -d -1day).log
                              #配置前一天的日子
/application/nginx/sbin/nginx -s reload ##重新记载nginx使得触发重新生访问日志

2.スケジュールされたタスク構成にスクリプトを追加し、スクリプトを毎日0:00に実行して、split関数を実装します。

[root@localhost /]# crontab -e
00 00 * * * /bin/bash /log_split  ###添加这行内容

2.アクセスする必要のないログを記録しない
統計はPVに基づいているため、実際の作業では、ロードバランサのヘルスノードチェックまたは特定の特定のファイル（画像、JS、CSSなど）のログを記録する必要は通常ありません。ページが計算され、ログの書き込みが多すぎるとディスクI / Oが大量に消費され、サーバーのパフォーマンスが低下します

location ~ .*\.(js|jpg|css)$ {
     access_log off;
}

Nginxイメージとディレクトリの盗難防止チェーンソリューション

1.リソースのホットリンクとは何ですか？
簡単に言えば、悪質なWebサイトが他のWebサイトのリソースを自分のWebサイトプログラムで許可なく不正に使用し、これらの呼び出しリソースを自分のWebサイトに表示して自分自身を埋めます。 Webサイトの影響、この動きは、リソースWebサイトを呼び出すネットワークトラフィックを浪費するだけでなく、他のWebサイトの帯域幅とサービスのプレッシャーを厳しくし

ます。2.盗難防止チェーンソリューションを実装する基本原則
（1）HTTPリファラーによると
、HTTPプロトコルで盗難を防止します。現在のページのリソースに対してリンクが使用される場所を示すURL形式を使用して、参照するヘッダーフィールドがあります。リファラーは、アクセスしたソースWebページを検出できます。リソースファイルの場合は、それを表示するWebページアドレスを追跡できます。ソースがサイトでない場合は、すぐにブロックするか、指定したページに戻ることができ
ます。HTTPリファラーはヘッダーの一部です。サーバーがリクエストを送信すると、通常はリファラーをもたらし、どのページから来たかをサーバーに通知します。サーバーはこれを使用して、処理のための情報を取得します。Apache、nginx、LightttpdはすべてHTTPリファラーによる盗難防止チェーンをサポートします

（2）Cookie盗難防止チェーンによると
、一部のストリーミングメディアアプリケーションなどの一部の特別なビジネスデータでは、サーバーにリファラーヘッダーが提供されません。リファラー検出方法を使用すると、適切な役割を果たしません。特にFlash、Windows Mediaビデオ、および大量のトラフィックを消費するその他のビジネスデータの場合、盗難防止チェーンはより困難です。現時点では、Cookieテクノロジーを使用してストリーミングメディアの問題を解決できます

Webサイトの高速化にCDNを使用する

1. CDNとはCDN
の正式名称は、コンテンツ配信ネットワークです。これは、中国語のコンテンツ配信ネットワークを意味します。単に、既存のインターネットに新しいネットワークアーキテクチャを追加することにより、Webサイトのコンテンツはユーザーに最も近いキャッシュサーバーに投稿されます。インテリジェントなDNS負荷分散テクノロジーにより、ユーザーのソースが決定されるため、ユーザーは同じ回線帯域幅のユーザーは、必要なコンテンツを取得するためにキャッシュサーバーにアクセスします。オペレーターは通常、CDNサービスを提供します

CDNは国内またはグローバルの分散キャッシュクラスターのセットです。本質は、インテリジェントDNSを介してユーザーのソースリージョンとインターネットアクセスラインを特定し、ユーザーに最も近いキャッシュノードを選択し、ユーザーインターネットアクセスラインと同じサービスノードを選択することです。ユーザーが同じ線上にいるため、アクセス速度が向上し、ユーザーエクスペリエンスが向上します

2.
CDNの機能CDNは、ユーザーエリアとラインに基づいてインテリジェントスケジューリングを行う分散メモリキャッシュクラスタです。次のような特徴があります
。サーバーメモリを介してWebサイトデータをキャッシュし、企業サイト（特に、多くの写真やビデオを含むサイト）を改善します。アクセス速度、およびエンタープライズサイトの安定性の向上
。ユーザーはインテリジェントDNSテクノロジーに従って最適なキャッシュサーバーを自動的に選択し、異なるオペレーター間の相互接続のボトルネックの影響を軽減し、異なるネットワークのユーザーが確実に適切なものになるようにします。アクセス品質
・アクセス速度の高速化、元のサイトの帯域幅
の削減・ユーザーがアクセスしたときにサーバーのメモリからデータを読み取り、ネットワークトラフィックを共有し、元のサイトの負荷を軽減
・CDNを使用してソースサイトのネットワークトラフィックを共有同時に、元のサイトの負荷圧力を軽減し、Webサイトに対するハッキングやさまざまなDDOS攻撃の影響を軽減して、Webサイトのサービス品質を確保できます。

[root@localhost /]# curl -I www.4399.com
HTTP/1.1 200 OK
Date: Mon, 18 Nov 2019 07:30:11 GMT
Content-Type: text/html
Content-Length: 172976
Connection: keep-alive
Expires: Mon, 18 Nov 2019 07:33:39 GMT
Server: nginx
Last-Modified: Mon, 18 Nov 2019 01:14:14 GMT
ETag: "5dd1f066-2a3b0"
Cache-Control: max-age=1800
Accept-Ranges: bytes
Age: 1592
X-Via: 1.1 PShbsjzsxie214:4 (Cdn Cache Server V2.0), 1.1 bd37:3 (Cdn Cache Server V2.0), 1.1 PSsdzbwtxt63:12 (Cdn Cache Server V2.0)

###Cdn Cache Server V2.0 就说明这个站点使用了CDN加速