本文已經發表于InfoQ中文站點（http://www.infoq.com/cn/news/2007/07/light-web-servers）
IBM developerWorks網站上最近發布了一則Cameron Laird的關于輕量級Web服務器的文章，
里面列舉了很多的輕型的Web服務器實現和它們的特點，Cameron還從自己的經驗出發總結了評價Web服務器的一些指標。這篇文章目的在于擴展我們在
Web應用部署時的思路，讓我們重新思考Web應用的架構和部署方案。眾多的輕量級Web服務器其實見證了動態腳本語言實現Web應用的火爆，給實現
Web應用提供了更多解決方案。
輕量Web服務器這個概念關注“輕巧性”，這意味著簡單、易于安裝、流線化、要求低和健壯。這種“輕巧”主要是相對于目前市場占有率占優的
Apache和IIS而言的，輕量Web服務器應該更小更簡單，并且它們至少要有一些性能／特性超過這兩個產品（這樣它們才可能分得市場份額）。
Cameron這樣對比了“輕量”相比“重量”的一些優勢：
輕量級Web服務器可以適用于市場領頭產品和其他“重量級”服務器無法勝任的情況。例如，整個服務器可以打包在一個文件中。這意
味著開發人員可以方便地攜帶生產環境所需的所有工具。即使在生產服務器上運行的是
Apache，也仍然可以在賓館的房間里，借助只需數秒鐘就可以安裝完畢的輕量級Web服務器以嘗試新想法。而且，由于輕量級Web服務器要求很低，因此
可以在那些無法負擔IIS的主機上順暢地運行。
我們關注一下目前的Web服務器占有率情況，Netcraft在它2007年7月的Web服務器調查中的服務器占有率數據如下：
| 開發者 |
2007年6月 |
百分比 |
2007年7月 |
百分比 |
變更率 |
| Apache |
65588298 |
53.76 |
66144734 |
52.65 |
-1.11 |
| Microsoft |
38836030 |
31.83 |
41257913 |
32.84 |
1.01 |
| Google |
4872765 |
3.99 |
5465538 |
4.35 |
0.36 |
| Sun |
2273173 |
1.86 |
2245493 |
1.79 |
-0.07 |
| lighttpd |
1470930 |
1.21 |
1471779 |
1.17 |
-0.04 |
| Zeus |
480698 |
0.39 |
463449 |
0.37 |
-0.02 |
其中Apache占有率最高，它是公認的穩定、性能優良、開發者活躍的開源軟件產品。而Microsoft則受益于Windows平臺內置的PWS
和IIS的優勢及.NET平臺的市場占優率，占有第二的位置。Sun則是由于歷史問題，它的iPlanet、SunONE和一并計算的Netscape-
Communications產品還能躋身前4。后面的lighttpd則是輕量型Web容器的代表，已經超過了老牌的商業Web服務器Zeus
（ServerWatch給出了一個lighttpd市場占有率上升的分析），主要因為一些AJAX項目和Ruby on Rails（以下簡稱RoR）的流行對它的廣泛部署起了推波助瀾的作用。
輕量Web服務器除了lighttpd還有mongrel也經常被提及，主要因為它們是RoR項目的兩種主要部署方案。JavaEye的創始人Robbin Fan曾經在它的blog中對比過RoR的這兩種部署方案：
（RoR項目）用fcgi方式還是http方式，我個人覺得區別不大，關鍵還是看應用的場合，一般而言，推薦的搭配是lighttpd＋fcgi 或者nginx＋mongrel，而Apache因為性能差距，而不被推薦。
lighttpd+fcgi是大量使用腳本語言編寫的網站的首選部署方案，Robbin Fan在同一篇文章中闡述了他選擇lighttp部署JavaEye的理由：
JavaEye為什么用lighttpd＋fcgi呢？原因如下：
1) lighttpd發展了好幾年了，市場占有率也相當高，是一個經過實踐檢驗的server，它的文檔也很全；
2) JavaEye的Ruby進程和Web Server在一臺機器上面跑，通過unix socket使用fcgi協議通訊可以避免tcp的網絡開銷，其通訊速度比使用tcp socket使用http協議通訊要快一些。
Robbin選擇lighttpd的主要原因是性能好于Apache。并且Apache目前的fastcgi模塊有些bug，而對于像RoR這樣的項目fastcgi是一種很好的部署方式，所以Apache就因此失去了這塊份額。最近InfoQ報道過的RubyWorks提
供的RoR工作棧中選擇了Haproxy+mongrel的方式，這也是前面引用的Robbin所說的另外一種部署方案。mongrel本身可以跑
Ruby進程，同時也是一個http服務器，它可以兼顧動態和靜態Web服務，配合Haproxy做負載均衡就可以支持大并發量的Web應用，所以它越來
越流行了。
可見輕量級Web服務器由于性能／特性上的一些優勢，開始逐漸瓜分Apache、IIS所沒有照顧到的一些新興的市場分額。那么如何去評價一個Web服務器呢？Cameron給出了如下的
一些重要指標：
性能：對請求作出響應的速度有多快？
可伸縮性：當很多用戶同時訪問它時，服務器還能繼續可靠地運行嗎？
安全性：服務器是否只執行它應該執行的操作。它在認證用戶和加密傳輸方面提供了怎樣的支持？它的使用是否使附近的應用程序或主機變得更易受攻擊？
可靠性：服務器的失效模式和故障發生率如何？
標準遵從性：服務器遵從相關的 RFC 嗎？
靈活性：是否可以對服務器進行調優，以支持較重的請求負載、需要計算的動態頁面或者代價不菲的認證等等？
平臺需求：該服務器可用于哪些平臺？它是否有特定的硬件需求？
易管理性：服務器是否易于設置和維護？它是否與日志記錄、審計、成本計算等組織標準兼容？
目前越來越多的輕型Web服務器開始在上面的一個或著多個方面向Apache和IIS提出了挑戰，因為很難有一個Web服務器可以做到面面俱到。我們可以從Cameron提供的一份列表里面看到一些選用輕量級Web服務器的
成功案例：
YouTube依靠lighttpd快速交付歸檔的內容，例如視頻；
cdServe運行 “German Woodworking Machinery and Tools” CD；
LiteSpeed宣揚它在
twitter、www.funnyoride.com、www.airliners.com、WordPress.com、
fanfiction.com、SlashGear、www.forumactif.com 和其他著名Web 站點上擔任的角色；
OpenSUSE、RubyOnRails、MarkaBoo和其他一些著名站點依賴于Mongrel；
demon.net、bluelight.com、mtv.com、The Drudge Report、garfield.com等站點則使用thttpd；
上面的例子中有一些使用RoR的網站的例子，Cameron指出不僅是網站可以使用常規以外的其他編程語言。“不常見”語言還可以被用來實現輕量
Web服務器，例如Erlang、Java、Lisp、Lua、Perl、Python和Tcl。用這些語言實現的輕量級Web服務器不一定只是在性能／
特性上超過Apache和IIS，它們可以提供例如容易嵌入、體積輕小這樣的特性來吸引開發者的使用。Cameron給出了使用“不常見”語言編寫輕量級
Web服務器的原因：
教學：使用輕量級Web服務器來制定一個重要、但是并不太大的目標。這是獲得使用某種語言的經驗的好方法。
雖然用C編寫的輕量級Web服務器大小為10-50KB，更高級的語言有100KB到數MB的運行時，但整個 Web 服務器的源文件可能只占幾千個字節。這種Web服務器占用的空間很小，因此比Apache更易于與技術伙伴共享。
更高級的語言可以使實驗更吸引人 —— 例如，添加一個新的HTTP/1.1特性可能只需幾行源代碼。這些輕量級服務器是非常方便的實驗材料。
將HTTP服務器添加到已有的、用高級語言編寫的應用程序中只需增加幾行源代碼。
如前所述，不同的輕量級Web服務器有著不同的優點，它們或多或少獨立于編程語言。所有輕量級Web服務器都比Apache更小、更易于配置。與
Apache相比，有些輕量級 Web
服務器更快，有些則快得多。有些則強調安全性、重負載下的從容性、可擴展性或者內存占有量。在任何情況下，都可以以一種不適用于 Apache
的方式徹底地理解這些服務器。
這些理由從另外一個方面說明了輕量級Web服務器的優勢，Cameron還提供了一長串的輕量級Web服務器的列表和簡介，感興趣的讀者可以認真閱讀，從中尋找到您感興趣的實現。輕量級Web服務器不只是Apache、IIS的競爭者，也是很好的合作者（例如我們經常可以見到關于mongrel與Apache配合使用的文章），現在我們還可以看到很多服務器協作部署的例子，各取所長應該是最佳的選擇，所以我們更應該從現在就開始拓寬眼界，尋找我們所需要的。
最后，推薦對Web服務器感興趣的讀者可以使用Netcraft提供的Webserver Search的服務器查詢功能來探索你感興趣的網站的服務器，Webserver Search可以報告搜索的url對應的服務器的操作系統和Web服務器類型，是設計部署方案的一個很好參考。