深入剖析 Web 伺服器與 PHP 應用之間的通訊機制 - 掌握 CGI 和 FastCGI 協議的執行原理
本文首發於 深入剖析 Web 伺服器與 PHP 應用之間的通訊機制 - 掌握 CGI 和 FastCGI 協議的執行原理，轉載請註明出處！
身為一名使用 PHP 語言開發後端服務的程式猿，我們每天都和 PHP 以及 Web 伺服器產生無數次的親密接觸。得益於它們，我們才能夠如此快速的構建出令人陶醉的 Web 產品。
儘管我們已經和 Web 伺服器和 PHP 建立起深厚的友誼，但你知道它們之間為何能夠配合的如此默契麼？
這一切都需要從 CGI（Common Gateway Interface：通用閘道器介面）協議說起。但是請不要對 CGI 協議產生任何的恐懼心理，它並非什麼特別複雜的協議，如果你對它不甚瞭解，可能的原因或許是你還有花一點小心思來學習它。
所以，你應該明白，現在你應該抽出 20 多分鐘仔細的研究一下： Web 伺服器與 PHP 應用之間是如何進行通訊的這個問題。
介紹
我們知道 PHP 自 5.4 起為我們內建的 Web 伺服器。不過在此之前的版本（或者不使用這個內建伺服器時），我們就需要使用其他的 Web 伺服器，通常是 Nginx 或者 Apache 這兩塊 Web 伺服器，來部署我們的 PHP 應用。
這就涉及一個問題，當用戶發起一個 HTTP 請求後，我們的 PHP 應用程式在處理這個請求時並沒有直接的解析這個 HTTP 協議，而是可以直接從 \$_GET、\$_POST 和 \$_SERVER
要想整明白這個問題，我們就不得不需要整明白一個問題：CGI 協議。
CGI 協議同 HTTP 協議一樣是一個「應用層」協議，它的 功能 是為了解決 Web 伺服器與 PHP 應用（或其他 Web 應用）之間的通訊問題。
既然它是一個「協議」，換言之它與語言無關，即只要是實現類 CGI 協議的應用就能夠實現相互的通訊。
深入 CGI 協議
我們已經知道了 CGI 協議是為了完成 Web 伺服器和應用之間進行資料通訊這個問題。那麼，這一節我們就來看看究竟它們之間是如何進行通訊的。
簡單來講 CGI 協議它描述了 Web 伺服器和應用程式之間進行資料傳輸的格式，並且只要我們的程式語言支援標準輸入（STDIN）、標準輸出（STDOUT）以及環境變數等處理，你就可以使用它來編寫一個 CGI 程式。
CGI 的執行原理
- 當用戶訪問我們的 Web 應用時，會發起一個 HTTP 請求。最終 Web 伺服器接收到這個請求。
- Web 伺服器建立一個新的 CGI 程序。在這個程序中，將 HTTP 請求資料已一定格式解析出來，並通過標準輸入和環境變數傳入到 URL 指定的 CGI 程式（PHP 應用 $_SERVER）。
- Web 應用程式處理完成後將返回資料寫入到標準輸出中，Web 伺服器程序則從標準輸出流中讀取到響應，並採用 HTTP 協議返回給使用者響應。
一句話就是 Web 伺服器中的 CGI 程序將接收到的 HTTP 請求資料讀取到環境變數中，通過標準輸入轉發給 PHP 的 CGI 程式；當 PHP 程式處理完成後，Web 伺服器中的 CGI 程序從標準輸出中讀取返回資料，並轉換回 HTTP 響應訊息格式，最終將頁面呈獻給使用者。然後 Web 伺服器關閉掉這個 CGI 程序。
可以說 CGI 協議特別擅長處理 Web 伺服器和 Web 應用的通訊問題。然而，它有一個嚴重缺陷，對於每個請求都需要重新 fork 出一個 CGI 程序，處理完成後立即關閉。
CGI 協議的缺陷
- 每次處理使用者請求，都需要重新 fork CGI 子程序、銷燬 CGI 子程序。
- 一系列的 I/O 開銷降低了網路的吞吐量，造成了資源的浪費，在大併發時會產生嚴重的效能問題。
深入 FastCGI 協議
從功能上來講，CGI 協議已經完全能夠解決 Web 伺服器與 Web 應用之間的資料通訊問題。但是由於每個請求都需要重新 fork 出 CGI 子程序導致效能堪憂，所以基於 CGI 協議的基礎上做了改進便有了 FastCGI 協議，它是一種常駐型的 CGI 協議。
本質上來將 FastCGI 和 CGI 協議幾乎完全一樣，它們都可以從 Web 伺服器裡接收到相同的資料，不同之處在於採取了不同的通訊方式。
再來回顧一下 CGI 協議每次接收到 HTTP 請求時，都需要經歷 fork 出 CGI 子程序、執行處理並銷燬 CGI 子程序這一系列工作。
而 FastCGI 協議採用 程序間通訊（IPC） 來處理使用者的請求，下面我們就來看看它的執行原理。
FastCGI 協議執行原理
- FastCGI 程序管理器啟動時會建立一個 主（Master） 程序和多個 CGI 直譯器程序（Worker 程序），然後等待 Web 伺服器的連線。
- Web 伺服器接收 HTTP 請求後，將 CGI 報文通過 套接字（UNIX 或 TCP Socket）進行通訊，將環境變數和請求資料寫入標準輸入,轉發到 CGI 直譯器程序。
- CGI 直譯器程序完成處理後將標準輸出和錯誤資訊從同一連線返回給 Web 伺服器。
- CGI 直譯器程序等待下一個 HTTP 請求的到來。
為什麼是 FastCGI 而非 CGI 協議
如果僅僅因為工作模式的不同，似乎並沒有什麼大不了的。並沒到非要選擇 FastCGI 協議不可的地步。
然而，對於這個看似微小的差異，但意義非凡，最終的結果是實現出來的 Web 應用架構上的差異。
CGI 與 FastCGI 架構
在 CGI 協議中，Web 應用的生命週期完全依賴於 HTTP 請求的宣告週期。
對每個接收到的 HTTP 請求，都需要重啟一個 CGI 程序來進行處理，處理完成後必須關閉 CGI 程序，才能達到通知 Web 伺服器本次 HTTP 請求處理完成的目的。
但是在 FastCGI 中完全不一樣。
FastCGI 程序是常駐型的，一旦啟動就可以處理所有的 HTTP 請求，而無需直接退出。
再看 FastCGI 協議
通過前面的講解，我們相比已經可以很準確的說出來 FastCGI 是一種通訊協議 這樣的結論。現在，我們就將關注的焦點挪到協議本身，來看看這個協議的定義。
同 HTTP 協議一樣，FastCGI 協議也是有訊息頭和訊息體組成。
訊息頭資訊
主要的訊息頭資訊如下：
- Version：用於表示 FastCGI 協議版本號。
- Type：用於標識 FastCGI 訊息的型別 - 用於指定處理這個訊息的方法。
- RequestID：標識出當前所屬的 FastCGI 請求。
- Content Length: 資料包包體所佔位元組數。
訊息型別定義
- BEGIN_REQUEST：從 Web 伺服器傳送到 Web 應用，表示開始處理新的請求。
- ABORT_REQUEST：從 Web 伺服器傳送到 Web 應用，表示中止一個處理中的請求。比如，使用者在瀏覽器發起請求後按下瀏覽器上的「停止按鈕」時，會觸發這個訊息。
- END_REQUEST：從 Web 應用傳送給 Web 伺服器，表示該請求處理完成。返回資料包裡包含「返回的程式碼」，它決定請求是否成功處理。
- PARAMS：「流資料包」，從 Web 伺服器傳送到 Web 應用。此時可以傳送多個數據包。傳送結束標識為從 Web 伺服器發出一個長度為 0 的空包。且 PARAMS 中的資料型別和 CGI 協議一致。即我們使用 \$_SERVER 獲取到的系統環境等。
- STDIN：「流資料包」，用於 Web 應用從標準輸入中讀取出使用者提交的 POST 資料。
- STDOUT：「流資料報」，從 Web 應用寫入到標準輸出中，包含返回給使用者的資料。
Web 伺服器和 FastCGI 互動過程
- Web 伺服器接收使用者請求，但最終處理請求由 Web 應用完成。此時，Web 伺服器嘗試通過套接字（UNIX 或 TCP 套接字，具體使用哪個由 Web 伺服器配置決定）連線到 FastCGI 程序。
- FastCGI 程序檢視接收到的連線。選擇「接收」或「拒絕」連線。如果是「接收」連線，則從標準輸入流中讀取資料包。
- 如果 FastCGI 程序在指定時間內沒有成功接收到連線，則該請求失敗。否則，Web 伺服器傳送一個包含唯一的 RequestID 的 BEGIN_REQUEST 型別訊息給到 FastCGI 程序。後續所有資料包傳送都包含這個 RequestID。
然後，Web 伺服器傳送任意數量的 PARAMS 型別訊息到 FastCGI 程序。一旦傳送完畢，Web 伺服器通過傳送一個空 PARAMS 訊息包，然後關閉這個流。
另外，如果使用者傳送了 POST 資料 Web 伺服器會將其寫入到 標準輸入（STDIN） 傳送給 FastCGI 程序。當所有 POST 資料傳送完成，會發送一個空的 標準輸入（STDIN） 來關閉這個流。 - 同時，FastCGI 程序接收到 BEGIN_REQUEST 型別資料包。它可以通過響應 END_REQUEST來拒絕這個請求。或者接收並處理這個請求。如果接收請求，FastCGI 程序會等待接收所有的 PARAMS 和 標準輸入資料包。
然後，在處理請求並將返回結果寫入 標準輸出（STDOUT） 流。處理完成後，傳送一個空的資料包到標準輸出來關閉這個流，並且會發送一個 END_REQUEST 型別訊息通知 Web 伺服器，告知它是否發生錯誤異常。
為什麼需要在訊息頭髮送 RequestID 這個標識？
如果是每個連線僅處理一個請求，傳送 RequestID 則略顯多餘。
但是我們的 Web 伺服器和 FastCGI 程序之間的連線可能處理多個請求，即一個連線可以處理多個請求。所以才需要採用資料包協議而不是直接使用單個數據流的原因：以實現「多路複用」。
因此，由於每個資料包都包含唯一的 RequestID，所以 Web 伺服器才能在一個連線上傳送任意數量的請求，並且 FastCGI 程序也能夠從一個連線上接收到任意數量的請求資料包。
另外我們還需要明確一點就是 Web 伺服器 與 FastCGI 程序間通訊是 無序的。即使我們在互動過程中看起來一個請求是有序的，但是我們的 Web 伺服器也有可能在同一時間發出幾十個 BEGIN_REQUEST 型別的資料包，以此類推。
PHP-FPM
其實講解完 CGI 和 FastCGI 協議，基本上我們就已經研究完 「Web 伺服器與 PHP 應用之間的通訊機制」這個問題了。但是對於我們 PHP 軟體工程師來講，可能還會遇到「什麼是 PHP-FPM」及其相關問題。這裡我們一併來稍微講解一下。
PHP-FPM 是 FastCGI 程序管理器（PHP FastCGI Process Manager），用於替換 PHP 核心的 FastCGI 的大部分附加功能（或者說一種替代的 PHP FastCGI 實現），對於高負載網站是非常有用的。
下面是官網中獲取到的它所支援的特性：
- 支援平滑停止 / 啟動的高階程序管理功能；
- 可以工作於不同的 uid/gid/chroot 環境下，並監聽不同的埠和使用不同的 php.ini 配置檔案（可取代 safe_mode 的設定）；
- stdout 和 stderr 日誌記錄；
- 在發生意外情況的時候能夠重新啟動並快取被破壞的 opcode；
- 檔案上傳優化支援；
- "慢日誌" - 記錄指令碼（不僅記錄檔名，還記錄 PHP backtrace 資訊，可以使用 ptrace 或者類似工具讀取和分析遠端程序的執行資料）執行所導致的異常緩慢；
- fastcgi_finish_request() - 特殊功能：用於在請求完成和重新整理資料後，繼續在後臺執行耗時的工作（錄入視訊轉換、統計處理等）；
- 動態／靜態子程序產生；
- 基本 SAPI 執行狀態資訊（類似 Apache 的 mod_status）；
- 基於 php.ini 的配置檔案。
那麼 PHP-FPM 是如何工作的呢？
PHP-FPM 程序管理器有兩種程序組成，一個 Master 程序和多個 Worker 程序。Master 程序負責監聽埠，接收來自 Web 伺服器的請求，然後指派具體的 Worker 程序處理請求；worker 程序則一般有多個 (依據配置決定程序數)，每個程序內部都嵌入了一個 PHP 直譯器，用來執行 PHP 程式碼。
Nginx 伺服器如何與 FastCGI 協同工作
Nginx 伺服器無法直接與 FastCGI 伺服器進行通訊，需要啟用 ngx_http_fastcgi_module 模組進行代理配置，才能將請求傳送給 FastCGI 服務。
其中，包括我們熟知的配置指令：
- fastcgi_pass 用於設定 FastCGI 伺服器的 IP 地址（TCT 套接字）或 UNIX 套接字。
- fastcgi_param 設定傳入 FastCGI 伺服器的引數。
你可以到 PHP FastCGI 例項教程 學習一些基本使用。
總結
到這裡我們基本就學習完 CGI、FastCGI、PHP-FPM以及 Nginx 伺服器與 FastCGI 服務通訊原理。一句話：
CGI 和 FastCGI 是一種協議和 HTTP 協議一樣位於應用層，與語言無關；PHP-FPM 是一種 FastCGI 協議的實現，能夠管理 FastCGI 程序。
擴充套件閱讀
- https://blog.cuiyongjian.com/fe/tencent-cgi/
- https://zhuanlan.zhihu.com/p/20694204
- https://stackoverflow.com/questions/2089271/what-is-common-gateway-interface-cgi
- https://paper.seebug.org/289/
- https://blog.csdn.net/shreck66/article/details/50355729
- http://www.phppan.com/2011/05/php-cgi/
- https://github.com/pangudashu/php7-internal/blob/master/1/fpm.md
- https://github.com/YuanLianDu/YLD-with-Php/blob/master/articles/php/php-fpm.md
- http://blog.51cto.com/13581826/2093473
- http://haiyangxu.github.io/posts/2014/2014-05-11-How_web_works_HTTP_and_CGI.html
- https://www.cnblogs.com/xueweihan/p/5319893.html
- https://www.zybuluo.com/phper/note/50231
- https://www.awaimai.com/371.html
- http://tiankonguse.com/blog/?p=896
- https://www.digitalocean.com/community/tutorials/understanding-and-implementing-fastcgi-proxying-in-nginx
- http://www.whizkidtech.redprince.net/cgi-bin/tutorial
- https://fastcgi-archives.github.io/FastCGI_FAQ.html
- http://php.net/manual/zh/install.unix.commandline.php
- http://php.net/manual/zh/reserved.variables.server.php
- http://www.php-internals.com/book/?p=chapt02/02-02-03-fastcgi
- https://www.yanxurui.cc/posts/server/2017-01-04-write-a-cgi-program-in-c-language/