1. 記事の説明
- 注: 現在説明しているのは nginx のコア テクノロジーの前半部分です。後の章では、前半部分をコア テクノロジーとして詳細に説明します。詳細については、後続のコースのリリースにご注意ください。
2. 環境の導入と準備
2.1 はじめに
Nginx (エンジン x) は、IMAP/POP3/SMTP サービスも提供する高性能 HTTP およびリバース プロキシ Web サーバーです。Nginx は、ロシアで 2 番目にアクセス数の多い Rambler.ru サイト (ロシア語: Рамблер) 用に Igor Sesoev によって開発され、最初の公開バージョン 0.1.0 が 2004 年 10 月 4 日にリリースされました。BSD のようなライセンスに基づいてソース コードをリリースしており、その安定性、豊富な機能セット、シンプルな構成ファイル、およびシステム リソースの消費量の少なさで知られています。2011 年 6 月 1 日、nginx 1.0.4 がリリースされました。Nginx は、BSD のようなプロトコルでリリースされた軽量の Web サーバー/リバース プロキシ サーバーおよび電子メール (IMAP/POP3) プロキシ サーバーです。その特徴は、占有メモリが少なく、強力な同時実行機能を備えていることです。実際、nginx の同時実行機能は、同じタイプの Web サーバー間でより優れたパフォーマンスを発揮します。中国本土の nginx Web サイトのユーザーには、Baidu、JD.com、Sina、NetEase、Tencent が含まれます。 、タオバオなど。
2.2 環境を準備する
注: 環境の準備とは、仮想マシンのインストール、Linux システムのインストール、仮想マシンの構成などを指します。環境の準備は、Linux を学習するときに以前に構成されているため、ここで仮想マシンを直接クローンしてから、IP とホスト名を変更できます。
- IP:
192.168.10.31
- ホスト名:
nginx01
2.2.1 仮想マシンのインストール
仮想マシンを使用して Nginx の
機能をインストールして学習します。
- 取り付けも使用も簡単
- 伝統的な企業で使用されている
- VPSに最適
- 高性能サーバーの導入に最適
2.2.2 学習中のコンピュータ構成
- メモリ:8G以上推奨
- ディスク:SSD推奨
- CPU : メインストリームには4コア以上で十分
2.2.3 仮想マシンのインストールと構成
準備:
- VMware、Virtualbox、Parallels
- CentOS7.4イメージ
オペレーティング システムをインストールして構成します。
- インターネットにアクセスするための仮想マシンの構成
- 静的 IP アドレスを構成する
2.2.4 仮想マシンがインターネットにアクセスできない場合の簡単なトラブルシューティング
- Vmware のゲートウェイは正しいですか?
- IP アドレスに直接 ping を実行できますか (物理接続のトラブルシューティング)。
- 教師と同じバージョンのソフトウェアを使用する
- アンインストールして再インストールする最も速い方法
3.nginxのインストール
3.1 4 つのリリースの概要
一般的に使用されるバージョンは 4 つのグループに分かれています
- Nginx オープンソース版
- http://nginx.org/
- 公式 Web サイトから直接ダウンロードしたオリジナル バージョンは比較的クリーンで、基本的な機能 (Web サイト サーバー、プロキシ サーバー、負荷分散) のみを備えていますが、二次開発を行うのはより難しく、多くのサードパーティ モジュールを統合する必要があります。
- Nginx プラス商用バージョン (基本的な nginx の拡張機能)
- https://www.nginx.com
- F5が公式に提供するnginxファミリーバケットにはすべての機能が備わっています
- Openresty (無料のオープンソース、基本的な nginx の拡張機能)
- http://openresty.org
- nginx と Lua スクリプトに基づく統合は比較的強力で、カスタマイズ機能をサポートしています。
- Tengine (無料のオープンソース、基本的な nginx の拡張機能)
- http://tengine.taobao.org/
- タオバオが開発したバージョンはC言語形式で拡張機能があり、二次開発機能は少ないですが、クラスタで使用する場合の安全性と安定性がより優れています。
3.2 Linux システムに nginx オープンソース バージョンをインストールする
3.2.1 バックアップ環境
その目的は、後続のインストール エラーを容易にし、以前のアンインストール状態を迅速に復元することです。
-
方法 1: スナップショットを使用する (例としてスナップショットを使用します)
-
方法 2: 現在の仮想マシンのクローンを作成する
3.2.2 インストール手順
1) 仮想マシンへのダウンロードとアップロード
2) 圧縮パッケージを解凍します。
tar zxvf nginx-1.21.6.tar.gz
3) 依存関係のチェック
# 进入到解压后的nginx目录
cd nginx-1.21.6/
# 检查依赖
./configure
- エラーが発生した場合: C 言語コンパイラがありません
checking for OS
+ Linux 3.10.0-693.el7.x86_64 x86_64
checking for C compiler ... not found
./configure: error: C compiler cc is not found
- 解決策: gcc をインストールする
yum install -y gcc
- システムの nginx ディレクトリにインストールします
# 此目录会自动生成
./configure --prefix=/usr/local/nginx
- エラーが発生した場合
./configure: error: the HTTP rewrite module requires the PCRE library.
You can either disable the module by using --without-http_rewrite_module
option, or install the PCRE library into the system, or build the PCRE library
statically from the source with nginx by using --with-pcre=<path> option.
- 解決策: Perl ライブラリをインストールする
yum install -y pcre pcre-devel
- 不足している依存関係がまだあるかどうかをもう一度確認してください
./configure --prefix=/usr/local/nginx
- エラーが発生しました
./configure: error: the HTTP gzip module requires the zlib library.
You can either disable the module by using --without-http_gzip_module
option, or install the zlib library into the system, or build the zlib library
statically from the source with nginx by using --with-zlib=<path> option.
- 解決策: zlib ライブラリをインストールする
yum install -y zlib zlib-devel
- 不足している依存関係がないか再度確認してください
./configure --prefix=/usr/local/nginx
- 依存関係に不足はなく、ログエラーの影響はないことがわかります。
4) インストール
# 2条命令依次执行
make
make install
インストール前に設定した/usr/local/nginx
ディレクトリにnginxがあるか確認する
5) nginxの起動(共通コマンド)
- インストールが成功すると、usr に追加のフォルダー local/nginx が作成され、nginx ディレクトリー内に sbin ディレクトリーがあり、sbin ディレクトリー内に起動スクリプトが存在します。
- インストールされたディレクトリ /usr/local/nginx/sbin を入力します。
./nginx 启动
./nginx -s stop 快速停止
./nginx -s quit 优雅关闭,在退出前完成已经接受的连接请求
./nginx -s reload 重新加载配置
./nginx -v 查看 nginx 版本号
3.2.3 ファイアウォールについて
Windows システムの Linux で nginx にアクセスする場合、ファイアウォールの問題により、デフォルトではアクセスできません。
- 方法 1: ファイアウォールをオフにする
# 关闭防火墙
systemctl stop firewalld.service
# 禁止防火墙开机启动
systemctl disable firewalld.service
- 方法 2: オープン アクセス ポート番号、ポート 80
# 放行端口
firewall-cmd --zone=public --add-port=80/tcp --permanent
# 重启防火墙
firewall-cmd --reload
查看防火墙开放的端口号有哪些
firewall-cmd --list-all
3.2.4 アクセステスト
ファイアウォールがオフであることが前提で、
デフォルトのポート番号は80ですが、省略可能です。
http://192.168.10.31/
3.2.5 システムサービスとしてインストール(スクリプトコマンドによる起動)
注: 現在、nginx 実行ファイルを起動するときに sbin ディレクトリに移動して実行するのは非常に面倒ですが、スクリプトとしてインストールすると使いやすくなります。
サービススクリプトの作成
# 创建目录和文件
vi /usr/lib/systemd/system/nginx.service
サービススクリプトの内容
注: パスは、以前の nginx インストール パスと一致している必要があります。
[Unit]
Description=nginx - web server
After=network.target remote-fs.target nss-lookup.target
[Service]
Type=forking
PIDFile=/usr/local/nginx/logs/nginx.pid
ExecStartPre=/usr/local/nginx/sbin/nginx -t -c /usr/local/nginx/conf/nginx.conf
ExecStart=/usr/local/nginx/sbin/nginx -c /usr/local/nginx/conf/nginx.conf
ExecReload=/usr/local/nginx/sbin/nginx -s reload
ExecStop=/usr/local/nginx/sbin/nginx -s stop
ExecQuit=/usr/local/nginx/sbin/nginx -s quit
PrivateTmp=true
[Install]
WantedBy=multi-user.target
実行可能プログラムの起動方法を使用する前に、システム サービスをリロードし、シャットダウンします。
#重新加载系统服务
systemctl daemon-reload
#查看使用ngin可执行程序启动的方式是否还在
ps -ef | grep nginx
#关闭之前使用可执行程序启动的方式,否则2种方式都有可能会造成冲突
./nginx -s stop 快速停止
サービス開始
# 启动服务
systemctl start nginx.service
# 停止服务
systemctl stop nginx.service
#查看启动状态
systemctl status nginx.service
3.2.6 起動
systemctl enable nginx.service
4. ディレクトリ構造と基本的な動作原理
4.1 目次
Nginx ホームディレクトリに入ると、これらのフォルダーが表示されます。
client_body_temp
conf 用来存放配置文件相关
fastcgi_temp
html 用来存放静态文件的默认目录 html、css等
logs
proxy_temp
sbin nginx的主程序
scgi_temp
uwsgi_temp
これらのフォルダーはインストール後は使用できなくなり、主に操作中に一時ファイルを保存するために使用されます。
client_body_temp
fastcgi_temp
proxy_temp
scgi_temp
4.2 基本的な動作原理
概要: nginx は起動すると、1 つのプロセスを起動するだけでなく、複数のプロセスを同時に実行します。メイン プロセスのマスターは動作していませんが、サブプロセスのワーカーを調整するために使用されます。構成ファイルの検証はメイン プロセスによって完了します。ワーカーは構成ファイルを読み取って特定のファイルを見つけます。
5. Nginxの基本構成
-
構成ファイルが置かれているディレクトリ:
cd /usr/local/nginx/conf/
-
設定ファイル:
nginx.config
-
設定ファイルの完全な情報
#user nobody;
worker_processes 1;
#error_log logs/error.log;
#error_log logs/error.log notice;
#error_log logs/error.log info;
#pid logs/nginx.pid;
events {
worker_connections 1024;
}
http {
include mime.types;
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"';
#access_log logs/access.log main;
sendfile on;
#tcp_nopush on;
#keepalive_timeout 0;
keepalive_timeout 65;
#gzip on;
server {
listen 80;
server_name localhost;
#charset koi8-r;
#access_log logs/host.access.log main;
location / {
root html;
index index.html index.htm;
}
#error_page 404 /404.html;
# redirect server error pages to the static page /50x.html
#
error_page 500 502 503 504 /50x.html;
location = /50x.html {
root html;
}
# proxy the PHP scripts to Apache listening on 127.0.0.1:80
#
#location ~ \.php$ {
# proxy_pass http://127.0.0.1;
#}
# pass the PHP scripts to FastCGI server listening on 127.0.0.1:9000
#
#location ~ \.php$ {
# root html;
# fastcgi_pass 127.0.0.1:9000;
# fastcgi_index index.php;
# fastcgi_param SCRIPT_FILENAME /scripts$fastcgi_script_name;
# include fastcgi_params;
#}
# deny access to .htaccess files, if Apache's document root
# concurs with nginx's one
#
#location ~ /\.ht {
# deny all;
#}
}
# another virtual host using mix of IP-, name-, and port-based configuration
#
#server {
# listen 8000;
# listen somename:8080;
# server_name somename alias another.alias;
# location / {
# root html;
# index index.html index.htm;
# }
#}
# HTTPS server
#
#server {
# listen 443 ssl;
# server_name localhost;
# ssl_certificate cert.pem;
# ssl_certificate_key cert.key;
# ssl_session_cache shared:SSL:1m;
# ssl_session_timeout 5m;
# ssl_ciphers HIGH:!aNULL:!MD5;
# ssl_prefer_server_ciphers on;
# location / {
# root html;
# index index.html index.htm;
# }
#}
}
- 設定ファイルのコメント部分の情報を削除します。
- ここで学習するのは簡略化した設定ファイルのみで、アノテーション部分については以下で説明します。
worker_processes 1;
events {
worker_connections 1024;
}
http {
include mime.types;
default_type application/octet-stream;
sendfile on;
keepalive_timeout 65;
server {
listen 80;
server_name localhost;
location / {
root html;
index index.html index.htm;
}
error_page 500 502 503 504 /50x.html;
location = /50x.html {
root html;
}
}
}
5.1 最小限の設定ファイル
ワーカープロセス
# 默认为1,表示开启一个业务进程(一般一个cpu内核对应一个业务进程)
worker_processes 1;
ワーカー接続
# 单个业务进程可接受连接数
worker_connections 1024;
mime.types を含めます。
# 引入额外的配置文件
# 这个文件设置的是请求的头,标名当前返回或者发送的文件是什么类型
include mime.types;
デフォルトタイプアプリケーション/オクテットストリーム;
# 如果mime配置文件中的类型没匹配上,默认使用二进制流的方式传输。
default_type application/octet-stream;
ファイルを送信します。
# 使用linux的 sendfile(socket, file, len) 高效网络传输,也就是数据0拷贝。
# 所谓的零拷贝,其目的并不是说不需要拷贝数据,而是通过一些手段省略 CPU 拷贝环节,减少了不必要的拷贝次数,提升数据拷贝效率。
sendfile on;
sendfile が有効になっていない
後のKeepalive_timeout 65
。
# 保持连接超时的时间
keepalive_timeout 65;
サーバー: 仮想ホスト構成
#一个server代表一台虚拟主机(vhost)
#一个主机,多个主机都可以配置在nginx的配置文件中
server {
listen 80; 监听当前服务器的端口号
server_name localhost; 域名或主机名
#域名后面跟的子路径(到后面在详解)
# 举例:http://atguigu.com/xxoo/index.html,匹配atguigu.com域名后的路径。
location / {
匹配路径
root html; 文件根目录(nginx的安装路径)
index index.html index.htm; 默认页名称
}
#http://atguigu.com/xxoo/index.html一旦报错会替换为
#http://atguigu.com/50x.html,跳转到50x.html页面
#但是没有这个50x.html页面,所以在下面定义这个页面路径
#逻辑:跳转到这个页面,但是这个页面没有,用户一旦访问/50x.html,
#会从root html这个目录下去寻找50x.html页面
error_page 500 502 503 504 /50x.html; 报错编码对应页面
location = /50x.html {
root html;
}
}
6. 仮想ホストとドメイン名の解決
6.1 ブラウザ、Nginx、および http プロトコル
-
TCP プロトコル: TCP は、データをストリーム形式で送信する広範なブラウザ プロトコルです (データはバイナリです)。
-
データ フロー: 蛇口に相当し、オンになった後もデータが流れ続け、オフにするアクションはありません。
-
HTTP プロトコル: TCP 上のプロトコルです。ストリームをオフにするタイミングを TCP プロトコルに指示します。ユーザーのブラウザと Nginx サーバーの両方が HTTP プロトコルに準拠し、実装している場合、それらの間で情報を交換できます。通信されて受け渡されます。の上。
-
HTTPS プロトコル: データを保護するためにデータ暗号化の層を追加する HTTP 上のプロトコル。
-
リクエストプロセス: ユーザーのブラウザがリクエストを送信 -> ゲートウェイ (階層型ゲートウェイ) -> -> インターネット -> Nginx サーバー -> リクエストを解析 -> リソースを検索 -> ユーザーに返す
6.2 仮想ホストの原理
-
本来、1台のサーバーは1つのサイトにしか対応できませんが、バーチャルホスト技術により複数のサイトに仮想化し、同時に外部にサービスを提供することができます。
-
このようなシナリオがある場合、ホストが 1 つのサイトのみをマウントすると、このサイトへのアクセスがあまり多くない場合、過剰なリソースが発生します (リソースが残っています)。このとき、仮想ホストをオンにしてマウントすることができます。複数のサイト、ホスト リソースの合理的な使用。
-
IP アドレスは複数のドメイン名に対応することができます。ドメイン名に応じて、これらのドメイン名に対応するリソース ディレクトリが検索されます。これらのリソースが見つかった後、ユーザーに返されます。
-
もちろん、このドメイン名をリクエスト メッセージに追加する必要があります。そうしないと、サーバーはどのドメイン名リソースが必要かを認識できなくなります。
6.3 実際のドメイン名解決と汎ドメイン名解決
6.3.1 hosts ファイルを使用してドメイン名を解決する
hosts ファイルとは: 簡単に言うと、hosts ファイルはローカル DNS サービスに使用されます。ip ドメイン名の形式でテキスト ファイルに書き込まれます。hosts は拡張子のないシステム ファイルです。次のようなツールで開くことができます。メモ帳として機能します。その機能は、一般的に使用される URL ドメイン名とそれに対応する IP アドレスの間に関連付けられた「データベース」を確立することです。ユーザーがブラウザにログインする必要がある URL を入力すると、システムはまず、その URL を自動的に検索します。 Hosts ファイルからの対応する IP アドレス。見つかると、システムは対応する Web ページをすぐに開きます。見つからない場合は、システムは IP アドレス解決のために URL を DNS ドメイン名解決サーバーに送信します。
- switchhosts を管理者として使用して、hosts ファイルを開き、次の構成を実行します。
#虚拟机ip 空格 编写的域名
192.168.10.31 s1.com
- テスト結果: ドメイン名を使用すると正常に ping が実行され、デフォルト ページに正しくアクセスできることがわかりました。
6.3.2 パブリック ネットワークのドメイン名の構成と汎ドメイン名解決の実践
注: 上記は、hosts ファイルでドメイン名解決を設定しているように見せかけています。企業では、通常、実際のドメイン名を購入して使用します。ここでは、実際のドメイン名を設定および解決する方法と、設定されているオプションについて説明します。という意味で。
- ドメイン名の最大のプロバイダーは Wanwang で、Alibaba Cloud に買収されたため、Alibaba Cloud に直接ログインしてドメイン名を購入できます。
- 小規模なサプライヤーが逃げ出す可能性があるため、大手ブランドのサプライヤーからドメイン名を購入することをお勧めします。
- 初めての方は、ドメイン名を無料でお試しいただけます。ここでは例としてドメイン名を使用します。登録手順は次のとおりです。
-
Alibaba Cloud ホームページにログインし、「無料トライアル」をクリックします。
-
ドメイン名を検索する
-
利用したいドメイン名が登録されているか確認する
-
登録するには、情報テンプレートに記入する必要があります
-
情報テンプレートページに個人情報を入力して送信してください。情報テンプレートの審査には時間がかかります。
-
情報テンプレートが正常に確認されたら、注文確認ページに戻って購入と支払いを行います。
-
登録したばかりのドメイン名がドメイン名コンソールに表示されます (レジストリによる確認には時間がかかります)。
-
- 登録済みのドメイン名を使用します。
-
ドメイン名の解決: ドメイン名を仮想マシン (イントラネットまたは外部ネットワーク) の IP アドレスに解決します。つまり、ドメイン名が IP アドレスを指すようにします。
-
解析が成功したかどうかを確認します。
ping www.xiaomings.xyz
-
ドメイン名を使用して nginx のデフォルト ページにアクセスします: アクセス成功
-
ドメイン名が多数ある場合は、解決のためにレコードを 1 つずつ追加する必要があります。
-
第 2 レベル、第 3 レベルのドメイン名が多数ある場合、たとえばドメイン名のプレフィックスが多い場合は、ワイルドカードを使用して設定することができ、このとき、任意のプレフィックスを持つドメイン名にアクセスできます。
-
6.3.3 Nginx 仮想ホストのドメイン名の設定
- 現在、アクセスされるすべてのドメイン名は 1 つの IP アドレスを指しており、サービスを提供できるサイトは 1 つだけです。次に、アクセスできるように複数のサイトを構成します。
ステップ:
- サイトディレクトリを作成します: www
- www ディレクトリに 2 つのサイトを作成します: www、vod
- テスト用に 2 つのサイトにそれぞれページを作成します
- 設定ファイルを変更します: 間違いを恐れる必要はありません。以下に nginx のデフォルトの設定ファイルもあります。間違いを犯した場合は復元できます。
worker_processes 1;
events {
worker_connections 1024;
}
http {
include mime.types;
default_type application/octet-stream;
sendfile on;
keepalive_timeout 65;
#虚拟主机www
server {
listen 80;
server_name www.xiaomings.xyz; #主机名、域名
location / {
root /www/www;
index index.html index.htm;
}
error_page 500 502 503 504 /50x.html;
location = /50x.html {
root html;
}
}
#虚拟主机vod
server {
listen 80;
server_name vod.xiaomings.xyz; #主机名、域名
location / {
root /www/vod;
index index.html index.htm;
}
error_page 500 502 503 504 /50x.html;
location = /50x.html {
root html;
}
}
}
-
nginx を再起動して有効にします。
systemctl reload nginx
-
アクセステスト:2つのドメイン名でそれぞれアクセスし、ページにアクセスできることを確認します。
6.3.4 サーバー名の一致ルール
注意する必要があるのは、サーバー名の一致が順序であり、前の一致に書かれている場合、それ以降は一致しません。
DNS はドメイン名を IP アドレスに解決し、一致ルールに基づいてサーバー上のリソースを検索します。
完全一致
同じサーバー名内の複数のドメイン名を一致させることができます
server_name vod.mmban.com www1.mmban.com;
ワイルドカードマッチング
server_name *.mmban.com
ワイルドカードは一致を終了します
server_name vod.*;
レギュラーマッチ
server_name ~^[0-9]+\.mmban\.com$;
6.3.5 ドメイン名に基づくいくつかのインターネット企業のニーズ
• マルチユーザーの第 2 レベルのドメイン名
• 短縮URL
• httpdns
7. リバースプロキシ
リバース プロキシ サーバーはユーザーとターゲット サーバーの間に配置されますが、ユーザーにとってリバース プロキシ サーバーはターゲット サーバーと同等です。つまり、ユーザーはリバース プロキシ サーバーに直接アクセスして、ターゲット サーバーのリソースを取得できます。 。同時に、ユーザーはターゲットサーバーのアドレスを知る必要がなく、クライアント側で設定を行う必要もありません。リバース プロキシ サーバーは通常、Web アクセラレーションとして使用できます。つまり、Web サーバーのフロントエンド マシンとしてリバース プロキシを使用すると、ネットワークとサーバーの負荷が軽減され、アクセス効率が向上します。
7.1 ゲートウェイ、プロキシ、およびリバース プロキシ
-
ゲートウェイ: ネットワークへの入り口がゲートウェイであり、プロキシ サーバーもゲートウェイです。すべてのリクエストはゲートウェイを通過します。したがって、ゲートウェイの帯域幅が十分でなければ、ネットワークの帯域幅がどんなに高くても役に立たないという欠点があります。この問題は、lvs の DR モデルで解決できます DR モデルは、リクエストが入る際にはゲートウェイを経由しますが、サーバーからクライアントにデータを転送する際にはゲートウェイを経由しません。
-
フォワードプロキシ: 明確な宛先を持つリクエストがクライアントから送信されます。クライアントによって開始されたリクエストは、明確な宛先を知っていますが、外部ネットワークなど、そこにアクセスすることはできません。このとき、プロキシサーバーを使用して、アクセスするのに役立ちます。アクセスするターゲット。フォワード プロキシでは、クライアントがプロキシされる側であり、サーバーは誰がリクエストを送信したかを知りません。
-
リバースプロキシ: 明確な宛先を持つリクエストがサーバーから行われます。クライアントは、そのリクエストが実際にどのサーバーに送信されるのかを知りませんが、サーバーは誰がリクエストを送信したかを知っています。リバース プロキシでは、サーバーがプロキシされ、クライアントはリクエストが実際に誰に送信されるかを知りません。
-
フォワードプロキシとリバースプロキシ、フォワードとリバースを区別するにはどうすればよいですか?
- クライアントに対して順方向であっても逆方向であっても、順方向と逆方向のターゲットはクライアントです。
7.2 システムアーキテクチャにおけるリバースプロキシの適用シナリオ
- 従来の企業システム アーキテクチャ:
まず、ユーザーはルーティングとドメイン名解決を通じてインターネットにアクセスし、次にコンピューター室のゲートウェイに送信され、次にファイアウォールを通って nginx サーバーに送信され、その後 nginx サーバー プロキシによって実サーバーに転送されます。 。
- 中小規模のインターネット企業の場合:
nginx はリバース プロキシとして機能するだけでなく、ビジネス ロジックでいくつかの機能を実行し、ファイル ゲートウェイ サーバーなどとしても機能します。