CodeIgniter 3 nginx配置 nginx 代码

概述

NGINX本身提供了简单的脚本解析功能来提高配置使用的灵活性。与常用的语言一样，可以通过在NGINX配置文件中使用变量和指令来完成对NGINX的编程，来实现特定的功能。

简单变量使用例子：

…

location /test {

     if ($args_name = “test”) {

         return 200 “welcome”;

    }

}

上面的配置完成的功能是，如果客户访问的服务器的/test URI并且携带的name参数值是test, 则给client返回状态码200并且输出“welcome”。

上述简单的例子中，if对应的是指令，args_name对应的是变量。变量和指令也是任何编程语言必备的要素。通过使用脚本语言和变量，可以大大提高NGINX的灵活性，避免了通过大量添加新代码来支持新功能。

NGINX提供的变量机制，使得NGINX在处理每一个具体的HTTP请求时，可以在不同处理阶段直接传递数据。比如在POST_READ阶段在读取了client请求以后，我们就可以获取本次请求的相关host等信息。通过变量机制，后续的模块就可以通过变量$host来获取本次请求的host数据信息。

下面我们通过一系列的文章，来分析NGINX脚本语言是如何实现的。本篇文章，我们先介绍NGINX变量的基本特性。下一篇，我们继续分析变量的实现原理。最后我们将分析NGINX指令的实现原理以及变量是如何被使用的。

变量的定义

任何语言的变量都是用来存储和表示数据的。在定义变量时，我们首先需要给变量命名。比如在C语言中，我们通过int abc = 10;来定义一个整数类型的变量。其中int表示变量的类型，abc表示变量的名字。

关于定义变量的类型，在NGINX中所有的变量除了内置变量“${binary_remote_addr}”以外，剩余的变量都是字符串类型。

每种语言对于可以表示变量的字符要求不尽相同。在NGINX脚本语言中，变量的名字是使用“$”或“${}”符号来表示一个变量。可以用来定义变量的有效字符只有四种：“a-z”、“A-Z”、“0-9”、“_”。 比如 set $abc ‘abc’或者set ${abc} ‘abc’。 符号{}的意义在于，如果一个变量名需要和它相邻的字符进行区分时，需要显式地添加{}来实现。比如 变量${a}s 与$as和${as}两个变量表示的意义是不一样的，前者表示在变量a的值后面再添加一个s字符。 $as和${as}都表示变量as本身。

NGINX的变量支持变量插入，比如我们通过set $def “this is a test $abc”定义变量$def。在进行赋值时，需要首先计算出变量abc的值然后再和另外的字符串连接，最后把连接后的字符串赋值给变量def。如果变量abc的值是“yeah!”，那么变量def的值就是 “this is a test yeah!”。

变量的分类

NGINX变量可以分为内置变量和自定义变量两种。自定义变量是通过NGINX不同模块的进行显示定义。比如通过rewrite模块中的set指令可以如下定义： set $test “abc”;这个指令完成定义一个名为test的变量，并且在变量第一次被使用时把字符串abc赋值给test变量。还有比如geo模块也可以如下根据客户端的IP来定义一个新的变量。

geo $a  {

    default    “我是geo默认值”;

    127.0.0.1  “客户端ip是127.0.0.1”;

}

除了自定义变量以外，NGINX还支持大量的内置变量。这些内置变量根据系统的层次模型，可以分为系统相关的变量比如$pid、网络三层相关的变量，比如$remote_addr、四层相关的变量，比如$remote_port、表示层(SSL,TLS)相关的变量，比如$http_ssl_vars以及七层HTTP，比如$url相关的变量。

内置变量又可以分为静态内置变量和动态内置变量。静态内置变量是在不同的模块中通过代码预先定义的。比如在NGX_HTTP_CORE_MODULAR里面就定义了大量的系统变量如$HOST,  $URI等。

所谓“动态”指的是变量的名字是不确定的，这个不确定性发生在NGINX的运行过程中。比如对于一个HTTP请求，同一个请求可以有不同的查询参数，而查询参数的不同又可以返回不同的结果，比如这个查询功能：

/query?name=jikui

/query?occurpation=coder

该查询功能有两个输入参数，一个是name，一个是occupation。当请求发生的时候，在NGINX内部肯定可以解析出所有的查询入参和对应的值，但是在配置文件中如何得到和使用呢？ NGINX通过使用前缀的方式来表示HTTP模块中各种动态内置变量。分别使用用arg_name和arg_occurpation来表示其对应的变量。而arg_就是查询参数中某个入参的变量前缀。如此一来NGINX只需要在内部内置一个以arg_开头的规则就可以方便的表示这类参数相关数据了。

目前在NGINX的http模块中有如下几种内置动态变量，分别是“http_”、“sent_http_”、“sent_trailer_”、“upstream_http_”、 “upstream_cookie_”、“cookie_”，“arg_”, “upstream_trailer_”。

以“http_”开头的动态内置变量可以表示http请求过程中的任意请求头，使用的过程中不区分大小写，并且请求头中如果有“-”字符需要用“_”字符替代。另外别的种类的动态内置变量也有相应的对应HTTP处理阶段。

变量的作用域

NGINX在启动时，会对变量进行静态检查，如果有指令使用未经定义的变量，NGINX启动会出错。并且打印如下的出错信息：“NGINX: [emerg] unknown "**" variable”。

NGINX变量在配置文件中是全局可见的，基于此，在如下的配置中，虽然我们是在location /test2中定义的变量name,在locaiton /test1中也进行了使用，但是这样在NGINX启动时是也不会出错。

        location /test1 {

               return 200 “I am $name”;

        }

        location /test2 {

             set $name“jikui”;

             return 200 “I am $name”;

         }

在实际的访问中，如果访问location test1返回的结果是 “I am”而访问location test2返回的结果是 “I am jikui”。这是因为，虽然静态的变量定义是全局可见的，但是对应每一个请求，都会有自己的一份变量的定义和数值。虽然对于不同的请求，都有各自不同的变量定义，但是在父子请求模型中，所有的子请求自动继承父请求所有的变量值。     

变量的可变性

根据变量是否可以被再次赋值，NGINX中的变量分为可变变量和不可变变量。在C语言中有特定的修饰符const用来描述这个变量的可变性。但是在NGINX中，并没有显著的修饰符来区分变量的可变性。只能从变量的实现代码实现中来判断某个变量是否可变。

具体来说，在定义NGINX的变量时都会打上一个是否可以被改变的标记，然后把这个变量放到一个容器中。当后续试图再次定义同一个变量时，NGINX会首先从这个容器中查找这个变量，如果找到相同的变量，再判断这个变量的可改变的标记。如果变量的可变标志是True，则会把容器中的变量覆盖掉，反之则返回错误并终止NGINX启动。具体的实现我们下篇变量实现中继续分析。

NGINX的内置变量要先于“set”或“geo”指令存放到系统中，如果某个内置变量，比如$host，被打上了不可改变的标记，后续其它指令就无法再定义相同名字的变量了。如果试图再次定义$host变量，则会出现如下错误：

nginx: [emerg] the duplicate "host" variable in / nginx.conf:45

目前NGINX的核心http模块中几乎所有静态内置变量都是不可改变的。只有“$args”和“$limit_rate”这两个内置变量可以被改变。另外由于http模块的动态内置变量并不会把自己放入到容器中，所以它是可以被改变。

比如：

location /name {

    set $arg_name “jikui”;

    return 200 “$arg_name”;

}

在访问location /name时，输出的是通过set指令设置的数值“jikui”而不是url参数中的“test”。

curl http://127.0.0.1/name?name=test

jikui

这是因为在NGINX中，一自定义或内置变量不会被赋予动态变量的特性。比如例子中的“$arg_name”，通过set指令赋值后，其实已经变成了一个自定义变量，相应的动态变量特征也就不存在了。但在这个请求中，其它以“$arg_”开头的变量仍然是动态变量。  

变量的可缓存性

变量的可缓存性是指，在获取变量值时，是否需要每次都实时计算变量的值。对于不可缓存变量，获取数值时都是实时计算的。对于可缓存的变量，不需要每次都实时计算。

具体来说，NGINX中所有的变量在定义时都会被关联上一个get_handler()方法。所有变量在第一次获取值时，都是通过这个handler方法获取。后续再次获取变量值时，是否仍然调用该handler方法则取决于该变量是否可以被缓存。

比如“$arg_”开头的动态变量，每次获取值时都会从查询参数中重新解析对应的值；而可以缓存的变量并不会每次都调用这个handler方法，在它的整个生命周期中，如果这个变量没有被刷新过，那么自始至终只会调用一次。

NGINX中用set指令定义的变量都是可以缓存的，但set指令不会改变已有变量的缓存特性，而所有以“arg_”开头的动态变量都是不可缓存的。这两种变量结合在一起的时候会产生一种有意思的现象，来看一个简单的例子：

比如：

location /url {

    set   $name   “$arg_name”;

    set   $args   “name=jikui”;

    return 200   “$name = $arg_name”;

}

访问url输出结果是:

curl http://127.0.0.1/url?name=test

test = jikui

这时候我们可以看到，“$name”和“$arg_name”这两个变量虽然都是在表示入参name的值，但是却输出了不同的结果。

这其实就是变量是否可缓存的特性引起的，因为变量“$name”是一个可缓存的变量，当被设置后变量值就被保存下来了；而“$arg_name”是一个不可被缓存的变量，每次获取该值的时候都会调用其对应的handler方法。我们看到第一次调用的时候查询参数值是“name=test”，这个值被赋值给了变量“$name”，在第二次获取该变量值之前，我们把查询参数改成了“name=jikui”，当它再次调用对应的handler方法的时候获取到的值就变成了“jikui”。

动态内置变量此时仍然是一个特殊的存在，我们之前说过，动态变量被重新定义后它就不再是动态变量了，所以它也就不再保有不可缓存的特性，看个例子就知道了：

location /a {

    set     $arg_name     “$arg_name”;

    set     $name     “$arg_name”;

    set     $args     “name=jikui”;

    return   200    “$name = $arg_name”;

}

访问location：

curl http://127.0.0.1/a?name=test

test = test

可以看到这两个变量的值又一样了。原因是，在用set指令重新定义“$arg_name”后，它就不再是动态变量了，它原本的不可缓存特性也就不存在了，所以此时查询参数的更改对他也就不起任何作用。具体原因我们可以通过下篇代码分析来看实际的实现原理。

变量的隔离性

NGINX中变量的隔离性类似于其它编程语言中变量的作用域。比如C语言中的局部变量和全局变量。而NGINX中的变量的作用域是基于请求的。同一个变量在不同的请求中毫无关系(子请求例外，子请求继承了父请求所有的变量），即A请求不会读到(或改变)B请求中的变量值，B也不会读到(改变)A的，比如下面一个例子：

server {

    set $name “$uri”;

    location /test1 {

        return 200 “I am $name”;

    }

    location /test2 {

        return 200 “I am $name”;

    }

}

我们在server块定义了一个看似是“全局变量”的“$name”。如果它有全局性，那么访问上面的两个location的时候肯定会得到相同的值，但NGINX中不是这样的。

在NGINX中两个location都可以看到这个变量“$name”，这体现了NGINX变量的全局可见性；但两个location看到的变量值确实是不一样的，这体现了隔离性。上述配置的运行结果是:

curl http://127.0.0.1/test1

I am test1

curl http://127.0.0./test2

I am test2

在同一个请求中NGINX的变量是有全局性的，但仅限于当前请求中。不管变量的更改发生在配置文件的哪个位置，在同一个请求中都可以被看到，看下面一个例子：

server {

    set $name “server”;

    location / {

        set $name “location”;

        if ($uri) {

           set $name “if”;

        }

        return 200 “$name”;

    }

}

从上面的例子可以看到，变量“$name”被更改了三次。上面的例子一定是输出字符串“if”。从上面这个例子我们看到，NGINX 变量值容器的生命期是与当前正在处理的请求绑定的，而与 location 无关。

结语

本篇简单介绍了NGINX变量的一些特性。下篇我们将继续分析变量是如何实现的。然后我们还将通过分析NGINX的脚本语言的实现，来分析NGINX的变量是如何在系统中被使用的。