nginx 学习

刚开始接触nginx，本文用于备忘及方便本身查找，主要内容是转载其余文章内容，但并非彻底转载，若是有什么错漏请查看参考连接。

参考：

　　nginx中文文档

　　nginx中文手册

　　nginx参数配置及基本说明

 

编译以前，可能须要安装

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

 

 

启动nginx(根据本身tengine(淘宝开源nginx)安装路径,)

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

 

一、检查nginx进程pid，并从容关闭

$ 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快速关闭

　　或者

$ 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）