php公共網關介面

⑴ 了解php-FPM

在伺服器上，當我們查看php進程時，全都是php-fpm進程，大家都知道這個就是php的運行環境，那麼，它到底是個什麼東西呢？

PHP-FPM，就是PHP的FastCGI管理器，用於替換PHP FastCGI的大部分附加功能，在PHP5.3.3後已經成為了PHP的標配。

有小夥伴要問了，FastCGI又是什麼鬼？CGI程序又叫做「通用網關介面」，就是讓Web伺服器和你的應用程序進行交互的一個介面。就像nginx中需要配置的fastcgi_pass，一般我們會使用127.0.0.1:9000或者unix:/tmp/php-cgi.sock來配置這個參數。它的意思就是告訴nginx，過來的請求使用tcp:9000埠的監聽程序來處理或者使用unix/socket來處理。它們都是指向的PHP運行程序。

再說得通俗一點，我們運行php腳本用的是

php-fpm就相當於是這個php命令。nginx通過fastcgi_pass來運行php $nginx_root(nginx配置文件中網站根目錄root配置)下的index.php。所以，如果你用的是python或者其他什麼語言，都可以用它們的cgi程序來讓nginx調用。

FastCGI和CGI又有什麼不同呢？FastCGI是啟動一個socket介面，伺服器應用不需要自己去運行php，只需要向這個socket介面提交請求就可以了。

php-fpm在編譯php時需要添加--enable-fpm。一些通用的集成安裝包如lnmp、phpStudy等都會默認編譯並使用php-fpm，畢竟是標配。

上文中說過nginx可以使用127.0.0.1:9000和unix:/tmp/php-cgi.sock這兩種方式來調用php-fpm。它們有什麼區別呢？

前者，一般帶9000埠號的，是tcp形式的調用。也就是php-fpm啟動了一個監聽進程對9000埠進行監聽。它會調起一個tcp/ip服務，nginx在調用的時候會走一次tcp請求流程，也就是3次握手4次揮手，會走到網路七層中的第四層傳輸層。相對來說這種方式性能會稍差一點，啟動php-fpm後使用nestat查看埠中會出現9000埠的佔用。

後者，使用的是unix套接字socket服務，通過sock文件來交換信息，性能相對好一些，因為它沒有tcp連接過程，也不會有9000埠的佔用。

對於高負載大訪問量的網站還是推薦使用unix方式，對於普通小網站來說，無所謂使用哪個都可以，tcp方式反而更容易配置和理解，也是php-fpm.conf中默認的監聽方式。

php-fpm.conf配置中的listen屬性用來配置監聽，這里的配置要和nginx中的一致，使用tcp的就監聽127.0.0.1:9000，使用unix的就設置成/tmp/php-cgi-56.sock。

以下內容摘自官方文檔：

===========

各自媒體平台均可搜索【硬核項目經理】

⑵ php5-cgi和php5-fpm 這兩個東西是什麼意思啊有什麼區別怎麼使用

CGI

CGI全稱是逗公共網關介面地(Common Gateway Interface)，HTTP伺服器與你的或其它機器上的程序進行逗交談地的一種工具，其程序須運行在網路伺服器上。

CGI可以用任何一種語言編寫，只要這種語言具有標准輸入、輸出和環境變數。如php,perl,tcl等。

FastCGI

FastCGI像是一個常駐(long-live)型的CGI，它可以一直執行著，只要激活後，不會每次都要花費時間去fork一次（這是CGI最為人詬病的fork-and-execute 模式）。它還支持分布式的運算，即 FastCGI 程序可以在網站伺服器以外的主機上執行並且接受來自其它網站伺服器來的請求。

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

FastCGI特點

FastCGI具有語言無關性.
FastCGI在進程中的應用程序，獨立於核心web伺服器運行，提供了一個比API更安全的環境。APIs把應用程序的代碼與核心的web伺服器鏈接在一起，這意味著在一個錯誤的API的應用程序可能會損壞其他應用程序或核心伺服器。 惡意的API的應用程序代碼甚至可以竊取另一個應用程序或核心伺服器的密鑰。
FastCGI技術目前支持語言有：C/C++、java、Perl、Tcl、Python、SmallTalk、Ruby等。相關模塊在Apache, ISS, Lighttpd等流行的伺服器上也是可用的。
FastCGI的不依賴於任何Web伺服器的內部架構，因此即使伺服器技術的變化, FastCGI依然穩定不變。
FastCGI的工作原理

Web Server啟動時載入FastCGI進程管理器（IIS ISAPI或Apache Mole)
FastCGI進程管理器自身初始化，啟動多個CGI解釋器進程(可見多個php-cgi)並等待來自Web Server的連接。
當客戶端請求到達Web Server時，FastCGI進程管理器選擇並連接到一個CGI解釋器。Web server將CGI環境變數和標准輸入發送到FastCGI子進程php-cgi。
FastCGI子進程完成處理後將標准輸出和錯誤信息從同一連接返回Web Server。當FastCGI子進程關閉連接時，請求便告處理完成。FastCGI子進程接著等待並處理來自FastCGI進程管理器(運行在Web Server中)的下一個連接。 在CGI模式中，php-cgi在此便退出了。
在上述情況中，你可以想像CGI通常有多慢。每一個Web請求PHP都必須重新解析php.ini、重新載入全部擴展並重初始化全部數據結構。使用FastCGI，所有這些都只在進程啟動時發生一次。一個額外的好處是，持續資料庫連接(Persistent database connection)可以工作。

FastCGI的不足

因為是多進程，所以比CGI多線程消耗更多的伺服器內存，PHP-CGI解釋器每進程消耗7至25兆內存，將這個數字乘以50或100就是很大的內存數。

Nginx 0.8.46+PHP 5.2.14(FastCGI)伺服器在3萬並發連接下，開啟的10個Nginx進程消耗150M內存（15M*10=150M），開啟的64個php-cgi進程消耗1280M內存（20M*64=1280M），加上系統自身消耗的內存，總共消耗不到2GB內存。如果伺服器內存較小，完全可以只開啟25個php-cgi進程，這樣php-cgi消耗的總內存數才500M。
上面的數據摘自Nginx 0.8.x + PHP 5.2.13(FastCGI)搭建勝過Apache十倍的Web伺服器(第6版)

PHP-CGI

PHP-CGI是PHP自帶的FastCGI管理器。

PHP-CGI的不足：

php-cgi變更php.ini配置後需重啟php-cgi才能讓新的php-ini生效，不可以平滑重啟。
直接殺死php-cgi進程，php就不能運行了。(PHP-FPM和Spawn-FCGI就沒有這個問題，守護進程會平滑從新生成新的子進程。）
PHP-FPM

PHP-FPM是一個PHP FastCGI管理器，是只用於PHP的，可以在 下載得到。

PHP-FPM其實是PHP源代碼的一個補丁，旨在將FastCGI進程管理整合進PHP包中。必須將它patch到你的PHP源代碼中，在編譯安裝PHP後才可以使用。

⑶ cgi是什麼php—cgi又是什麼這兩個有什麼關系

CGI是公共網關介面，是網站伺服器進程經過操作系統和互聯網客戶端進行通訊的一套規范標准。
PHP-CGI是PHP支持CGI標準的執行檔。

傳統CGI需要為每個訪問開一個操作系統進程，導致負荷很大。基本在伺服器部署上已經不採用CGI。現在主要應用Fast-CGI標准

⑷ WEB編程語言的公共網關介面

公共網關接升困口(Common Gateway Interface)為web伺服器定義了一種與外部應用程序交互、共享信息的標准。 1. 擴大了WEB伺服器的功能；
2. 它打破了伺服器軟體的局限性，允許用戶根據需要採用各種語言去實現無法用HTTP、HTML實現的功能，給WWW提消兆供了更為廣闊的應用拿笑租空間。
3. 為在不同的平台之間進行溝通提供了範例。
連接伺服器與外部應用程序。伺服器可以向CGI程序發送信息，CGI程序也可以向伺服器程序回送信息。

⑸ POST /cgi-bin/php.cgiff什麼意思

這個是向cgi發送post請求，其中參數是ff

php運行有多種方式。

1. php-fpm nginx
2. php.cgi以公用網關介面方式運行
3. mole apache作為模塊
4. fastcgi 多個cgi程序解析php請求

php.cgi是其中的一種運行方式，它會解析web請求。這里描述的是post請求，並且對請求的頭部做了一些聲明。指定的cgi應用程序沒有返回完整的http頭，產生報錯，這里可以嘗試通過pho manager設置fastcgi來解決。

⑹ php中如何取文件尾椎

第1種方法：

復制代碼代碼如下:

function get_extension($file)
{
substr(strrchr($file, '.'), 1);
}

第2種方法：

復制代碼代碼如下:

function get_extension($file)
{
return substr($file, strrpos($file, '.')+1);
}

第3種方法：

復制代碼代碼如下:

function get_extension($file)
{
return end(explode('.', $file));
}

第4種方法：

復制代碼代碼如下:

function get_extension($file)
{
$info = pathinfo($file);
return $info['extension'];
}

第5種方法：

復制代碼代碼如下:

function get_extension($file)
{
return pathinfo($file, PATHINFO_EXTENSION);
}

以上幾種方式粗看了一下，好像都行，特別是1、2種方法，在我不知道pathinfo有第二個參數之前也一直在用。但是仔細考慮一下，前四種方法都有各種各樣的毛病。要想完全正確獲取文件的擴展名，必須要能處理以下三種特殊情況。
沒有文件擴展名
路徑中包含了字元.，如/home/test.d/test.txt
路徑中包含了字元.，但文件沒有擴展名。如/home/test.d/test
很明顯：1、2不能處理第三種情況，3不能正確處理第一三種情況。4可以正確處理，但是在不存在擴展名時，會發出一個警告。只有第5種方法才是最正確的方法。順便看一下pathinfo方法。官網上介紹如下：
$file_path = pathinfo('/www/htdocs/your_image.jpg');

echo "$file_path ['dirname']\n";
echo "$file_path ['basename']\n";
echo "羨敗拍$file_path ['extension']\n";
echo "$file_path ['filename']\n"; // only in PHP 5.2+
它會返回一個數組，包含最多四個元素，但是並不會一直有四個，比如在沒有擴展名的情況下，就不會有extension元素存在，所以第4種方法才會發現警告。但是phpinfo還支持第二個參數。可以傳遞一個常量，指定返回某一部分的數據：
PATHINFO_DIRNAME - 目錄
PATHINFO_BASENAME - 文件名（含擴展名）
PATHINFO_EXTENSION - 擴展名
PATHINFO_FILENAME - 文件名（不含擴展名，PHP>5.2）
這四個常量的值分別是1、2、枯塌4、8，剛開始我還以為可以通過或運算指定多個：
pathinfo($file, PATHINFO_EXTENSION | PATHINFO_FILENAME);
後來發現這樣不行，這只會返回幾個進行或運算常量中最小的那個。也就是四個標志位中最小位為1的常量。
以下是一些補充方法
一，php explode函數

復制代碼代碼如下:

$pic = 'abc.php';
$pics = explode('.' , $pic);
echo $num = count($pics);
echo '<br>'.$pics[$num-1];

這樣就可以輸出
.php了。

下面利用foreach

復制代碼代碼如下:

foreach ($pics as $value) //2
{
$a = $value;
}
echo $a.'<br>';

來有一個比較好的函數end我推薦使用此函數快捷 end函數用法

復制代碼兄羨代碼如下:

echo end($pics);
echo '<br>';

⑺ phpinfo的Server API為CGI/FastCGI是什麼模式

php印版是作為伺服器的一個某塊的形式存在的,比如說apache,除此之外它還能以fasetCGI模式運行.以下這段話來自TiPi開源項目(有空的話可以看看，很不錯，不過我才學php沒多久，看著很吃力)
CGI全稱是「通用網關介面」(Common Gateway
Interface)，它可以讓一個客戶端，從網頁瀏覽器向執行在Web伺服器上的程序請求數據。 CGI描述了客戶端和這個程序之間傳輸數據的一種標准。
CGI的一個目的是要獨立於任何語言的，所以CGI可以用任何一種語言編寫，只要這種語言具有標准輸入、輸出和環境變數。
FastCGI是Web伺服器和處理程序之間通信的一種協議，是CGI的一種改進方案，FastCGI像是一個常駐(long-live)型的CGI，它可以一直執行，在請求到達時不會花費時間去fork一個進程來處理(這是CGI最為人詬病的fork-and-execute模式)。正是因為他只是一個通信協議，它還支持分布式的運算，即
FastCGI 程序可以在網站伺服器以外的主機上執行並且接受來自其它網站伺服器來的請求。

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

⑻ 關於PHP CGI和CLI的幾點學習

CGI ：「公共網關介面」(Common Gateway Interface)，HTTP伺服器 與你的或其它機器上的程序 進行 「交談」的一種工具 ，其程序 須運行在網路 伺服器 上。在伺服器 環境中，為「程序 」提供標准 的介面，通過這個介面，「程序 」可以對伺服器 與客戶端 交換的信息 做一些事情 。「程序 」的語 言並沒有要求。程序 對介面進行 操作。伺服器 要支持 CGI就要提供CGI中要求的環境變數 ，或者還有別的。我的理解至此為之。
CLI ：「 命令 行界面」(Command Line Interface)，可在用戶 提示符下鍵入可執行指令 的界面。
?SAPI ：「 伺服器 應用程序 介面」(Server Application Programme Interface)，可以認為是伺服器 端的API。貌似和CGI是一個東西 ，每個伺服器 提供的API可能不同，但是他們都提供了CGI。所以可以理解CGI是每個伺服器 都應該 有的SAPI。apache 有自己的SAPI，IIS也有自己的。但是php 能這些不同的伺服器 端工作，因為php 支持 了它們各自的SAPI。(CGI和CLI都是SAPI的類 型 )
ISAPI ：ISAPI 伺服器 擴展 是可以被 HTTP 伺服器 載入 和調用 的 DLL。Internet 伺服器 擴展 也稱為 Internet 伺服器 應用程序 (ISA)，用於增強符合 Internet 伺服器 API (ISAPI) 的伺服器 的功能 。ISA 通過瀏覽器 應用程序 調用 ，並且將相似的功能 提供給通用網關介面 (CGI) 應用程序 。

⑼ 關於FastCGI、php-cgi、php-fpm的區別是什麼，各自有什麼用途，以及相互間的關系是什麼

fastcgi是一個通用網關介面，用於web伺服器(iis, apache)和應用程序通信。

php-cgi是php平台的cgi程序
以上兩個結合，可以使php整合在web服務中
php-fpm是一個獨立的php-fcgi管理軟體，它要整合進web服務中，需要使用代理模式
一般與nginx搭配。也可以與apache搭配
php-fpm一般不直接作為服務容器提供外網訪問，而是通過常用web容器作代理

php作為伺服器端的解析程序，運行模式分很多種，fastcgi, mod_php, proxy(代理)等。
與iis搭配時一般採用fast-cgi模式，iis自帶fast-cgi引擎，配置好php參數即可
與apache搭配，在windows平台下，一般也是fast-cgi模式，在linux系統中一般是mod_php模式，把php作為一個子模塊載入
也可以配置php-fpm 然後在apache中配置代理模式
與nginx搭配，一般就是用php-fpm+代理模式了

⑽ Asp,php,jsp在網站中各是起什麼作用的

asp、php、asp.net、jsp介紹及優缺點比較

現在主流的網站開發語言無外乎asp、php、asp.net、jsp等。

網頁從開始簡單的hmtl到復雜的服務語言，走過了10多個年頭，各種技術層出不窮，單個的主流技術也在不斷翻新的版本，現在分析下各種語言的區別、優勢、劣勢、開發注意事項！

HTML:當然這是網頁最基本的語言,每一個伺服器語言都需要它的支持,要學習,這個肯定是開始,不說了.

主流網站開發語言之ASP:ASP是微軟（Microsoft）所開發的一種後台腳本語言，它的語法和Visual BASIC類似，可以像SSI（Server Side Include）那樣把後台腳本代碼內嵌到HTML頁面中。雖然ASP簡單易用，但是它自身存在著許多缺陷，最重要的就是安全性問題。目前在微軟的 .net 戰略中新推出的ASP.net 借鑒了Java技術的優點，使用C Sharp (C#) 語言作為ASP.net的推薦語言，同時改進了以前ASP的安全性差等缺點。但是，使用ASP/ASP.net仍有一定的局限性，因為從某種角度來說它們只能在微軟的 Windows NT/2000/XP + IIS的伺服器平台上良好運行（雖然像ChilliSoft提供了在UNIX/Linux上運行ASP的解決方案，但是目前ASP在UNIX/Linux上的應用可以說幾乎為0）。所以平台的局限性和ASP自身的安全性限制了ASP的廣泛應用。
ASP在執行的時候，是由IIS調用程序引擎，解釋執行嵌在HTML中的ASP代碼，最終將結果和原來的HTML一同送往客戶端。

主流網站開發語言之PHP:PHP 的全名非常有趣，它是一個巢狀的縮寫名稱——「PHP: Hypertext Preprocessor」，打開縮寫還是縮寫。PHP是一種HTML 內嵌式的語言 (就像上面講的ASP那樣)。而 PHP 獨特的語法混合了C，Java，Perl以及 PHP 式的新語法。它可以比 CGI 或者 Perl 更快速地執行動態網頁。
PHP的源代碼完全公開，在 Open Source 意識抬頭的今天，它更是這方面的中流砥柱。不斷地有新的函數庫加入，以及不停地更新，使得 PHP 無論在 UNIX 或是 Win32 的平台上都可以有更多新的功能。它提供豐富的函數，使得在程式設計方面有著更好的資源。目前PHP的最新版本為4.1.1 ，它可以在Win32以及UNIX/Linux等幾乎所有的平台上良好工作。PHP在4.0版後使用了全新的Zend引擎，其在最佳化之後的效率，比較傳統 CGI 或者 ASP 等技術有了更好的表現。
平山正台無關性是PHP的最大優點，但是在優點的背後，還是有一些小小的缺點的。如果在PHP中不使用ODBC，而用其自帶的資料庫函數（這樣的效率要比使用ODBC高）來連接資料庫的話， 使用不同的資料庫，PHP的函數名不能統一。這樣，使得程序的移植變得有些麻煩。不過，作為目前應用最為廣泛的一種後台語言，PHP的優點還是異常明顯的。

ASP.NET:ASP.net是Microsoft.net的一部分，作為戰略產品，不僅僅是 Active Server Page (ASP) 的下一個版本；它還提供了一個統一的 Web 開發模型，其中包括開發輪孝人員生成企業級 Web 應用程序所需的各種服務。ASP.NET 的語法在很大程度上與 ASP 兼容，同時它還提供一種新的編程模型和結構，可生成伸縮性和穩定性更好的應用程序，並提供更好的安全保護。可以通過在現有 ASP 應用程序中逐漸添加 ASP.NET 功能，隨時增強 ASP 應用程序的功能。ASP.NET 是一個已編譯的、基於 .NET 的環境，可以用任何與 .NET 兼容的語言（包括 Visual Basic .NET、C# 和 JScript .NET.）創作應用程序。另外，任何 ASP.NET 應用程序都可以使用整個 .NET Framework。開發人員可以方便地獲得這些技術的優點，其中包括託管的公共語言運行庫環境、類型安全、繼承等等。ASP.NET 可以無縫地與 WYSIWYG HTML 編輯器和其他編程工具（包括 Microsoft Visual Studio .NET）一起工作。這不僅使得 Web 開發更加方便，而且還能提供這些工具必須提供的所有優點，包括開發臘唯稿人員可以用來將伺服器控制項拖放到 Web 頁的 GUI 和完全集成的調試支持。微軟為ASP.net設計了這樣一些策略：易於寫出結構清晰的代碼、代碼易於重用和共享、可用編譯類語言編寫等等，目的是讓程序員更容易開發出Web應用，滿足計算向Web轉移的戰略需要。

主流網站開發語言之JSP:JSP和Servlet要放在一起講，是因為它們都是Sun公司的J2EE（Java 2 platform Enterprise Edition）應用體系中的一部分。
Servlet的形式和前面講的CGI差不多，它是HTML代碼和後台程序分開的。它們的啟動原理也差不多，都是伺服器接到客戶端的請求後，進行應答。不同的是，CGI對每個客戶請求都打開一個進程（Process），而Servlet卻在響應第一個請求的時候被載入，一旦Servlet被載入，便處於已執行狀態。對於以後其他用戶的請求，它並不打開進程，而是打開一個線程（Thread），將結果發送給客戶。由於線程與線程之間可以通過生成自己的父線程（Parent Thread）來實現資源共享，這樣就減輕了伺服器的負擔，所以，Java Servlet可以用來做大規模的應用服務。
雖然在形式上JSP和ASP或PHP看上去很相似——都可以被內嵌在HTML代碼中。但是，它的執行方式和ASP或PHP完全不同。在JSP被執行的時候，JSP文件被JSP解釋器（JSP Parser）轉換成Servlet代碼，然後Servlet代碼被Java編譯器編譯成 .class 位元組文件，這樣就由生成的Servlet來對客戶端應答。所以，JSP可以看做是Servlet的腳本語言（Script Language）版。
由於JSP/Servlet都是基於Java的，所以它們也有Java語言的最大優點——平台無關性，也就是所謂的「一次編寫，隨處運行（WORA – Write Once, Run Anywhere）」。除了這個優點，JSP/Servlet的效率以及安全性也是相當驚人的。因此，JSP/Servlet雖然在國內目前的應用並不廣泛，但是其前途不可限量。
在調試JSP代碼時，如果程序出錯，JSP伺服器會返回出錯信息，並在瀏覽器中顯示。這時，由於JSP是先被轉換成Servlet後再運行的，所以，瀏覽器中所顯示的代碼出錯的行數並不是JSP源代碼的行數，而是指轉換後的Servlet程序代碼的行數。這給調試代碼帶來一定困難。所以，在排除錯誤時，可以採取分段排除的方法（在可能出錯的代碼前後輸出一些字元串，用字元串是否被輸出來確定代碼段從哪裡開始出錯），逐步縮小出錯代碼段的范圍，最終確定錯誤代碼的位置。

主流網站開發語言之CGI:CGI就是公共網關介面 (Common Gateway Interface) 的縮寫。它是最早被用來建立動態網站的後台技術。這種技術可以使用各種語言來編寫後台程序，例如C，C++，Java，Pascal等，但是目前在CGI中使用的最為廣泛的是Perl語言。所以，狹義上所指的CGI程序一般都是指Perl程序，一般CGI程序的後綴都是.pl或者.cgi 。
CGI程序在運行的時候，首先是客戶向伺服器上的CGI程序發送一個請求，伺服器接收到客戶的請求後，就會打開一個新的Process（進程）來執行CGI程序，處理客戶的請求。CGI程序最後將執行的結果（HTML頁面代碼）傳回給客戶。
由於CGI程序每響應一個客戶就會打開一個新的進程，所以，當有多個用戶同時進行CGI請求的時候，伺服器就會打開多個進程，這樣就加重了伺服器的負擔，使伺服器的執行效率變得越來越低下。這也就是最近幾年來隨著各種新的後台技術的誕生，CGI應用在Internet上越來越少的原因。CGI方式不適合大訪問量的應用。

如今主流的Web伺服器軟體主要由IIS或Apache組成。IIS支持ASP且只能運行在Windows平台下，Apache支持PHP，CGI，JSP且可運行於多種平台，雖然Apache是世界使用排名第一的Web伺服器平台，但是眾所周知，Windows以易用而出名，也因此占據不少的伺服器市場。

我們常用的開發組合:

IIS環境下
1.ASP+ACCESS
2.ASP+SQL SERVER
3.ASP.NET+ACCESS
4.ASP.NET+SQL SERVER
APACHE環境下
5.jsp+Oracale
6.JSP+MYSQL
7.PHP+MYSQL

可以說,asp確實快過時了，在未來jsp和asp.net將會有巨大的潛力，但php憑借其開源的特性也會佔有一定份額。

vb一般指vb6.0,是傳統的win32編程。vb.net和asp.net是基於微軟.net平台的語言。說java好主要是因為java的j2ee部分做企業級開發很強大，而且跨平台。c#是.net平台上最好用的語言，現在只能運行在windows系統。 web開發方面.net和j2ee的競爭很激烈，難說以後鹿死誰手。 現在做網站大部分都是asp.net或jsp的，asp.net容易上手，比較普及，但是平台單一，jsp雖然上手難，但是跨平台，安全性高。

下面比較一下ASP、ASP.net、JSP和PHP的優點和缺點：

ASP優點:
1. 無需編譯
2. 易於生成
3. 獨立於瀏覽器
4. 面向對象
5. 與任何ActiveX scripting 語言兼容
6. 源程序碼不會外漏

缺點:
1、Windows本身的所有問題都會一成不變的也累加到了它的身上。安全性、穩定性、跨平台性都會因為與NT的捆綁而顯現出來。
2、ASP由於使用了COM組件所以它會變的十分強大，但是這樣的強大由於Windows NT系統最初的設計問題而會引發大量的安全問題。只要在這樣的組件或是操作中一不注意，哪么外部攻擊就可以取得相當高的許可權而導致網站癱瘓或者數據丟失。
3、由於ASP還是一種Script語言所沒除了大量使用組件外，沒有辦法提高其工作效率。它必須面對即時編繹的時間考驗，同時我們還不知其背後的組件會是一個什麼樣的狀況。
4、無法實現跨操作系統的應用。當然這也是微軟的理由之一，只有這樣才能發揮ASP最佳的能力。可是我卻認為正是Windows限制了ASP，ASP的概念本就是為一個能讓系統運行於一個大的多樣化環境而設計的。
5、還無法完全實現一些企業級的功能：完全的集群、負載均橫。

ASP.NET優點：
1． 簡潔的設計和實施。
2． 語言靈活，並支持復雜的面向對象特性。
3． 開發環境。

缺點：
1．資料庫的連接復雜。

JSP優點：
1、 一處編寫隨處運行。
2、 系統的多台平支持。
3、 強大的的可伸縮性。
4、 多樣化和功能強大的開發工具支持。

缺點：
1、 與ASP一樣，Java的一些優勢正是它致命的問題所在。
2、 缺少系統性的資料。
3、 速度超慢

PHP優點：
1、 一種能快速學習、跨平台、有良好資料庫交互能力的開發語言。
2、 簡單輕便，易學易用。
3、 與Apache及其它擴展庫結合緊密。
4、 良好的安全性。

缺點：
1、 資料庫支持的極大變化。
2、 不適合應用於大型電子商務站點
3、 安裝復雜。
4、 缺少正規的商業支持。
5、 無法實現商品化應用的開發。