PHP 接收到請求的原因

這篇文章將為大家詳細講解有關PHP 接收到請求的原因，文章內容質量較高，因此小編分享給大家做個參考，希望大家閱讀完這篇文章后對相關知識有一定的了解。

本篇文章主要描述一下幾點

● nginx 怎么轉發請求 給 PHPFPM?

● CGI 和 FastCGI 到底是個什么玩意？

● PHPFPM 是什么？有什么作用？

簡單場景描述

在瀏覽器上訪問一個 php+nginx+mysql 構建的商城，并且購買一件商品。

分析 （這里訪問的有兩種資源）

● 靜態資源（網站的一些圖片，圖標等）

● 動態資源 （購買商品的價格，商品的簡介等）

瀏覽器發起請求 --> web_server（nginx）分發處理 --> php 執行代碼返回結果 （這是大概的流程）

nginx 是怎么分發請求？

當用戶發起請求的時候 (瀏覽器默認請求 80 端口)，nginx 監聽到 80 端口，通過 nginx 配置正則匹配是否屬于靜態資源，如果是靜態資源則返回文件，請求結束。如果是動態資源，通過 正則匹配到請求 php 腳本，那么他會通過 nginx 的模塊 ngx_http_fastcgi_module 把請求分發給 PHPFPM 處理，然后處理完畢返回結果。

● CGI

CGI 是 Web 服務器運行外部程序的規范。意思就是通過 CGI 可以與你的程序通信，通過 CGI 標準格式。你的程序可以和瀏覽器交互。

（簡單理解 CGI 就是一個協議，規定了一些東西該怎么傳，你的程序這邊怎么接受處理等規范。）

● PHP-CGI

PHP-CGI 就是 CGI 協議 php 的一個實現版。PHP-CGI 會為每個請求 fork 一個進程處理，處理完成后退出。(這個模式叫做 fork-and-execute)。這樣的模式不符合現在動不動大規模的流量，所以已退出歷史舞臺。

● FastCGI

FastCGI 是 CGI 的升級版，他會預先啟動一個 master 進程讀取配置文件，然后 fork 多個 work 進程等待連接。監聽到請求，分配個 work 進程做具體的處理。這樣大大提高了程序的性能。（FastCGi 會管理進程，處理完成后不會輕易銷毀。而 CGI 會為每一個請求 創建進程，銷毀進程。）

● PHPFPM

作為世界上最好的語言，當然要跟上潮流。當發現 PHP-CGI 性能不佳時，又恰好出現了 FastCGI 協議。所以 PHP 實現了一個 php 版本的 FastCGI，名字叫做 PHPFPM（FastCGI Process Manager）。 PHPFPM 啟動時會開啟 一個 master 進程和若干個 work 進程。master 進程監聽請求，并轉發給 work 進程處理，每一個 work 進程都有一個 php 解釋器，你的代碼在每一個 work 進程中都有一份，work 進程是真正執行代碼的地方。

SO

PHPFPM 監聽 9000 端口，nginx 匹配到 php 文件，把請求轉發給 PHPFPM。PHPFPM master 監聽到請求后，分配給 work 處理（每一個 work 進程中都有一個 php 解釋器），PHPFPM 在啟動的時候就已經 work 進程已經加載了配置，加載了你寫代碼。所以說 work 進程收到請求后立馬執行，然后返回結果。

ngx_http_fastcgi_module 模塊

在瀏覽器請求 web_server 是 http 協議 或者 https 協議，但是 PHPFPM 不懂怎么辦了？這里 nginx 提供了一個 ngx_http_fastcgi_module ，ngx_http_fastcgi_module 把 http 或者 https 請求 映射成 FastCGI 請求。這樣 php 程序就能和用戶互動了。

純個人理解，如果有誤請指出。

關于PHP 接收到請求的原因就分享到這里了，希望以上內容可以對大家有一定的幫助，可以學到更多知識。如果覺得文章不錯，可以把它分享出去讓更多的人看到。