您現在的位置: 365建站網 > 365學習 > CGI、FastCGI和PHP-FPM關系圖解概念和區別

CGI、FastCGI和PHP-FPM關系圖解概念和區別

文章來源:365jz.com     點擊數:413    更新時間:2018-07-25 10:13   參與評論

在搭建 LAMP/LNMP 服務器時,會經常遇到 PHP-FPM、FastCGI和CGI 這幾個概念。如果對它們一知半解,很難搭建出高性能的服務器。接下來我們就以圖形方式,解釋這些概念之間的關系。

基礎

在整個網站架構中,Web Server(如Apache)只是內容的分發者。舉個栗子,如果客戶端請求的是 index.HTML,那么Web Server會去文件系統中找到這個文件,發送給瀏覽器,這里分發的是靜態數據。

如果請求的是 index.php,根據配置文件,Web Server知道這個不是靜態文件,需要去找 PHP 解析器來處理,那么他會把這個請求簡單處理,然后交給PHP解析器。

當Web Server收到 index.php 這個請求后,會啟動對應的 CGI 程序,這里就是PHP的解析器。接下來PHP解析器會解析php.ini文件,初始化執行環境,然后處理請求,再以規定CGI規定的格式返回處理后的結果,退出進程,Web server再把結果返回給瀏覽器。這就是一個完整的動態PHP Web訪問流程,接下來再引出這些概念,就好理解多了,

  • CGI:是 Web Server 與 Web Application 之間數據交換的一種協議。

  • FastCGI:同 CGI,是一種通信協議,但比 CGI 在效率上做了一些優化。同樣,SCGI 協議與 FastCGI 類似。

  • PHP-CGI:是 PHP (Web Application)對 Web Server 提供的 CGI 協議的接口程序。

  • PHP-FPM:是 PHP(Web Application)對 Web Server 提供的 FastCGI 協議的接口程序,額外還提供了相對智能一些任務管理。

WEB 中,

  • Web Server 一般指Apache、Nginx、IIS、Lighttpd、Tomcat等服務器,

  • Web Application 一般指PHP、Java、Asp.net等應用程序。

Module方式

在了解 CGI 之前,我們先了解一下Web server 傳遞數據的另外一種方法:PHP Module加載方式。以 Apache 為例,在PHP Module方式中,是不是在 Apache 的配置文件 httpd.conf 中加上這樣幾句:

# 加入以下2句LoadModule php5_module D:/php/php5apache2_2.dllAddType application/x-httpd-php .php# 修改如下內容<IfModule dir_module>
    DirectoryIndex index.php index.html</IfModule>

上面是 Windows 下安裝php和apache環境后手動配置,在linux下源碼安裝大致是這樣配置的:

# ./configure --with-mySQL=/usr/local --with-apache=/usr/local/apache --enable-track-vars

所以,這種方式,他們的共同本質都是用 LoadModule 來加載 php5_module,就是把php作為apache的一個子模塊來運行。當通過web訪問php文件時,apache就會調用php5_module來解析php代碼。

那么php5_module是怎么來將數據傳給php解析器來解析php代碼的呢?答案是通過sapi。

我們再來看一張圖,詳細的說說apache 與 php 與 sapi的關系:

mode_php

從上面圖中,我們看出了sapi就是這樣的一個中間過程,SAPI提供了一個和外部通信的接口,有點類似于socket,使得PHP可以和其他應用進行交互數據(apache,nginx等)。php默認提供了很多種SAPI,常見的提供給apache和nginx的php5_module、CGI、FastCGI,給IIS的ISAPI,以及Shell的CLI。

所以,以上的apache調用php執行的過程如下:

apache -> httpd -> php5_module -> sapi -> php

好了。apache與php通過php5_module的方式就搞清楚了吧!

這種模式將php模塊安裝到apache中,所以每一次apache結束請求,都會產生一條進程,這個進程就完整的包括php的各種運算計算等操作。

在上圖中,我們很清晰的可以看到,apache每接收一個請求,都會產生一個進程來連接php通過sapi來完成請求,可想而知,如果一旦用戶過多,并發數過多,服務器就會承受不住了。

而且,把mod_php編進apache時,出問題時很難定位是php的問題還是apache的問題。

CGI

CGI(Common Gateway Interface)全稱是“通用網關接口”,WEB 服務器與PHP應用進行“交談”的一種工具,其程序須運行在網絡服務器上。CGI可以用任何一種語言編寫,只要這種語言具有標準輸入、輸出和環境變量。如php、perl、tcl等。

WEB服務器會傳哪些數據給PHP解析器呢?URL、查詢字符串、POST數據、HTTP header都會有。所以,CGI就是規定要傳哪些數據,以什么樣的格式傳遞給后方處理這個請求的協議。仔細想想,你在PHP代碼中使用的用戶從哪里來的。

也就是說,CGI就是專門用來和 web 服務器打交道的。web服務器收到用戶請求,就會把請求提交給cgi程序(如php-cgi),cgi程序根據請求提交的參數作應處理(解析php),然后輸出標準的html語句,返回給web服服務器,WEB服務器再返回給客戶端,這就是普通cgi的工作原理。

CGI的好處就是完全獨立于任何服務器,僅僅是做為中間分子。提供接口給apache和php。他們通過cgi搭線來完成數據傳遞。這樣做的好處了盡量減少2個的關聯,使他們2變得更獨立。

但是CGI有個蛋疼的地方,就是每一次web請求都會有啟動和退出過程,也就是最為人詬病的fork-and-execute模式,這樣一在大規模并發下,就死翹翹了。

FastCGI介紹

FastCGI簡單介紹

從根本上來說,FastCGI是用來提高CGI程序性能的。類似于CGI,FastCGI也可以說是一種協議。

FastCGI像是一個常駐(long-live)型的CGI,它可以一直執行著,只要激活后,不會每次都要花費時間去fork一次。它還支持分布式的運算, 即 FastCGI 程序可以在網站服務器以外的主機上執行,并且接受來自其它網站服務器來的請求。

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

FastCGI的工作原理

FastCGI接口方式采用C/S結構,可以將HTTP服務器和腳本解析服務器分開,同時在腳本解析服務器上啟動一個或者多個腳本解析守護進程。當HTTP服務器每次遇到動態程序時,可以將其直接交付給FastCGI進程來執行,然后將得到的結果返回給瀏覽器。這種方式可以讓HTTP服務器專一地處理靜態請求,或者將動態腳本服務器的結果返回給客戶端,這在很大程度上提高了整個應用系統的性能。

fastcgi

  1. Web Server啟動時載入FastCGI進程管理器(Apache Module或IIS ISAPI等)

  2. FastCGI進程管理器自身初始化,啟動多個CGI解釋器進程(可建多個php-cgi),并等待來自Web Server的連接。

  3. 當客戶端請求到達Web Server時,FastCGI進程管理器選擇并連接到一個CGI解釋器。Web server將CGI環境變量和標準輸入發送到FastCGI子進程php-cgi。

  4. FastCGI子進程完成處理后,將標準輸出和錯誤信息從同一連接返回Web Server。當FastCGI子進程關閉連接時,請求便告處理完成。FastCGI子進程接著等待,并處理來自FastCGI進程管理器(運行在Web Server中)的下一個連接。 在CGI模式中,php-cgi在此便退出了。

FastCGI與CGI特點:

  1. 對于CGI來說,每一個Web請求PHP都必須重新解析php.ini、重新載入全部擴展,并重新初始化全部數據結構。而使用FastCGI,所有這些都只在進程啟動時發生一次。一個額外的好處是,持續數據庫連接(Persistent database connection)可以工作。

  2. 由于FastCGI是多進程,所以比CGI多線程消耗更多的服務器內存,php-cgi解釋器每進程消耗7至25兆內存,將這個數字乘以50或100就是很大的內存數。

PHP-FPM介紹

要了解PHP-FPM,就得先說說PHP-CGI。

PHP-CGI就是PHP實現的自帶的FastCGI管理器。 雖然是php官方出品,但是這丫的卻一點也不給力,性能太差,而且也很麻煩不人性化,主要體現在:

  1. php-cgi變更php.ini配置后,需重啟php-cgi才能讓新的php-ini生效,不可以平滑重啟。

  2. 直接殺死php-cgi進程,php就不能運行了。

上面2個問題,一直讓很多人病垢了很久,所以很多人一直還是在用 Module 方式。 直到 2004年一個叫 Andrei Nigmatulin的屌絲發明了PHP-FPM ,這神器的出現就徹底打破了這種局面,這是一個PHP專用的 fastcgi 管理器,它很爽的克服了上面2個問題,而且,還表現在其他方面更表現強勁。

也就是說,PHP-FPM 是對于 FastCGI 協議的具體實現,他負責管理一個進程池,來處理來自Web服務器的請求。目前,PHP5.3版本之后,PHP-FPM是內置于PHP的。

因為PHP-CGI只是個CGI程序,他自己本身只能解析請求,返回結果,不會進程管理。所以就出現了一些能夠調度 php-cgi 進程的程序,比如說由lighthttpd分離出來的spawn-fcgi。同樣,PHP-FPM也是用于調度管理PHP解析器php-cgi的管理程序。

PHP-FPM通過生成新的子進程可以實現php.ini修改后的平滑重啟。

總結

最后,我們來總結一下,這些技術經過不斷的升級,可以解決什么問題(不然也不會升級嘛)。

所以,如果要搭建一個高性能的PHP WEB服務器,目前最佳的方式是Apache/Nginx + FastCGI + PHP-FPM(+PHP-CGI)方式了,不要再使用 Module加載或者 CGI 方式啦:)

總結:

CGI、FastCGI和php-fpm的概念和區別

CGI是HTTP Server和一個獨立的進程之間的協議,把HTTP Request的Header設置成進程的環境變量,HTTP Request的正文設置成進程的標準輸入,而進程的標準輸出就是HTTP Response包括Header和正文。

FASTCGI是和HTTP協議類似的概念。無非就是規定了在同一個TCP連接里怎么同時傳多個HTTP連接。這實際上導致了個問題,有個HTTP連接傳個大文件不肯讓出FASTCGI連接,在同一個FASTCGI連接里的其他HTTP連接就傻了。所以Lighttpd? 引入了 X-SENDFILE 。

php-fpm就相當于是Apache+mod_php。無非php-fpm自帶了FASTCGI Server,而Apache是HTTP Server。

那個WSGI和這個問題沒啥關系吧。WSGI這個只是Python內部的一個接口。無論你前面是FASTCGI,HTTP,SCGI,uWSGI等協議,你的FASTCGI/HTTP/SCGI/uWSGI Server都以相同的參數格式去調用一個函數,這樣你用Python寫的Web應用并不需要修改代碼,就可以運行在不同的Server后面了。無非CGI協議是進程間的,而WSGI是進程內的。

 

1. 一般web服務器接受到瀏覽器的請求時,如果是靜態資源的話就直接將其返回給瀏覽器,如果是動態資源的話那就沒有現成的資源返回了,那這個時候cgi就出場了

2. cgi可以理解為一種協議or一類處理程序,就是動態去生成文件,從程序上來理解就是web服務器exec這樣一個進程,然后交給他一些輸入參數,他就慢慢的處理完后把結果返回給web服務器,那從協議層面來說cgi協議就是規范了web服務器和cgi程序的一些輸入輸出參數的含義

3.所以可以有很多不同的cgi程序,別可以執行php腳本的or可以執行python腳本的,只要符合這類規范就能供web服務器調用,當然它的缺點就是每次都需要去啟動這個cgi程序,這會使得處理速度很慢

4.針對這種缺陷加以改進就成了fastcgi,同樣的他也可以理解為一種協議or一個程序,它跟cgi的不同就是不需要每次去exec,它會事先啟動起來,作為一個cgi的管理服務器存在,預先啟動一系列的子進程來等待處理,然后等待web服務器發過來的請求,一旦接受到請求就交由子進程處理,這樣由于不需要在接受到請求后啟動cgi,會快很多。

5.phpfpm是php對fastcgi的一種具體實現,它的啟動后會創建多個cgi子進程,然后主進程負責管理子進程,同時它對外提供一個socket,那web服務器當要轉發一個動態請求時只需要按照fastcgi協議要求的格式將數據發往這個socket的就可以了,那phpfpm創建的子進程去爭搶這個socket連接,誰搶到了誰處理并將結果返回給web服務器,那phpfpm主進程干什么了?比方說其中一個子進程異常退出了怎么辦,那phpfpm會去監控他一旦發現一個cgi子進程就會又啟動一個,還有其他諸多管理功能

6 phpfpm作為一個獨立的進程存在 通過socket與nginx建立連接,而mod_php 是作為一個模塊被加載進了apache服務器,同時他們兩作為cgi調度管理器,他們對其管理的方式也不一樣

通俗的可以把服務器看作餐廳,用戶請求看作來用餐的顧客,服務器處理請求看作解決顧客的就餐問題(響應輸出一份飯)。

服務器上靜態資源看作已做好的飯,只要放到餐盒里就可以返回給顧客,動態資源需要廚房大廚現成做份再放到餐盒里返回給顧客。

php_mod這個大廚有個特點,看見有顧客進門就點火,不管顧客要不要現做的,有點浪費資源

php_fpm這個大廚有好多小弟一直點著火(多個處理進程),等有顧客說要現做,大廚就安排小弟做份返回給客戶

cgi也是個大廚,不過他等到顧客要現做,他才點火,做飯,然后熄火。等待下一個要現做的到來

fastcgi呢就是個大廚雇了一幫小弟,專門做需要現場做的飯,大廚只管分派任務,小弟真正操鍋做飯


如對本文有疑問,請提交到交流論壇,廣大熱心網友會為你解答??! 點擊進入論壇


發表評論 (413人查看,0條評論)
請自覺遵守互聯網相關的政策法規,嚴禁發布色情、暴力、反動的言論。
用戶名: 驗證碼: 點擊我更換圖片
最新評論
------分隔線----------------------------
自拍偷拍福力视频,偷拍国际精品,麻豆一区福利电影,国产网红视频午夜福利,se视频大全,久久国产AV影院 男朋友说让我舒服上天| 在线观看国产成人av天堂| 邻居三个老汉一起弄我| 杂乱小说1第403部分| 无码国产成人午夜电影在线观看| 成为人视频免费视频免费观看| 大香伊蕉在人线免费视频| 亚洲av女人的天堂在线观看| 性欧美牲交xxxxx视频| 边摸边吃奶边做爽免费视频| 青草青草欧美日本一区二区| 最新亚洲av日韩av二区| 亚洲制服师生 中文字幕| 69久久夜色精品国产| 很黄很色很污18禁免费| 日韩欧美在线综合网另类| 国产香蕉尹人视频在线| caoprom最新超碰地址| 天天摸天天碰天天添| 被两个男人同时嘬奶头| 欧美 国产 日产 韩国a片| 办公室里玩弄人妻系列| 亚洲熟妇无码aⅤ在线播放| 求你们不要了np| z0z大狗| 五月天婷婷激情无码专区| 免费永久看黄神器| 好黄好硬好爽免费视频| 天然格斗少女千寻| 五月丁香综合缴情六月| 韩国三级中文字幕hd无码| http://www.sharoushi-navi.com