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

1、检查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

2、使用信号操作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）