FastCGI 要解決 CGI 的哪一件事

CGI 的成本集中在一句話：每個請求啟動一個新程序，請求結束程序就消失。載入 PHP 執行檔、讀設定、初始化擴充這些工作，每個請求都要重做一次，OPcache 也因為程序不續命而永遠命中不了。

FastCGI 的原始規格由 Open Market 在 1996 年發布，開宗明義寫它「designed to support long-lived application processes」——支援長時間存活的應用程式程序。它保留 CGI 已經可行的部分（請求資訊用一組具名的參數傳遞，回應用資料流送回），只改掉程序的壽命：應用程式程序啟動一次後常駐，透過一條連線接收一個又一個請求。

一個請求在 FastCGI 協定裡的樣子

FastCGI 把一條連線上的資料切成一筆一筆的記錄（record），每筆記錄有型別。一個請求用到的主要型別：

• FCGI_PARAMS：web 伺服器把請求的參數（名稱與值的配對）送給應用程式，裝的就是 CGI 那套 meta-variables——REQUEST_METHOD、QUERY_STRING、SCRIPT_FILENAME 等。PHP 的 $_SERVER 就是從這裡填出來的。
• FCGI_STDIN：請求的內容（POST 的資料）。
• FCGI_STDOUT：應用程式送回的回應，包含標頭與內容。
• FCGI_END_REQUEST：應用程式宣告這個請求處理完了。

FastCGI 的角色裡最常用的是 Responder，規格說它對應 CGI 原本做的事：接收一個 HTTP 請求的全部資訊，產生一個 HTTP 回應。PHP-FPM 實作的就是這個角色。

這帶出一個分工上的事實：web 伺服器收到 HTTP 請求之後，自己把它拆解成 FCGI_PARAMS 裡的參數，再送給 PHP。PHP 收到的是 web 伺服器整理好的參數，原始的 HTTP 請求留在 web 伺服器那一側。其中一個參數決定了 PHP 要執行哪個檔案，而它由 web 伺服器填寫——這是下一節的安全邊界。

web 伺服器決定 PHP 執行哪個檔案

SCRIPT_FILENAME 這個參數告訴 PHP 要執行磁碟上的哪一個檔案。在 Nginx 加 PHP-FPM 的設定裡，它由 Nginx 組出來：

1location ~ \.php$ {
2    fastcgi_pass fpm:9000;
3    include fastcgi_params;
4    fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
5}

這段設定要讀者改的是 fastcgi_pass 後面的位址：fpm:9000 是 PHP-FPM 在這個環境裡的主機名與埠，同一台機器上通常是 127.0.0.1:9000 或一個 Unix socket 的路徑。$fastcgi_script_name 是 Nginx 從請求路徑推出來的腳本路徑。問題出在 location ~ \.php$：它只要求路徑以 .php 結尾，沒有要求那個檔案存在。

這一點配上 PHP 的 cgi.fix_pathinfo 設定會變成一個漏洞。cgi.fix_pathinfo 開著時（這是預設值），PHP 拿到一個不存在的檔案路徑，會往前找路徑裡存在的那一段當成要執行的腳本。把這幾件事擺在一起，一個常見的攻擊路徑是：使用者上傳一個內含 PHP 程式碼、副檔名卻是圖片的檔案（evil.jpg），再用 /uploads/evil.jpg/x.php 這個網址存取它。

在刻意寫成不安全版本（location ~ \.php$ 沒有檢查檔案存在、cgi.fix_pathinfo=1、PHP-FPM 的 security.limit_extensions 放寬到容許 .jpg）的環境實測：

1$ curl localhost/uploads/evil.jpg/x.php
2executed as PHP: /var/www/html/uploads/evil.jpg   [200]

Nginx 看到路徑以 .php 結尾，把它交給 PHP；PHP 找不到 x.php，依 cgi.fix_pathinfo 往前找到存在的 evil.jpg，把這個圖片當成 PHP 執行了。上傳的內容因此變成在伺服器上執行的程式碼。

三道各自獨立的防線

這個漏洞要同時打穿幾道設定才成立，所以每一道都能單獨擋下它。實測三種修法各自的效果：

PHP-FPM 的 security.limit_extensions 限制哪些副檔名可以被當成 PHP 執行，預設只有 .php。保持預設時，evil.jpg 根本不會被執行：

1$ curl localhost/uploads/evil.jpg/x.php
2Access denied.   [403]
3# php-fpm log: Access to the script '/var/www/html/uploads/evil.jpg'
4#   has been denied (see security.limit_extensions)

把 cgi.fix_pathinfo 關掉（php_admin_value[cgi.fix_pathinfo] = 0），PHP 不再往前找存在的檔案，找不到 x.php 就直接回報沒有輸入檔：

1$ curl localhost/uploads/evil.jpg/x.php
2No input file specified.   [404]

在 Nginx 的 location ~ \.php$ 裡加 try_files $uri =404，要求檔案存在才交給 PHP，不存在的 x.php 在 Nginx 這一層就被擋下，根本到不了 PHP：

1location ~ \.php$ {
2    try_files $uri =404;        # 檔案不存在就直接回 404，不轉給 PHP
3    fastcgi_pass fpm:9000;
4    include fastcgi_params;
5    fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
6}

1$ curl localhost/uploads/evil.jpg/x.php
2[404]

三道防線的位置不同：try_files 在 web 伺服器（請求還沒到 PHP）、security.limit_extensions 與 cgi.fix_pathinfo 在 PHP 端。預設值已經擋住這個攻擊（security.limit_extensions 預設 .php、而 fix_pathinfo 的風險要配上寬鬆的 location 才成立），要出事得有人主動放寬設定。三道一起設是縱深防禦：任何一道被改錯，另外兩道還在。

這個邊界的根源是本篇開頭那件事：SCRIPT_FILENAME 由 web 伺服器決定，PHP 照著它執行。PHP 信任 web 伺服器交來的檔案路徑，所以 web 伺服器的路由規則寫得鬆，PHP 就會執行到不該執行的檔案。

FastCGI 與 PHP-FPM 的關係

FastCGI 是協定，規定 web 伺服器與應用程式程序之間怎麼傳遞請求和回應。它本身不規定那群常駐的應用程式程序由誰啟動、開幾個、一個掛了怎麼補、記憶體漲了怎麼辦。

這些是「程序管理」的工作，PHP 的答案是 PHP-FPM（FastCGI Process Manager）。它實作 FastCGI 的 Responder 角色，接 Nginx 或 Apache 用這個協定送來的請求，並管理那一群 PHP worker 程序。程序管理的每一個旋鈕，以及它們怎麼影響服務的行為與壓測數字，在 PHP-FPM 展開。

為什麼常駐程序需要一個管理者

FastCGI 要求應用程式程序常駐，於是出現幾個 CGI 下不存在的問題，因為 CGI 的程序活一個請求就結束、沒有機會累積：

• 開幾個程序：太少，並發的請求要排隊；太多，記憶體吃光。
• 一個程序掛了誰補：常駐的程序可能因為程式錯誤或記憶體不足而死掉，要有人把它補回來。
• 記憶體隨時間漲：worker 活得久，C 擴充的記憶體洩漏會一點一點累積。
• 某個請求卡住：一個跑不完的請求會一直佔著一個 worker，佔住的 worker 越多，能處理新請求的就越少。

PHP-FPM 就是處理這幾件事的常駐服務（見 PHP-FPM）。它的 PHP 版本記在官方 ChangeLog 裡：PHP 5.3.3（2010 年 7 月）的 ChangeLog 記著「Added FastCGI Process Manager (FPM) SAPI」，FPM 從這個版本起隨 PHP 本體發行。PHP-FPM 的架構是一個主程序（master）加一群 worker：master 不處理請求，只負責讀設定、開 worker、補死掉的 worker、轉送管理訊號；worker 才是實際執行 PHP 的程序。

PHP 官方文件對它有一句明確的安全要求：php-fpm must not be reachable from an untrusted network——FastCGI 的埠（預設 9000）不能對不受信任的網路開放。FastCGI 協定本身沒有驗證，誰連得上這個埠，誰就能指定 SCRIPT_FILENAME 要 PHP 執行哪個檔案（見 FastCGI 的安全邊界）。所以它只聽 127.0.0.1 或 Unix socket，或用 listen.allowed_clients 限制來源。

pool：一組 worker 與它的執行身分

PHP-FPM 把 worker 分成一個或多個 pool，每個 pool 是一組設定相同的 worker，可以指定自己的執行帳號（user / group）、監聽位址（listen）、以及 PHP 設定。這一個機制解掉了 mod_php 最大的限制：

mod_php 的所有站台都以 Apache 的帳號執行，彼此的檔案互相看得到。PHP-FPM 讓每個站台一個 pool、各自指定執行帳號：

1[site_a]
2user = site_a
3group = site_a
4listen = /run/php/site_a.sock
5
6[site_b]
7user = site_b
8group = site_b
9listen = /run/php/site_b.sock

listen 可以是 Unix socket 的路徑（如上）或 IP:埠。web 伺服器與 PHP-FPM 在同一台機器、同一個檔案系統時可以用 Unix socket，少走一層 TCP；分在不同容器或不同機器時要用 TCP，這也是容器環境預設 listen = 9000 的原因。

site_a 的 PHP 以 site_a 的帳號執行，讀不到 site_b 的檔案，產生的檔案也屬於 site_a。這把 CGI 加 suEXEC 才有的隔離，做在了常駐程序上——既有隔離，又沒有每個請求啟動程序的成本。這是共享主機從 CGI 換到 PHP-FPM 的主因。

pm：開 worker 的三種策略

pm 決定 PHP-FPM 怎麼決定開幾個 worker，有三個值：

三者的上限都是 pm.max_children，差別只在平常保持幾個 worker 活著。dynamic 是預設，它的「動態」是 PHP-FPM 在常駐的 worker 群裡依閒置數量增減，不是每個請求開關程序，所以跟 CGI 的每請求一程序是兩回事。

容器裡的取捨跟整台伺服器不同。一個容器通常只跑一個 pool，而且 max_children 已經依容器的記憶體上限配好；這時 dynamic 省下的閒置記憶體別的程式也用不到，static 反而省掉流量上升時臨時開 worker 的延遲。

max_children：並發上限與排隊

pm.max_children 是這個 pool 最多能同時存在的 worker 數量，也就是這個 pool 最多能同時處理幾個請求。一個 worker 一次只處理一個請求，所以超過這個數量的請求要排隊等。每個 worker 各自連資料庫，所以實例數 × pm.max_children 也是資料庫連線數的上限，要算進資料庫的 max_connections（各語言的連線模型對照見 1.17 應用程式存取資料庫的工具分層）。

這一點可以直接量。設 pm = static、pm.max_children = 2，然後同時送 6 個各需要 1 秒的請求：

1各請求完成的秒數：[1.06, 1.06, 2.07, 2.07, 3.08, 3.09]  總時間 3.1 秒

兩個 worker 同時處理兩個請求（約 1 秒完成），剩下的排隊：第三、四個等前兩個做完（約 2 秒），第五、六個再等一輪（約 3 秒）。這就是 max_children 太小時的樣子：請求都成功了，延遲隨排隊長度線性增加。

max_children 要設多大，由兩件事夾出來：

• 上界是記憶體：每個 worker 都佔記憶體（框架越大佔越多）。max_children 乘上單一 worker 的記憶體，不能超過機器分給 PHP 的量，否則系統開始用 swap 或直接把程序殺掉。單一 worker 的記憶體要用最重的那一類請求的峰值估，不能用平均值：下面〈max_requests〉一節量到，worker 處理完一個重請求之後，記憶體會保留一段時間才降回來，而尖峰時可能每個 worker 剛好都處理過重請求。
• 下界是並發需求：太小就像上面那樣排隊。需要多少並發，看請求把時間花在哪裡：大部分時間在等資料庫或外部 API 的請求，worker 等待時不佔 CPU，數量可以遠多於 CPU 核心數；大部分時間在計算的請求，worker 數超過核心數之後只增加切換成本，處理量不會再上升。

這是 PHP-FPM 最常調、也最該記進壓測結果的一個值。壓測時換了機器、換了框架、改了這個值，數字就不能跟之前比。

max_requests：定期換掉 worker 以控制記憶體

pm.max_requests 讓一個 worker 處理滿指定數量的請求之後，自己結束，由 master 開一個新的 worker 補上。設 pm.max_requests = 3，對計數腳本連續請求，可以看到 PID 換掉：

1pid=7 static=1 ...
2pid=7 static=1 ...
3pid=7 static=1 ...
4pid=8 static=1 ...     # PID 7 處理滿 3 個請求後，換成 PID 8

它防的是哪一種記憶體成長，要先把 worker 的記憶體分成兩類，因為兩類跨請求的行為不同。

PHP 程式碼用的記憶體不會隨處理過的請求數增長，但會暫時停在高點。 PHP 程式碼建立的變數、陣列與物件，由 PHP 自己的記憶體管理器（Zend Memory Manager）配置，請求結束時全部釋放——這是 shared-nothing 的一部分。不過「釋放」是釋放給記憶體管理器，不等於立刻還給作業系統，所以從作業系統看到的 RSS 不會馬上降。用一個只開一個 worker 的 pool，讓每個請求都落在同一個程序上，量它的 RSS（作業系統看到的實體記憶體佔用）：

1初始                                  rss=10MB
2一個建立 50 萬筆小陣列的請求（PHP 峰值 210MB）
3之後的小請求，依序：                  rss=112MB → 62MB → 36MB → 24MB → 18MB → 14MB → 14MB

請求早就結束了，RSS 卻停在 112MB，再隨後面的請求逐步降回約 14MB。原因在記憶體管理器的實作：它以 2MB 的 chunk 為單位向作業系統要記憶體，請求結束時不把 chunk 全部還回去，而是留下一部分給下一個請求用，省掉反覆向作業系統申請與歸還的成本。留下多少由一個移動平均決定，每個請求結束時更新成「上一次的平均與這次請求的峰值兩者的平均」，保留的 chunk 數跟著這個平均走。代入上面的量測：重請求之前平均接近 0，重請求的峰值約 210MB，這個請求結束時平均變成兩者的一半、約 105MB，所以保留了約 102MB；之後每個輕請求的峰值只有約 2MB，平均每次再減半。PHP 回報的記憶體依序是 102、52、26、14、8、4、2 MB，就是這個減半。這個調整只在請求結束時發生：worker 閒著沒有請求時，RSS 停在原來的值，不會隨時間自己降下來。單一一次配置超過約 2MB 的大區塊不走 chunk，請求結束時直接還給作業系統：一個配置 200MB 字串的請求結束後，RSS 立刻回到 12MB。

所以 worker 的 RSS 反映的是最近處理過的請求的峰值，不是它累計處理過幾個請求。重複「每 5 個輕請求夾 1 個重請求」六輪，每輪結束時的 RSS 都停在 14MB，沒有一輪比一輪高。

真正會跨請求累積的，是 PHP 記憶體管理器以外的記憶體。 C 寫的擴充與它們依賴的函式庫，有一部分記憶體直接向作業系統的配置器要，不經過 Zend Memory Manager，也不在請求結束時被清掉。這一類有洩漏時，worker 的 RSS 會隨處理過的請求數一路往上，不會降回來。max_requests 防的是這一類：與其逐一追查是哪個擴充在漏，讓 worker 處理一定數量的請求後整個換掉，舊程序累積的記憶體隨它結束一起還給作業系統。代價是新 worker 的 OPcache 命中要重新累積（見 OPcache 與程序壽命），所以這個值不設太小。

這兩類的分別給出一個判讀方法：在穩定的負載下，觀察 worker 的 RSS 在輕請求之後回落到的底部。底部固定，代表成長來自重請求的暫時保留，max_requests 不必設；底部隨時間一路往上，代表有 PHP 記憶體管理器以外的洩漏，這才是 max_requests 要處理的情形。

request_terminate_timeout 與 slowlog：跑太久的請求

一個卡住的請求會一直佔著一個 worker。佔住的 worker 越多，max_children 裡能處理新請求的名額就越少，到最後整個 pool 都卡在慢請求上，新請求全部排隊。PHP-FPM 有兩個設定處理這件事。

request_terminate_timeout 是強制上限：一個請求跑超過這個時間，PHP-FPM 直接終止處理它的 worker。設 request_terminate_timeout = 3s，對一個會跑 5 秒的請求：

1$ curl -o /dev/null -w "%{http_code} after %{time_total}s" localhost/sleep.php?s=5
2502 after 3.24s

PHP-FPM 的 log 記下整個過程：

1WARNING: child 11, script 'sleep.php' execution timed out (3.2 sec), terminating
2WARNING: child 11 exited on signal 15 (SIGTERM) ...

而 Nginx 這一側，因為 worker 被終止、連線斷掉，記下：

1[error] recv() failed (104: Connection reset by peer) while reading
2  response header from upstream

這解釋了一個常見的現象：前端收到 502 Bad Gateway，但 Nginx 的 log 寫的是「連線被 upstream 重設」——因為 PHP-FPM 為了保護 worker 名額，主動把那個卡住的 worker 殺掉了。5xx 還有另一個常見成因跟逾時無關：worker 全忙時新請求在佇列裡排隊，延遲一路上升，排得夠久會撞到 Nginx 自己的逾時。兩者在 status 頁分得開，後者的 max listen queue 會大於 0（見下面的〈status 頁〉一節）。request_terminate_timeout 跟 PHP 自己的 max_execution_time 量的不是同一種時間。PHP 官方文件寫明，max_execution_time 只計算腳本本身執行的時間，花在腳本以外的活動——系統呼叫、串流操作、資料庫查詢——不算進去（Windows 例外，那裡量的是實際經過的時間）。所以一個卡在等資料庫回應的請求，max_execution_time 可能永遠不會觸發。request_terminate_timeout 由 PHP-FPM 從外部計算實際經過的時間，卡在哪裡都會終止。

request_slowlog_timeout 不終止請求，只在請求超過指定時間時把它當下的 PHP 呼叫堆疊記進 slowlog。設 request_slowlog_timeout = 1s，一個在 loadReport() 裡 sleep 的請求會留下：

1[pool www] pid 6
2script_filename = /var/www/html/slow.php
3[0x...] usleep() /var/www/html/slow.php:2
4[0x...] loadReport() /var/www/html/slow.php:3
5[0x...] handle() /var/www/html/slow.php:4

堆疊直接指出慢在哪一行、哪一層呼叫。這是找出慢請求根源最直接的工具，不必改程式加計時。

一個部署上的細節：PHP-FPM 取 worker 的堆疊是靠 ptrace 這個系統呼叫，在 Docker 預設的權限下會失敗（failed to ptrace(ATTACH) ... Operation not permitted），slowlog 因此是空的。容器裡要用 slowlog 得在啟動時加 --cap-add SYS_PTRACE。

status 頁：看這個 pool 現在的狀態

pm.status_path 開一個狀態頁，列出 pool 當下的 worker 數量、排隊與累計計數。前面那個 max_children = 2 的排隊測試跑完後，狀態頁是：

 1pool:                 www
 2process manager:      static
 3accepted conn:        15
 4listen queue:         0
 5max listen queue:     4
 6idle processes:       1
 7active processes:     1
 8total processes:      2
 9max active processes: 2
10max children reached: 0
11slow requests:        0

幾個欄位直接對應前面的設定：

• max listen queue：等待空閒 worker 的請求，最多排到過幾個。上面是 4，正好是那次 6 個並發裡、扣掉 2 個正在處理的其餘 4 個。這個數字長期大於 0，代表 max_children 在尖峰時不夠用，請求要排隊等空閒的 worker。
• max children reached：PHP-FPM 想多開 worker、卻撞到 max_children 上限的次數。這個計數只在 dynamic 與 ondemand 下會動，因為只有這兩種模式會「想多開」：上面那次是 static，請求排了 4 個而它仍然是 0；同樣 6 個並發換成 pm = dynamic（max_children = 2）時，它變成 1、max listen queue 是 5。所以 static 模式要看 max listen queue，不能看這一欄。
• slow requests：超過 request_slowlog_timeout 的請求累計數。

所以判斷 max_children 夠不夠，要先看 pool 用的是哪一種 pm：static 只能看 max listen queue（max children reached 在 static 下永遠是 0），dynamic 與 ondemand 兩欄都能看。max listen queue 長期大於 0 就該往上調，前提是記憶體容得下；長期是 0 代表還有餘裕。

停機與重載的訊號

PHP-FPM 的 master 依收到的訊號決定怎麼停或怎麼換掉 worker，PHP 原始碼附的 man page 列出四個：

「graceful」要等正在處理的請求多久，由另一個設定 process_control_timeout 決定：master 送出停止訊號之後，最多等 worker 這麼久。它的預設值是 0，也就是不等。一個請求要跑 3 秒，在它跑到第 1 秒時對 master 送 SIGUSR2：

1process_control_timeout = 0（預設）  →  502，在 1.07 秒時中斷
2process_control_timeout = 10         →  200，跑滿 3.0 秒才回應

SIGQUIT 一樣：預設值下 docker stop 一送出 PHP-FPM 就結束，進行中的請求拿到 502；設成 10 之後，docker stop 花了 2 秒，等那個請求做完。所以要讓 reload 與停機不中斷請求，process_control_timeout 要設成比最長的正常請求還長的秒數（它寫在設定檔的 [global] 段），而容器平台的停機逾時（docker stop -t、Kubernetes 的 terminationGracePeriodSeconds）要比它更長，否則平台會先強制終止。

設好之後，reload 只換 PHP 不動 Nginx。這跟 mod_php 的「改 PHP 設定要重載 Apache」是不同的隔離層級：PHP-FPM 是獨立的服務，重載 PHP 時 Nginx 的程序與它和客戶端之間的連線都不受影響。這也是 PHP 官方建議「用 PHP-FPM 取代 mod_php」的理由之一——PHP 能獨立於 web 伺服器重啟。

PHP-FPM 管的事情總覽

回到開頭那幾個「常駐程序帶出的問題」，PHP-FPM 的每一個旋鈕各對應一個：

這些旋鈕都是因為 worker 常駐才需要。worker 常駐同時讓一件事變得有意義：OPcache。程序活得夠久，編譯好的 opcode 才有機會被下一個請求重用，重用的程度在 OPcache 與程序壽命 實測。

如果連應用程式的狀態也想跨請求保留（框架只啟動一次），就要再往前走一步到常駐 worker 模型，那是另一組取捨，見 常駐 worker 模型。而把 Nginx 跟 PHP-FPM 放進容器時，兩個程序怎麼擺、要不要拆成兩個容器，見 容器裡的 Nginx 與 PHP-FPM。