nginx 學習

剛開始接觸nginx,本文用於備忘及方便本身查找,主要內容是轉載其餘文章內容,但並非徹底轉載,若是有什麼錯漏請查看參考連接。

參考:javascript

  nginx中文文檔php

  nginx中文手冊css

  nginx參數配置及基本說明html

 

編譯以前,可能須要安裝java

sudo apt-get update
sudo apt-get install libpcre3-dev 
sudo apt-get install libssl-dev

 

 

啓動nginx(根據本身tengine(淘寶開源nginx)安裝路徑,)node

$ sudo ~/OpenSource/tengine2.2.2/objs/nginx
#或者
$ sudo /usr/local/nginx/sbin/ngin

 

一、檢查nginx進程pid,並從容關閉linux

$ ps -ef | grep nginx
root     25889  2179  0 16:32 ?        00:00:00 nginx: master process ./nginx
nobody   25890 25889  0 16:32 ?        00:00:00 nginx: worker process
dyan     26025  5496  0 16:36 pts/2    00:00:00 grep --color=auto nginx
$ sudo kill -QUIT  25889

  或者TERM、INT快速關閉nginx

  或者正則表達式

$ sudo kill -9 25889

 

二、使用信號操做nginx服務器

  TERM, INT    : 快速關閉
  QUIT        : 從容關閉
  HUP         : 重載配置;用新的配置開始新的工做進程;從容關閉舊的工做進程
  USR1       : 從新打開日誌文件
  USR2       : 平滑升級可執行程序。
  WINCH       : 從容關閉工做進程

  15       : 關閉nginx

$ sudo kill -15  25889

  平滑改變配置文件,最好先測試配置文件格式是否正確

    -c </path/to/config> 爲 Nginx 指定一個配置文件,來代替缺省的。

    -t 不運行,而僅僅測試配置文件。nginx 將檢查配置文件的語法的正確性,並嘗試打開配置文件中所引用到的文件。

$ sudo ./nginx -t -c /usr/local/nginx/conf/nginx.conf
$ sudo kill -HUP 25889

  當 nginx 接收到 HUP 信號,它會嘗試先解析配置文件(若是指定配置文件,就使用指定的,不然使用默認的),成功的話,就應用新的配置文件(例如:從新打開日誌文件或監聽的套接 字)。以後,nginx 運行新的工做進程並從容關閉舊的工做進程。通知工做進程關閉監聽套接字可是繼續爲當前鏈接的客戶提供服務。全部客戶端的服務完成後,舊的工做進程被關閉。 若是新的配置文件應用失敗,nginx 將繼續使用舊的配置進行工做。

  nginx在0.8版本以後,引入了一系列命令行參數,來方便咱們管理。好比,./nginx -s reload,就是來重啓nginx,./nginx -s stop,就是來中止nginx的運行。如何作到的呢?咱們仍是拿reload來講,咱們看到,執行命令時,咱們是啓動一個新的nginx進程,而新的nginx進程在解析到reload參數後,就知道咱們的目的是控制nginx來從新加載配置文件了,它會向master進程發送信號,而後接下來的動做,就和咱們直接向master進程發送信號同樣了。  

3.nginx基本配置及參數說明

  這個配置文件的默認位置在安裝路徑(/usr/local/nginx不是./nginx所在目錄附近)下,好比:/usr/local/nginx/conf/nginx.conf(在./nginx所在路徑的相對路徑也有../conf/nginx.conf,可是不是使用的這個文件,修改也沒有用,或許從新編譯安裝會把這個文件拷貝過去)。也可使用前面提到的平滑改變配置文件來指定配置文件路徑。

#運行用戶
user nobody;
#啓動進程,一般設置成和cpu的數量相等
worker_processes  1;

#全局錯誤日誌及PID文件
#error_log  logs/error.log;
#error_log  logs/error.log  notice;
#error_log  logs/error.log  info;

#pid        logs/nginx.pid;

#工做模式及鏈接數上限
events {
    #epoll是多路複用IO(I/O Multiplexing)中的一種方式,
    #僅用於linux2.6以上內核,能夠大大提升nginx的性能
    use   epoll; 

    #單個後臺worker process進程的最大併發連接數    
    worker_connections  1024;

    # 併發總數是 worker_processes 和 worker_connections 的乘積
    # 即 max_clients = worker_processes * worker_connections
    # 在設置了反向代理的狀況下,max_clients = worker_processes * worker_connections / 4  爲何
    # 爲何上面反向代理要除以4,應該說是一個經驗值
    # 根據以上條件,正常狀況下的Nginx Server能夠應付的最大鏈接數爲:4 * 8000 = 32000
    # worker_connections 值的設置跟物理內存大小有關
    # 由於併發受IO約束,max_clients的值須小於系統能夠打開的最大文件數
    # 而系統能夠打開的最大文件數和內存大小成正比,通常1GB內存的機器上能夠打開的文件數大約是10萬左右
    # 咱們來看看360M內存的VPS能夠打開的文件句柄數是多少:
    # $ cat /proc/sys/fs/file-max
    # 輸出 34336
    # 32000 < 34336,即併發鏈接總數小於系統能夠打開的文件句柄總數,這樣就在操做系統能夠承受的範圍以內
    # 因此,worker_connections 的值需根據 worker_processes 進程數目和系統能夠打開的最大文件總數進行適當地進行設置
    # 使得併發總數小於操做系統能夠打開的最大文件數目
    # 其實質也就是根據主機的物理CPU和內存進行配置
    # 固然,理論上的併發總數可能會和實際有所誤差,由於主機還有其餘的工做進程須要消耗系統資源。
    # ulimit -SHn 65535

}


http {
    #設定mime類型,類型由mime.type文件定義
    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 指令指定 nginx 是否調用 sendfile 函數(zero copy 方式)來輸出文件,
    #對於普通應用,必須設爲 on,
    #若是用來進行下載等應用磁盤IO重負載應用,可設置爲 off,
    #以平衡磁盤與網絡I/O處理速度,下降系統的uptime.
    sendfile     on;
    #tcp_nopush     on;

    #鏈接超時時間
    #keepalive_timeout  0;
    keepalive_timeout  65;
    tcp_nodelay     on;

    #開啓gzip壓縮
    gzip  on;
    gzip_disable "MSIE [1-6].";

    #設定請求緩衝
    client_header_buffer_size    128k;
    large_client_header_buffers  4 128k;


    #設定虛擬主機配置
    server {
        #偵聽80端口
        listen    80;
        #定義使用 www.nginx.cn訪問
        server_name  www.nginx.cn;

        #定義服務器的默認網站根目錄位置
        root html;

        #設定本虛擬主機的訪問日誌
        access_log  logs/nginx.access.log  main;

        #默認請求
        location / {
            
            #定義首頁索引文件的名稱
            index index.php index.html index.htm;   

        }

        # 定義錯誤提示頁面
        error_page   500 502 503 504 /50x.html;
        location = /50x.html {
        }

        #靜態文件,nginx本身處理
        location ~ ^/(images|javascript|js|css|flash|media|static)/ {
            
            #過時30天,靜態文件不怎麼更新,過時能夠設大一點,
            #若是頻繁更新,則能夠設置得小一點。
            expires 30d;
        }

        #PHP 腳本請求所有轉發到 FastCGI處理. 使用FastCGI默認配置.
        location ~ .php$ {
            fastcgi_pass 127.0.0.1:9000;
            fastcgi_index index.php;
            fastcgi_param  SCRIPT_FILENAME  $document_root$fastcgi_script_name;
            include fastcgi_params;
        }

        #禁止訪問 .htxxx 文件
            location ~ /.ht {
            deny all;
        }

    }
}

4.location配置。

location匹配命令

~      #波浪線表示執行一個正則匹配,區分大小寫
~*    #表示執行一個正則匹配,不區分大小寫
^~    #^~表示普通字符匹配,若是該選項匹配,只匹配該選項,不匹配別的選項,通常用來匹配目錄
=      #進行普通字符精確匹配
@     #"@" 定義一個命名的 location,使用在內部定向時,例如 error_page, try_files

location 匹配的優先級(與location在配置文件中的順序無關)
= 精確匹配會第一個被處理。若是發現精確匹配,nginx中止搜索其餘匹配。
普通字符匹配,正則表達式規則和長的塊規則將被優先和查詢匹配,也就是說若是該項匹配還需去看有沒有正則表達式匹配和更長的匹配。
^~ 則只匹配該規則,nginx中止搜索其餘匹配,不然nginx會繼續處理其餘location指令。
最後匹配理帶有"~"和"~*"的指令,若是找到相應的匹配,則nginx中止搜索其餘匹配;當沒有正則表達式或者沒有正則表達式被匹配的狀況下,那麼匹配程度最高的逐字匹配指令會被使用。

  這是nginx.conf中的部分規則。看了說明仍是不怎麼理解,這裏再應用@周葛亮的理解:

Location處理邏輯
1.用uri測試全部的prefix string;
2.Uri精確匹配到=定義的loacation,使用這個location,中止搜索;
3.匹配最長prefix string,若是這個最長prefix string帶有^~修飾符,使用這個location,中止搜索,不然:
4.存儲這個最長匹配;
5.而後匹配正則表達;
6.匹配到第一條正則表達式,使用這個location,中止搜索;
7.沒有匹配到正則表達式,使用#4步存儲的prefix string的location。

location  = / {
  # 只匹配"/".
  [ configuration A ] 
}
location  / {
  # 匹配任何請求,由於全部請求都是以"/"開始
  # 可是更長字符匹配或者正則表達式匹配會優先匹配
  [ configuration B ] 
}
location ^~ /images/ {
  # 匹配任何以 /images/ 開始的請求,並中止匹配 其它location
  [ configuration C ] 
}
location ~* .(gif|jpg|jpeg)$ {
  # 匹配以 gif, jpg, or jpeg結尾的請求. 
  # 可是全部 /images/ 目錄的請求將由 [Configuration C]處理.   
  [ configuration D ] 
}

 

 

 

一些匹配規則:

  1.若是server塊中指定了root,及時這個server塊中不包含location / {...}, 在請求沒有任何一個location匹配成功的狀況,默認處理這個請求的不是第一個location塊,而是location / {...},儘管它並不沒有顯示地出如今server塊中;

     而,若是server塊中沒有指定root,在請求沒有匹配到任何location時,交給第一個location塊處理。(以上,不明確指定默認處理location)

相關文章
相關標籤/搜索