nginx、php-fpm二三問

php-cgi爲何沒了？ php-fpm子進程是幹啥的?
php-cgi是原來php自帶的fastcgi進程管理器，有一些缺點，好比不能平滑重啓，進程管理差。
php-fpm能夠看作升級版的php-fpm.
php-fpm子進程就是工做進程，負責接收和處理請求, 和nginx相似。

fastcgi_pass 127.0.0.1:9000是幹啥的 這種方式是http協議仍是fastcgi協議？
是php-fpm的監聽地址,能夠是本機，也能夠是其餘機器.好比192.168.0.21:9000,php-fpm.conf中也須要爲php-fpm進程池配置相同參數.
fastcgi協議。
這種經過tcp方式發送數據。
若是nginx和php部署在同臺機器,也可用socket形式進行進程間通信.

nginx若是和php socket通信，是否是也要佔用端口？
是，也是經過tcp協議，目標地址和端口已知，nginx做爲客戶端.php-fpm接受請求時需分配端口.若是部署在同臺機器，可經過socket文件進行進程間通信。極大提升性能。

fastcgi_pass和proxy_pass區別 
fastcgi_pass是把進程按照fastcgi要求的格式發送到php-fpm監聽的地址。
proxy_pass只是把請求轉發到其餘web服務器.
fastcgi_pass和proxy_pass均可以交給upstream 模塊處理。

php-fpm master進程並不接收和分發請求,而是worker進程直接accpet請求後poll處理.
我看一篇文章這麼說，那幾百個worker進程,怎麼知道誰去處理當前這個請求呢,這個邏輯誰作的 ？
搶佔式的嗎 ?仍是master來作空閒子進程的判斷，指定某個進程處理？
搶佔式，本身搶本身的。公園裏餵魚是的。

php-fpm和mod apache比較？php-fpm優點，爲何選擇php-fpm
性能表現差距不大。
內存小的時候,php-fpm更快，php-fpm使用更少的內存，apache對php模塊管理較差。
以CGI方式運行時,web server將用戶請求以消息的方式轉交給PHP獨立進程,PHP與web服務之間無從屬關係.
純粹調用--返回結果的形式通信.而模塊方式,則是將PHP作爲web-server的子進程控制,二者之間有從屬關係.最明顯的例子就是在CGI模式下,若是修改了PHP.INI的配置文件,不用重啓web服務即可生效,而模塊模式下則須要重啓web服務.
php-fpm可獨立部署,固然解耦的同時也會帶來tcp網絡通信的開銷.

php爲何須要nginx,本身接受請求處理不就好了嗎？
php固然能夠本身接受請求處理，好比用socket能夠本身實現一個web服務器，而且自己php5.4也內置一個web服務器。
使用nginx，我的理解，首先是一個解耦的操做，web服務器代碼和業務代碼解耦。而且nginx使用epoll，能快速處理請求。
其次，安全考慮，nginx能過濾不少非法請求，php自己是一門語言，請求處理並不強大，固然go語言等這方面作的不錯。

--enable-force-cgi-redirect 選項做用？
通常安裝php用 --enable-force-cgi-redirect 選項,PHP 在此模式下只會解析已經經過了 web 服務器的重定向規則的 URL。
若使用 CGI VERSION 模式來執行 PHP ，打開本選項會增長安全性。此編譯選項能夠防止任何人經過如 http://my.host/cgi-bin/php/secretdir/script.php 這樣的 URL 直接調用 PHP。PHP 在此模式下只會解析已經經過了 web 服務器的重定向規則的 URL。 
我的理解這種適合單一入口的程序。都進入index.php統一處理。若是程序非單一入口，則不能夠啓用該選項。

cgi和http的區別？
CGI腳本簡單地講是個運行在Web服務器上的程序, 有瀏覽器的輸入觸發. 這個腳本一般象服務器和系統中其餘程序如數據庫的橋樑。
CGI腳本是用下列兩種方法使用的: 做爲一個表單的ACTION 或 做爲一個頁中的直接link。如今cgi大部分用來處理表單。
爲了能編寫和運行CGI腳本, 你須要一個Web服務器. 
即便你有一個Web服務器, 這個服務器必須特別地爲運行CGI腳本配置一下. 那意味着你全部的腳本必須放置在一個叫作cgi-bin的目錄下.
cgi比較古老，新的動態網頁解析語言有php等。
http是一種協議，瀏覽器發送的也是http接口，我的理解瀏覽器發送過去的數據通過nginx,nginx處理成符合fastcgi協議標準，傳遞到php-fpm,經php解釋器處理後，一部分是填充一些超全局變量，一部分解析爲知足http協議的具體數據(好比form表單數據)，而後進行處理。
總之關係不大，一個是處理動態網頁程序，一個是一種程序間通信協議。

http和rpc的區別？爲何要使用rpc框架(hessian等)?
http是一種應用層協議,php使用時，須要本身拼裝http協議的頭部和內容,若是須要響應頭，curl設置
curl_setopt($curl, CURLOPT_HEADER, true); 本身解析。
RPC是一個軟件結構概念，是構建分佈式應用的理論基礎.也能夠基於http實現，或者基於socket等其餘方式實現，我的理解，他的好處就是客戶端調用像本地調用同樣，方便，簡潔，當系統之間交互不少，優勢就體現出來了.
若是rpc基於tcp實現，傳輸中更是少了http頭部傳輸，理論上一個請求能更快的完成。

http長鏈接和短鏈接的區別？HTTP1.1規定了默認保持長鏈接（HTTP persistent connection ，也有翻譯爲持久鏈接），數據傳輸完成了保持TCP鏈接不斷開（不發RST包、不四次握手），等待在同域名下繼續用這個通道傳輸數據；相反的就是短鏈接。Keep-Alive: timeout=20，表示這個TCP通道能夠保持20秒。另外還可能有max=XXX，表示這個長鏈接最多接收XXX次請求就斷開。用長鏈接以後，客戶端、服務端怎麼知道本次傳輸結束呢？兩部分：1是判斷傳輸數據是否達到了Content-Length指示的大小；2動態生成的文件沒有Content-Length，它是分塊傳輸（chunked），這時候就要根據chunked編碼來判斷，chunked編碼的數據在最後有一個空chunked塊，代表本次傳輸數據結束。