nginx

Nginx
Nginx 的歷史
Nginx 特點
高併發,CPU消耗低,內存消耗少,它可以保持1000個沒有活動的連接只佔2.5M內存,成本低廉,配置簡單、
支持Rewrite重寫、內置健康檢查功能、節省帶寬、穩定性高、支持熱部署,效率高,具有穩定性,可以實
現靜態網頁,啓動容易,可以實現負載均衡和反向代理
Nginx是俄羅斯人編寫的十分輕量級的HTTP服務器,Nginx,它的發音爲“engine X”, 是一個高性能的
HTTP和反向代理服務器,同時也是一個IMAP/POP3/SMTP 代理服務器.Nginx是由俄羅斯人 Igor Sysoev爲
俄羅斯訪問量第二的 Rambler.ru站點開發的.Igor Sysoev在建立的項目時,使用基於BSD許可.自Nginx 發佈
以來,Nginx 已經因爲它的穩定性、豐富的功能集、示例配置文件和低系統資源的消耗而聞名.在俄羅斯許多
大網站都已經使用它, 且一直表現不凡.俄羅斯大約有20%左右的虛擬主機是由nignx服務或代理的.Google
在線安全博客中統計Nginx服務或代理了大約所有Internet虛擬主機的4%.而Netcraft的統計顯示,Nginx服
務的主機在過去的一年裏以四倍的速度增長並且在這幾年裏,它的排名還在不斷上升
爲什麼要用Nginx
Nginx專爲性能優化而開發,性能是其最重要的考量,實現上非常注重效率 .它支持內核Poll模型,能經受高
負載的考驗,有報告表明能支持高達 50,000個併發連接數.Nginx具有很高的穩定性,其它HTTP服務器當遇
到訪問的峯值,或者有人惡意發起慢速連接時,也很可能會導致服務器物理內存耗盡頻繁交換,失去響應只能
重啓服務器.例如當前Apache一旦上到200個以上進程,web響應速度就明顯非常緩慢了.而Nginx採取了分
階段資源分配技術,使得它的CPU與內存佔用率非常低.Nginx官方表示保持10,000(即C10K)個沒有活動的連
接,它只佔2.5M內存,所以類似DOS這樣的***對Nginx來說基本上是毫無用處的.就穩定性而言,nginx比
lighttpd更勝一籌.Nginx支持熱部署,它的啓動特別容易, 並且幾乎可以做到7*24不間斷運行,即使運行數個
月也不需要重新啓動.你還能夠在不間斷服務的情況下,對軟件版本進行進行升級.Nginx採用master-slave模
型,能夠充分利用SMP的優勢,且能夠減少工作進程在磁盤I/O的阻塞延遲.
Nginx代碼質量非常高,代碼很規範,手法成熟, 模塊擴展也很容易.
Nginx採用了一些os提供的最新特性如對sendfile (Linux2.2+),acceptfilter(FreeBSD4.1
+),TCP_DEFER_ACCEPT (Linux 2.4+)的支持,從而大大提高了性能.當然,nginx還很年輕,多多少少存在一
些問題,比如:Nginx是俄羅斯人創建,目前文檔方面還不是很完善.因爲文檔大多是俄語,所以文檔方面這也
是個障礙.儘管Nignx的模塊比較多,但它們還不夠完善.對腳本的支持力度不夠.
nginx和apache的80端口之爭(必看):https://cloud.tencent.com/developer/news/139466

獲取Nginx
Nginx的官方網站: http://nginx.org/en/download.html
Nginx官網提供了三個類型的版本
Mainline version:Mainline 是 Nginx 目前主力在做的版本,可以說是開發版
Stable version:最新穩定版,生產環境上建議使用的版本
Legacy versions:遺留的老版本的穩定版
2/34

服務器系統和軟件排名統計網站:www.netcraft.com

3/34

nginx安裝
源碼包的編譯安裝流程:
1、安裝gcc、gcc-c++編譯器和相關的依賴包
2、下載軟件的源碼包、解包解壓縮
3、生成安裝配置文件: ./configuration [選項]
4、根據配置文件編譯源碼文件:make
5、安裝:make install
nginx源碼包的安裝實例:
1、 安裝gcc、gcc-c++編譯器:yum install -y gcc gcc-c++ wget curl
2、 用wget下載nginx軟件的源碼包、解包解壓縮:http://nginx.org
wget http://nginx.org/download/nginx-1.15.8.tar.gz
ls
tar -xvf nginx-1.15.8.tar.gz
3、 生成安裝配置文件Makefile:
cd nginx-1.15.8
yum install -y pcre-devel openssl-devel
./configure
4、 根據Makefile配置文件編譯源碼文件:make
5、 安裝:make install
6、 創建nginx命令的快捷方式:ln -s /usr/local/nginx/sbin/nginx /bin/nginx
7、 啓動nginx服務:
nginx -h 查nginx命令的幫助
nginx -t 檢測nginx配置文件語法
nginx 啓動nginx服務
nginx -s reload 重啓nginx服務
nginx -s stop 停止nginx服務
8、 訪問nginx的默認網站:curl 192.168.11.11
瀏覽器訪問nginx的默認網站:http://192.168.11.11
4/34
Nginx編譯安裝:

  1. 停止原有web服務器: lsof -i:80 && systemctl stop httpd
    2.下載nginx-1.8.1版的軟件:
    首先,在瀏覽器中輸入nginx.org回車進入nginx的官網,然後單擊網站右側的download進入下載頁面,復
    制nginx-1.8.1版的網址,再執行如下命令。
    cd
    wget http://120.52.51.13/nginx.org/download/nginx-1.8.1.tar.gz
    ls nginx
  2. 添加普通用戶賬號來運行nginx:
    [root@clone1 nginx-1.8.1]# useradd nginx -M -s /sbin/nologin
    [root@clone1 nginx-1.8.1]# yum install -y gcc pcre-devel openssl-devel 安裝gcc編譯器和相
    關的依賴包
  3. 解壓並安裝Nginx:
    [root@clone1 nginx-1.8.1]# tar xf nginx-1.8.1.tar.gz
    [root@clone1 nginx-1.8.1]# cd nginx-1.8.1
    [root@clone1 nginx-1.8.1]# ./configure --prefix=/usr/local/nginx --user=nginx --group=nginx --
    with-http_stub_status_module --with-http_ssl_module 生成編譯安裝的Makefile環境配置文件
    [root@clone1 nginx-1.8.1]# make && make install

    --prefix=/usr/local/nginx \指定安裝路徑
    --with-http_stub_status_module \聲明啓用service status服務狀態頁,默認不啓用
    --with-http_ssl_module \啓用ssl(Secure Sockets Layer安全套接層)模塊,以支持https請

    --sbin-path=/usr/bin/ \聲明nginx命令目錄

  4. 啓動:
    [root@clone1 nginx-1.8.1]# ln -s /usr/local/nginx/sbin/nginx /usr/bin/nginx
    [root@clone1 nginx-1.8.1]# nginx -t 檢測nginx配置文件的語法
    [root@clone1 nginx-1.8.1]# nginx 啓動nginx服務
    [root@clone1 nginx-1.8.1]# lsof -i:80 或 netstat -atunlp | grep :80

    查看命令幫助:
    /usr/local/nginx/sbin/nginx -h
    -v 查看nginx版本
    -V 查看編譯參數
    -t 測試默認配置文件
    -c 加載非默認位置配置文件,默認配置文件是/usr/local/nginx/conf/nginx.conf
    -s 發送信號(signal)給nginx的master主進程,信號可以是stop, quit, reopen, reload
    nginx文件解說:
    nginx的工作目錄:/usr/local/nginx/
    主配置文件:/usr/local/nginx/conf/nginx.conf
    默認主頁目錄:/usr/local/nginx/html/
    默認主頁:/usr/local/nginx/html/index.html
    50x錯誤提示網頁:/usr/local/nginx/html/50x.html
    日誌文件目錄:/usr/local/nginx/logs
    mkdir /usr/local/nginx/conf.d
    sed -i '18a\ include /usr/local/nginx/conf.d/*.conf;' /usr/local/nginx/conf/nginx.conf
    5/34
    練習:修改nginx的默認主頁文件,並做內測。
    echo 'welcome to nginx software.' >> /usr/local/nginx/html/index.html
    lsblk >> /usr/local/nginx/html/index.html
    elinks 127.0.0.1

  5. 查看啓動狀態:
    [root@clone1 nginx-1.8.1]# netstat -tanp|grep 80
    tcp 0 0 0.0.0.0:80 0.0.0.0:* LISTEN 5535/nginx
  6. 測試主頁是否可以訪問:
    在192.168.11.11本地測試(內測):elinks 127.0.0.1
    在192.168.11.1的win7系統中遠程測試(公測):Win+R運行-->explorer http://192.168.11.11

8.kill信號:
TERM, INT 快速關閉
QUIT 從容關閉,關閉主進程順便關閉工作子進程
HUP 重載配置用新的配置開始新的工作進程從容關閉舊的工作進程
USR1 重新打開日誌文件
USR2 平滑升級可執行程序
WINCH 從容關閉工作進程,不會立即關閉子進程
作業
1.編寫一個名稱爲/sh/nginx.sh的腳本,要求實現自動下載nginx-1.8.1.tar.gz軟件包,並自動解壓和安裝
nginx軟件包,最後啓動nginx服務,並用elinks做內測。
方法一
#!bin/bash
lsof -i:80 && systemctl stop httpd
wget http://nginx.org/download/nginx-1.8.1.tar.gz
ls && (useradd nginx -M -s /sbin/nologin;id nginx)
yum -y install gcc openssl-devel pcre-devel
tar xf nginx-1.8.1.tar.gz
ls && cd nginx-1.8.1/
./configure --prefix=/usr/local/nginx --user=nginx --group=nginx --with-http_stub_status_module --
with-http_ssl_module
make && make install
ln -s /usr/local/nginx/sbin/nginx /usr/bin/nginx
nginx -t && nginx
lsof -i:80
elinks 127.0.0.1
方法二
touch nginx.sh
chmod -v +x nginx.sh
cat > nginx.sh <<EOF
#!/bin/bash
id nginx || useradd -M -s /sbin/nologin nginx
6/34
yum install -y gcc pcre-devel openssl-devel curl elinks
[ -f nginx-1.10.3.tar.gz ] && tar xf nginx-1.10.3.tar.gz
[ -d nginx-1.10.3 ] && cd nginx-1.10.3
./configure --prefix=/usr/local/nginx \
--user=nginx \
--group=nginx \
--with-http_stub_status_module \
--with-http_ssl_module
read -p '按enter鍵繼續安裝nginx...'
make && make install
#測試配置文件,並啓動nginx服務.
ln -s /usr/local/nginx/sbin/nginx /usr/bin/nginx
nginx -t
nginx
curl 127.0.0.1
netstat -ntlp|grep :80
chmod -v +x /etc/rc.d/rc.local
grep nginx /etc/rc.d/rc.local||echo '/usr/local/nginx/bin/nginx' >> /etc/rc.d/rc.local
pwd
cd ..
mkdir -pv /usr/local/nginx/conf.d
grep 'conf.d' /usr/local/nginx/conf/nginx.conf
[ \$? -eq 0 ] || sed -i '18a\include ../conf.d/*.conf;' /usr/local/nginx/conf/nginx.conf
read -p 'ctrl+c退出操作。按enter鍵,繼續配置8081端口的虛擬主機...'
cat > /usr/local/nginx/conf.d/8081.conf <<EOA
server {
listen 8081;
server_name localhost;
#charset koi8-r;
#access_log logs/host.access.log main;
location / {
root html/8081;
index index.html index.htm;
}
}
EOA
mkdir -pv /usr/local/nginx/html/8081
echo 'www.8081.com:8081' > /usr/local/nginx/html/8081/index.html
nginx -t && nginx -s reload
netstat -atnlp|grep 80
curl 127.0.0.1:8081
EOF
2.給node11主機臨時設置一個新IP 192.168.11.110,並在此主機上創建網站主頁目錄/web/qf,網站主
頁文件爲/web/qf/index.html,用nginx基於IP和端口(端口號爲8088)的虛擬主機技術發佈此網站,配置文
件名爲/usr/local/nginx/conf.d/qf.conf。網站域名爲web.qf.com。
ifconfig ens33:4 192.168.11.110 up
ip a
mkdir -pv /web/qf
echo welcome to linux >/web/qf/index.html
vim /usr/local/nginx/conf.d/qf.conf
server {
listen 192.168.11.110:8088;
server_name web.qf.com;
location / {
7/34
root /web/qf;
index index.html index.htm;
}
}
nginx -t
nginx -s reload
curl 192.168.11.110:8088
3.要求給第2題的web.qf.com的網站做基於用戶認證的訪問控制,允許alice用戶訪問此網站。
htpasswd -c /usr/local/nginx/passwd alice
New password:0
Re-type new password:0
vim /usr/local/nginx/conf.d/qf.conf
server {
listen 192.168.11.110:8088;
server_name web.qf.com;
location / {
root /web/qf;
index index.html index.htm;
auth_basic "ll";
auth_basic_user_file /usr/local/nginx/passwd;
}
}
nginx -t
nginx -s reload
curl 192.168.11.110:8088 -u alice:0
nginx.sh
配置文件詳解
nginx主配置文件主要有以下幾大塊
1、全局塊:配置影響nginx全局的指令。一般有運行nginx服務器的用戶組,nginx進程pid存放路徑,日
志存放路徑,配置文件引入,允許生成worker process數等。
2、events(事件)塊:配置影響nginx服務器或與用戶的網絡連接。有每個進程的最大連接數,選取哪種
事件驅動模型處理連接請求,是否允許同時接受多個網路連接,開啓多個網絡連接序列化等。
3、http塊:可以嵌套多個server(可用於配置web虛擬主機),配置代理,緩存,日誌定義等絕大多數功
能和第三方模塊的配置。如文件引入,mime-type定義,日誌自定義,是否使用sendfile傳輸文件,連接超
時時間,單連接請求數等。
4、server(服務器)塊:配置虛擬主機的相關參數,一個http中可以有多個server。
5、location(定位)塊:配置請求的路由(用於做反向代理、正向代理),以及各種頁面的處理情況。
[root@clone1 nginx]# vim /usr/local/nginx/conf/nginx.conf
#user nobody; #nginx用戶及組,如果用戶和組名一樣可只寫一個
worker_processes 1; #定義了nginx對外提供web服務時的worker進程數。
#最優值取決於許多因素,包括(但不限於)CPU核的數量、存
8/34
儲數據的硬盤數量及負載模式。
#不能確定的時候,將其設置爲可用的CPU核心數將是一個好的
開始(設置爲“auto”將嘗試自動檢測它)
#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;
server_tokens off; #隱藏軟件版本號
#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;

9/34
#}

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;

}

#}
}
自定義日誌
自己定義日誌:在日誌部分寫入
log_format cust '$remote_addr : $time_local : $http_user_agent';
access_log logs/access.log cust; #cust:自定義的日誌名稱
測試自定義日誌: # curl 192.168.1.254
#cat access.log
訪問的Ip:訪問的時間:訪問的客戶端的類型
$remote_addr 記錄客戶端的ip
$remote_user 記錄遠程客戶端的名字
$time_local 記錄訪問時間
$request 記錄請求的URL或HTTP協議
$status 記錄請求狀態
10/34
$body_bytes_sent 記錄發送給客戶端的文件的內容的大小
$http_referer 記錄從哪個頁面鏈接訪問過來的
$http_user_agent 記錄客戶端瀏覽器的信息
$http_x_forwarded_for 記錄客戶端的ip
虛擬主機
web虛擬主機:
就是虛擬出來的主機,實質上是在一臺物理主機上發佈多個網站。實現web虛擬主機的方法有基於IP、
端口、域名。

基於IP的虛擬主機:
準備工作:準備網站主頁目錄和主頁,給ens33網卡臨時設置192.168.11.21和192.168.11.22這兩個IP。
mkdir -pv /11 /12
echo www.11.com > /11/index.html
echo www.12.com > /12/index.html
ifconfig ens33:1 192.168.11.21/24 up
ifconfig ens33:2 192.168.11.22/24 up
ifconfig 或 ip a
創建虛擬主機的配置文件:
mkdir /usr/local/nginx/conf.d
grep -n include /usr/local/nginx/conf/nginx.conf
sed -i '18a\ include /usr/local/nginx/conf.d/*.conf;' /usr/local/nginx/conf/nginx.conf
grep -n include /usr/local/nginx/conf/nginx.conf
vim /usr/local/nginx/conf.d/ip.conf 基於IP的虛擬主機配置文件代碼如下
server {
listen 192.168.11.21:80; 監聽192.168.11.21 IP的80號端口
server_name web.11.com; 服務器的名稱(域名,即網址)
location / { 定位設置(也稱位置設置)
root /11; 網站主頁的根目錄
index index.html index.htm; 默認的主頁文件索引列表
}
}
server {
listen 192.168.11.22:80;
server_name web.12.com;
location / {
root /12;
index index.html index.htm;
}
}
本地測試:
nginx -t
nginx -s reload
curl 192.168.11.21
curl 192.168.11.22
11/34

基於端口的虛擬主機:
server {
listen 192.168.11.21:8081;
server_name web.11.com;
location / {
root /11;
index index.html index.htm;
}
}
server {
listen 192.168.11.21:8082;
server_name web.12.com;
location / {
root /12;
index index.html index.htm;
}
}

本地測試:
nginx -t
nginx -s reload
curl 192.168.11.21:8081
curl 192.168.11.21:8082

基於域名的虛擬主機:
1.域名解析
方法一:用/etc/hosts文件做本地域名解析
echo '192.168.11.11 web.11.com web.12.com' >> /etc/hosts
ping -c 2 web.11.com
ping -c 2 web.12.com
2.修改配置文件vim /usr/local/nginx/conf.d/ip.conf
server {
listen 80 default; #default 在瀏覽器中直接鍵入IP地址會進入這個;
server_name web.11.com;
location / {
root /11; #發佈/11目錄
index index.html index.htm;
}
}
server {
listen 80;
server_name web.12.com;
location / {
root /12; #發佈/12目錄
index index.html index.htm;
}
}
server {
listen 80;
server_name www.baidu.com;
location / {
12/34
root /baidu; #發佈/baidu目錄
index index.html index.htm;
}
}
本地測試:
nginx -t
nginx -s reload
curl www.google.com
curl www.163.com
在win7/10下訪問測試:
首先,在c:\windows\system32\drivers\etc\hosts文件中添加如下內容
192.168.11.11 web.11.com web.12.com
然後,打開IE、UC、360、chrome、firefox瀏覽器,輸入如下網址進行測試:
web.11.com
web.12.com
訪問控制
訪問控制:
有時我們會有這麼一種需求,就是你的網站並不想提供一個公共的訪問或者某些頁面不希望公開,我們
希望的是某些特定的客戶端可以訪問.那麼我們可以在訪問時要求進行身份認證,就如給你自己的家門加一
把鎖,以拒絕那些不速之客.我們在服務課程中學習過apache的訪問控制,對於Nginx來說同樣可以實現,並且
整個過程和Apache 非常的相似.
用戶認證:
location / {
root /11;
index index.html index.htm;
auth_basic "haha";
auth_basic_user_file /usr/local/nginx/passwd.db;
}
apache認證用戶賬號的創建工具:htpasswd [查 which htpasswd]
查htpasswd文件由哪個包提供:yum provides htpasswd
安裝htpasswd工具的軟件:yum install -y httpd-tools
[root@web html]# htpasswd -c /usr/local/nginx/passwd.db lucy 創建lucy用戶,密碼爲0
New password: 0
Re-type new password:0
Adding password for user user1
[root@web html]# cat /usr/local/nginx/passwd.db
htpasswd命令選項:
-c 創建新的htpasswd賬號文件,僅用於第1次
-m 以MD5方式加密用戶密碼
-D 刪除指定的用戶賬號
本地測試:
curl 192.168.11.11 匿名訪問網站(無法訪問),會報錯401狀態碼
13/34
curl 192.168.11.11 -u lucy:0 使用此用戶訪問網站(正常訪問)
curl 192.168.11.11 -u alice:01 使用此用戶訪問網站(無法訪問),因爲passwd.db賬號文件中沒有此
用戶
win7/10訪問測試:打開IE、360、UC、chrome等瀏覽器,在地址欄中輸入192.168.11.11回車,會提示
輸入用戶名、密碼的對話框,輸入正確的用戶名和密碼就可以訪問到網站的內容。
訪問控制(基於IP):
location / {
root /11;
index index.html index.htm;
allow 192.168.11.12; 允許此IP的客戶端訪問此網站
allow 192.168.11.11; 允許此IP的客戶端訪問此網站
#allow 192.168.11.0/24; 允許此網段的客戶端訪問此網站
deny all; 拒絕所有其他IP的客戶端訪問此網站
}
解釋說明:
order allow,deny
allow from 192.168.10.0/24
deny from all
deny/allow順序:從上到下

網站的訪問測試如下:
本地訪問測試:curl 192.168.11.11 會報錯403狀態碼
在node12上訪問測試:curl 192.168.11.11 正常顯示網頁內容
win7/10訪問測試:curl 192.168.11.11
狀態訪問
注意:此功能必須在編譯安裝時啓用--with-http_stub_status_module模塊。
狀態訪問統計:
在server中添加如下行
location ~ /status {
stub_status on;
access_log off;
}
查看訪問狀態統計:
瀏覽器:http://192.168.11.111/status 刷新可得到如下變化結果
Active connections: 557
server accepts handled requests 服務器接受處理過的請求
36573075 36573075 43806112
Reading: 3 Writing: 16 Waiting: 538
Active connections
活動連接數
server accepts handled requests
14/34
nginx總共處理了36573075個連接, 成功創建36573075次握手 (相等表示中間沒有失敗的), 總共處理了
43806112個請求 (平均每次握手處理了1.2個數據請求).
Reading
nginx讀取到客戶端的Header信息數.
Writing
nginx返回給客戶端的Header信息數.
Waiting
開啓keep-alive的情況下,這個值等於active - (reading + writing),意思就是Nginx說已經處理完正在等候
下一次請求指令的駐留連接.

查詢http協議的頭部信息:curl -i 192.168.11.111/status
HTTP/1.1 200 OK
Server: nginx/1.8.1
Date: Mon, 18 Mar 2019 01:45:08 GMT
Content-Type: text/plain
Content-Length: 100
Connection: keep-alive
Active connections: 1
server accepts handled requests
20 20 20
Reading: 0 Writing: 1 Waiting: 0

http狀態碼及501-504錯誤
訪問日誌管理
必須記住的狀態碼功能:200、400、401、403、404、500
訪問日誌中常見錯誤代碼(管理必備)
100 請求已接收,客戶端可以繼續發送請求
101 Switching Protocals服務器根據客戶端的請求切換協議
200 一切正常
201 服務器已經創建了文檔
202 已經接受了請求,但處理尚未完成
300 文檔正常返回,但一些頭部信息可能不正確
301 客戶端請求的資源可以在其他位置找到
305 請求代理服務
400 請求語法錯誤
401 訪問被拒絕
401.1 登錄失敗
403 資源不可用
403.6 IP地址被拒絕
403.9 用戶數過多
404 無法找到指定資源 頁面找不到
406 指定資源已找到,但MIME類型與客戶端要求不兼容
407 要求進行代理身份驗證
500 服務器內部錯誤
15/34
501 服務器不支持客戶端請求的功能
501.3 服務器太忙
502 網關錯誤
503 服務不可用
504 網關超時,服務器處於維護或負載過高無法響應
505 服務器不支持客戶端請求的HTTP版本
404 頁面找不到
403 訪問被拒絕
nginx的500,502,504錯誤解決方法
一、解決500錯誤:
1、500錯誤指的是服務器內部錯誤,也就是服務器遇到意外情況,而無法履行請求.
2、500錯誤一般有幾種情況:
(1)web腳本錯誤,如php語法錯誤,lua語法錯誤等.
(2)訪問量大的時候,由於系統資源限制,而不能打開過多的文件
3、一般分析思路:
(1)查看nginx error log ,查看php error log
(2)如果是too many open files,修改nginx的worker_rlimit_nofile參數,使用ulimit查看系統打開文件限制,
修改/etc/security/limits.conf
(3)如果是腳本的問題,則需要修復腳本錯誤,並優化代碼
(4)各種優化都做好,還是出現too many open files,那就要考慮做負載均衡,把流量分散到不同服務器上去

二、解決502,504錯誤
1、使用nginx代理,而後端服務器發生故障;或者php-cgi進程數不夠用;php執行時間長,或者是php-cgi進
程死掉;已經fastCGI使用情況等都會導致502、504.
2、502 是指請求的php-fpm已經執行,但是由於某種原因而沒有執行完畢,最終導致php-fpm進程終止.
一般來說,與php-fpm.conf的設置有關,也與php的執行程序性能有關,網站的訪問量大,而php-cgi的進程數偏
少.針對這種情況的502錯誤,只需增加php-cgi的進程數.
具體就是修改/usr/local/php/etc/php-fpm.conf文件,將其中的max_children值適當增加.
這個數據要依據你的VPS或獨立服務器的配置進行設置.一般一個php-cgi進程佔20M內存,你可以自己計算
下,適量增多.
/usr/local/php/sbin/php-fpm restart 然後重啓一下.
3、504 表示超時,也就是客戶端所發出的請求沒有到達網關,請求沒有得到可以執行的php-fpm
三、解決503錯誤
503 Service Temporarily Unavailable錯誤
單個ip併發設置過小會導致503報錯
反向代理、負載均衡
nginx的反向代理*****
用nginx做反向代理,有負載均衡:
負載均衡策略:
1.輪循:風水輪流轉
2.加權輪循:能者多勞,通過weight指定權重值。
16/34
3.ip hash:用hash算法
[root@nginx conf]# vim /usr/local/nginx/conf/nginx.conf
http {
include mime.types;
default_type application/octet-stream;
sendfile on;
#tcp_nopush on;
keepalive_timeout 65;
#gzip on;
upstream qf {
server 192.168.10.11:80;
server 192.168.10.12;
server 192.168.10.13;
}
server {
listen 80;
server_name www.nginx.com;
index index.html index.htm;
location / {
proxy_pass http://qf;
}
error_page 500 502 503 504 /50x.html;
location = /50x.html {
root html;
}
}

如果真實WEB服務的性能不同,爲了保證每個apache-server都能夠滿足最大的訪問.
可以加入權重,權重值越高,分到的請求越多.
[root@nginx conf]# vim /usr/local/lnmp/nginx/conf/nginx.conf

upstream uplook {
server 192.168.10.11 weight=1 max_fails=2 fail_timeout=30s;
server 192.168.10.12 weight=2;
server 192.168.10.13 backup; \backup:備份,其他服務器宕機後啓用 sorry
}
說明:max_fails是指定失敗的retry重試次數
fail_timeout是指單次連接的重試超時時間

爲了保證在短時間內,同一個客戶端的請求不被分配到其他的apache-server上?
[root@nginx conf]# vim nginx.conf

upstream back {
ip_hash;
server 172.16.0.10;
server 172.16.5.100;
server 172.16.16.100;
}
17/34
客戶端測試:
一直得到同一個頁面.

nginx+(apache|nginx) ,實現後端的真實WEB服務器獲取客戶端真實IP
代理服務器(node11): vim /usr/local/nginx/conf.d/proxy.conf
location / {
#root html;
#index index.html index.htm;
proxy_pass http://webs;
proxy_set_header Host $host;
proxy_set_header X-Real-ip $remote_addr;
proxy_set_header X-Forward-For $proxy_add_x_forwarded_for;
}

後端的真實WEB服務器:
apache(node12): vim /etc/httpd/conf/httpd.conf主配置文件中修改如下代碼(第196行)
LogFormat "%h %l %u %t \"%r\" %>s %b \"%{Referer}i\" \"%{X-Real-ip}i\" \"%{User-Agent}i
\"" combined
重啓服務:systemctl restart httpd
nginx:
安裝real-ip模塊
location / {
root html;
index index.html index.htm;
set_real_ip_from 10.10.10.11;
real_ip_header X-Real-ip;
}

反向代理練習
反向代理
在計算機網絡中,反向代理是代理服務器的一種。服務器根據客戶端的請求,從其關係的一組或多
組後端服務器(如Web服務器)上獲取資源,然後再將這些資源返回給客戶端,客戶端只會得知反向代理
的IP地址,而不知道在代理服務器後面的服務器簇的存在[1]。
與前向代理(即正向代理)不同,前向代理作爲客戶端的代理,將從互聯網上獲取的資源返回給一個或多個
的客戶端,服務端(如Web服務器)只知道代理的IP地址而不知道客戶端的IP地址;而反向代理是作爲服
務器端(如Web服務器)的代理使用,而不是客戶端。客戶端藉由前向代理可以間接訪問很多不同互聯網
服務器(簇)的資源,而反向代理是供很多客戶端都通過它間接訪問不同後端服務器上的資源,而不需要
知道這些後端服務器的存在,而以爲所有資源都來自於這個反向代理服務器。
反向代理在現時的互聯網中並不少見,而另一些例子,像是CDN、SNI代理等,是反向代理結合DNS的一類
延伸應用。
18/34
首先,給ens33臨時添加一個新IP地址192.168.11.111。
ifconfig ens33:111 192.168.11.111/24 up
ip a
19/34
然後,新建proxy.conf代理的配置文件。
vim /usr/local/nginx/conf.d/proxy.conf 配置文件全文內容如下
server {
listen 192.168.11.111:80;
server_name proxy.qf.com;
location / {
proxy_pass http://12700696.ys168.com/;
}
location /images/ {
root /data;
}
}
重啓服務,並測試:
nginx -t && nginx -s reload
curl 192.168.11.111
注意:server_name基於端口、ip時可以註釋,基於域名時不能省略

負載均衡:
負載:承受能力,載重能力。
均衡:平均分配
負載均衡器:將載重壓力平均分配給不同的後端服務器。負載均衡器類似於現實生活中酒店的接單
員,後端的真實服務器類似於酒店裏的廚房的廚師。
準備工作:後端web服務器準備(node12上做)。
yum install -y httpd
systemctl restart httpd
systemctl enable httpd
cd /var/www/html
ls
mkdir -v www mail
echo haha > /var/www/html/index.html
echo w.qf.com > www/index.html
echo mail.qf.com > mail/index.html
curl 127.0.0.1/www/
curl 127.0.0.1/mail/
用基於端口的方式發佈www(port-8081)、mail(port-8082)目錄的網站
rpm -ql httpd | grep vhost
vim /etc/httpd/conf.d/port.conf
Listen 8081
Listen 8082
<VirtualHost :8081>
ServerAdmin [email protected]
DocumentRoot "/var/www/html/www"
ServerName w.qf.com
</VirtualHost>
<VirtualHost
:8082>
ServerAdmin [email protected]
DocumentRoot "/var/www/html/mail"
ServerName mail.qf.com
</VirtualHost>
20/34
然後,重啓httpd服務,做訪問測試:
systemctl restart httpd
netstat -atunlp | grep :80
curl 127.0.0.1
curl 127.0.0.1:8081
curl 127.0.0.1:8082
後端真實服務器的準備工作完畢,請在node11主機上繼續做nginx負載均衡。

負載均衡的配置代碼:vim /usr/local/nginx/conf.d/proxy.conf
upstream back { 定義一個名稱爲back的後端服務器羣,名稱中不允許用_下劃線,否則會報400錯誤
server 192.168.11.12:80;
server 192.168.11.12:8081;
server 192.168.11.12:8082;
}
server {
listen 192.168.11.111:80;
server_name proxy.qf.com;
location / {
proxy_pass http://back/;

}
location /images/ {
root /data;
}
}
重啓服務,並測試:
nginx -t && nginx -s reload
打開IE瀏覽器:輸入 192.168.11.111回車
緩存
1.定義一個簡單nginx緩存服務器
[root@nginx ~]# vim /etc/nginx/nginx.conf
upstream test{
server 192.168.10.21;
}
proxy_cache_path /usr/local/nginx/cache levels=1:2 keys_zone=test:20m max_size=1g;
server {
listen 80;
server_name localhost;
#charset koi8-r;
#access_log logs/host.access.log main;
location / {
proxy_pass http://test;
proxy_set_header X-forwarded-for $proxy_add_x_forwarded_for;
21/34
proxy_set_header X-real-ip $remote_addr;
proxy_cache test;
proxy_cache_valid 200 10m;
}
}
A客戶---B代理商----C生產商
2.指令說明
proxy_cache_path
語法:proxy_cache_path path [levels=number] keys_zone=zone_name:zone_size [inactive=time]
[max_size=size];
默認值:None
使用字段:http
指令指定緩存的路徑和一些其他參數,緩存的數據存儲在文件中,並且使用代理url的哈希值作爲關鍵字與
文件名。levels參數指定緩存的子目錄數,例如:
proxy_cache_path /data/nginx/cache levels=1:2 keys_zone=one:10m;
文件名類似於:/data/nginx/cache/c/29/b7f54b2df7773722d382f4809d65029c
levels指定目錄結構,可以使用任意的1位或2位數字作爲目錄結構,如 X, X:X,或X:X:X 例如: “2”, “2:2”,
“1:1:2“,但是最多隻能是三級目錄。
所有活動的key和元數據存儲在共享的內存池中,這個區域用keys_zone參數指定。one指的是共享池的名
稱,10m指的是共享池的大小。
注意每一個定義的內存池必須是不重複的路徑,例如:
proxy_cache_path /data/nginx/cache/one levels=1 keys_zone=one:10m;
proxy_cache_path /data/nginx/cache/two levels=2:2 keys_zone=two:100m;
proxy_cache_path /data/nginx/cache/three levels=1:1:2 keys_zone=three:1000m;
如果在inactive參數指定的時間內緩存的數據沒有被請求則被刪除,默認inactive爲10分鐘。一個名爲
cache manager的進程控制磁盤的緩存大小,它被用來刪除不活動的緩存和控制緩存大小,這些都在
max_size參數中定義,當目前緩存的值超出max_size指定的值之後,超過其大小後最少使用數據(LRU替
換算法)將被刪除。內存池的大小按照緩存頁面數的比例進行設置,一個頁面(文件)的元數據大小按照
操作系統來定,如FreeBSD/i386下爲64字節,FreeBSD/amd64下爲128字節。
proxy_cache
語法:proxy_cache zone_name;
默認值:None
使用字段:http, server, location
設置一個緩存區域的名稱,一個相同的區域可以在不同的地方使用。
在0.7.48後,緩存遵循後端的”Expires”, “Cache-Control: no-cache”, “Cache-Control: max-age=XXX”頭部
字段,0.7.66版本以後,”Cache-Control:“private”和”no-store”頭同樣被遵循。nginx在緩存過程中不會處
理”Vary”頭,爲了確保一些私有數據不被所有的用戶看到,後端必須設置 “no-cache”或者”maxage=0”頭,或者proxy_cache_key包含用戶指定的數據如$cookie_xxx,使用cookie的值作爲
proxy_cache_key的一部分可以防止緩存私有數據,所以可以在不同的location中分別指定
proxy_cache_key的值以便分開私有數據和公有數據。
緩存指令依賴代理緩衝區(buffers),如果proxy_buffers設置爲off,緩存不會生效。
proxy_cache_valid
語法:proxy_cache_valid reply_code [reply_code …] time;
默認值:None
使用字段:http, server, location
爲不同的應答設置不同的緩存時間,例如:
proxy_cache_valid 200 302 10m;
22/34
proxy_cache_valid 404 1m;
爲應答代碼爲200和302的設置緩存時間爲10分鐘,404代碼緩存1分鐘。
如果只定義時間:
proxy_cache_valid 5m;
那麼只對代碼爲200, 301和302的應答進行緩存。
同樣可以使用any參數任何應答。
proxy_cache_valid 200 302 10m;
proxy_cache_valid 301 1h;
proxy_cache_valid any 1m;
3.新建緩存目錄
4.重新加載一下配置文件
5.測試
location
nginx location在配置中的優先級
語法規則: location [=|~|~|^~] /uri/ { … }
location表達式類型(必知)
~ 表示執行一個正則匹配,區分大小寫
~
表示執行一個正則匹配,不區分大小寫
^~ 表示普通字符匹配。使用前綴匹配。如果匹配成功,則不再匹配其他location。
= 進行普通字符精確匹配。也就是完全匹配。
@ “@” 定義一個命名的 location,使用在內部定向時,例如 error_page, try_files
location優先級說明
在nginx的location和配置中location的順序沒有太大關係。正location表達式的類型有關。相同類型的表達
式,字符串長的會優先匹配。
以下是按優先級排列說明:
第一優先級:等號類型(=)的優先級最高。一旦匹配成功,則不再查找其他匹配項。
第二優先級:^~類型表達式。一旦匹配成功,則不再查找其他匹配項。
第三優先級:正則表達式類型(~ ~)的優先級次之。如果有多個location的正則能匹配的話,則使用正
則表達式最長的那個。
第四優先級:常規字符串匹配類型。按前綴匹配。
location優先級順序示意圖: = > ^~ > ~ ~
> /
location優先級示例
配置項如下:
location = / {

只匹配請求 /

[ configuration ]
index index.html
}
location / {

匹配所有以 / 開頭的請求。但是更長字符匹配或者正則表達式匹配會優先匹配

[ configuration B ]
index b.html
23/34
}
location /docs/ {

匹配所有以 /docs/ 開頭的請求。但是如果有更長的同類型的表達式,則選擇更長的表達式。

#如果有正則表達式可以匹配,則優先匹配正則表達式。
[ configuration C ]
alias /web/dir1/dir2;
index c.html;
}
location ^~ /images/ {

匹配所有以 /images/ 開頭的表達式,如果匹配成功,則停止匹配查找。所以,即便有符合的正則表達

式location,也不會被使用
[ configuration D ]
alias /web/images/;
index img.html;
}
location ~* .(gif|jpg|jpeg)$ {

匹配所有以 gif jpg jpeg結尾的請求。但是 以 /images/開頭的請求,將使用 Configuration D

[ configuration E ]
root /web/images/;
}
請求匹配示例
/ -> configuration A
/index.html -> configuration B
/documents/document.html -> configuration C
/images/1.gif -> configuration D
/documents/1.jpg -> configuration E
注意,以上的匹配和在配置文件中定義的順序無關。
----
練習準備:
mkdir -v /usr/local/nginx/html/xx
echo 'xx.com' > /usr/local/nginx/html/xx/index.html
curl 192.168.11.11/xx/
練習:
首先,備份/usr/local/nginx/conf.d的.conf配置文件,然後配置location代碼。
cd /usr/local/nginx/conf.d
ls
mkdir bak
mv
.conf bak/
cd /usr/local/nginx/conf
vim nginx.conf 修改如下內容
44 location /xx/ {
然後,重啓nginx服務,並做訪問測試。
nginx -t & nginx -s reload
curl 192.168.11.11/xx/
24/34
location總結
Nginx Location配置總結
語法規則: location [=|~|~|^~] /uri/ { … }
= 開頭表示精確匹配
^~ 開頭表示uri以某個常規字符串開頭,理解爲匹配 url路徑即可。nginx不對url做編碼,因此請求爲/
static/20%/aa,可以被規則^~ /static/ /aa匹配到(注意是空格)。
~ 開頭表示區分大小寫的正則匹配
~
開頭表示不區分大小寫的正則匹配
!~和!~分別爲區分大小寫不匹配及不區分大小寫不匹配 的正則
/ 通用匹配,任何請求都會匹配到。
多個location配置的情況下匹配順序(優先級)爲:
首先匹配 =,其次匹配^~, 其次是按文件中順序的正則匹配,最後是交給 / 通用匹配。當有匹配
成功時候,停止匹配,按當前匹配規則處理請求。
例子,有如下匹配規則:
location = / {
#規則A
}
location = /login {
#規則B
}
location ^~ /static/ {
#規則C
}
location ~ .(gif|jpg|png|js|css)$ {
#規則D
}
location ~
.png$ {
#規則E
}
location !~ .xhtml$ {
#規則F
}
location !~* .xhtml$ {
#規則G
}
location / {
#規則H
}
那麼產生的效果如下:
訪問根目錄/, 比如http://localhost/ 將匹配規則A
訪問 http://localhost/login 將匹配規則B,http://localhost/register 則匹配規則H
訪問 http://localhost/static/a.html 將匹配規則C
訪問 http://localhost/a.gif, http://localhost/b.jpg 將匹配規則D和規則E,但是規則D順序優先,規則E不
起作用,而 http://localhost/static/c.png 則優先匹配到規則C
訪問 http://localhost/a.PNG 則匹配規則E,而不會匹配規則D,因爲規則E不區分大小寫。
訪問 http://localhost/a.xhtml 不會匹配規則F和規則G,http://localhost/a.XHTML不會匹配規則G,因爲
25/34
不區分大小寫。規則F,規則G屬於排除法,符合匹配規則但是不會匹配到,所以想想看實際應用中哪裏會
用到。
訪問 http://localhost/category/id/1111 則最終匹配到規則H,因爲以上規則都不匹配,這個時候應該是
nginx轉發請求給後端應用服務器,比如FastCGI(php),tomcat(jsp),nginx作爲方向代理服務器存
在。
所以實際使用中,個人覺得至少有三個匹配規則定義,如下:
#直接匹配網站根,通過域名訪問網站首頁比較頻繁,使用這個會加速處理,官網如是說。
#這裏是直接轉發給後端應用服務器了,也可以是一個靜態首頁

第一個必選規則

location = / {
proxy_pass http://tomcat:8080/index
}

第二個必選規則是處理靜態文件請求,這是nginx作爲http服務器的強項

有兩種配置模式,目錄匹配或後綴匹配,任選其一或搭配使用

location ^~ /static/ {
root /webroot/static/;
}
location ~ .(gif|jpg|jpeg|png|css|js|ico)$ {
root /webroot/res/;
}
#第三個規則就是通用規則,用來轉發動態請求到後端應用服務器
#非靜態文件請求就默認是動態請求,自己根據實際把握
#畢竟目前的一些框架的流行,帶.php,.jsp後綴的情況很少了
location / {
proxy_pass http://tomcat:8080/
}
三、ReWrite語法
last – 基本上都用這個Flag。
break – 中止Rewirte,不在繼續匹配
redirect – 返回臨時重定向的HTTP狀態302
permanent – 返回永久重定向的HTTP狀態301
1、下面是可以用來判斷的表達式:
-f和!-f用來判斷是否存在文件
-d和!-d用來判斷是否存在目錄
-e和!-e用來判斷是否存在文件或目錄
-x和!-x用來判斷文件是否可執行
2、下面是可以用作判斷的全局變量
例:http://localhost:88/test1/test2/test.php
$host:localhost
$server_port:88
$request_uri:http://localhost:88/test1/test2/test.php
$document_uri:/test1/test2/test.php
$document_root:D:\nginx/html
$request_filename:D:\nginx/html/test1/test2/test.php
26/34
四、Redirect語法
server {
listen 80;
server_name start.igrow.cn;
index index.html index.php;
root html;
if ($http_host !~ “^star.igrow.cn$&quot {
rewrite ^(.
) http://star.igrow.cn$1 redirect;
}
}
五、防盜鏈
location ~ .(gif|jpg|swf)$ {
valid_referers none blocked start.igrow.cn sta.igrow.cn;
if ($invalid_referer) {
rewrite ^/ http://$host/logo.png;
}
}
六、根據文件類型設置過期時間
location ~
.(js|css|jpg|jpeg|gif|png|swf)$ {
if (-f $request_filename) {
expires 1h;
break;
}
}
七、禁止訪問某個目錄
location ~* .(txt|doc)${
root /data/www/wwwroot/linuxtone/test;
deny all;
}
一些可用的全局變量:
$args
$content_length
$content_type
$document_root
$document_uri
$host
$http_user_agent
$http_cookie
$limit_rate
$request_body_file
$request_method
$remote_addr
$remote_port
$remote_user
$request_filename
$request_uri
$query_string
$scheme
$server_protocol
$server_addr
$server_name
$server_port
$uri
27/34
location案例OK
nginx location指令詳解
Nginx的HTTP配置主要包括三個區塊,結構如下:
http { //這個是協議級別   
include mime.types;   
default_type application/octet-stream;   
keepalive_timeout 65;   
gzip on;     

server { //這個是服務器級別       
listen 80;       
server_name localhost;         
location / { //這個是請求級別           
root html;           
index index.html index.htm;         
}       
}
}
root 、alias指令區別
location /img/ { alias /var/www/image/; }
#若按照上述配置的話,則訪問/img/目錄裏面的文件時,ningx會自動去/var/www/image/目錄找文件
location /img/ { root /var/www/image; }
#若按照這種配置的話,則訪問www.baiud.com/img/目錄下的文件時,nginx會去/var/www/image/img/
目錄下找文件。]
總結:alias是一個目錄別名的定義,root則是最上層目錄的定義。

警告:還有一個重要的區別是alias後面必須要用“/”結束,否則會找不到文件的。。。而root則可有可無~~
location區段
通過指定模式來與客戶端請求的URI相匹配,基本語法如下:
location [=|~|~|^~|@] pattern{……}
1、沒有修飾符 表示:必須以指定模式開始,如:
server {   
server_name baidu.com;   
location /abc {
   root /web/qf;
index index.html index.htm index.php;
……
  }
}
那麼,如下是對的(即能模糊匹配到的訪問):
28/34
http://baidu.com/abc
http://baidu.com/abc?p1
http://baidu.com/abc/
http://baidu.com/abcde
2、=表示:必須與指定的模式精確匹配
server {
server_name sish   
location = /abc {     ……   } }
那麼,如下是對的:
http://baidu.com/abc
http://baidu.com/abc?p1
警告:?p1中的?號是從數據庫中請求信息,p1是數據庫表中的字段名。
如下是錯的:
http://baidu.com/abc/
http://baidu.com/abcde
3、~ 表示:指定的正則表達式要區分大小寫
server { server_name baidu.com;   
location ~ ^/abc$ {     ……   } } 匹配以/開頭,中間是ab,以c結尾且區分大小寫的請求
那麼,如下是對的:
http://baidu.com/abc
http://baidu.com/abc?p1=11&p2=22
如下是錯的:
http://baidu.com/ABC
http://baidu.com/abc/
http://baidu.com/abcde
4、~
表示:指定的正則表達式不區分大小寫
server { server_name baidu.com;
location ~* ^/abc$ {     ……   } } 匹配以/開頭,中間是ab,以c結尾且不區分大小寫的請求

那麼,如下是對的:
http://baidu.com/abc
http://baidu..com/ABC
http://baidu..com/abc?p1=11&p2=22
如下是錯的:
http://baidu..com/abc/
http://baidu..com/abcde
5、^~ 類似於無修飾符的行爲,也是以指定模式開始,不同的是,如果模式匹配,那麼就停止搜索其他
模式了。(必記)
6、@ :定義命名location區段,這些區段客戶端不能訪問,只可以由內部產生的請求來訪問,如try_files
或error_page等
查找順序和優先級
1:帶有“=“的精確匹配優先
2:沒有修飾符的精確匹配
3:正則表達式按照他們在配置文件中定義的順序
29/34
4:帶有“^~”修飾符的,開頭匹配
5:帶有“~” 或“~” 修飾符的,如果正則表達式與URI匹配
6:沒有修飾符的,如果指定字符串與URI開頭匹配
location優先級順序示意圖: = > ^~ > ~ ~
> /
URL:是統一資源定位符(Uniform Resource Locators),對可以從互聯網上得到的資源的位置和訪問方
法的一種簡潔的表示,是互聯網上標準資源的地址。互聯網上的每個文件都有一個唯一的URL,它包含的
信息指出文件的位置以及瀏覽器應該怎麼處理它。
例如:http://www.baidu.com/music/index.html就是一個URL地址
URI:統一資源標識符(Uniform Resource Identifier,或URI)是一個用於標識某一互聯網資源名稱的字符
串。
-----------
Location區段匹配示例
location = / { [ configuration A ] }  

只匹配 / 的查詢.   

location / { [ configuration B ] }

匹配任何以 / 開始的查詢,但是正則表達式與一些較長的字符串將被首先匹配。   

location ^~ /images/ { [ configuration C ] }  

匹配任何以 /images/ 開始的查詢並且停止搜索,不檢查正則表達式。   

location ~* .(gif|jpg|jpeg)$ { [ configuration D ] }  

匹配任何以gif, jpg, or jpeg結尾的文件,但是所有 /images/ 目錄的請求將在Configuration C中處理。

  
各 請求的處理如下例:
■/ → configuration A ■/documents/document.html → configuration B ■/images/1.gif → configuration C
■/documents/1.jpg → configuration D

動靜分離
動:動態腳本請求;靜:靜態頁面請求;分離:動態的請求和靜態的請求在一臺服務器分離出來,由nginx-webserver 處理靜態頁面請求,由 PHP 處理動態請求.
使用fastcgi:
CGI:通用網關接口,web-server和動態的腳本語言之間進行通信的接口.
fastCGI:高速的運行在web-server上的和動態的腳本語言之間進行通信的接口.
運行原理:
fastcgi在linux下是socket,爲了調用CGI程序,還需要一個應用程序-wrapper,這個wrapper綁定在
socket上.
30/34
(1)nginx將動態的HTTP請求交給 socket,通過 fastcgi接口,由wrapper接受請求,然後派生出一個線
程,調用請求數據;
(2)wrapper將得到的數據通過 fastcgi接口通過 socket交給 nginx;
(3)nginx把數據交給客戶端.
請求過程:client客戶端--->nginx代理服務器--->socket--->fastcgi--->數據服務器
(LAMP或Tomcat)
響應過程:client客戶端<---nginx代理服務器<---socket<---fastcgi<---數據服務器
(LAMP或Tomcat)
alias與root用法
Nginx的alias與root的用法區別
alias與root的用法區別:
最基本的區別:alias指定的目錄是準確的,root是指定目錄的上級目錄,並且該上級目錄要含有
location指定名稱的同名目錄。
location /abc/ {
alias /home/html/abc/;
}
這個配置實際上指向的是/home/html/abc/目錄。
location /abc/ {
root /home/html/abc/;
}
這個指向的是/home/html/abc/abc/這個目錄
URL-URI
URL和URI
簡單理解是這樣的:
理解URI和URL的區別,我們引入URN這個概念。
URI = Universal Resource Identifier 統一資源標誌符
URL = Universal Resource Locator 統一資源定位符
URN = Universal Resource Name 統一資源名稱
這三者的關係如下圖:
31/34
也就是說,URI分爲三種,URL or URN or (URL and URI)
URL代表資源的路徑地址,而URI代表資源的名稱。
通過URL找到資源是對網絡位置進行標識,如:
· http://example.org/absolute/URI/with/absolute/path/to/resource.txt
· ftp://example.org/resource.txt
通過URI找到資源是通過對名稱進行標識,這個名稱在某命名空間中,並不代表網絡地址,如:
· urn:issn:1535-3613
例如:
http://www.baidu.com/music/a/b/c/d/a.html
location /URI_music/ {
root /web/qf;
}
譯者:華科小濤:http://www.cnblogs.com/hust-ghtao/
初學http協議,就被這兩個相似的術語搞蒙了,查了很多資料,總算搞清楚了。(找資料還是英文啊,靠
譜。。。)。
本篇博客翻譯自:https://danielmiessler.com/study/url_vs_uri/,是在是一片簡單實用的好文,對幫我們
弄清概念很有幫助:
譯文:

一直存在很多技術上的爭論,其中最爲妙的恐怕就是web地址應該叫什麼的問題。通常情況就是這樣:
有人把地址欄的內容叫“URL”,這時候有些人就來勁了:“不!其實那時URI。。。”
對於這種糾正的反應呢,通常也有這麼幾種情況,心眼小的就尋思這人趕緊走吧,淡定點的就聳聳肩表
示同意,火氣大的就拔刀相向了好不?
那這篇文章呢,就對這個只是提供一個簡單的總結,畢竟互黑也要黑到點子上是吧。
URI,URL,URN
從上面的那幅圖可以看出來,一共有三個不同的概念URI,URL,URN。這討論這樣的問題時,最好的方法就
32/34
是回到原點啊,這裏我們在RFC 3986: Uniform Resource Identifier (URI): Generic Syntax裏面收集了點
資料:
“A Uniform Resource Identifier (URI) 是一個緊湊的字符串用來標示抽象或物理資源。”
“A URI 可以進一步被分爲定位符、名字或兩者都是. 術語“Uniform Resource Locator” (URL) 是URI的子
集, 除了確定一個資源,還提供一種定位該資源的主要訪問機制(如其網絡“位置”)。“
那我們無所不知的維基百科把這段消化的很好,並描述的更加形象了:
“URI可以分爲URL,URN或同時具備locators 和names特性的一個東西。URN作用就好像一個人的名字,URL
就像一個人的地址。換句話說:URN確定了東西的身份,URL提供了找到它的方式。”
通過這些描述我們可以得到一些結論:
· 首先,URL是URI的一種(通過那個圖就看的出來吧)。所以有人跟你說URL不是URI,他就錯了
唄。但也不是所有的URI都是URL哦,就好像蝴蝶都會飛,但會飛的可不都是蝴蝶啊,你讓蒼蠅怎麼想!
· 讓URI能成爲URL的當然就是那個“訪問機制”,“網絡位置”。e.g. http:// or ftp://.。
· URN是唯一標識的一部分,就是一個特殊的名字。
  下面就來看看例子吧,當來也是來自權威的RFC:
· ftp://ftp.is.co.za/rfc/rfc1808.txt (also a URL because of the protocol)
· http://www.ietf.org/rfc/rfc2396.txt (also a URL because of the protocol)
· ldap://[2001:db8::7]/c=GB?objectClass?one (also a URL because of the protocol)
· mailto:[email protected] (also a URL because of the protocol)
· news:comp.infosystems.www.servers.unix (also a URL because of the protocol)
· tel:+1-816-555-1212
· telnet://192.0.2.16:80/ (also a URL because of the protocol)
· urn:oasis:names:specification:docbook:dtd:xml:4.1.2
  這些全都是URI, 其中有些事URL. 哪些? 就是那些提供了訪問機制的.
總結
下面到了回答問題的時候了:
當我們替代web地址的時候,URI和URL那個更準確?
基於我讀的很多的文章,包括RFC,我想說URI更準確。
別急,我有我的理由:
我們經常使用的URI不是嚴格技術意義上的URL。例如:你需要的文件在files.hp.com. 這是URI,但不是
URL--系統可能會對很多協議和端口都做出正
確的反應。
你去http://files.hp.com 和ftp://files.hp.com.可能得到完全不同的內容。這種情況可能更加普遍,想想不
同谷歌域名上的不同服務啊。
所以,用URI吧,這樣你通常技術上是正確的,URL可不一定。最後“URL”這個術語正在被棄用。所以明智
吧少年!
結語
If you don’t mind being “that guy”, URI is probably the more accurate term to use. But if you are in
the linguist / “use what’s understood” camp, feel free to go with URL.
標籤: Network
平滑升級
平滑升級1.8.1到1.10.2:(必會)
可以在不中斷服務的情況下,新的請求也不會丟失,使用新的 nginx 可執行程序替換舊的(當升級新
版本或添加/刪除服務器模塊時).
33/34
準備工作:下載nginx-1.10.3.tar.gz源碼包
cd
wget http://120.52.51.15/nginx.org/download/nginx-1.10.3.tar.gz
tar xf nginx-1.10.3.tar.gz
cd nginx-1.10.3
ls
1.查看老版本的編譯選項:
[root@clone1 ~]# /usr/local/nginx/sbin/nginx -V
nginx version: nginx/1.8.1
built by gcc 4.4.7 20120313 (Red Hat 4.4.7-4) (GCC)
built with OpenSSL 1.0.1e-fips 11 Feb 2013
TLS SNI support enabled
configure arguments: --user=nginx --group=nginx --prefix=/usr/local/nginx --withhttp_stub_status_module --with-http_ssl_module
2.編譯新版:
[root@clone1 nginx]# cd nginx-1.10.2
[root@clone1 nginx-1.10.2]# ./configure --user=nginx --group=nginx --prefix=/usr/local/nginx --
with-http_stub_status_module --with-http_ssl_module
[root@clone1 nginx-1.10.2]# make 編譯
3.用新編譯的命令替換原來的命令
[root@clone1 nginx-1.10.2]# mv /usr/local/nginx/sbin/nginx /usr/local/nginx/sbin/nginx.bak 備份
舊版本
[root@clone1 nginx-1.10.2]# cp -av objs/nginx /usr/local/nginx/sbin/ 複製新版本的nginx可
執行程序
4.啓用新的,關閉舊的(平滑將舊版本的進程轉移到新版本上)
[root@clone1 ~]# cat /usr/local/nginx/logs/nginx.pid
[root@clone1 ~]# kill -USR2 $(cat /usr/local/nginx/logs/nginx.pid)
主進程將重命名它的 .pid 文件爲 .oldbin,然後執行新的可執行程序,依次啓動新的主進程和新的工作進
程.
[root@clone1 ~]# cat /usr/local/nginx/logs/nginx.pid.oldbin
[root@clone1 ~]# kill -WINCH $(cat /usr/local/nginx/logs/nginx.pid.oldbin)
給舊的主進發WINCH信號,把舊的主進程關閉,把所有請求轉到新的主進程,但是原有的請求不會中斷,有
新請求的時候發到新進程
注意:如果無法出現nginx.pid.oldbin文件,就無法做nginx進程的平滑遷移,那就只能做非平滑啓動新版
本,即直接執行nginx -s quit退出服務,然後執行nginx來啓動新版本的服務程序。

這時,因爲舊的服務器還尚未關閉它監聽的套接字,所以,通過下面的幾步,你仍可以恢復舊的服務器: (kill -l)
1.發送 HUP (kill -1 nginx的pid等同於nginx -s reload)信號給舊的主進程 - 它將在不重載配置文件的
情況下啓動它的工作進程
2.發送 QUIT (退出)信號給新的主進程,要求其從容關閉其工作進程
3.發送 TERM (終止)信號給新的主進程,迫使其退出
4.如果因爲某些原因新的工作進程不能退出,向其發送 KILL 信號
新的主進程退出後,舊的主進程會由移除 .oldbin 前綴,恢復爲它的 .pid 文件,這樣,一切就都恢復到升級之前
了.


[root@clone1 ~]# kill -QUIT cat /usr/local/nginx/logs/nginx.pid.oldbin
34/34
如果嘗試升級成功,而你也希望保留新的服務器時,發送 QUIT 信號給舊的主進程使其退出而只留下新的
服務器運行.
特殊情況的重新平滑升級測試流程:
如果做nginx平滑升級時,在“啓用新的,關閉舊的 ”步驟kill無法生成nginx.pid.oldbin文件時,請將虛擬機
快照恢復到env-ok狀態,然後重新編譯安裝nginx1.8.1版,再做nginx的平滑升級操作。因爲這個問題是系
統某些程序衝突而導致無法生成nginx.pid.oldbin文件。

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章