浏览 3.4k
概述
NGINX本身提供了简单的脚本解析功能来提高配置使用的灵活性。与常用的语言一样，可以通过在NGINX配置文件中使用变量和指令来完成对NGINX的编程，来实现特定的功能。
简单变量使用例子：
…
location /test {
if ($arg_name = “test”) {
return 200 “welcome”;
}
}
上面的配置完成的功能是，如果客户访问的服务器的/test URI并且携带的name参数值是test, 则给client返回状态码200并且输出“welcome”。
上述简单的例子中，if对应的是指令，args_name对应的是变量。变量和指令也是任何编程语言必备的要素。通过使用脚本语言和变量，可以大大提高NGINX的灵活性，避免了通过大量添加新代码来支持新功能。
下面我们通过一系列的文章，来分析NGINX脚本语言是如何实现的。本篇文章，我们先介绍NGINX变量的基本特性。下一篇，我们继续分析变量的实现原理。最后我们将分析NGINX指令的实现原理以及变量是如何被使用的。
变量的定义
任何语言的变量都是用来存储和表示数据的。在定义变量时，我们首先需要给变量命名。比如在C语言中，我们通过int abc = 10;来定义一个整数类型的变量。其中int表示变量的类型，abc表示变量的名字。
关于定义变量的类型，在NGINX中所有的变量除了内置变量“${binary_remote_addr}”以外，剩余的变量都是字符串类型。变量“${binary_remote_addr}”根据IP的版本可是IPV4或者IPV6格式的二进制形式。
每种语言对于可以表示变量的字符要求不尽相同。在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的变量是如何在系统中被使用的。
点赞 12
浏览 2.5k点赞 1浏览 1.3k点赞 1浏览 848
微信公众号
加入微信群
