CGI的歷史

????早期的webserver只處理html等靜態(tài)文件，但是隨著技術(shù)的發(fā)展，出現(xiàn)了像php等動態(tài)語言。?

????webserver處理不了了，怎么辦呢？那就交給php解釋器來處理吧！?

????交給php解釋器處理很好，但是，php解釋器如何與webserver進行通信呢？

????為了解決不同的語言解釋器(如php、python解釋器)與webserver的通信，于是出現(xiàn)了cgi協(xié)議。只要你按照cgi協(xié)議去編寫程序，就能實現(xiàn)語言解釋器與webwerver的通信。如php-cgi程序。

FastCGI的改進

????有了cgi協(xié)議，解決了php解釋器與webserver通信的問題，webserver終于可以處理動態(tài)語言了。但是，webserver每收到一個請求，都會去fork一個cgi進程，請求結(jié)束再kill掉這個進程。這樣有10000個請求，就需要fork、kill php-cgi進程10000次。

????有沒有發(fā)現(xiàn)很浪費資源？

????于是，出現(xiàn)了cgi的改良版本，fast-cgi。fast-cgi每次處理完請求后，不會kill掉這個進程，而是保留這個進程，使這個進程可以一次處理多個請求。這樣每次就不用重新fork一個進程了，大大提高了效率。

PHP-FPM是什么

????????php-fpm即php-Fastcgi Process Manager.?

????????php-fpm是 FastCGI 的實現(xiàn)，并提供了進程管理的功能。?

????????進程包含 master 進程和 worker 進程兩種進程。?

????????master 進程只有一個，負(fù)責(zé)監(jiān)聽端口，接收來自 Web Server 的請求，而 worker 進程則一般有多個(具體數(shù)量根據(jù)實際需要配置)，每個進程內(nèi)部都嵌入了一個 PHP 解釋器，是 PHP 代碼真正執(zhí)行的地方。

FastCGI是什么？

????????FastCGI是語言無關(guān)的、可伸縮架構(gòu)的CGI開放擴展，其主要行為是將CGI解釋器進程保持在內(nèi)存中并因此獲得較高的性能。眾所周知，CGI解釋器的反復(fù)加載是CGI性能低下的主要原因，如果CGI解釋器保持在內(nèi)存中并接受FastCGI進程管理器調(diào)度，則可以提供良好的性能、伸縮性、Fail-Over特性等等。

????????FastCGI的官方站點在http://www.fastcgi.com

FastCGI的工作原理是

????????1、Web Server?啟動時載入FastCGI進程管理器（IIS ISAPI或Apache Module,nginx?下?fastcgi?與服務(wù)器是分離的，fastcgi?可有?lighttpd?下的spawan-cgi或者?php-fpm?來管理））;

????????2、FastCGI進程管理器自身初始化，啟動多個CGI解釋器進程?(在任務(wù)管理器中可見多個php-cgi.exe)并等待來自Web Server的連接。

????????3、當(dāng)客戶端請求到達Web Server時，FastCGI進程管理器選擇并連接到一個CGI解釋器。Web server將CGI環(huán)境變量和標(biāo)準(zhǔn)輸入發(fā)送到FastCGI子進程php-cgi.exe。

????????4、FastCGI子進程完成處理后將標(biāo)準(zhǔn)輸出和錯誤信息從同一連接返回Web Server。當(dāng)FastCGI子進程關(guān)閉連接時，請求便告處理完成。FastCGI子進程接著等待并處理來自FastCGI進程管理器（運行在WebServer中）的下一個連接。 在正常的CGI模式中，php-cgi.exe在此便退出了。

????????在上述情況中，你可以想象CGI通常有多慢。每一個Web請求PHP都必須重新解析php.ini、重新載入全部dll擴展并重初始化全部數(shù)據(jù)結(jié)構(gòu)。使用FastCGI，所有這些都只在進程啟動時發(fā)生一次。一個額外的好處是，持續(xù)數(shù)據(jù)庫連接(Persistent database connection)可以工作。

總結(jié)

????????nginx與php-fpm的結(jié)合，完整的流程是這樣的：

為什么要使用FastCGI，而不是多線程CGI解釋器？

????????這可能出于多方面的考慮，例如：

????????1、你無論如何也不能在windows平臺上穩(wěn)定的使用多線程CGI解釋器，無論是IIS ISAPI方式還是APACHE Module方式，它們總是運行一段時間就崩潰了。奇怪么？但是確實存在這樣的情況！當(dāng)然，也有很多時候你能夠穩(wěn)定的使用多線程CGI解釋器，但是，你有可能發(fā)現(xiàn)網(wǎng)頁有時候會出現(xiàn)錯誤，無論如何也找不到原因，而換用FastCGI方式時這種錯誤的概率會大大的降低。我也不清楚這是為什么，我想獨立地址空間的CGI解釋器可能終究比共享地址空間的形式來得穩(wěn)定一點點。

????????2、性能！性能？可能么，難道FastCGI比多線程CGI解釋器更快？但有時候確實是這樣，只有測試一下你的網(wǎng)站，才能最后下結(jié)論。原因嘛，我覺得很難講，但有資料說在Zend WinEnabler的時代，Zend原來也是建議在Windows平臺下使用FastCGI而不是IIS ISAPI或Apache Module，不過現(xiàn)在Zend已經(jīng)不做這個產(chǎn)品了。

FastCGI的技術(shù)原理

????????如果想了解FastCGI的技術(shù)原理就要了解何為”短生存期應(yīng)用程序”,何為”長生存期應(yīng)用程序”。

????????先從CGI技術(shù)開刀，以下是CGI技術(shù)的理論：每次當(dāng)客戶請求一個CGI的時候，Web服務(wù)器就請求操作系統(tǒng)生成一個新的CGI進程。當(dāng)CGI滿足要求后，服務(wù)器就殺死這個進程。服務(wù)器對客戶端的每個請求都要重復(fù)這樣的過程。

????????而FastCGI技術(shù)的理論為：FastCGI程序一旦產(chǎn)生后，他可以持續(xù)工作,足夠滿足客戶的請求直到被明確的終止。如果你希望通過協(xié)同處理來提高程序的性能，你可以請求Web服務(wù)器運行多個FastCGI?應(yīng)用程序的副本。

????????CGI就是所謂的短生存期應(yīng)用程序，FastCGI就是所謂的長生存期應(yīng)用程序。

????????由于FastCGI程序并不需要不斷的產(chǎn)生新進程，可以大大降低服務(wù)器的壓力。并且產(chǎn)生較高的應(yīng)用效率。

????????自今，較為流行的Java語言Servlet技術(shù)在設(shè)計上是以參考FastCGI的技術(shù)運行所設(shè)計。

FastCGI的特點

????????1.?打破傳統(tǒng)頁面處理技術(shù)

????????????????傳統(tǒng)的頁面處理技術(shù)，程序必須與Web服務(wù)器或Application服務(wù)器處于同一臺服務(wù)器中。這種歷史已經(jīng)早N年被FastCGI技術(shù)所打破，?FastCGI技術(shù)的應(yīng)用程序可以被安裝在服務(wù)器群中的任何一臺服務(wù)器，而通過TCP/IP協(xié)議與Web服務(wù)器通訊，這樣做既適合開發(fā)大型分布式Web?群，也適合高效數(shù)據(jù)庫控制。

????????2.?明確的請求模式

????????????????CGI技術(shù)沒有一個明確的角色，在FastCGI程序中，程序被賦予明確的角色（響應(yīng)器角色、認(rèn)證器角色、過濾器角色）。

????????3.?合理的程序結(jié)構(gòu)

????????????????起初，真的很討厭FastCGI應(yīng)用程序的結(jié)構(gòu)要求。沒關(guān)系，您經(jīng)過一段時間編寫后就會喜歡這種結(jié)構(gòu)，只有這種完全規(guī)范的結(jié)構(gòu)才能讓您的程序更有效率。

轉(zhuǎn)載于:https://www.cnblogs.com/mjhblog/p/11527857.html

總結(jié)

以上是生活随笔為你收集整理的Fast CGI 工作原理的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。