しばらく前、私は會(huì)社の Web サイトのテストに使用したサーバーにログインし、誤って access.log.gz ファイル パッケージを目にしました。好奇心に駆られて、それをリモート サーバーからローカル コンピューターにダウンロードし、解凍して開きました。それはアクセス ファイルでした。私はいつもアクセス ログについて頭の中で聞いていましたが、それが何なのかは知りませんでした。理解できないので、nginx サーバー ソフトウェアというものについて知りました。暇なときに簡単に理解した後、毎日の開発とデバッグ中に、最もよく使用されるポートを監(jiān)視することもできるのではないかと考えました。一種の學(xué)習(xí)ですが、やはり本や資料を読むよりも自分でやったほうがより深い體験ができます。今日は構(gòu)成についてのみ説明します。學(xué)習(xí)が進(jìn)むにつれて、ロード バランシング、リバース プロキシ、最適化などについても觸れていきます。間違っている點(diǎn)があれば、修正して、お互いに學(xué)び、一緒に進(jìn)歩してください。

Apaceh や他のものと比較すると、Nginx には多くの利點(diǎn)がありますが、ここではあまり強(qiáng)調(diào)しません。それらは、高い同時(shí)接続、低メモリ消費(fèi)、シンプルな設(shè)定ファイルにすぎません。等

(1) インストール

ubuntu システムへの nginx のインストールは非常に簡単で、コマンド 1 つで実行できます。

sudo apt-get install nginx

ちなみに、インストール中にエラーが発生した場合、ターミナルに「パッケージ リストまたはステータス ファイルを解析または開くことができません」というメッセージが表示されます。詳細(xì)は次のとおりです。

E: Encountered a Section withいいえ パッケージ: ヘッダー

E: MergeList /var/lib/apt/lists/cn.archive.ubuntu.com_ubuntu_dists_natty_main_i18n_Translation-en に関する問題

E: パッケージ リストまたはステータス ファイルを解析または開くことができません。

解決策:

sudo rm /var/lib/apt/lists/* -vf //削除できない場合は、パラメータ -r を追加して強(qiáng)制削除を使用できます

sudo apt-get update

もう一つのポイントApache がコンピュータにインストールされ、すでに実行されている場合は、Apache と Nginx のデフォルト ポートが両方とも 80 であるため、Apache を停止します。

インストールが成功すると、実行可能なコマンドが表示され、ターミナルを開いてコマンド nginx -h を入力すると、いくつかのコマンド パラメーター情報(bào)が表示されます。

nginx -h コマンドヘルプを表示します

nginx -v バージョン情報(bào)を表示します

nginx -V バージョン情報(bào)と設(shè)定オプションを表示します

nginx -t 設(shè)定ファイルをテストします

nginx -T 設(shè)定ファイルをテストしてダンプします

nginx - q 構(gòu)成テスト中にエラー以外のメッセージを抑制します

nginx -s signal シグナルをメインプログラムに送信します。シグナルには、stop、stop nginx、exit、open、open; が含まれます。

nginx -p prefix プレフィックスのパスを設(shè)定します。デフォルトは /usr/share/nginx/

nginx -c filename 設(shè)定ファイルを設(shè)定します。デフォルトは /etc/nginx/nginx.conf です

ngnix -g ディレクティブ設(shè)定は構(gòu)成ファイルの範(fàn)囲を超えています グローバル コマンド

注: これらのコマンドを使用するときにエラーが発生した場合は、権限の問題である可能性があります。root に切り替えて実行してください。

(2)設(shè)定ファイル

メインの設(shè)定ファイルはnginx.conf、デフォルトパスは/etc/nginx/

PHP関連はfastcgi_params、Python関連はuwsgi_paramsです

設(shè)定ファイルのパラメータとそれらの意味は次のとおりです:

ユーザー www www ;

Nginx ユーザーおよびグループ。

worker_processes 8;

ワーカープロセスの數(shù)がウィンドウで指定されていません。ハードウェアの調(diào)整に応じて、通常は CPU コアの合計(jì)數(shù)と同じか、コアの合計(jì)數(shù)の 2 倍になります。

error_log /var/logs/error.log crit;

エラー ログの保存パスとレベル。レベルは [debug|info|notice|warn|error|crdit] です。

各エラー ログ レベルについては、を參照してください。ブログ投稿 http://blog.csdn.net/solmyr_biti/article/details/50634533

pid /run/nginx.pid;

pid プロセス識(shí)別子のストレージ パス。 pid ファイルは、プロセスの ID を記録する內(nèi)容が 1 行だけのテキスト ファイルです。 pid ファイルの目的は、プロセスが複數(shù)のコピーを開始しないようにすることです。 pid ファイル (固定パス、固定ファイル名) の書き込み許可 (F_WRLCK) を取得したプロセスのみが正常に起動(dòng)し、自身の PID をファイルに書き込むことができます。同じプログラムの他の冗長プロセスは自動(dòng)的に終了します。

nginx の pid ファイルを使用して、nginx をスムーズに停止、再起動(dòng)、再起動(dòng)します。例 コマンドの形式は次のとおりです:

kill-signal type `cat /run/nginx.pid`

シグナルのタイプは主に次のとおりです:

TERM, int すぐにシャットダウンします。 設(shè)定ファイルをロードします

USER1 再開します。ログ ファイルを切り取るときに非常に便利です

USER2 開くことができる最大の記述子。

このコマンドは、nginx プロセスによって開かれるファイル記述子の最大數(shù)を指します。理論値は、開いているファイルの最大數(shù) (ulimit -n) を nginx プロセスの數(shù)で割ったものである必要があります。 ulimit -n の値は一貫したままです。

現(xiàn)在、Linux 2.6 カーネルで開いているファイルの數(shù)は 65535 であり、それに応じて worker_rlimit_nofile には 65535 を入力する必要があります。

これは、nginx のスケジューリング時(shí)のプロセスへのリクエストの割り當(dāng)てがあまりバランスが取れていないためです。そのため、10240 を入力し、合計(jì)同時(shí)実行數(shù)が 30,000 ～ 40,000 に達(dá)すると、プロセス數(shù)が 10240 を超える可能性があり、502 エラーが返されます。

イベント

{

epoll を使用する;

epoll のネットワーク I/O モデルを使用します。 Linux は epoll を推奨し、FreeBSD は kqueue を推奨しますが、window では指定されません。

epoll、select、kqueue がいつ使用されるかに関する関連情報(bào)を確認(rèn)できます。

worker_connections 204800;

ワーカー プロセスごとの最大接続數(shù)。ハードウェアに応じて調(diào)整し、前の作業(yè)プロセスと組み合わせて使用??してください。ただし、CPU を 100% で実行しないでください。理論上、nginx サーバーごとの最大接続數(shù)は、worker_processes*worker_connections

keepalive_timeout 60;

keepalive timeout です。

client_header_buffer_size 4k;

クライアントリクエストヘッダーのバッファサイズ。これは、システムのページング サイズに応じて設(shè)定できます。通常、リクエスト ヘッダーのサイズは 1k を超えることはありません。ただし、システムのページング サイズはここで設(shè)定されます。

ページング サイズは getconf PAGESIZE コマンドで取得できます。

ただし、 client_header_buffer_size が 4k を超える場合もありますが、 client_header_buffer_size の値は「システム ページング サイズ」の整數(shù)倍に設(shè)定する必要があります。

open_file_cache max=65535 inactive=60s;

これは、開いているファイルのキャッシュを指定します。最大値は、開いているファイルの數(shù)と一致するように指定します。ファイルが要求されていない期間が経過したら、キャッシュを削除します。

open_file_cache_valid 80s;

これは、キャッシュされた有効な情報(bào)を確認(rèn)する頻度を指します。

open_file_cache_min_uses 1;

open_file_cache ディレクティブの inactive パラメーター內(nèi)のファイルの最小使用數(shù)。この數(shù)値を超えると、ファイル記述子は常にキャッシュ內(nèi)で開かれます。非アクティブ時(shí)間內(nèi)に一度も使用されなかった場合は削除されます。

}

##以下は、http サーバーを設(shè)定し、そのリバース プロキシ機(jī)能を使用して負(fù)荷分散サポートを提供する方法です

http

{

include mime.types;

MIME タイプを設(shè)定します。タイプはby mime.type ファイル定義

default_type application/octet-stream;

log_format main '$remote_addr - $remote_user [$time_local] "$request" '

'$status $body_bytes_sent "$http_referer" '

'"$ http_user_agent" "$http_x_forwarded_for"';

log_format log404 '$status [$time_local] $remote_addr $host$request_uri $sent_http_location';

ログ形式の設(shè)定。

$remote_addr と $http_x_forwarded_for はクライアントの IP アドレスを記録するために使用されます。

$remote_user: クライアントのユーザー名を記録するために使用されます。リクエストの URL と http プロトコルを記録します。

$status: リクエストのステータスを記録するために使用されます。成功の場合は 200、

$body_bytes_sent: クライアントに送信されたファイルの本文のサイズを記録します。からアクセスされたページのリンクを記録するために使用されます;

$http_user_agent: 顧客のブラウザの関連情報(bào)を記録します;

通常、Web サーバーはリバース プロキシの背後に配置されているため、顧客の IP アドレスは取得できません。 $remote_add はプロキシ サーバーの IP アドレスを逆にします。リバース プロキシ サーバーは、転送されたリクエストの http ヘッダー情報(bào)に x_forwarded_for 情報(bào)を追加して、元のクライアントの IP アドレスと元のクライアントのリクエストのサーバー アドレスを記録できます。

access_log logs/host.access.log main;

access_log logs/host.access.404.log log404;

log_format ディレクティブを使用してログ形式を設(shè)定した後、access_log ディレクティブを使用してストレージ パスを指定する必要がありますログ ファイルの;

gzip on:

gzip 圧縮出力を有効にして、ネットワーク送信を削減します。

gzip_min_length 1k

圧縮が許可されるページの最小バイト數(shù)を設(shè)定します。ページのバイト數(shù)はヘッダーのコンテンツ長から取得されます。デフォルト値は 20 です。バイト數(shù)を 1k より大きく設(shè)定することをお?jiǎng)幛幛筏蓼埂?k 未満の場合、圧縮がさらに進(jìn)む可能性があります。

gzip_buffers 4 16k

gzip 圧縮結(jié)果のデータ ストリームを保存するために複數(shù)ユニットのキャッシュを取得するようにシステムを設(shè)定します。 4 16k は、16k 単位でインストールされる元のデータの 4 倍のサイズのメモリを 16k 単位で申請(qǐng)することを意味します。

gzip_http_version 1.0

初期のブラウザは Gzip 圧縮をサポートしておらず、文字化けが発生する可能性があるため、Nginx のリバース プロキシを使用する場合にこのオプションが追加されました。 Gzip 圧縮も有効にするには、最終通信が http/1.0 であるため、1.0 に設(shè)定してください。

gzip_comp_レベル 6

gzip 圧縮率、1 は圧縮率が最小で処理速度が最も速く、9 は圧縮率が最大ですが処理速度が最も遅くなります (送信は速いですが CPU の消費(fèi)量が多くなります)

gzip_types

指定されているかどうかに関係なく、圧縮の MIME タイプと一致しますではなく、「text/html」型は常に圧縮されます。

gzip_proxied any

Nginx がリバース プロキシとして使用される場合に有効になり、バックエンド サーバーから返される結(jié)果の圧縮を有効にするか無効にするかを決定します。照合の前提條件は、バックエンド サーバーが「Via」を含むヘッダーを返す必要があることです。 。

の

gzip_vary は http ヘッダーに関連しています。Vary: Accept-Encoding が応答ヘッダーに追加され、フロントエンド キャッシュ サーバーが gzip 圧縮されたページをキャッシュできるようになります。たとえば、Squid を使用して Nginx をキャッシュします。圧縮されたデータ。 。

server_names_hash_bucket_size 128;

サーバー名を保存するハッシュテーブルは、server_names_hash_max_size およびserver_names_hash_bucket_size の命令によって制御されます。パラメータのハッシュ バケット サイズは常にハッシュ テーブルのサイズと等しく、プロセッサ キャッシュ サイズの倍數(shù)です。メモリ內(nèi)のアクセス數(shù)を減らした後、プロセッサ內(nèi)のハッシュ テーブルのキー値の検索を高速化することができます。ハッシュ バケット サイズがプロセッサ キャッシュのサイズと等しい場合、キーを検索するとき、メモリ內(nèi)の検索回?cái)?shù)は最悪の場合 2 回になります。 1 回目はストレージ ユニットのアドレスを決定し、2 回目はストレージ ユニット內(nèi)のキー値を見つけます。したがって、Nginx がハッシュ最大サイズまたはハッシュ バケット サイズを増やす必要があるというプロンプトを表示した場合、最初に行うことは、前のパラメーターのサイズを増やすことです。

クライアント リクエストのバッファ サイズです。ヘッダ。これは、システムのページング サイズに応じて設(shè)定できます。通常、リクエストのヘッダー サイズは 1k を超えないため、ページング サイズはここで設(shè)定されます。ページング サイズは、getconf PAGESIZE コマンドで取得できます。

large_client_header_buffers 8 128k;

クライアントリクエストヘッダーバッファサイズ。デフォルトでは、nginx は client_header_buffer_size バッファーを使用してヘッダー値を読み取ります。ヘッダーが大きすぎる場合は、large_client_header_buffers を使用してそれを読み取ります。

open_file_cache max=102400 inactive=20s;

このコマンドは、キャッシュが有効かどうかを指定します。キャッシュの最大數(shù)とキャッシュ時(shí)間も指定されます。 20 秒以上非アクティブになった後にクリアできるように、比較的長い最大時(shí)間を設(shè)定できます

open_file_cache_errors on off

デフォルト値: open_file_cache_errors off 使用するフィールド: http、server、location、このディレクティブは、ファイル ログ キャッシュ エラーを検索すると、

open_file_cache_min_uses

構(gòu)文: open_file_cache_min_uses 數(shù)値 デフォルト値: open_file_cache_min_uses 1 使用フィールド: http、server、location このディレクティブは、無効なパラメーターの特定の時(shí)間範(fàn)囲內(nèi)で使用できる最小値を指定します。 open_file_cache ディレクティブ。より大きな値を使用すると、ファイル記述子は常にキャッシュ內(nèi)で開かれます。 構(gòu)文: open_file_cache_valid time デフォルト値: open_file_cache_valid 60 このディレクティブは、いつを指定します。 open_file_cache でキャッシュされたアイテムの有効な情報(bào)を確認(rèn)します。

client_max_body_size 300m;

nginx を通じてアップロードされるファイルのサイズを設(shè)定します。

効率的なファイル転送モードを有効にします。ファイルを出力する機(jī)能により、ユーザー空間からカーネル空間へのコンテキストの切り替えが減少します。通常のアプリケーションではオンに設(shè)定し、ダウンロードなどのディスク IO 負(fù)荷の高いアプリケーションで使用する場合はオフに設(shè)定すると、ディスクとネットワークの I/O 処理速度のバランスをとり、システムの負(fù)荷を軽減できます。

tcp_nopush on;

このオプションは、sendfile を使用する場合にのみ使用されます。ハンドシェイクを開始するためのタイムアウトです。応答を待っています

proxy_read_timeout 180;

接続が成功した後、バックエンド サーバーが応答するまでの待ち?xí)r間。実際には、処理を待機(jī)しているバックエンド キューにすでに入っています (バックエンドの時(shí)間とも言えます)。

proxy_send_timeout 180;

バックエンドサーバーデータ 戻り時(shí)間は、バックエンドサーバーが指定された時(shí)間內(nèi)にすべてのデータを送信する必要があることを意味します。

proxy_buffer_size 4k; 最初のバッファサイズを設(shè)定します。プロキシ サーバーから読み取られた応答の一部。通常、応答のこの部分には小さな応答ヘッダーが含まれます。デフォルトでは、この値のサイズは proxy_buffers ディレクティブで指定されたバッファーのサイズですが、より小さい値に設(shè)定できます。

proxy_buffers 4 32k;

は応答を読み取るように設(shè)定されます(プロキシサーバーのバッファの數(shù)とサイズから)、デフォルトはページングサイズでもあり、オペレーティングシステムに応じて4kまたは8kになる可能性があります

proxy_busy_buffers_size 64k;

高負(fù)荷時(shí)のバッファ サイズ (proxy_buffers*2)

proxy_temp_file_write_size 64k;

プロキシ サーバーの応答を一時(shí)ファイルにキャッシュする場合、このオプションは毎回書き込まれる一時(shí)ファイルのサイズを制限します。 proxy_temp_path (コンパイル時(shí)に指定可能) に書き込むディレクトリ。

proxy_temp_path /data0/proxy_temp_dir;

proxy_temp_path と proxy_cache_path で指定されたパスは同じパーティション內(nèi)にある必要があります

proxy_cache_path /data0/proxy_cache_dirlevels=1:2keys_zone=cache_one:200m inactive=1d max_size=30g;

#メモリキャッシュスペースのサイズを200MBに設(shè)定し、1日間アクセスされなかったコンテンツは自動(dòng)的にクリアされます。ハードディスクのキャッシュスペースのサイズは 30GB です。

keepalive_timeout 120;

秒?yún)g位の長い接続タイムアウト。このパラメータは非常に重要であり、ブラウザの種類、バックエンド サーバーのタイムアウト設(shè)定、およびオペレーティング システムの設(shè)定に関係します。長時(shí)間の接続で多數(shù)の小さなファイルが要求される場合、接続を再確立するコストを削減できます。ただし、大きなファイルをアップロードする場合は、65 秒以內(nèi)にアップロードが完了しないと失敗します。セットアップ時(shí)間が長すぎてユーザー數(shù)が多い場合、長時(shí)間接続を維持すると多くのリソースが占有されます。

send_timeout 120;

は、クライアントに応答するためのタイムアウト期間を指定するために使用されます。このタイムアウトは、2 つの接続アクティビティの間の時(shí)間に制限されます。クライアント上で何もアクティビティがないままこの時(shí)間を超えると、Nginx は接続を閉じます。

tcp_nolay on;

は、データをキャッシュせずに少しずつ送信するように nginx に指示します。データを時(shí)間內(nèi)に送信する必要がある場合、戻り値をすぐに取得できないように、この屬性をアプリケーションに設(shè)定する必要があります。小さなデータ情報(bào)を送信するとき。

client_body_buffer_size 512k;

これを 256k などの比較的大きな値に設(shè)定した場合、Firefox または IE ブラウザを使用して 256k より小さい畫像を送信するのは通常のことです。このディレクティブをコメント アウトし、オペレーティング システムのページ サイズの 2 倍 (8k または 16k) であるデフォルトの client_body_buffer_size 設(shè)定を使用すると、問題が発生します。

firefox4.0でもIE8.0でも、約200kの比較的大きな畫像を送信すると500 Internal Server Errorが返されます

proxy_intercept_errors on;

は、HTTP応答コード400以上でnginxブロック応答を行うことを意味します。

アップストリーム ベイクエンド {

サーバー 127.0.0.1:8027;

サーバー 127.0.0.1:8029;

ハッシュ $request_uri;

}

これ負(fù)荷分散の問題を考慮して設(shè)計(jì)されている念頭に置いて。

nginx のアップストリームは現(xiàn)在、次の割り當(dāng)て方法をサポートしています

1. ポーリング (デフォルト)

各リクエストは、時(shí)系列に 1 つずつ異なるバックエンド サーバーに割り當(dāng)てられます。バックエンド サーバーがダウンした場合は、自動(dòng)的に割り當(dāng)てられます。排除された。

2. Weight

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

例:

upstream bakend {

server 192.168.0.14weight=10;

server 192.168.0.15weight=10;

}

3, ip_hash

各リクエストはハッシュ結(jié)果に従って割り當(dāng)てられますのアクセス IP。このようにして、各訪問者はバックエンド サーバーに固定アクセスできるようになり、セッションの問題を解決できます。

例:

アップストリーム ベイクエンド {

ip_hash;

server 192.168.0.14:88;

server 192.168.0.15:80;

}

4. フェア (サードパーティ)

バックエンドサーバーリクエストを押す応答時(shí)間に応じて割り當(dāng)てられ、応答時(shí)間の短いものが最初に割り當(dāng)てられます。

アップストリームバックエンド{

serverserver1;

serverserver2;

fair;

}

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

アクセスされたURLのハッシュ結(jié)果に従ってリクエストを分散し、各URLが同じバックエンド サーバーに送信されます。バックエンド サーバーがキャッシュである場合に、より効果的です。

例: 上流にハッシュ ステートメントを追加します。重みなどの他のパラメーターはサーバー ステートメントに記述できません。

hash $request_uri;

hash_method crc32;

}

#負(fù)荷分散デバイスの IP とデバイスのステータスを定義します

アップストリーム bakend{

ip_hash;

server 127.0.0.1:9090 down;

server 127.0 .0.1: 8080 Weight=2;

server 127.0.0.1:6060;

server 127.0.0.1:7070 Backup;

}

負(fù)荷分散を使用する必要があるサーバーに、

proxy_pass http:// bakend/;

各デバイスのステータスは次のように設(shè)定されます:

1.down は、前のサーバーが一時(shí)的に負(fù)荷に參加していないことを意味します

2.weight が大きいほど、負(fù)荷の重みが大きくなります。

3.max_fails: 許可されるリクエスト失敗の數(shù)のデフォルトは 1 です。最大數(shù)を超えると、proxy_next_upstream モジュールによって定義されたエラーが返されます。

4.fail_timeout: max_fails 失敗後の一時(shí)停止時(shí)間。

5.backup: 他のすべての非バックアップ マシンがダウンしているかビジー狀態(tài)の場合、バックアップ マシンを要求します。したがって、このマシンの圧力は最も少なくなります。

nginx は、未使用のサーバーで使用するために、同時(shí)に複數(shù)の負(fù)荷分散グループを設(shè)定することをサポートしています。

client_body_in_file_only は、デバッグ用にクライアントの投稿からファイルに記録できます。

記録されたファイルのディレクトリを設(shè)定します。

location は URL と一致します。プロキシ負(fù)荷分散

##仮想マシンを構(gòu)成する

server

{

listen 80;

listen ポートを構(gòu)成する

server_name image.***.com;

Configureアクセスドメイン名

場所 ~* .( mp3|exe)$ {

「mp3 または exe」で終わるアドレスを負(fù)荷分散するための正規(guī)表現(xiàn)

proxy_pass http://img_relay$request_uri;

のポートまたはソケットを設(shè)定しますプロキシ サーバーと URL

proxy_set_header ホスト $host;

proxy_set_header X-Real-IP $remote_addr;

proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;

上記3行の目的は、プロキシサーバーが受け取ったユーザー情報(bào)を?qū)gサーバーに転送することです

}

location /face {

if ($http_user_agent ~* "xnp") {

rewrite ^(.*)$ http://211.151.188.190:8080/face.jpg redirect;

}

#これには、スペースが限られているため、Nginx の Rewrite ルールの問題が含まれます。次のセクション

proxy_pass http ://img_relay$request_uri;

proxy_set_header ホスト $host;

proxy_set_header X-Real-IP $remote_addr;

proxy_set_header

}

}

}

それもできます上記のことから、nginx.conf ファイルの主な形式は次のとおりであることがわかります。

…

サーバー

}

...

}

Nginx の構(gòu)成は主要な機(jī)能です。これは、CSS ファイルのスタイル定義と比較できます。子要素は親要素のスタイル定義を継承し、同様の継承関係が nginx 設(shè)定にも存在します。

nginx 設(shè)定の継承モデルを理解するには、nginx 設(shè)定には複數(shù)のブロックがあることを知っておく必要があります。たとえば、サーバー コンテキストで定義された命令は、server{} ブロックに保存されます。 http コンテキスト內(nèi) 定義された命令は http{} ブロックに保存されます。

nginx には 6 つの可能なコンテキストがあり、高位から低位の順序は次のとおりです:

グローバル

Http

サーバー

If

Location

ネストされた場所

位置內(nèi)の場合

limit_excel

デフォルトの継承モデルの方向は、水平方向または逆方向ではなく、下位層が上位層を継承することです。一般的なシナリオでは、書き換え要求がある場所から別の場所にジャンプすると、最初の場所ブロックで定義された命令は無視され、2 番目の場所ブロックで定義された命令のみが場所コンテキスト內(nèi)に有効になります。ここで簡単に言及しただけです。

実際、Nginx の設(shè)定はこれらだけではなく、他にもあります。結(jié)局のところ、Nginx には多くのモジュールがあり、各モジュールにはいくつかの特別な設(shè)定コマンドがある場合があります。ここでは、いくつかの基本的な設(shè)定情報(bào)についてのみ説明します。より深く、そして段階的に追加してください。間違いがあれば批判して修正してください。