PHP常見問題 - 技術 - 我的學習文章

分享一些今年所遇到的麵試題。

1、寫一箇函數，盡可能高效的，從一箇標準url裡取齣文件的擴展名例如: http://www.test.com.cn/abc/de/fg.PHP?id=1需要取齣php或.php

 1 第一種寫法：  2 function getExt1($url){  3     $arr = parse_url($url);  4     $file = basename($arr['path']);  5     $ext = explode('.',$file);  6     return $ext[1];  7 }  8 第二種寫法：  9 function getExt2($url){ 10     $b=parse_url($url); 11     echo substr($b['path'],strpos($b['path'],'.')); 12 } 13 第三種寫法： 14 function getExt3($url){ 15     $b=parse_url($url); 16     $ext = explode('.',$b['path']); 17     echo end($ext); 18 } 19  20 $a="http://www.test.com.cn/abc/de/fg.php?id=1"; 21 echo getExt($a);

2、使用五種以上方式穫取一箇文件的擴展名

 1 function get_ext1($file_name){  2     returnsubstr(strrchr($file_name, '.'),1);  3 }  4 function get_ext2($file_name){  5     returnsubstr(substr($file_name, strrpos($file_name, '.')),1);  6 }  7 function get_ext3($file_name){  8     $a=explode('.', $file_name);  9     returnarray_pop($a); 10 } 11 function get_ext4($file_name){ 12     returnpathinfo($file_name, PATHINFO_EXTENSION); 13 } 14 function get_ext5($file_name){ 15     returnstrrev(substr(strrev($file_name), 0, strpos(strrev($file_name), '.'))); 16 }

3、HTTP中POST、GET、PUT、DELETE方式的區彆

HTTP定義瞭與服務器交互的不衕的方法，最基本的是POST、GET、PUT、DELETE，與其比不可少的URL的全稱是資源描述符，我們可以這樣理解：url描述瞭一箇網絡上資源，而post、get、put、delete就是對這箇資源進行增、刪、改、查的操作！

3.1錶單中get和post提交方式的區彆

get是把蔘數數據隊列加到提交錶單的action屬性所指的url中，值和錶單內各箇字段一一對應，從url中可以看到；post是通過HTTPPOST機製，將錶單內各箇字段與其內容防止在HTML的head中一起傳送到action屬性所指的url地址，用戶看不到這箇過程
對於get方式，服務器端用Request.QueryString穫取變量的值，對於post方式，服務器端用Request.Form穫取提交的數據
get傳送的數據量較小，post傳送的數據量較大，一般被默認不受限製，但在理論上，IIS4中最大量爲80kb，IIS5中爲1000k，get安全性非常低，post安全性較高
3.2
GET請求會曏數據庫髮索取數據的請求，從而來穫取信息，該請求就像數據庫的select操作一樣，隻是用來查詢一下數據，不會修改、增加數據，不會影響資源的內容，卽該請求不會産生副作用。無論進行多少次操作，結果都是一樣的。
與GET不衕的是，PUT請求是曏服務器端髮送數據的，從而改變信息，該請求就像數據庫的update操作一樣，用來修改數據的內容，但是不會增加數據的種類等，也就是説無論進行多少次PUT操作，其結果併沒有不衕。
POST請求衕PUT請求類似，都是曏服務器端髮送數據的，但是該請求會改變數據的種類等資源，就像數據庫的insert操作一樣，會創建新的內容。幾乎目前所有的提交操作都是用POST請求的。
DELETE請求顧名思義，就是用來刪除某一箇資源的，該請求就像數據庫的delete操作。

4、優化數據庫的方法

1、選取適當的字段屬性。

2、使用連接查詢代替子查詢。

3、使用聯閤查詢代替手動創建的臨時錶

4、使用事務。

5、鎖定錶。

6、使用外鍵。

7、使用索引

8、優化查詢語句

詳情可以看我之前髮錶的《優化數據庫的八種方法》

5、對於大流量網站，採用什麽方法來解決訪問量的問題

1、首先，確認服務器硬件是否足夠支持當前的流量

普通的P4服務器一般最多能支持每天10萬獨立IP，如果訪問量比這箇還要大，那麽必鬚首先配置一颱更高性能的專用服務器纔能解決問題，否則怎麽優化都不可能徹底解決性能問題。

2、數據庫的讀寫分離，優化錶結構；

讀寫分離：頻繁請求數據庫時會造成堵塞，增加數據的讀取與寫入時間。讀寫分離可使不衕的數據庫分擔不衕的任務，減少每箇數據庫的連接數，加快數據讀取速度；

3、緩存技術的閤理運用，減少數據庫的頻繁操作；

優化數據庫訪問前颱實現完全的靜態化當然最好，可以完全不用訪問數據庫，不過對於頻繁更新的網站，靜態化往往不能滿足某些功能。
緩存技術就是另一箇解決方案，就是將動態數據存儲到緩存文件中，動態網頁直接調用這些文件，而不必再訪問數據庫，WordPress和Z-Blog都大量使用這種緩存技術如果確實無法避免對數據庫的訪問，那麽可以嚐試優化數據庫的查詢SQL.避免使用 Select * from這樣的語句，每次查詢隻返迴自己需要的結果，避免短時間內的大,盡量做到"所查卽所得" ,遵循以小錶爲主,附錶爲輔,查詢條件先索引,先小後大的原則,提高查詢效率.量SQL查詢。

4、程序功能規則，減少外部盜鏈；

外部網站的圖片或者文件盜鏈往往會帶來大量的負載壓力，因此應該嚴格限製外部對於自身的圖片或者文件盜鏈，好在目前可以簡單地通過refer來控製盜鏈，Apache自己就可以通過配置來禁止盜鏈，IIS也有一些第三方的ISAPI可以實現衕樣的功能。當然，僞造refer也可以通過代碼來實現盜鏈，不過目前蓄意僞造refer盜鏈的還不多，可以先不去考慮，或者使用非技術手段來解決，比如在圖片上增加水印。

5、控製大文件的上傳與下載；

大文件的下載會佔用很大的流量，併且對於非SCSI硬盤來説，大量文件下載會消耗 CPU，使得網站響應能力下降。因此，盡量不要提供超過2M的大文件下載，如果需要提供，建議將大文件放在另外一颱服務器上。

6、使用不衕主機分流主要流量

將文件放在不衕的主機上，提供不衕的鏡像供用戶下載。比如如果覺得RSS文件佔用流量大，那麽使用FeedBurner或者FeedSky等服務將RSS輸齣放在其他主機上，這樣彆人訪問的流量壓力就大多集中在FeedBurner的主機上，RSS就不佔用太多資源瞭

7、使用流量分析統計軟件

在網站上安裝一箇流量分析統計軟件，可以卽時知道哪些地方耗費瞭大量流量，哪些頁麵需要再進行優化，因此，解決流量問題還需要進行精確的統計分析纔可以。

6、數據庫中的事務是什麽?

事務（transaction）是作爲一箇單元的一組有序的數據庫操作。如果組中的所有操作都成功，則認爲事務成功，卽使隻有一箇操作失敗，事務也不成功。如果所有操作完成，事務則提交，其修改將作用於所有其他數據庫進程。如果一箇操作失敗，則事務將迴滾，該事務所有操作的影響都將取消。ACID 四大特性,原子性、隔離性、一緻性、持久性。

7、瞭解XSS攻擊嗎？如何防止？

XSS跨站腳本攻擊指攻擊者在網頁中嵌入客戶端腳本(例如JavaScript)，當用戶瀏覽此網頁時，腳本就會在用戶的瀏覽器上執行，從而達到攻擊者的目的，比如穫取用戶的Cookie，導航到惡意網站，攜帶木馬等。

如何防止XSS跨站腳本攻擊：

原則：不相信用戶輸入的數據

將重要的cookie標記爲http only，這樣的話Javascript 中的document.cookie語句就不能穫取到cookie瞭
隻允許用戶輸入我們期望的數據。例如：年齡的textbox中，隻允許用戶輸入數字，而數字之外的字符都過濾掉
對數據進行Html Encode 處理。< 轉化爲 <、> 轉化爲 >、& 轉化爲 &、' 轉化爲 '、" 轉化爲 "、空格轉化爲  
過濾或移除特殊的Html標籤。例如：<script>、<iframe>、< for <、> for >、&quot for

5. 過濾JavaScript 事件的標籤。例如 “onclick=”、”onfocus”等等
很多瀏覽器都加入瞭安全機製來過濾XSS

註意：攻擊代碼不一定在 <script></script> 中

8、SQL註入漏洞産生的原因？如何防止？

所謂SQL註入，就是通過把SQL命令插入到Web錶單遞交或輸入域名或頁麵請求的查詢字符串，最終達到欺騙服務器執行惡意的SQL命令。

如何防止SQL註入：

永遠不要信任用戶的輸入。對用戶的輸入進行校驗，可以通過正則錶達式，或限製長度；對單引號和雙”-“進行轉換等。
永遠不要使用動態拚裝sql，可以使用蔘數化的sql或者直接使用存儲過程進行數據查詢存取
永遠不要使用管理員權限的數據庫連接，爲每箇應用使用單獨的權限有限的數據庫連接
不要把機密信息直接存放，加密或者hash掉密碼和敏感的信息

應用的異常信息應該給齣盡可能少的提示，最好使用自定義的錯誤信息對原始錯誤信息進行包裝

9、對於關繫型數據庫而言，索引是相當重要的概念，請迴答有關索引的幾箇問題：

a)、索引的目的是什麽？

快速訪問數據錶中的特定信息，提高檢索速度
創建唯一性索引，保證數據庫錶中每一行數據的唯一性。
加速錶和錶之間的連接
使用分組和排序子句進行數據檢索時，可以显著減少查詢中分組和排序的時間

b)、索引對數據庫繫統的負麵影響是什麽？

負麵影響：
創建索引和維護索引需要耗費時間，這箇時間隨著數據量的增加而增加；索引需要佔用物理空間，不光是錶需要佔用數據空間，每箇索引也需要佔用物理空間；當對錶進行增、刪、改、的時候索引也要動態維護，這樣就降低瞭數據的維護速度。

c)、爲數據錶建立索引的原則有哪些？

在最頻繁使用的、用以縮小查詢範圍的字段上建立索引。
在頻繁使用的、需要排序的字段上建立索引

d)、什麽情況下不宜建立索引？

對於查詢中很少涉及的列或者重覆值比較多的列，不宜建立索引。
對於一些特殊的數據類型，不宜建立索引，比如文本字段（text）等。

e)索引的副作用

（1）索引是有大量數據的時候纔建立的，沒有大量數據反而會浪費時間，因爲索引是使用二叉樹建立.
（2）當一箇繫統查詢比較頻繁，而新建，修改等操作比較少時，可以創建索引，這樣查詢的速度會比以前快很多，衕時也帶來弊端，就是新建或修改等操作時，比沒有索引或沒有建立覆蓋索引時的要慢。
（3）索引併不是越多越好，太多索引會佔用很多的索引錶空間，甚至比存儲一條記録更多。
對於需要頻繁新增記録的錶，最好不要創建索引，沒有索引的錶，執行insert、append都很快，有瞭索引以後，會多一箇維護索引的操作，一些大錶可能導緻insert 速度非常慢。

10、簡述在MySQL數據庫中MyISAM和InnoDB的區彆

區彆於其他數據庫的最重要的特點就是其插件式的錶存儲引擎。切記：存儲引擎是基於錶的，而不是數據庫。

MyISAM是MySQL的默認數據庫引擎（5.5版之前），由早期的ISAM（Indexed Sequential Access Method：有索引的順序訪問方法）所改良。雖然性能極佳，但卻有一箇缺點：不支持事務處理（transaction）。不過，在這幾年的髮展下，MySQL也導入瞭InnoDB（另一種數據庫引擎），以強化蔘考完整性與併髮違規處理機製，後來就逐漸取代MyISAM。

InnoDB，是MySQL的數據庫引擎之一，爲MySQL AB髮佈binary的標準之一。InnoDB由Innobase Oy公司所開髮，2006年五月時由甲骨文公司併購。與傳統的ISAM與MyISAM相比，InnoDB的最大特色就是支持瞭ACID兼容的事務（Transaction）功能，類似於PostgreSQL。目前InnoDB採用雙軌製授權，一是GPL授權，另一是專有軟件授權。

MyISAM與InnoDB的區彆是什麽？

1、存儲結構

MyISAM：每箇MyISAM在磁盤上存儲成三箇文件。第一箇文件的名字以錶的名字開始，擴展名指齣文件類型。.frm文件存儲錶定義。數據文件的擴展名爲.MYD (MYData)。索引文件的擴展名是.MYI (MYIndex)。
InnoDB：所有的錶都保存在衕一箇數據文件中（也可能是多箇文件，或者是獨立的錶空間文件），InnoDB錶的大小隻受限於操作繫統文件的大小，一般爲2GB。

2、存儲空間

MyISAM：可被壓縮，存儲空間較小。支持三種不衕的存儲格式：靜態錶(默認，但是註意數據末尾不能有空格，會被去掉)、動態錶、壓縮錶。
InnoDB：需要更多的內存和存儲，牠會在主內存中建立其專用的緩衝池用於高速緩衝數據和索引。

3、可移植性、備份及恢複

MyISAM：數據是以文件的形式存儲，所以在跨平颱的數據轉移中會很方便。在備份和恢複時可單獨針對某箇錶進行操作。
InnoDB：免費的方案可以是拷貝數據文件、備份 binlog，或者用 mysqldump，在數據量達到幾十G的時候就相對痛苦瞭。

4、事務支持

MyISAM：強調的是性能，每次查詢具有原子性,其執行數度比InnoDB類型更快，但是不提供事務支持。
InnoDB：提供事務支持事務，外部鍵等高級數據庫功能。具有事務(commit)、迴滾(rollback)和崩潰修複能力(crash recovery capabilities)的事務安全(transaction-safe (ACID compliant))型錶。

5、 AUTO_INCREMENT

MyISAM：可以和其他字段一起建立聯閤索引。引擎的自動增長列必鬚是索引，如果是組閤索引，自動增長可以不是第一列，他可以根據前麵幾列進行排序後遞增。
InnoDB：InnoDB中必鬚包含隻有該字段的索引。引擎的自動增長列必鬚是索引，如果是組閤索引也必鬚是組閤索引的第一列。

6、錶鎖差異

MyISAM：隻支持錶級鎖，用戶在操作myisam錶時，select，update，delete，insert語句都會給錶自動加鎖，如果加鎖以後的錶滿足insert併髮的情況下，可以在錶的尾部插入新的數據。
InnoDB：支持事務和行級鎖，是innodb的最大特色。行鎖大幅度提高瞭多用戶併髮操作的新能。但是InnoDB的行鎖，隻是在WHERE的主鍵是有效的，非主鍵的WHERE都會鎖全錶的。

7、全文索引

MyISAM：支持 FULLTEXT類型的全文索引
InnoDB：不支持FULLTEXT類型的全文索引，但是innodb可以使用sphinx插件支持全文索引，併且效果更好。

8、錶主鍵

MyISAM：允許沒有任何索引和主鍵的錶存在，索引都是保存行的地址。
InnoDB：如果沒有設定主鍵或者非空唯一索引，就會自動生成一箇6字節的主鍵(用戶不可見)，數據是主索引的一部分，附加索引保存的是主索引的值。

11、解釋MySQL外連接、內連接與自連接的區彆

先説什麽是交叉連接: 交叉連接又叫笛卡爾積，牠是指不使用任何條件，直接將一箇錶的所有記録和另一箇錶中的所有記録一一匹配。

內連接 則是隻有條件的交叉連接，根據某箇條件篩選齣符閤條件的記録，不符閤條件的記録不會齣現在結果集中，卽內連接隻連接匹配的行。
外連接 其結果集中不僅包含符閤連接條件的行，而且還會包括左錶、右錶或兩箇錶中的所有數據行，這三種情況依次稱之爲左外連接，右外連接，和全外連接。

左外連接，也稱左連接，左錶爲主錶，左錶中的所有記録都會齣現在結果集中，對於那些在右錶中併沒有匹配的記録，仍然要顯示，右邊對應的那些字段值以NULL來填充。右外連接，也稱右連接，右錶爲主錶，右錶中的所有記録都會齣現在結果集中。左連接和右連接可以互換，mysql目前還不支持全外連接。

12、列舉流行的Ajax 框架？説明 Ajax 實現原理是什麽及json在 Ajax 中起什麽作用？

流行的 Ajax 框架有 jQuery，Prototype，Dojo，MooTools。

Ajax 的工作原理是一箇頁麵的指定位置可以加載另一箇頁麵所有的輸齣內容，這樣就實現瞭一箇靜態頁麵也能穫取到數據庫中的返迴數據信息瞭。所以 Ajax 技術實現瞭一箇靜態網頁在不刷新整箇頁麵的情況下與服務器通信，減少瞭用戶等待時間，衕時也從而降低瞭網絡流量，增強瞭客戶體驗的友好程度。
在使用 Ajax 時，涉及到數據傳輸，卽將數據從服務器返迴到客戶端，服務器端和客戶端分彆使用不衕的腳步語言來處理數據，這就需要一種通用的數據格式，XML 和json就是最常用的兩種，而json比 XML 更簡單。

13、談談你對MVC的認識

MVC是Model—View—Controler的簡稱。卽模型—視圖—控製器。MVC是一種設計模式，牠強製性的把應用程序的輸入、處理和輸齣分開。

MVC中的模型、視圖、控製器牠們分彆擔負着不衕的任務。

視圖: 視圖是用戶看到併與之交互的界麵。視圖曏用戶顯示相關的數據，併接受用戶的輸入。視圖不進行任何業務邏輯處理。

模型: 模型錶示業務數據和業務處理。一箇模型能爲多箇視圖提供數據。這提高瞭應用程序的重用性。

控製器: 當用戶單擊Web頁麵中的提交按鈕時,控製器接受請求併調用相應的模型去處理請求。然後根據處理的結果調用相應的視圖來顯示處理的結果。

MVC的處理過程：首先控製器接受用戶的請求，調用相應的模型來進行業務處理，併返迴數據給控製器。控製器調用相應的視圖來顯示處理的結果。併通過視圖呈現給用戶。

一、MVC的優點
1、可以爲一箇模型在運行時衕時建立和使用多箇視圖。變化-傳播機製可以確保所有相關的視圖及時得到模型數據變化，從而使所有關聯的視圖和控製器做到行爲衕步。
2、視圖與控製器的可接插性，允許更換視圖和控製器對象，而且可以根據需求動態的打開或關閉、甚至在運行期間進行對象替換。
3、模型的可移植性。因爲模型是獨立於視圖的，所以可以把一箇模型獨立地移植到新的平颱工作。需要做的隻是在新平颱上對視圖和控製器進行新的修改。
4、潛在的框架結構。可以基於此模型建立應用程序框架，不僅僅是用在設計界麵的設計中。

MVC的不足
MVC的不足體現在以下幾箇方麵：
（1）增加瞭繫統結構和實現的複雜性。對於簡單的界麵，嚴格遵循MVC，使模型、視圖與控製器分離，會增加結構的複雜性，併可能産生過多的更新操作，降低運行效率。
（2）視圖與控製器間的過於緊密的連接。視圖與控製器是相互分離，但確實聯繫緊密的部件，視圖沒有控製器的存在，其應用是很有限的，反之亦然，這樣就妨礙瞭他們的獨立重用。
（3）視圖對模型數據的低效率訪問。依據模型操作接口的不衕，視圖可能需要多次調用纔能穫得足夠的顯示數據。對未變化數據的不必要的頻繁訪問，也將損害操作性能。
（4）目前，一般高級的界麵工具或構造器不支持MVC架構。改造這些工具以適應MVC需要和建立分離的部件的代價是很高的，從而造成使用MVC的睏難。

14、用過緩存技術嗎？説説對Memcache的理解

概念

Memcache是一箇高性能的分佈式的內存對象緩存繫統。是箇開源的軟件，可以通過簡單的方法，管理數據庫在內存中的存取。簡單的説就是緩存數據庫查詢結果(數據)到內存中，然後從內存中讀取，從而大大提高讀取速度，減少數據庫訪問蔘數，以提高動態web應用的速度，提高可擴展性

怎麽理解Memcache?

Memcache 是隻有一張錶的數據庫，這張錶有兩箇字段分彆是主鍵key 和value，value就是我們要保存的數據，key就是這箇數據的id,用來保證我們查找時候的唯一性

Memcache 使用場景

非持久化存儲：對數據存儲要求不高,服務停止後，裡麵的數據就會丟失

分佈式存儲：單颱數據的內存容量有限，可以在多箇電腦上安裝memcache 服務

Key/Value存儲：需要緩存的對象或數據以“key/value”對的形式保存在服務器端

Memcache 在WEB中的應用

MemCache緩存繫統最主要的就是爲瞭提高動態網頁應用，分擔數據庫檢索的壓力。對於網站流量比較大的，可以使用memcache緩解數據庫的壓力，主要的焦點集中在以下兩箇方麵：

1. 使用MemCache作爲中間緩存層減少數據庫的壓力。

2. MemCache分佈式的應用

連接memcache

實例化memcache類

$memcache=new memcache;

連接memcache服務器

格式：$memcache->connect('127.0.0.1','11211');

蔘數1：主機（必寫）；

蔘數2：Memcached服務的端口號，默認11211（可選）

關閉服務器連接

$memcache->close()

15、Memcache與Redis的區彆

NoSQL因其優勢，目前是大行其道，而Memcached和Redis更是NoSQL中的明星。二者衕爲Key-Value型，且衕樣優秀，少不瞭一番比較。以下是一些簡單的比較，不涉及底層基礎等。

1.存儲最大值

Memcached的key最大爲250字節，value最大爲1MB；Redis的key和value最大都是512MB。

2.數據類型

Memcached存儲的類型僅支持key-value類型；Redis支持五種數據類型：string（字符串），hash（哈希），list（列錶），set（集閤）及zset(sorted set：有序集閤)。

3.數據備份

Memcached不支持數據備份；Redis支持master-slave模式的數據備份，教程在此：Redis數據備份與恢複。

4.災難恢複

Memcached不可恢複，卽restart之後數據也會清空；Redis可以恢複。

5.性能比較

放上引用的一段話，鏈接地址會在下文給齣：

由於Redis隻使用單核，而Memcached可以使用多核，所以在比較上，平均每一箇核上 Redis在存儲小數據時Memcached性能更高。而在100k以上的數據中，Memcached性能要高於Redis，雖然Redis最近也在存儲大數據的性能上進行優化，但是比起Memcached，還是稍有遜色。説瞭這麽多，結論是，無論你使用哪一箇，每秒處理請求的次數都不會成爲瓶頸。

6.持久化

這一點可以説是二者之間本質上的區彆，衕時也是上一點災難恢複的基礎。Memcached不可以持久化，所有的數據都在內存中。Redis有兩種持久化的方式：RDB（快照）方式和AOF（追加）方式，教程在此：Redi持久化。

7.使用場景

私以爲，Memcached足以應對一般網站的緩存需求，此博客旣是使用Memcached。如果有更多的需求，如持久化、可靠性或者更多數據類型，應當考慮Redis。

16、Apache與Nginx的區彆

nginx 相對 apache 的優點：
輕量級，衕樣起web 服務，比apache 佔用更少的內存及資源
抗併髮，nginx 處理請求是異步非阻塞的，而apache 則是阻塞型的，在高併髮下nginx 能保持低資源低消耗高性能
高度模塊化的設計，編寫模塊相對簡單
社區活躍，各種高性能模塊齣品迅速啊

apache 相對nginx 的優點：
rewrite ，比nginx 的rewrite 強大
模塊超多，基本想到的都可以找到
少bug ，nginx 的bug 相對較多
超穩定

存在就是理由，一般來説，需要性能的web 服務，用nginx 。如果不需要性能隻求穩定，那就apache 吧。後者的各種功能模塊實現得比前者，例如ssl 的模塊就比前者好，可配置項多。

這裡要註意一點，epoll(freebsd 上是 kqueue )網絡IO 模型是nginx 處理性能高的根本理由，但併不是所有的情況下都是epoll 大穫全勝的，如果本身提供靜態服務的就隻有寥寥幾箇文件，apache 的select 模型或許比epoll 更高性能。當然，這隻是根據網絡IO 模型的原理作的一箇假設，真正的應用還是需要實測瞭再説的。

1、作爲 Web 服務器：相比 Apache，Nginx 使用更少的資源，支持更多的併髮連接，體現更高的效率，這點使 Nginx 尤其受到虛擬主機提供商的歡迎。在高連接併髮的情況下，Nginx是Apache服務器不錯的替代品: Nginx在美國是做虛擬主機生意的老闆們經常選擇的軟件平颱之一. 能夠支持高達 50000 箇併髮連接數的響應, 感謝Nginx爲我們選擇瞭 epoll and kqueue 作爲開髮模型.
Nginx作爲負載均衡服務器: Nginx 旣可以在內部直接支持 Rails 和 PHP 程序對外進行服務, 也可以支持作爲 HTTP代理服務器對