nginx 入门

1、nginx 如何处理一个请求

IP，域名的处理

server {

listen  80  default_server;     //添加 default_server就是一个默认的server

server_name   nginx.org  www.nginx.org

.....

}

server {

listen 80;

server_name  nginx.net   www.nginx.net

}

nginx 仅测试请求头中的host，从而决定这个请求被路由到哪个server， 如果host没有匹配的，或者host不存在，则由默认的server进行处理

server_name的匹配规则

域名遵循下述优先级规则：
1、完整匹配的名称。
2、名称开始于一个文件通配符：*.example.com。
3、名称结束于一个文件通配符：www.example.*。
4、使用正则表达式的名称。

阻止处理不明确主机名的请求

如果客户请求头中，可能会有host不明确的情况，如果不想处理这类请求，可以定义默认的server来进行抛弃

server{

listen 80 default_server;

server_name  _;

return 444;

}

1选择一个不存在的服务器名字，并返回特殊的非标准的代码444，以便关闭这个连接。

如果listen  192.168.1.45:80 则优先进行ip匹配，再进行server_name匹配

URI 的处理

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 ~* \.(gif|jpg|js|css|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，因为不区分大小写。规则F，规则G属于排除法，符合匹配规则但是不会匹配到，所以想想看实际应用中哪里会用到。
访问 http://localhost/category/id/1111 则最终匹配到规则H，因为以上规则都不匹配，这个时候应该是nginx转发请求给后端应用服务器，比如FastCGI（php），tomcat（jsp），nginx作为方向代理服务器存在。

rewrite 规则：

实现url的重写或者重定向。rewrite只能放在  server{},loacation{}, if{}中，并且只对域名后面出去参数的字符串起作用，例如 http://www.facebank.cn/a/we/index.php?userid=1&password=222

只能对/a/we/index.php起作用. 语法rewrite regex replacement [flag]

执行顺序：

1. 执行server块的rewrite指令
2. 执行location匹配
3. 执行选定的location中的rewrite指令

如果其中某步uri被重写，则重复循环执行1-3，直到找到真实的文件；循环超过10次，则返回500 internal server error 错误

http {
    # 定义image日志格式
    log_format imagelog '[$time_local] ' $image_file ' ' $image_type ' ' $body_bytes_sent ' ' $status;
    # 开启重写日志
    rewrite_log on;

    server {
        root /home/www;

        location / {
                # 重写规则信息
                error_log logs/rewrite.log notice;
                # 注意这里要用‘’单引号引起来，避免{}
                rewrite '^/images/([a-z]{2})/([a-z0-9]{5})/(.*)\.(png|jpg|gif)$' /data?file=$3.$4;
                # 注意不能在上面这条规则后面加上“last”参数，否则下面的set指令不会执行
                set $image_file $3;
                set $image_type $4;
        }

        location /data {
                # 指定针对图片的日志格式，来分析图片类型和大小
                access_log logs/images.log mian;
                root /data/images;
                # 应用前面定义的变量。判断首先文件在不在，不在再判断目录在不在，如果还不在就跳转到最后一个url里
                try_files /$arg_file /image404.html;
        }
        location = /image404.html {
                # 图片不存在返回特定的信息
                return 404 "image not found\n";
        }
}

对形如/images/ef/uh7b3/test.png的请求，重写到/data?file=test.png，于是匹配到location /data，先看/data/images/test.png文件存不存在，如果存在则正常响应，如果不存在则重写tryfiles到新的image404 location，直接返回404状态码。

upstream  m_server{
    server  192.168.1.1  weight=10;
    server  192.168.1.2  weight=5;
// weight 是一种访问权重
******************************************
    ip_hash;
    server 192.168.1.1:80;
    server 192.168.1.3:8080;
    //通过ip hash值进行分配请求到各个机器，解决session问题
    hash $remoute_addr;
    hash   $cookie_QN99; 
    hash_again  10;
  #增加hash_again是避免已cookies或者session hash的机器宕机后，再次进行hash，请求到其他机器上

   upstream web_pool {

        server 172.23.136.148;

        server 172.23.136.149;

        fair;

      #按后端服务器的响应时间来分配请求，响应时间短的优先分配.

      }

 

 健康机制：

    healthcheck_enabled ##启用此模块

healthcheck_delay ##对同一台后端服务器两次检测之间的时间间隔，单位毫秒，默认为1000；

healthcheck_timeout ##进行一次健康检测的超时时间，单位为毫秒，默认值2000；

healthcheck_failcount ##对一台后端服务器检测成功或失败多少次之后方才确定其为成功或失败，并实现启用或禁用此服务器；

healthcheck_send ##为了检测后端服务器的健康状态所发送的检测请求；如：healthcheck_send "GET /health HTTP/1.0" 'Host: coolinuz.9966.org';

healthcheck_expected ##期望从后端服务器收到的响应内容；如果未设置，则表示从后端服务器收到200状态码即为正确；

healthcheck_buffer ##健康状态检查所使用的buffer空间大小；

 

#好处：当某个机器宕机后，请求依然会打到某个机器上，虽然有可能设置了fail_timeout的时间，但过了设置时间后，不管机器是否已经好了，请求会再次打到此机器上

}