PHP與webserver【簡書看到的】

好久之前，人們造出來一個機器人，它的英文名字叫web server，中文名叫網頁服務器。（爲了簡寫，下文稱web server爲server）

server的工做很簡單，就是作內容的分發。

初期的sever功能很簡單，只能處理靜態請求，當客戶端請求/index.html的時候，server去文件系統裏面找到對應的index.html文件，而後返回給客戶端，這個時期的server就像一個倉庫管理員，別人要啥，他給啥。

但是這樣的機器人很明顯不能知足人們的需求，由於sever機器人只能處理靜態請求，卻不能處理動態請求，如/index.php或者/index.java，這就好像它是服務員，只能端出作好的紅燒肉，卻不能本身作出紅燒肉。

爲了可以讓server機器人處理動態請求（作出紅燒肉），聰明的人類開始了他們的發明，因而他們在server機器人的肚子上挖出了一個長方形的洞，取名叫作接口，這個接口上只要插入製做紅燒肉的智能芯片，server機器就能作紅燒肉，插入製做烤魚的芯片，server機器就能作烤魚。

爲了體現專業性，人們給sever機器人肚子上面的洞，這個接口，取了一個高大上的名字，叫作CGI（全稱是是Command Gateway Interface，一般翻譯爲公共網關接口），經過這個接口，其餘的應用程序能夠與server機器人進行交互。

製做紅燒肉的芯片，叫作php解析器。

製做紅燒肉的芯片，叫作java解析器。

固然，與server進行交互的應用程序除了php解析器，java解析器，還有不少。

綜上，sever主要工做內容：

（1）處理靜態請求，當客戶端請求靜態文件的時候，如/a.html，web server會去文件系統中找到a.html這個文件，發送給瀏覽器。

（2）處理動態請求，當客戶端請求/a.php的時候，web server會根據本身的配置文件（http.conf或者nginx.conf）得知，該請求的是動態數據，因而web server須要把請求交給PHP解析器（php-cgi）來處理，webserver與php通訊須要遵循cgi接口定義的協議，將url地址，header消息頭，post/get數據等一系列內容按照必定的格式傳給php解析器（即php-cgi）處理，php解析器處理完成以後返回給web server,最後web server接到結果返回給客戶端。

 

好景不長，問題來了

CGI接口的出現，讓server可以處理動態請求，讓server的功能有另外一個飛躍。

天天，客戶端與server就這樣不斷的循環往復：

 

（1）客戶端發送請求給sever

（2）server接收請求和數據

（3）server會fork一個進程來啓動對應的CGI程序（這裏主要是php-cgi，PHP的解釋器是php-cgi）

（4）php-cgi會解析php.ini文件，初始化執行環境，並處理請求，解析CGI接口傳來的數據

（5）php-cgi以CGI接口規定的格式返回server處理後的結果

（6）server將結果返回客戶端。

但是，好景不長，一心追求完美的人類，發現了一個問題。

每次客戶端發起新的請求，server端都會fork一個進程出來啓動php-cgi，而php-cgi卻又每次都會進行一次初始化的工做（解析php.ini文件，初始化執行環境），人們以爲這樣的重複實在效率過低，不只很消耗時間，還很耗資源，因而想出來一個新的方案。

新的方案來臨，FASTCGI的誕生

FASTCGI和CGI同樣也是接口，是CGI的升級方案。

當server啓動的時候，fastcgi會先啓一個master進程（這裏是php-fpm，主要用來管理php-cgi），解析php.ini，初始化執行環境，而後再啓動多個worker（php-cgi）。當請求過來時，master會傳遞給一個worker（php-cgi），而後當即能夠接受下一個請求，同時，當worker不夠用時，master能夠根據配置預先啓動幾個worker等着；固然空閒worker太多時，也會停掉一些。

 

這種fastcgi對進程的管理，避免了重複的勞動，提升了性能，縮短了處理的時間，節省了資源，也就成爲了目前主流的通訊交互方式。