摘要：其主要行為是將解釋器進(jìn)程保持在內(nèi)存中并因此獲得較高的性能。當(dāng)子進(jìn)程關(guān)閉連接時(shí)，請(qǐng)求便處理完成。

1、FastCGI是什么？
首先我們看下CGI,CGI全稱為通用網(wǎng)關(guān)接口 Common Cateway Interface.用于HTTP服務(wù)上的程序服務(wù)通信交流的一種工具，可以讓一個(gè)客戶端，從網(wǎng)頁(yè)瀏覽器向執(zhí)行在網(wǎng)絡(luò)服務(wù)器上的程序請(qǐng)求數(shù)據(jù)。CGI描述了服務(wù)器和請(qǐng)求處理程序之間傳輸數(shù)據(jù)的一種標(biāo)準(zhǔn)。 CGI程序必須運(yùn)行在網(wǎng)絡(luò)服務(wù)器上。常見(jiàn)的如php-cgi.exe。是php支持CGI標(biāo)準(zhǔn)的執(zhí)行檔。
CGI的工作原理：每當(dāng)客戶請(qǐng)求CGI的時(shí)候，WEB服務(wù)器就請(qǐng)求操作系統(tǒng)生成一個(gè)新的解釋器進(jìn)程(如php-cgi.exe),當(dāng)CGI進(jìn)程完成當(dāng)前任務(wù)結(jié)束后，web服務(wù)器就會(huì)殺死這個(gè)進(jìn)程。
但是CGI接口方式性能較差，由于每次HTTP服務(wù)器遇到動(dòng)態(tài)程序都需要重啟解析器來(lái)執(zhí)行解析，拿php舉例，每一個(gè)web請(qǐng)求,php都必須重新解析php.ini、重新載入全部dll擴(kuò)展并重新初始化全部數(shù)據(jù)結(jié)構(gòu)，你可以想象這樣多慢。這在處理高并發(fā)的問(wèn)題時(shí)，幾乎是不可能的。因此誕生了FastCGI.
所以，CGI解釋器的反復(fù)加載是CGI性能低下的主要原因，如果CGI解釋器保持在內(nèi)存中并接受FastCGI進(jìn)程管理器調(diào)度，則可以提供良好的性能、伸縮性、Fail-Over特性等等。
FastCGI:是一個(gè)可伸縮、高速的在web server和腳步語(yǔ)言間通訊的接口。其主要行為是將CGI解釋器進(jìn)程保持在內(nèi)存中并因此獲得較高的性能。
2、FastCGI在web服務(wù)器(Nginx)中的工作原理。
(1)、web Sever 啟動(dòng)時(shí)載入FastCGI進(jìn)程管理器，如php的FastCGI進(jìn)程管理器是PHP-FPM(php-FastCGI Process Manger).
(2)、FastCGI進(jìn)程管理器自身初始化，啟動(dòng)多個(gè)CGI解釋器進(jìn)程(在任務(wù)管理器中可見(jiàn)多個(gè)php-cgi.exe)并等待來(lái)自web服務(wù)器的連接。啟動(dòng)php-cgi FastCGI進(jìn)程時(shí)，可以配置以TCP協(xié)議或socker兩種方式啟動(dòng)。
(3)、當(dāng)客戶端請(qǐng)求到達(dá)Web Server時(shí)，Web Server將請(qǐng)求采用TCP協(xié)議或socket方式轉(zhuǎn)發(fā)到FastCGI主進(jìn)程，F(xiàn)astCGI主進(jìn)程選擇并連接到一個(gè)CGI解釋器(子進(jìn)程php-cgi.exe)。Web Server將CGI環(huán)境變量和標(biāo)準(zhǔn)輸入發(fā)送到FastCGI子進(jìn)程php-cgi.exe.
(4)、FastCGI子進(jìn)程php-cgi.exe完成處理后將標(biāo)準(zhǔn)輸出和錯(cuò)誤信息從原來(lái)的連接原路返回給web server。當(dāng)FastCGI子進(jìn)程關(guān)閉連接時(shí)，請(qǐng)求便處理完成。但是如果在傳統(tǒng)的CGI接口中，此時(shí)php-cgi子進(jìn)程便在此退出了。
下圖所示的是Nginx+FastCGI的運(yùn)作過(guò)程，腳本程序語(yǔ)言是php.

3、FastCGI的優(yōu)點(diǎn)
(1)、php腳本運(yùn)行速度更快，php解釋程序被載入內(nèi)存而不是每次需要時(shí)從存儲(chǔ)器讀取，極大提升了依靠腳本運(yùn)行站點(diǎn)的性能。
(2)、需要使用的系統(tǒng)資源更少，由于服務(wù)器不用每次在需要時(shí)都載入php解釋程序，你可以將站點(diǎn)的傳輸速度提升很多而不必增加cpu負(fù)擔(dān)。
(3)、可以把動(dòng)態(tài)語(yǔ)言和HTTP服務(wù)器分離開(kāi)來(lái)，同時(shí)在腳本解析服務(wù)器上啟動(dòng)一個(gè)或者多個(gè)腳本解析守護(hù)進(jìn)程。多數(shù)流行的HTTP服務(wù)器都支持FastCGI包括Apache/Nginx/lighttpd等。
(4)、當(dāng)HTTP服務(wù)器每次遇到動(dòng)態(tài)程序時(shí)，可以將其直接交付給FastCGI進(jìn)程來(lái)執(zhí)行，然后將得到的結(jié)果返回給瀏覽器。這種方式可以讓HTTP服務(wù)器專一地處理靜態(tài)請(qǐng)求或者將動(dòng)態(tài)腳本服務(wù)器的結(jié)果返回給客戶端，這在很大程度上提高了整個(gè)應(yīng)用系統(tǒng)的性能。

用戶瀏覽器發(fā)起對(duì)網(wǎng)頁(yè)的訪問(wèn):http://192.168.1.103/index.php
用戶和nginx服務(wù)器進(jìn)行三次握手進(jìn)行TCP連接(還包括nginx訪問(wèn)控制策略、nginx防火墻等訪問(wèn)控制策略)
第一步：nginx接收到來(lái)自服務(wù)器的http請(qǐng)求。
第二步：nginx會(huì)根據(jù)用戶訪問(wèn)的URL和后綴對(duì)請(qǐng)求進(jìn)行判斷。
(1)、例如客戶端訪問(wèn)的index.php，nginx則會(huì)根據(jù)配置文件中的location進(jìn)行匹配。
例如：

server {
        listen 8054;
        
        location ~ .php$ {
            fastcgi_pass 127.0.0.1:9000;
            fastcgi_index index.php;
            fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
            include fastcgi_params;
        }   
        #error_page  404              /404.html;

        # redirect server error pages to the static page /50x.html
        #
        error_page   500 502 503 504  /50x.html;
        location = /50x.html {
            root  html;
        }
}

用戶訪問(wèn)的是index.php，則會(huì)匹配到location ~.php$，這個(gè)的含義是對(duì)用戶通過(guò)url訪問(wèn)的資源進(jìn)行區(qū)分大小的匹配，并且訪問(wèn)的資源是以.php結(jié)尾的。
這里的 fastcgi_pass 127.0.0.1:9000，表示nginx通過(guò)fastcgi的接口將http請(qǐng)求發(fā)給127.0.0.1:9000進(jìn)行處理，這個(gè)過(guò)程就是上面fastcgi運(yùn)行原理中的第三部。這里的php腳本解析服務(wù)和nginx放在同一個(gè)服務(wù)器上面。 這里我用的是php返回動(dòng)態(tài)的資源，所以這里的FastCGI進(jìn)程管理器用的是php-fpm。
(2)、fastcgi_pass將動(dòng)態(tài)資源交給php-fpm后，php-fpm會(huì)講資源轉(zhuǎn)給php腳本解析服務(wù)器的wrapper.
(3)、wrapper收到php-fpm轉(zhuǎn)過(guò)來(lái)的請(qǐng)求后，wrapper會(huì)生成一個(gè)新的線程調(diào)用php動(dòng)態(tài)程序處理腳本并讀取返回?cái)?shù)據(jù);比如讀取mysql數(shù)據(jù)庫(kù)，會(huì)觸發(fā)讀庫(kù)操作。
(4)、php會(huì)將查詢處理得到的結(jié)果返回給wrapper,一直返回到nginx。最后Nginx將返回的數(shù)據(jù)發(fā)送給客戶端。
參考連接：
https://blog.csdn.net/m136663...
https://blog.csdn.net/riuhaze...
https://www.cnblogs.com/lidab...