前面在 （二） 中我們已經(jīng)了解到變量值容器的生命期是與請求綁定的，但是我當(dāng)時有意避開了“請求”的正式定義。大家應(yīng)當(dāng)一直默認(rèn)這里的“請求”都是指客戶端發(fā)起的 HTTP 請求。其實在 Nginx 世界里有兩種類型的“請求”，一種叫做“主請求”（main request），而另一種則叫做“子請求”（subrequest）。我們先來介紹一下它們。 所謂“主請求”，就是由 HTTP 客戶端從 Nginx 外部發(fā)起的請求。

成都創(chuàng)新互聯(lián)是一家集網(wǎng)站建設(shè),南開企業(yè)網(wǎng)站建設(shè),南開品牌網(wǎng)站建設(shè),網(wǎng)站定制,南開網(wǎng)站建設(shè)報價,網(wǎng)絡(luò)營銷,網(wǎng)絡(luò)優(yōu)化,南開網(wǎng)站推廣為一體的創(chuàng)新建站企業(yè)，幫助傳統(tǒng)企業(yè)提升企業(yè)形象加強(qiáng)企業(yè)競爭力。可充分滿足這一群體相比中小企業(yè)更為豐富、高端、多元的互聯(lián)網(wǎng)需求。同時我們時刻保持專業(yè)、時尚、前沿，時刻以成就客戶成長自我，堅持不斷學(xué)習(xí)、思考、沉淀、凈化自己，讓我們?yōu)楦嗟钠髽I(yè)打造出實用型網(wǎng)站。

我們前面見到的所有例子都只涉及到“主請求”，包括 （二） 中那兩個使用 echo_exec 和 rewrite 指令發(fā)起“內(nèi)部跳轉(zhuǎn)”的例子。 而“子請求”則是由 Nginx 正在處理的請求在 Nginx 內(nèi)部發(fā)起的一種級聯(lián)請求。“子請求”在外觀上很像 HTTP 請求，但實現(xiàn)上卻和 HTTP 協(xié)議乃至網(wǎng)絡(luò)通信一點兒關(guān)系都沒有。它是 Nginx 內(nèi)部的一種抽象調(diào)用，目的是為了方便用戶把“主請求”的任務(wù)分解為多個較小粒度的“內(nèi)部請求”，并發(fā)或串行地訪問多個 location 接口，然后由這些 location 接口通力協(xié)作，共同完成整個“主請求”。當(dāng)然，“子請求”的概念是相對的，任何一個“子請求”也可以再發(fā)起更多的“子子請求”，甚至可以玩遞歸調(diào)用（即自己調(diào)用自己）。當(dāng)一個請求發(fā)起一個“子請求”的時候，按照 Nginx 的術(shù)語，習(xí)慣把前者稱為后者的“父請求”（parent request）。值得一提的是，Apache 服務(wù)器中其實也有“子請求”的概念，所以來自 Apache 世界的讀者對此應(yīng)當(dāng)不會感到陌生。 下面就來看一個使用了“子請求”的例子：

location /main { echo_location /foo; echo_location /bar; } location /foo { echo foo; } location /bar { echo bar; } 這里在 location /main 中，通過第三方 ngx_echo 模塊的 echo_location 指令分別發(fā)起到 /foo 和 /bar 這兩個接口的 GET 類型的“子請求”。由 echo_location 發(fā)起的“子請求”，其執(zhí)行是按照配置書寫的順序串行處理的，即只有當(dāng) /foo 請求處理完畢之后，才會接著處理 /bar 請求。這兩個“子請求”的輸出會按執(zhí)行順序拼接起來，作為 /main 接口的最終輸出：

$ curl \'http://localhost:8080/main\' foo bar 我們看到，“子請求”方式的通信是在同一個虛擬主機(jī)內(nèi)部進(jìn)行的，所以 Nginx 核心在實現(xiàn)“子請求”的時候，就只調(diào)用了若干個 C 函數(shù)，完全不涉及任何網(wǎng)絡(luò)或者 UNIX 套接字（socket）通信。我們由此可以看出“子請求”的執(zhí)行效率是極高的。 回到先前對 Nginx 變量值容器的生命期的討論，我們現(xiàn)在依舊可以說，它們的生命期是與當(dāng)前請求相關(guān)聯(lián)的。每個請求都有所有變量值容器的獨立副本，只不過當(dāng)前請求既可以是“主請求”，也可以是“子請求”。即便是父子請求之間，同名變量一般也不會相互干擾。讓我們來通過一個小實驗證明一下這個說法：

location /main { set $var main; echo_location /foo; echo_location /bar; echo "main: $var"; } location /foo { set $var foo; echo "foo: $var"; } location /bar { set $var bar; echo "bar: $var"; } 在這個例子中，我們分別在 /main，/foo 和 /bar 這三個 location 配置塊中為同一名字的變量，$var，分別設(shè)置了不同的值并予以輸出。特別地，我們在 /main 接口中，故意在調(diào)用過 /foo 和 /bar 這兩個“子請求”之后，再輸出它自己的 $var 變量的值。請求 /main 接口的結(jié)果是這樣的：

$ curl \'http://localhost:8080/main\' foo: foo bar: bar main: main 顯然，/foo 和 /bar 這兩個“子請求”在處理過程中對變量 $var 各自所做的修改都絲毫沒有影響到“主請求” /main. 于是這成功印證了“主請求”以及各個“子請求”都擁有不同的變量 $var 的值容器副本。 不幸的是，一些 Nginx 模塊發(fā)起的“子請求”卻會自動共享其“父請求”的變量值容器，比如第三方模塊 ngx_auth_request. 下面是一個例子：

location /main { set $var main; auth_request /sub; echo "main: $var"; } location /sub { set $var sub; echo "sub: $var"; } 這里我們在 /main 接口中先為 $var 變量賦初值 main，然后使用 ngx_auth_request 模塊提供的配置指令 auth_request，發(fā)起一個到 /sub 接口的“子請求”，最后利用 echo 指令輸出變量 $var 的值。而我們在 /sub 接口中則故意把 $var 變量的值改寫成 sub. 訪問 /main 接口的結(jié)果如下：

$ curl \'http://localhost:8080/main\' main: sub 我們看到，/sub 接口對 $var 變量值的修改影響到了主請求 /main. 所以 ngx_auth_request 模塊發(fā)起的“子請求”確實是與其“父請求”共享一套 Nginx 變量的值容器。 對于上面這個例子，相信有讀者會問：“為什么‘子請求’ /sub 的輸出沒有出現(xiàn)在最終的輸出里呢？”答案很簡單，那就是因為 auth_request 指令會自動忽略“子請求”的響應(yīng)體，而只檢查“子請求”的響應(yīng)狀態(tài)碼。當(dāng)狀態(tài)碼是 2XX 的時候，auth_request 指令會忽略“子請求”而讓 Nginx 繼續(xù)處理當(dāng)前的請求，否則它就會立即中斷當(dāng)前（主）請求的執(zhí)行，返回相應(yīng)的出錯頁。在我們的例子中，/sub “子請求”只是使用 echo 指令作了一些輸出，所以隱式地返回了指示正常的 200 狀態(tài)碼。 如 ngx_auth_request 模塊這樣父子請求共享一套 Nginx 變量的行為，雖然可以讓父子請求之間的數(shù)據(jù)雙向傳遞變得極為容易，但是對于足夠復(fù)雜的配置，卻也經(jīng)常導(dǎo)致不少難于調(diào)試的詭異 bug. 因為用戶時常不知道“父請求”的某個 Nginx 變量的值，其實已經(jīng)在它的某個“子請求”中被意外修改了。諸如此類的因共享而導(dǎo)致的不好的“副作用”，讓包括 ngx_echo，ngx_lua，以及 ngx_srcache 在內(nèi)的許多第三方模塊都選擇了禁用父子請求間的變量共享。