來自：http://blog.sina.com.cn/s/blog_466c6640010000nj.html
1. TUX
2. lighttpd,thttpd,shttpd
3. 幾種web server表現的對比
4. 我的總結 　　目前它還只能提供靜態的網頁服務，只有和核心區模組，使用者區模組，以及一般的使用者區Web伺服器後臺一起應用的時候才提供動態的內容服務。一般使用者區的Web伺服器不需要為了適應TUX而改變很多地方。然而，使用者區資料段程式碼必須要有一個通向TUX的系統呼叫的介面。 　　雖然動態的內容服務現在增長的很迅速，但是也必須要提供靜態的內容服務。如，所有的圖片檔案就都是靜態的。TUX能給在Linux的核心裡提供非常高效率的靜態內容服務，就象在核心裡執行的NFS網路檔案系統服務一樣。 　　TUX也有處理動態內容的功能。TUX模組用網頁緩衝儲存動態內容的物件。當一個動態的請求到達的時候，一個TUX的模組就傳送會一個聯合 的動態請求並緩衝這個請求。這就是TUX的零拷貝快取校驗的結構。（建議TUX模組不許執行在使用者區，雖然他們也可以執行在核心區。） 　　這個新的動態內容的處理需要一個新的API介面。當前的CGI的API介面不能充分的用在TUX的API上。因此，當前的CGI程式為了使 用TUX就要修改當前的程式。如果CGI程式不需要增加TUX的速度的話，TUX也可以把它安一般的CGI來處理。要實現這個功能就要用TUX的CGI模 塊。TUX也可以處理複雜的CGI或是其他的請求，這要通過它把請求重定向到另外一個web伺服器後臺程式，如Apache。也就是說，靜態的內 容，TUX模組，老的CGI程式，以及為TUX Web伺服器編寫的特定的程式都可以在TUX這個主伺服器裡執行。 　　一句話，TUX和其他的Web伺服器的區別和TUX的好處包括： TUX是作為Linux的核心2.4.x或更高的一部分來執行的，另外一部分可以做為使用者區來執行。 TUX快取部分的TCP校驗並用它們來加快網路資料傳輸速度。 用一個特定的網路卡，TUX可以從頁面快取定向分散的DMA直接到網路，這樣就避免了資料的拷貝。 當TUX不知道如何去處理一個請求或是接受到一個請求不能去執行的時候，它一般會把這個請求傳送到使用者區的Web伺服器後臺去處理它。一個典型的使用者區Web伺服器就是Apache。 2．TUX 2.0的新功能 　　TUX 2.0是從TUX 1.0升級成的，仍然保守著與使用者區模組的相容性。 　　增加的功能包括：      真正的零磁碟讀拷貝，TUX1.0是放到一個臨時的快取裡的。
     生成網路寫的零拷貝。
     零拷貝解析。
　
 　其他新功能：      提高使用者去功能模組的支援。
     虛擬主機的支援，它不限制虛擬主機的數量。
     CGI可以繫結到特定的程序
     一些BUG的修復。 3．系統的基本需要      TUX需要基於2.4.x核心或是更高版本的系統。
     基於X86的伺服器。
     交替的Web伺服器如Apache來處理不知道的請求
　當前的限制：
 
     核心模組只支援伺服器端。
     TUX只在x86的Linux平臺上測試過。
     TUX能請求其他的Web伺服器如Apache來處理請求。在當前的版本，它對回滾不是處理的很好。
lighttpd,thttpd,shttpd
國內絕大部分的web server不是IIS就是Apache，而論市場佔有率，我認為Apache是大贏家了，至少是佔據了半壁江山。
但 除了IIS/Apache外，其實我們有很多選擇，對於高負載/大併發的網站而言，高效能、輕量級的web server是一劑良藥。最近手頭一臺Server 的負載太高，居然將swap吃光導致機器非常緩慢，後來一查，原來是Apache耗掉了幾乎所有資源，當時apache程序已有9XX個了。
於是用輕量級的web server替換掉apache就進入了日程表。這裡順帶介紹一下這些可選的物件：
lighttpd
官方主頁：

www.lighttpd.net
Lighttpd是一個德國人領導的開源軟體，其根本的目的是提供一個專門針對高效能網站，安全、快速、相容性好並且靈活的web server環境。具有非常低的記憶體開銷，cpu佔用率低，效能好，以及豐富的模組等特點。
lighttpd 是眾多OpenSource輕量級的web server中較為優秀的一個。支援FastCGI, CGI, Auth, 輸出壓縮(output compress), URL重寫, Alias等重要功能，而Apache之所以流行，很大程度也是因為功能豐富，在lighttpd上很多功能都有相應的實現了，這點對於apache的用 戶是非常重要的，因為遷移到lighttpd就必須面對這些問題。
實用起來lighttpd確實非常不錯，上文提到的apache overload的問題，用lighttpd就完全解決了。apache主要的問題是密集併發下，不斷的fork()和切換，以及較高（相對於 lighttpd而言）的記憶體佔用，使系統的資源幾盡枯竭。而lighttpd採用了Multiplex技術，程式碼經過優化，體積非常小，資源佔用很低， 而且反應速度相當快。
利用apache的rewrite技術，將繁重的cgi/fastcgi任務交給lighttpd來完成，充分利用兩者的優點，現在那臺伺服器的負載下降了一個數量級，而且反應速度也提高了一個甚至是2個數量級！
下面是他們官方站點上的一段話：
"lightTPD is the BEST webserver out there, much faster than apache and much much much more flexible/configurable/secure than tux, and its fcgi php support is simply unbeatable." thttpd
官方網站：

http://www.acme.com/software/thttpd/
thttpd 是一個非常小巧的輕量級web server，它非常非常簡單，僅僅提供了HTTP/1.1和簡單的CGI支援，在其官方網站上有一個與其他web server（如Apache, Zeus等）的對比圖+Benchmark，可以參考參考。此外，thttpd 也類似於lighttpd，對於併發請求不使用fork()來派生子程序處理，而是採用多路複用(Multiplex)技術來實現。因此效能很好。
Thttpd 支援多種平臺，如FreeBSD, SunOS, Solaris, BSD, Linux, OSF等。對於小型web server而言，速度快似乎是一個代名詞，通過官方站提供的Benchmark，可以這樣認為：thttpd至少和主流的web server一樣快，在高負載下更快，因為其資源佔用小的緣故。
Thttpd還有一個較為引人注目的特點：基於URL的檔案流量限制，這對於下載的流量控制而言是非常方便的。象Apache就必須使用外掛實現，效率較thttpd低。 shttpd
官方網站：

http://shttpd.sourceforge.net/ Shttpd是另一個輕量級的web server，具有比thttpd更豐富的功能特性，支援CGI, SSL, cookie, MD5認證, 還能嵌入(embedded)到現有的軟體裡。最有意思的是不需要配置檔案！
由於shttpd可以嵌入其他軟體，因此可以非常容易的開發嵌入式系統的web server，官方網站上稱shttpd如果使用uclibc/dielibc(libc的簡化子集)則開銷將非常非常低。以下是其特點： Stand-alone server, or embeddable into existing C/C++ program
GET, POST, PUT, DELETE methods
CGI
SSL
Digest (MD5) authorization
Multiple (and user defineable) index files
Directory listing
Standard logging
Cookies
inetd mode
User-defineable mime types
No configuration files
No external dependencies 由於shttpd可以輕鬆嵌入其他程式裡，因此shttpd是較為理想的web server開發原形，開發人員可以基於shttpd開發出自己的webserver！
下面是我翻譯的LiteSpeed Web Server官方的一篇文章。 圖片請參見...... http://www.litespeedtech.com/benchmark.html
幾種web server表現的對比：
被測試的web server 軟體
測試環境
測試結果
 以小的靜態檔案為測試基準
 以CGI為基準
 以FAST CGI為基準
 以PHP指令碼為基準：mod_php vs. FastCGI PHP
 以Perl指令碼為基準：mod_perl vs. lsperld
結論。 被測試的web server 軟體
下面幾種web server都包含在這次測試中。
Apache 1.3.33
Apache 2.0.52 (prefork mpm)
IIS 6.0
LiteSpeed 2.0 Standard
LiteSpeed 2.0 Professional
thttpd 2.25b
TUX 3.2
boa 0.94.14rc20
lighttpd 1.3.12
Aolserver 4.0.7
Mathopd 1.5p3
說明一下LSWS 是LiteSpeed Web Server的縮寫。
本來也很想把zeus和 sunone也放到這次基準測試中來，但是那些軟體的宣告不允許對對它們的測試結果進行公佈。 測試環境
Network Switch: D-Link Gigabit Eight Ports Switch DGS-1008D
Server Hardware: Dell PowerEdge SC1600
CPU: Single Intel Xeon 2.4GHz/533FSB/512KB L2 Cache
memory: 256MB ECC PC2700
Hard Drive: 36GB 10K RPM SCSI drive Seagate ST336607LW
NIC: on board Intel PRO/1000 Gigabit Adapter
Server Software:
Fedora Core 3 with stock kernel 2.6.10-1.760
IIS 6.0 on Windows 2003 Enterprise
Web Server Configurations:
Apache 1.3.33
Apache 2.0.52
IIS 6.0 - default
LiteSpeed 2.0 Standard - default
LiteSpeed 2.0 Professional - default
thttpd
TUX 3.2 - default
boa
lighttpd
Aolserver
Mathopd
如果想知道他們當時的具體配置可以去原文中檢視，Web Server Configurations: http://www.litespeedtech.com/benchmark.html  。 注意：LiteSpeed 和 lighttpd都支援在2.6核心中新的i/o 事件傳送器sys_epoll()。但是有意思的是。我們發現這兩種server基準測試的結果還沒以前的標準時間傳送器poll(),表現的好。
至少當我們通過網路測試併發等級<=1000的時候，我們僅僅用poll()來做我們所有的測試。
結果可能會和在本地機上通過迴路測試完全不同。 Client Hardware: MSI K7D
CPU: Dual Athlon MP 2000+/266FSB/256KB L2 Cache
memory: 1GB PC2100
Hard Drive: 36GB 1000RPM SCSI drive
NIC: Intel PRO/1000 Gigabit Adapater
Client Software:
OS: RedHat 8.0 with kernel 2.4.22smp
Test Tool: ApacheBench (ab) 1.3.33
測試結果：
每種情況執行3次，最好的結果被採納。伺服器被重新啟動，當每次測試完一種web server軟體。
以小的靜態檔案為測試基準
小的靜態頁面大小隻有100 bytes。用小檔案測試的原因是為了避免網路頻寬瓶頸。我們只為了展示web server的表現，而不是核心。
Non-KeepAlive test: ab -n 100000 -c <concurrent level> http://<ip>:<port>/100.html
 
這兒必然有某種Anti-DoS特性在IIS 6.0中，當併發等級大於10（小於100）的時候它丟棄了所有的連線。 KeepAlive test: ab -n 100000 -c <concurrent level> -k http://<ip>:<port>/100.html
 
CGI 基準測試
一個簡單的c cgi指令碼(echo)被用來在這裡測試。它是C CGI/FCGI在fcgi 2.4包中 的例子。用來打印出所有的cgi環境變數。
CGI Test: ab -n 3000 -c <concurrent level> http://<ip>:<port>/cgi-bin/echo
  不知道為什麼什麼原因使thttpd's CGI在這表現如此差。
Fast CGI 基準測試
一個簡單的c++ cgi指令碼(echocpp) 被用來這裡測試。它是一個fcgi 2.4包中修改版本的c++ FCGI例子。它被修改成只產生一個恆定的響應。這個響應是162 byte在響應體中（response body）。從請求到請求發生改變的部分被去掉了，因為ab（ApacheBench）不喜歡變長響應體的響應。
Fast CGI Test: ab -n 10000 -c <concurrent level> http://<ip>:<port>/cgi-bin/echo
  PHP指令碼基準測試: mod_php vs. FastCGI PHP
兩個簡單的php指令碼被用來測試。一個是hello.php只 輸出hello world。另一個是phpinfo.php，只調用phpinfo()。這裡都沒有配置操作碼加速器（opcode accelerator）。因為他們對這兩個簡單的php指令碼沒有太大的影響。
hello.php test: ab -n 10000 -c <concurrent level> http://<ip>:<port>/hello.php
 
phpinfo.php test: ab -n 10000 -c <concurrent level> http://<ip>:<port>/phpinfo.php
  Perl 指令碼基準測試: mod_perl vs. lsperld
一個Hello World perl指令碼，產生一個77 bytes的響應體。被用來測試。
Apache 2.0沒有測。因為在同一個伺服器上既為 1.3又為2.0安裝mod_perl太麻煩了。
Apache 1.3 被配置成用 Apache::Registry去處理perl 指令碼.
Lsperld 是一個Perl Fast CGI 指令碼它可以執行CGI perl 指令碼在一個 persistent Perl interpreter中, 就像 Apache mod_perl's Apache::Registry, 編譯perl 指令碼，cached 到記憶體中。 hello.pl test: AB -n 10000 -c <concurrent level> http://<ip>:<port>/hello.pl
  總結：
在以上的基準測試結果中我們得到了以下的結論。
Apache 1.3和 2.0的表現非常相近。2.0沒有什麼優勢。我們沒有測試Apache 2.0的worker MPM。因為prefork MPM更有可能被用於Unix/Linux系統的應用。跟Apache比起來, LiteSpeed Web Server能快3-7倍當它處理靜態內容的時候。當處理動態內容的是時候能快50-100%，包括CGI, FastCGI, PHP and Perl.方式。
我們早期的測試表明，Apache的效能下降非常大，當distributed configuration override (.htaccess) 被設定為enabled。然而LiteSpeed web server幾乎不受影響。所以我們將能看到更大的差距在一個共享的主機環境中。 跟這些純粹的使用者區（land） 內容加速器像thttpd, boa 和mathopd比較起來, LiteSpeed Web Server 在處理靜態內容上有更好的表現。跟kernel核心內容加速器比較起來，TUX,由於在核心中的快捷和簡單的特性設定。LiteSpeed Web Server Pro在non-keep-alive測試中表現有點遜色。
這全部的LiteSpeed web server的表現，包括Standard 和 Professional版本，比其他所有被測試的web server軟體都好。
  LiteSpeed Web Server 是一個多元（one-stop） 解決方案在高效能web服務環境中.
如果你真的想你的網站停止遭受各種各樣效能表現上的問題和在你現有的硬體上表現出最好的web服務的產出。你應該認真的考慮切換到LiteSpeed.。它將省去你所有在優化你的web各部分的時候所有頭疼的事情。因為我們已經為你做完了所有艱難的工作。
我的總結：
如果只有靜態頁面和圖片的話，可以用Zeus或者TUX，效率比apche高很多，尤其是TUX因為是和核心心結合的有較高的效率我認為是靜態內容server的最佳選擇，但他的限制是必須使用linux2.4以上的核心。我們的freebsd系統可能無法使用。 至於apache1.3和apache2.0對於理靜態內容的比較，和worker MPM 與 prefork MPM效能方面的比較，我還沒有一個權威的資料來說明。對於負載不是很高的站點，需要較高的穩定性的話，apache還是很好的選擇。 LiteSpeed Web Server的介紹我在這裡沒有列出，從比較來看，他的綜合性能是不錯的。我可以給出一段他的描述：http://www.litespeedtech.com/
LiteSpeed web server is an Apache interchangeable, full-featured high performance, secure HTTP server specifically engineered from the ground up with security and scalability in mind. lighttpd,thttpd,shttpd的穩定性還沒有一個肯定的說法。
以後再對這個文件進行補充。翻譯的不正確的地方歡迎指出，可以參看原文。