Apache服務(wù)器運行在linux系統(tǒng)上，F(xiàn)astCGI以Apache為平臺來運行，每一個客戶端發(fā)起的HTTP請求都會由Apache交給FastCGI來處理。HTTP協(xié)議屬于應(yīng)用層協(xié)議，建立在TCP(網(wǎng)絡(luò)層)協(xié)議上，它并不關(guān)心其上一層協(xié)議做了什么，只需做自己被定義的，本文檔只針對HTTP協(xié)議層尋找問題答案，因此，在后續(xù)的講述中，客戶端是如何找到服務(wù)器，服務(wù)器又是如何將數(shù)據(jù)返回給客戶端，數(shù)據(jù)是通過哪些被定義的函數(shù)來處理傳輸?shù)?，傳輸實現(xiàn)的細節(jié)是什么等等，這些都已經(jīng)被TCP協(xié)議所定義，不進行敘述。我們只需知道域名+端口就可以唯一地確定網(wǎng)絡(luò)中某臺服務(wù)器的某個進程即可
談?wù)刪ttp如何實現(xiàn)： HTTP在請求之前先通過TCP的三次握手建立與服務(wù)器的連接，連接成功后發(fā)送請求，請求方式有GET、POST、PUT、DELET等，常用的卻只有GET、POST方式，若服務(wù)器接收請求后受理業(yè)務(wù)并成功返回，客戶端則會顯示請求內(nèi)容，同時服務(wù)器斷開連接。 網(wǎng)上常會出現(xiàn)一些對GET、POST不負責(zé)任的言論，關(guān)于GET與POST ，客戶端中URL提交方式有三種：地址欄直接輸入、點擊鏈接、form表單對URL重寫提交，無論哪種其本質(zhì)都將URL傳輸重寫為以下格式(已做驗證，后續(xù)會實驗結(jié)果共享)：
<request-line> #請求行，標識請求類型(GET，POST，PUT，DELET)、要訪問的資源、使用的HTTP版本等
<headers> #消息報頭，附加信息(別急，稍后會實例說明它是什么)， 以回車換行符/r/n標識結(jié)束，/r/n既<CRLF>
[<request-body>] #請求正文，通常是POST提交方式的表單FORM包數(shù)據(jù)，其編碼方式由<headers>中的Content-type指定，長度由Content-Length指定，同樣以<CRLF>為標志結(jié)束(GET請求沒有此信息，數(shù)據(jù)會直接暴露在URL中)。
在HTTP協(xié)議中，無論GET還是POST都能進行表單提交，區(qū)別是參數(shù)傳輸放置位置不同，GET不能將參數(shù)放置在request-body中，POST則兩者都可以。有的地方說GET參數(shù)暴漏在外不安全，然而POST表單提交方式不是一樣也能通過工具看到嗎，至于傳輸數(shù)據(jù)長度是否受限制，沒做試驗驗證(網(wǎng)上有種說法是傳輸長度不限制，只會由瀏覽器決定)。 以上這些可以方便我們知道數(shù)據(jù)是從哪來，到哪去，是通過什么傳輸?shù)?，從而能針對不同的BUG進行調(diào)試，了解整個服務(wù)器框架各個部分的銜接方式，優(yōu)化性能。
CGI（common Gateway interface ）通用網(wǎng)關(guān)接口，一種動態(tài)網(wǎng)頁實現(xiàn)技術(shù)，它與Perl一樣古老，因編程困難，效率低下，修改復(fù)雜一系列缺點，逐漸被更為流行的ASP、JSP、PHP等代替(不流行的技術(shù)也許更安全，這正是CGI的優(yōu)點)。CGI并非常駐內(nèi)存，對于每次請求服務(wù)器都會FORK()載入CGI程序，初始化相關(guān)的數(shù)據(jù)結(jié)構(gòu)，因此高并發(fā)請求時會占用大量磁盤I/O操作，所以被FastCGI所替代，F(xiàn)astCGI是CGI的升級版，實現(xiàn)了對CGI進程的內(nèi)存管理，F(xiàn)astCGI啟動后先自我初始化，開啟多個CGI進程(多進程導(dǎo)致占用大量內(nèi)存)，輪番讓空閑的CGI進程接收及響應(yīng)請求，從而達到減少因反復(fù)加載所進行的I/O操作、多進程、持續(xù)數(shù)據(jù)庫連接、分布式運算等目的。
CGI中的Request方法用于處理client發(fā)出的GET、POST、PUT、DELET四 種請求，常用的只有GET、POST兩種，且FastCGI實現(xiàn)的前 提是已經(jīng)通過listen偵聽了一個端口，然后再去調(diào)用accept函數(shù)。
你可能會有一下疑問：
1 FastCGI請求的端口是如何獲取的，
2 怎么才能知道FastCGI的進程個數(shù)，如何確定哪些進程是空閑的以分配給它們客戶端傳來的請求，
3 FastCGI既然是多進程，運行在內(nèi)存中，如何實現(xiàn)一次編碼，然后能不斷的接收請求的，為什么CGI不行，
4 FastCGI的效率怎么樣。
解釋如下：
1 其實服務(wù)器會一直監(jiān)聽某個端口號(HTTP不說明情況下默認為80)，因為FastCGI是獨立的，它也會偵聽某個端口(一般是相同的端口，在配置中已經(jīng)指定)，所以每個FastCGI都可以進行accept連接，只要它空閑web服務(wù)器就允許其處理一個請求，否則可能是因為并發(fā)量太大，暫時處理不了。
2 如果FastCGI是由服務(wù)器直接啟動，作為父進程當然知道子進程個數(shù)，并進行控制，如果是通過其它程序間接啟動，父進程就不再是服務(wù)器，此時就無法知道進程個數(shù)，但是其相關(guān)父進程也會有一套相應(yīng)的實現(xiàn)機制，不影響整個工作流程。
3 FastCGI有自己的內(nèi)存管理機制，啟動后一直停留在內(nèi)存中，但處于掛起狀態(tài)，只在有HTTP請求時，F(xiàn)astCGI才會響應(yīng)執(zhí)行，完成后斷開連接，繼續(xù)掛起，等待下一次的請求。
4 作為解釋行語言，F(xiàn)astCGI雖然很方便，卻對編程人員有著較高的要求，不同人員編寫的程序速度相差很大，且修改起來困難，在效率上也比編譯型語言慢上很多。
聯(lián)系客服
