嵌入式設備web服務器比較
現在在嵌入式設備中所使用的web服務器主要有：boa、thttpd、mini_httpd、shttpd、lighttpd、goaheand、appweb和apache等。
Boa
1.介紹
Boa誕生于1991年，作者Paul Philips。是開源的，應用很廣泛，特別適合于嵌入式設備，網上流行程度很廣。它的官方網站說boa是最受人喜愛的嵌入式web服務器。功能較為強 大，支持認證，cgi等。Boa 是一個單任務的HTTP SERVER，它不像傳統的web服務器那樣為每個訪問連接開啟一個進程，也不會為多個連接開啟多個自身的拷貝。Boa對所有的活動的http連接在內部 進行處理，而且只為每個CGI連接（獨立的進程）開啟新的進程。因此，boa在同等硬件條件下顯示出更快的速度。測試表明boa在Pentium 300MHZ下能夠每秒鐘處理幾千次點擊，在20 MHz 386/SX下能夠每秒鐘處理幾十次點擊訪問。
Boa和thttpd等，與apache等高性能的web服務器主要區別是，它們一般是單進程的服務器，只有在完成一個用戶請求后才能響應另一個用戶的請求，無法并發響應，但這在嵌入式設備的應用場合里已經足夠了。
Boa設計主要出于速度和安全，是指不被惡意用戶暗中破壞，而不是指它有很好的訪問控制和通信加密。可以添加SSL來保證數據傳輸中的保密和安全。
2.操作系統
All POSIX (Linux/BSD/UNIX-like OSes)
3.版本
從0.90到現在的最新發布版本0.94。最新發布版本0.94：boa-0.94.13.tar大小為120k，解壓后為436k，編譯之后的可執行代碼在60k左右。最近開發版本：boa-0.94.14rc21
4.可執行程序的大小、內存需求情況
Boa有最少的資源需求。非常少的內存需求，能耗很小。 特別適合于嵌入式市場。含有gcc 2.95.3和 GNU libc 2.2.5的boa的二進制文件大小為61K（ 495K statically linked ）。使用庫uClibc，boa變得更小（92K statically linked）。
有人曾做過測試：所用環境AMD Duron 700，384MB RAM, RealTek 8139，SiS900 chipset-based NICs ，LinkSys 10/100 hub，Linux 2.4，結果是：Boa的虛擬內存（VmSize）大小是1696kB，85％是庫文件。虛擬內存數據（VmData size）大小是108kB。Boa每次連個并發連接消耗掉20kB的內存。
參考比較表：
Server
Stripped Binary Size
VmSize
External Libraries
Boa 0.94.13
61kB
1700kB
0
Apache 1.3.26
277kB
11,000kB
9
thttpd 2.20c
64kB
1800kB
0
5.功能、特點
l 支持HTTP/1.0(實驗性的、有條件的支持HTTP/1.1)
l 支持CGI/1.1，編程語言除了C語言外，還支持Python, Perl, PHP，但對PHP沒有直接支持，沒有mod_perl, mod_snake/mod_python等。
l 它可以配置成SSL/HTTPS和 IPv6。
l 支持虛擬主機功能。
Boa服務器與其它服務器的不同：
為了追求速度和簡單性，boa服務器在一些方面不同于一些流行的web服務器。
CGI程序的REMOTE_HOST環境變量沒有設置
The REMOTE_HOST environment variable is not set for CGI programs, for reasons already described. This is easily worked around because the IP address is provided in the REMOTE_ADDR variable, so (if the CGI program actually cares) gethostbyaddr or a variant can be used.
Boa不具有ssi（server side includes）。
We don't like them, and they are too slow to parse. We will consider more efficient alternatives.
Boa不具有訪問控制。
Boa will follow symbolic links, and serve any file that it can read. The expectation is that you will configure Boa to run as user "nobody", and only files configured world readable will come out.
沒有chroot選項。
There is no option to run chrooted. If anybody wants this, and is willing to try out experimental code, contact the maintainers.
官方網站：www.boa.org
Thttpd
1.介紹
Thttpd是ACME公司設計的一款比較精巧的開源Web服務器。它的初衷是提供一款簡單、小巧、易移植、快速和安全的HTTP服務器，而事實 上，Thttpd也正是這樣一款服務器。它在Unix系統上運行的二進制代碼程序，僅僅400k左右，在同類Web服務器中應該是相當精巧的。在可移植性 方面，它能夠在幾乎所有的Unix系統上和已知的操作系統上編譯和運行。Thttpd在默認的狀況下，僅運行于普通用戶模式下，從而能夠有效地杜絕非授權 的系統資源和數據的訪問，同時通過擴展它也可以支持HTTPS、SSL和TLS安全協議。Thttpd尤為稱道的是已經全面支持IPv6協議， 并且具有獨特的Throttling功能，可以根據需要限制某些URL和URL組的服務輸出量。此外，Thttpd全面支持HTTP 1.1協議（RFC 2616）、CGI 1.1、HTTP 基本驗證（RFC2617）、虛擬主機及支持大部分的SSI（Server Side Include）功能，并能夠采用PHP腳本語言進行服務器端CGI的編程。
thttpd是一個非常小巧的輕量級web server，它非常簡單，對于并發請求不使用fork()來派生子進程處理，而是采用多路復用(Multiplex)技術來實現。因此效能很好。對于小 型web server而言，速度快似乎是一個代名詞，通過官方站提供的Benchmark，可以這樣認為：thttpd至少和主流的web server一樣快，在高負載下更快，因為其資源占用小的緣故。Thttpd還有一個較為引人注目的特點：基于URL的文件流量限制，這對于下載的流量控 制而言是非常方便的。象Apache就必須使用插件實現，效率較thttpd低。Thttp是開源的。是用C語言編寫的。使用的很多。
2.操作系統
Thttpd支持多種平臺，如FreeBSD, SunOS, Solaris, BSD, Linux, OSF等。
3.版本
最新版本：thttpd-2.25b.tar 130kB，解壓后497kB
4. 可執行程序的大小、內存需求情況
編譯后的可執行的二進制文件為60kB左右，與boa差不多。版本已從1.90a發展到2.25b，
使用內存很少，沒查到具體的數據。
5.特點、功能
thttpd中是一個簡單,小型,輕便,快速和安全的http服務器.
特點：
簡單：它能夠支持HTTP/1.1協議標準，或者超過了最低水平
小巧：它具有非常少的運行時間，因為它不fork子進程來接受新請求，并且非常謹慎
的分配內存
便攜：它能夠在大部分的類Unix系統上運行，包括FreeBSD, SunOS 4, Solaris 2, BSD/OS, Linux, OSF等等
快速：它的速度要超過主流的Web服務器（Apache, NCSA, Netscape），在高負載情況下，它要快的多。
安全：它努力的保護主機不受到攻擊，不中斷服務器
thttpd，適合靜態資源類的服務，比如圖片、資源文件、靜態HTML等等的應用，性能應該比較好，同時也適合簡單的CGI應用的場合。
功能：
l 支持CGI1.1。
l 支持基本的認證功能。
l 支持Chroot功能
l 支持Throttling。
l 支持IPv6。
l 支持多虛擬主機功能。
l 支持自定義錯誤頁。
l 支持標準日志記錄。
l Thttpd處理了大量的信號，這些信號是通過標準的Unix kill(1) command發出的。
l 通過擴展它也可以支持HTTPS、SSL和TLS安全協議。
使用建議: 對于那些并發訪問量中等，而又需要較強響應能力、并期望能夠控制用戶訪問流量，而且有較高安全性需求的用戶而言，thttpd Web服務器顯然是一個比較好的選擇。 thttpd目前的最新版本是2.2.5版。
下圖為www.acme.com/software/thttpd網站對幾種web server比較圖。
· Software – 哪種web服務器
o Model - what kind of server it is. The models are:
§ fork - start a new process for each request.
§ pre-fork - pre-start a pool of processes which each handle multiple requests.
§ threads - use threads instead of processes.
§ Java threads - this version of the Java runtime uses "Green threads" instead of native threads, so it acts more like the select-based servers.
§ select - use non-blocking I/O and the select() system call to handle multiple requests in a single process, single thread.
從上面可以看到thttpd、boa都是使用select方式，apache使用的是pre-fork方式，由于apache是多進程方式，thttpd、boa是單進程方式，所使用的內存要遠小于apache，且速度快于apache。
o Auto-conf （自動配置）- whether there's a script to automatically configure the build process for your OS.
o Basic auth （基本認證）- whether the server supports Basic Authentication, for password-protected web pages.
o Chroot - whether the server lets you use the chroot() system call to enhance security.
o Throttling - the ability to set bandwidth limits on certain pages, so they don't use more than their fair share of the server's resources.
o Tar bytes - the uncompressed source tarchive size.
o Source files - how many source and header files.
o Source lines - how many lines in the source and header files.
o Exe - the executable size. For the compiled program this is size of the main executable file, stripped. For the Java servers it's the total size of the .class files or .zip files. For Roxen it's the size of the Pike interpreter.
· 基礎測試系統。The benchmark test system is a 297MHz Ultra Sparc with 256MB RAM / 512MB swap running Solaris 2.6, otherwise totally quiescent. RLIMIT_NOFILE is 256 soft / 1024 hard, and v.v_maxup is 3941.
· RPS – 每秒響應請求次數。maximum requests per second. This is determined by running the test load at various parallel-request rates and finding the maximum response rate. See the graph below for the full data.
o Small files - the small-file test load consists of 1000 files, each 1KB long, requested randomly.
o CGI - the CGI test load consists of a trivial "hello world" C program. .
· Max users – 最大處理的用戶數。This is determined by running the test load at various parallel-request rates and seeing when it starts screwing up. Typical screwups are running out of memory or processes, so that requests start timing out or getting refused.
o Large files - the large-file test load consists of 100 files, each 1MB long, requested randomly. Also, each connection is throttled to simulate a 33.6Kbps modem. Note that 1000 33.6Kbps connections is 3/4 of a T3.
上面的比較中，thttpd和boa都沒有使用最新版本，boa的最新版本已經支持基本認證、自動配置等功能。Thttpd和boa的基本功能差不 多，可以互相替換。現在選用web服務器時，同時有boa和thttpd的情況下，選擇使用boa的情況居多。我在一篇論文中提到一點，說：thttpd 在運行過程中所需要的資源要遠大于boa，但沒有驗證過。
官方地址：http://www.acme.com/software/thttpd/
下載地址：http://www.acme.com/software/thttpd/thttpd-2.25b.tar.gz
Mini_httpd
1. 介紹
Mini_httpd是一個小型的HTTP服務器。開源，它的性能不強，但是它非常適合于中小訪問量的站點。Mini_httpd和thttpd都是ACME Labs 開發的軟件，功能沒有thttpd強。
2. 操作系統
與thttpd相同。
3. 版本
發布的版本從1.00到1.19。最新發布的版本是version 1.19.tar 41kB,解壓后為140kB。
4. 功能、特點
它實現了HTTP服務器的所有的基本功能，包括：
· 支持CGI功能
· 支持基本的驗證功能
· 支持安全 .. 上級目錄功能
· 支持通用的MIME類型
· 支持目錄列表功能
· 支持使用 index.html, index.htm, index.cgi 作為首頁
· 支持多個根目錄的虛擬主機
· 支持標準日志記錄
· 支持自定義錯誤頁
· Trailing-slash redirection
· 它可以配置成SSL/HTTPS和 IPv6.
5.可執行文件大小、內存使用情況
編譯后可能要小于boa、thttpd，內存使用可能小于boa、thttpd。Mini_httpd的功能，thttpd功能幾乎都覆蓋了。
mini_httpd 也是相對比較適合學習、實驗使用，大體實現了一個Web Server的功能，支持靜態頁和CGI，能夠用來放置一些個人簡單的東西，不適宜投入生產使用。
官方地址：http://www.acme.com/software/thttpd/
下載地址：http://www.acme.com/software/mini_httpd/mini_httpd-1.19.tar.gz
Shttpd
1.介紹
Shttpd，開源。它是另一個輕量級的web server，具有比thttpd更豐富的功能特性，支持CGI, SSL, cookie, MD5認證, 還能嵌入(embedded)到現有的軟件里。最有意思的是不需要配置文件！由于shttpd可以輕松嵌入其他程序里，因此shttpd是較為理想的 web server開發原形，開發人員可以基于shttpd開發出自己的webserver，官方網站上稱shttpd如果使用 uclibc/dielibc(libc的簡化子集)則開銷將非常非常低。
2.操作系統
Windows, QNX, RTEMS, UNIX (*BSD, Solaris, Linux)。
3.版本
它的最新版本是：shttpd-1.38.tar ，75kB，解壓后為278kB。發布的版本從2004年的1.3到現在的2007年的1.38
4.功能、特點
l 小巧、快速、不膨脹、無需安裝、簡單的40KB的exe文件，隨意運行
l 支持GET, POST, HEAD, PUT, DELETE 等方法
l 支持CGI, SSL, SSI, MD5驗證, resumed download, aliases, inetd模式運行
l 標準日志格式
l 非常簡單整潔的嵌入式API
l 對庫dietlibc 支持友好，對uClibc (*)不友好。
l 容易定制運行在任意平臺：Windows, QNX, RTEMS, UNIX (*BSD, Solaris, Linux)
不具有的功能：
virtual hosts, user home directorires, ACL (access control lists), traffic shaping, keep-alive connections, FCGI (Fast CGI) support.
5.可執行文件大小、內存使用情況
編譯后的可執行的二進制文件為40kB左右.
網上查詢結果是有關內容很少。使用范圍不廣。有網友對它的評論是：shttpd功能算是比較全的, 但在處理二進制數據時不夠穩定, 時有異常. 有待觀察。
官方網站：http://shttpd.sourceforge.net/
下載地址：http://sourceforge.net/project/showfiles.php?group_id=126090&package_id=137886
Lighttpd
1.介紹
Lighttpd是一個德國人領導的開源軟件，歷時只有三年。其根本的目的是提供一個專門針對高性能網站，安全、快速、兼容性好并且靈活的web server環境。具有非常低的內存開銷，cpu占用率低，效能好，以及豐富的模塊等特點。lighttpd 是眾多OpenSource輕量級的web server中較為優秀的一個。支持FastCGI, CGI, Auth, 輸出壓縮(output compress), URL重寫, Alias等重要功能，而Apache之所以流行，很大程度也是因為功能豐富，在lighttpd上很多功能都有相應的實現了，這點對于apache的用 戶是非常重要的，因為遷移到lighttpd就必須面對這些問題。實用起來lighttpd確實非常不錯，apache主要的問題是密集并發下，不斷的 fork()和切換，以及較高（相對于 lighttpd而言）的內存占用，使系統的資源幾盡枯竭。而lighttpd采用了Multiplex技術，代碼經過優化，體積非常小，資源占用很低， 而且反應速度相當快。利用apache的rewrite技術，將繁重的cgi/fastcgi任務交給lighttpd來完成，充分利用兩者的優點，現在 那臺服務器的負載下降了一個數量級，而且反應速度也提高了一個甚至是2個數量級！lighttpd 適合靜態資源類的服務，比如圖片、資源文件、靜態HTML等等的應用，性能應該比較好，同時也適合簡單的CGI應用的場合，lighttpd可以很方便的 通過fastcgi支持php。
2.操作系統
Unix、linux、Solaris、FreeBSD
3.版本
最新版本lighttpd-1.4.17.tar,783kB,解壓后為3.48MB
4.功能、特點
下面是lighttpd官方網站給出的lighttpd特點，
l virtual hosts
l virtual directory listings
l URL-Rewriting, HTTP-Redirects
l automatic expiration of files
l Large File Support (64bit fileoffsets)
l Ranges (start-end, start-, -end, multiple ranges)
l on-the-fly output-compression with transparent caching
l deflate, gzip, bzip2
l authentication
l basic, digest
l backends: plain files, htpasswd, htdigest, ldap
l fast and secure application controlled downloads
l Server Side Includes
l User Tracking
l FastCGI, CGI, SSI
l PHP-Support:
l same speed as or faster than apache + mod_php4
l includes a utility to spawn FastCGI processes (neccesary for PHP 4.3.x)
l via FastCGI and CGI interface
l support Code Caches like Turckmm, APC or eaccelarator
l load-balanced FastCGI
l (one webserver distibutes request to multiple PHP-servers via FastCGI)
l Security features:
l chroot(), set UID, set GID
l protecting docroot
l strict HTTP-header parsing
5.可執行文件大小、內存使用情況
沒有查到具體數據。
Lighttpd缺點就是bug比較多，軟件并不穩定，而且文檔太簡略，有些功能需要你自己猜測才懂得怎么配置。尤其是使用內存，很難說清楚具體使 用量，一般在10－20M（繁忙站點），但有時候會突發到100多M，并穩定下來。不過相對apache的使用量，這個已經不算多。
lighttpd雖然是web服務器中的輕量級。但對于嵌入式web服務器來說還是較大的一個web服務器，功能較強。
有人評論lighttpd：lighttpd、apache 屬重量級服務器, 成熟穩定, 體積較大, 在復雜的嵌入式應用上可選用.
Lighttpd使用的不廣泛，在google中搜索：嵌入式 lighttpd，結果幾乎沒有相關的內容。Lighttpd使用內存比其它小型嵌入式web服務器內存資源要多。畢竟它不是專為嵌入式設備開發的。
官方網站：www.lighttpd.net
Goahead
1.介紹
GoAhead Webserver是為嵌入式實時操作系統（RTOS）量身定制的Web服務器。它的目標也許不在于目前的WEB服務器市場，而是面向當嵌入式系統深入我 們的工作與生活的明天，那時，它也許會成為使用最廣泛的WEB服務器。GoAhead Webserver構建在設備管理框架（Device Management Framework）之上，用戶可以像標準的Web Services一樣來部署自己的應用，不需要額外的編程。GoAhead Webserver支持SOAP客戶端（Simple Object Access Protocol，簡單對象訪問協議），XML-RPC客戶端，各種Web瀏覽器和單獨的Flash客戶端。GoAhead Webserver支持一種類ASP的服務器端腳本語言，其語法形式和微軟的ASP語法基本相同（Active Server Page）。GoAhead Webserver是跨平臺的服務器軟件，可以穩定地運行在Windows，Linux和Mac OS X操作系統之上。GoAhead Webserver是開放源代碼的，這意味著你可以隨意修改Web服務器的功能。這款WEB服務器非常小巧，它的WIN CE版本編譯后的大小還不到60k，它的輸出通常也是面向一些小屏幕設備。在性能方面，使用一顆24MH z的68040處理器，它的響應速度為20次/秒，使用266MHz的Pentium處理器可以達到50次/秒的響應速度。
2.操作系統
Windows CE, Wind River VxWorks, Linux, Lynx, QNX,與Windows 95/98/NT
3版本
Goahead從2003年開始發布，最新的版本：webs218.tar ，827kB，解壓后為2.28MB
4.功能、特點
· 很小的內存消耗
· 支持認證功能Digest Access Authentication (DAA)
· 支持安全的通信，例如SSL（安全的套接字層）
· 支持動態Web頁面，如ASP頁面
· 可以使用傳統的C語言編程定制Web頁面里的HTML標簽
· 支持CGI（公共網關編程接口）
· 嵌入式的JavaScript腳本翻譯器
· 獨特的URL分析器
· 它基本上屬于一個HTTP1.0標準的WEB服務器，對一些HTTP1.1的特性如（持久連接）也提供了支持。每秒65次connections
5.可執行文件大小、內存使用情況
內存需求60K，它的WIN CE版本編譯后的大小還不到60k。
自 2004 年 2.18 版之后, GoAhead 官方不再對它免費許可的升級和支持,如果是學習和研究之用, 移植很方便, 不必關心太多; 如果商用, 那些已知的 bug 就必須手工去改，包括對 cgi 的支持, 對操作系統差異而引用的 bug，參考下這個 http://www.eybuild.com/develop/demoshow.htm ，這個就是用的 GoAhead。
GoAhead官方網站：http://webserver.goahead.com/
AppWeb
1.介紹
appWeb有兩種許可，一種是GPL，免費的，另外一種是商業許可，有30天的試用期。免費的版本在http://www.appwebserver.org/ 下載，appWeb的商業版本由Mbedthis公司發布和維護，網址是http://www.mbedthis.com/。appweb 是下一代嵌入式web服務器，它天生是為嵌入式開發的，它的最初設計理念就是安全。Appweb是一個快速、低內存使用量、標準庫、方便的服務器。與其它 嵌入式web服務器相比，appweb最大特點就是功能多和高度的安全保障。Appweb簡單、方便、開源。
2.操作系統
Linux, Windows, Mac OSX , Solaris
3.版本
Appweb最新版本是appweb-src-2.2.2 ，大小1.195MB，解壓后6.22MB
4.功能、特點
AppWeb提供的一些關鍵好處：
l 低開發成本。支持cgi/1.1、javastript、esp、php(4and5)，加快開發進度。
l 最小的資源需求。一秒能響應3500個請求，非常迅速，并且緊湊（110KB）。
l 靈活的開發環境。Appweb高度模塊化，可以根據需要取舍。
l 可靠性
具有的功能：
· 支持嵌入式JavaScript，esp，egi，cgi和php。.
· 容易使用。 大量的例子文檔可用。
· 安全。支持SSL、認證。 Secure Socket Layer (SSL) including both client and server certificates. Digest and Basic Authentication. Sandbox directives to limit denial of service attacks.
· 模塊化. Select only the features you need via dynamically loadable modules. Also supports granular source code compilation directives.
· 性能突出。. Fastest performance in its class. Over 3500 requests per second on a PC class device. Memory footprint from 110K. Code and web pages are fully ROMable.
· 符合標準. AppWeb supports HTTP/1.0, HTTP/1.1, CGI/1.1, SSL RFC 2246, HTTP RFC 2617
· 方便. AppWeb has been ported to Linux, Windows, Mac OSX and Solaris and support the following CPU architectures: ARM7, MIPS32, i386/X86, PowerPC and Sparc
Feature Overview
Dynamic Content
· Embedded Server Pages (ESP)
· Embedded Gateway Interface (in-memory CGI)
· CGI/1.1
· PHP (4 and 5)
Embedded Server Pages
· Server-side JavaScripting
· Integrated session state management
· Scripted generation of HTML
· Extensible via new functions
· Manage client state-data via sessions
· Post-back paradigm. Same page for form and post logic
Security
· Secure Sockets Layer (SSL)
· Basic and Digest Authentication
· Directory and URL location based authorization
· Sandbox limits
· Access and access violation logging
Modularity
· Dynamic loading of modules
· Extensible URL handlers
· Extensible / replaceable authorization, SSL and script
Ease of Use
· Apache-style configuration file
· Debugging and trace logging
· Packaged installations for Linux and Windows
· Run as a service / daemon
Other Features
· HTTP server and client access program
· Named and IP based virtual hosts
· Listen on multiple ports
· Compile web pages and files into C code for execution from ROM
Standards
· HTTP/1.1
· CGI/1.1
· Apache configuration file compatibility
Performance
· Multithreaded with high performance thread pool
· Request throughput (> 3,500 requests per second)
· Scales on multi-cpu systems
· Small memory footprint even under heavy load (from 400K)
Developer Features
· HTTP server and client libraries
· Shared and static libraries supplied
· C and C++ APIs
· Operate single-threaded or multithreaded (Compile or run-time selectable)
· Easy, intuitive programming model
· Integrate with common event mechanism: Windows Messages, Unix select, dedicated thread
· Coding minimized as most features can be specified via the configuration file
· Cookbook of samples (cut and paste to get going)
· SMP safe
· Extensive debug trace logging
O'Brien describes AppWeb as a "mini-Apache" in part because it features compatibility with Apache configuration syntax. "One of our customers was able to solve a problem using Apache documentation from the Internet," O'Brien notes. AppWeb is not based on the apache codebase, however. "It's a clean implementation," says O'Brien. "It's really hard to shrink something down."
AppWeb architecture
5.可執行文件大小、內存使用情況
內存使用110KB， Small memory footprint even under heavy load (from 400K)。
官方網站http://www.appwebserver.org/
Apache
最新的apache版本是httpd-2.2.4.tar，6.07MB，解壓后為27.2MB，在嵌入式web服務器中很少使用，在網上搜索看到 有人在vxwork上用過apache，在其它方面沒有，我認為，goahead、appweb具有豐富的功能，沒有使用apache的必要。另一個原因 是因為apache是一個多進程web服務器，使用的內存很多。
由于apache的prefork工作模式有關。每個apache進程只能同時服務于一個http連接。這種模式好處在于每個進程不互相干擾，穩定 性好；缺點也建立在優點之上，就是占用資源多，即使每個進程只使用2M內存（如果使用了php，這點內存根本不夠）,100的并發連接就用掉200M的內 存。
開發語言和開發工具
現在的嵌入式linux中CGI程序主要使用C語言。對于編寫C語言的CGI程序，可以編寫好程序之后，在linux操作系統下編譯，用針對硬件平 臺的linux的交叉編譯工具編譯就可以，寫的html網頁界面在記事本寫即可。我以前寫的CGI程序就是在此環境下寫的。這也是最普遍的開發方法。
對于用C語言編寫CGI程序還可以使用CSP/eybuild提供的平臺庫及其開發套件，它可以將CGI程序嵌入式到網頁中，可以提高開發效率。傳 統用C做CGI的方法是直接使用printf() 等標準I/O函數輸出HTML代碼，這樣不但使得C程序和HTML程序交織的混亂不堪，還使得頁面輸出的流程控制變得非常復雜。CSP與之不同，它充分吸 取了ASP/JSP/PHP等以HTML/ XML為模板嵌入腳本語言優點，并充分融合C語言的語言特性。使得CSP的開發更快速、更高效，同時還大大提了最終代碼的可讀性和維護性。 CSP設計的最原始的初衷，就是要為嵌入式開發定制的一套類似 ASP/JSP/PHP的C語言開發工具。針對設備WEB開發CSP提供了豐富的平臺庫和開發工具，它們為設備系統的WEB交叉開發和移植提供了有力的支 持。通過交叉開發，可以在其它硬功件平臺完全未準完畢的情況下進行高層軟件的開發。這不僅能為產品開發有效地節約軟硬件資源，還為WEB程序提供簡單有效 地調試工具。
但缺點是，CSP/eybuild不是一個開源的項目，如果你是個人使用或出于學習、研究目的你可以從eybuild的官方站點http: //www.eybuild.com 免費下載，或發郵件到 eybuild@hotmail.com 免費索取。它的站點上可以下載針對x86、arm920T的CSP/eybuild開發平臺，其它平臺需要向網站上定購。如果你想在你的嵌入式設備的開發 板上試用或出于學習和研究目的，你也可把您目標板及編譯環境的詳細資料發給eybuild@hotmail.com，請求為你的目標板單獨制作一份交叉編 譯開發的CSP/eybuild平臺。如果你想你的商用產品或項目中使用CSP/eybuild，你必須在CSP/eybuild的商用授權后才可使用。 商用授權后您將可以得到很好的技術支持和技術培訓。關于商用授權的詳細流程，可郵件至eybuild@hotmail.com 垂詢。
用C語言編寫CGI與其它語言編寫CGI的比較：
C語言簡潔緊湊，使用方便、靈活，對程序的語法結構要求不是很嚴，這就使得編程
人員在編程時具有很大的靈活性，可以設計出自己風格的程序。不像UNIX SHELL、Perl和TCL，C語言是一種編譯語言，源程序代碼要被系統的續譯器翻譯成機器能直接執行的二進制代碼，因此用C語言編寫的CGI程序的運 行速度要比用解釋性語言編寫的程序快。使用編澤語言的另一個好處是即使CGI執行程序陷入黑客之手，他們也無法像分析用解釋性語言編寫的CGI程序那樣找 到程序中的漏洞。由于C語言最初是針對系統設計的，這使得C語言的字符串處理能力比較差，如果CGI程序需要對字符串進行一些復雜的操作，用C諾言實現起 來將比較麻煩，代碼量也較多。現在網上用C語言編寫的CGI程序僅次于Perl（Perl編寫程序簡單方便）。
CGI與JSP的比較：
Servlet是Java技術對CGI編程的回答。Servlet程序在服務器端運行，動態地生成Web頁面。與傳統的CGI和許多其他類似CGI 的技術相比，Java Servlet具有更高的效率，更容易使用，功能更強大，具有更好的可移植性，更節省投資。詳細內容見備注。JSP是強于CGI，這也是現在CGI技術的 使用沒有JSP使用多的原因。但現在嵌入式web服務器端程序開發，還是CGI較多。由于使用JSP技術，在嵌入式web服務器開發中很少使用，在網上沒 有查到關于在嵌入式web服務器上應用的有關內容。
要實現閱讀器的lmt，所需的CGI代碼量估計不會很多，關鍵在于調試。
結論
根據上面的分析，考慮到使用范圍寬廣程度，在小型服務器、不要求太強功能，推薦選用boa、thttpd，其實它們足可以滿足大多數情況下的需求，也是使 用最廣、可參考最多的嵌入式web服務器。如果要求強大的功能，支持javastript等，推薦選用goahead、appweb。
備注：
一個網友的個人意見：
boa 的功能比較齊全, 便對嵌入式應用很多功能就是冗余(如virtual host), 內存使用量較大些.
thttpd 功能較少, 實現簡單. 內存使用量較少. 同時比較方便擴展.
shttpd 功能功能算是比較全的, 但在處理二進制數據時不夠穩定, 時有異常. 有待觀察.
light-httpd, apache 屬重量級服務器, 成熟穩定, 體積較大, 在復雜的嵌入式應用上可選用.
goAhead 是個比較專用的 webserver, 大部分功能都在服務它自己提供的 goform 功能和
ASP/javascript 功能. 最后的 2.1.8 版仍有不少bug. (見下)
mini-httpd 與 thttpd 是同一家, 功能幾乎完全一樣.
boa 缺陷:
(1) 未提供 CGI 解析頭處理.
可按這個地址方便修改. http://bbs.chinaunix.net/viewthread.php?tid=824840
(2) 對 POST 數據使用臨時文件緩沖, 對無法創臨時文件的小系統系統, 需要手工改下這部代碼.
很多人報告在移植時不能POST 數據, 都是這個原因.
(3) ...
thttpd 缺陷:
(1) CGI1.1 標準支持不完整(不般影響不大), 未提供對協議要求的其它HTTP頭處理,
如:If-Modified-Since, Accept-Language等應用程序就收不到.
(2) 直接使用 socket 到 CGI 應用的重定, 會導致提供大量 POST 數據時(如上傳文件),
CGI應用不讀完全部 POST 數據就無法向瀏覽器應答 bug
(3) ...
goAhead 缺陷:
(1) 專用, 如喜歡它提供的 goform和 asp 令論.
(2) CGI 對二進制輸出有很多 bug.
(3) 為實現單一任務處理, 在很平臺采用延時輪詢接收隊列, 處理效率不高.
(4) 其它 bug 有不一羅列了, 移植時要一個個訂下.
個人觀點, 僅供參考.
Good Luck!
CGI, mod_perl, PHP, JSP性能比較
這是網上一篇關于CGI，mod_perl,PHP,JSP的性能比較的文章，從中可以看出它們的性能。
測試結果很大程度上依賴于機器的硬件/軟件配置，并隨配置變化而產生差異，因此：
本測試結果 *僅供參考*
測試用硬件：
CPU: Intel PII 300(66x4.5)
RAM: 192M
HD: IBM 20G(2M cache)
測試用軟件：
OS: Slackware 7(自行編譯的2.2.14核心)
Web: Apache 1.3.12(標準模塊按缺省配置，所有模塊靜態編譯)
PHP 4.0 RC1(加入了MySQL支持)
mod_perl 1.23(缺省配置，未加EVERYTHING=1)
ApacheJServ 1.1(缺省配置)
JDK: JDK 1.2.2
JSDK: JSDK 2
JSP: GNUJSP 1.0.0
JSP: GNUJSP 1.0.0
本測試是用Apache自帶的Apache Bench(ab)進行的，命令為：
/www/bin/ab -c 20 -n 1000 CGI/腳本URL
此命令表示使用 20 個并發連接，進行 1000 次請求。所有測試均在本機進行，各種測試均反復進行5次，去掉最大最小值后取平均值。 我分別測試了C寫的CGI、Perl寫的CGI、用mod_perl執行的Perl CGI、PHP和JSP。
各種CGI/腳本均輸出內容相似的簡單頁面，內容如下：
html
body
h1The xxxx Hello Program/h1
p
Hello xxxx World!
/body
/html
測試結果(只取了最具代表性的 Requests per second 即每秒處理請求數這一項)
CGI/腳本類型 每秒處理請求數
C CGI 128
Perl CGI 69
mod_perl 223
PHP 237
JSP 21
測試結論：
除了JSP之外，其它幾種CGI/腳本的表現大致是正常的。Perl程序解釋執行，作為
CGI運行時又需要另外fork進程，所以最慢；mod_perl和PHP都直接在httpd內部運行腳本，省掉了fork的消耗，所以快了很多；C程序 雖然本應最快，但作為CGI 運行時也是因為fork而使性能大打折扣。至于JSP...我想這個結果并不具有代表性。畢竟測試用機只有192M內存，用top看看，一個JAVA就占 了11M。況且測試用機本身是一臺Web server，測試時還有好幾十個httpd在跑不過不管怎么說，在配置較低的服務器上，跑PHP、mod_perl在性能上要好過JSP是肯定的。
附測試用程序：
C程序 hello.c
#include stdio.h
int main(void)
{
char s[] = "C CGI";
printf ("Content-Type: text/html ");
printf ("html "
"body "
"h1The C CGI Hello Program/h1 "
"p "
"Hello %s World! "
"/body "
"/html ", s);
return 0;
}
用 gcc -o hello hello.c 編譯，把 hello 放到 cgi-bin目錄下。
Perl程序 hello.pl
#!/usr/bin/perl
#!/usr/bin/perl
$s = "Perl CGI";
print "Content-Type: text/html ";
print <<DONE
html
body
h1The Perl CGI Hello Program/h1
p
Hello $s World!
/body
/html
DONE
把hello.pl放到cgi-bin目錄下，兼作Perl CGI和mod_perl 腳本測試用。
PHP文件 hello.php
html
body
h1The PHP Hello Program/h1
<? $s = "PHP"; ?>;
p
Hello <? echo $s ?>; World!
/body
/body
/html
JSP文件 hello.jsp
html
body
h1The JSP Hello Program/h1
p
<% String s = "JSP"; %>;
p
Hello <%= s %>; World!
/body
/html
Java Servlet和JSP的技術概述以及比較
Java Servlet及其特點
Servlet是Java技術對CGI編程的回答。Servlet程序在服務器端運行，動態地生成Web頁面。與傳統的CGI和許多其他類似CGI 的技術相比，Java Servlet具有更高的效率，更容易使用，功能更強大，具有更好的可移植性，更節省投資（更重要的是， Servlet程序員收入要比Perl程序員高:-）：
高效:
在傳統的CGI中，每個請求都要啟動一個新的進程，如果CGI程序本身的執行時間較短，啟動進程所需要的開銷很可能反而超過實際執行時間。而在Servlet中，每個請求由一個輕量級的Java線程處理（而不是重量級的操作系統進程）。
在傳統CGI中，如果有N個并發的對同一CGI程序的請求，則該CGI程序的代碼在內存中重復裝載了N次；而對于Servlet，處理請求的是N個 線程，只需要一份Servlet類代碼。在性能優化方面，Servlet也比CGI有著更多的選擇，比如緩沖以前的計算結果，保持數據庫連接的活動，等 等。
方便:
Servlet提供了大量的實用工具例程，例如自動地解析和解碼HTML表單數據、讀取和設置HTTP頭、處理Cookie、跟蹤會話狀態等。
功能強大:
在Servlet中，許多使用傳統CGI程序很難完成的任務都可以輕松地完成。例如，Servlet能夠直接和Web服務器交互，而普通的CGI程序不能。Servlet還能夠在各個程序之間共享數據，使得數據庫連接池之類的功能很容易實現。
可移植性好:
Servlet用Java編寫，Servlet API具有完善的標準。因此，為I-Planet Enterprise Server寫的Servlet無需任何實質上的改動即可移植到Apache、Microsoft IIS或者WebStar。幾乎所有的主流服務器都直接或通過插件支持Servlet。
節省投資:
不僅有許多廉價甚至免費的Web服務器可供個人或小規模網站使用，而且對于現有的服務器，如果它不支持Servlet的話，要加上這部分功能也往往是免費的（或只需要極少的投資）。
JSP及其特點
JavaServer Pages（JSP）是一種實現普通靜態HTML和動態HTML混合編碼的技術，有關JSP基礎概念的說明請參見《JSP技術簡介 》。
許多由CGI程序生成的頁面大部分仍舊是靜態HTML，動態內容只在頁面中有限的幾個部分出現。但是包括Servlet在內的大多數CGI技術及其變種，總是通過程序生成整個頁面。JSP使得我們可以分別創建這兩個部分。例如，下面就是一個簡單的JSP頁面：
＜!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"＞
＜HTML＞
＜HEAD＞＜TITLE＞歡迎訪問網上商店＜/TITLE＞＜/HEAD＞
＜BODY＞
＜H1＞歡迎＜/H1＞
＜SMALL＞歡迎,
＜!-- 首次訪問的用戶名字為"New User" --＞
＜% out.println(Utils.getUserNameFromCookie(request)); %＞
要設置帳號信息，請點擊
＜A HREF=http://www.blue1000.com/article/"Account-Settings.HTML"＞這里＜/A＞＜/SMALL＞
＜P＞
頁面的其余內容。.
＜/BODY＞＜/HTML＞
下面是JSP和其他類似或相關技術的一個簡單比較：
JSP和Active Server Pages（ASP）相比
Microsoft的ASP是一種和JSP類似的技術。JSP和ASP相比具有兩方面的優點。首先，動態部分用Java編寫，而不是VB Script或其他Microsoft語言，不僅功能更強大而且更易于使用。第二，JSP應用可以移植到其他操作系統和非Microsoft的Web服務 器上。
JSP和純Servlet相比
JSP并沒有增加任何本質上不能用Servlet實現的功能。但是，在JSP中編寫靜態HTML更加方便，不必再用 println語句來輸出每一行HTML代碼。更重要的是，借助內容和外觀的分離，頁面制作中不同性質的任務可以方便地分開：比如，由頁面設計專家進行 HTML設計，同時留出供Servlet程序員插入動態內容的空間。
JSP和服務器端包含（Server-Side Include，SSI）相比
SSI是一種受到廣泛支持的在靜態HTML中引入外部代碼的技術。JSP在這方面的支持更為完善，因為它可以用Servlet而不是獨立的程序來生成動態內容。另外，SSI實際上只用于簡單的包含，而不是面向那些能夠處理表單數據、訪問數據庫的“真正的”程序。
JSP和JavaScript相比
JavaScript能夠在客戶端動態地生成HTML。雖然JavaScript很有用，但它只能處理以客戶端環境為基礎的動態信息。除了 Cookie之外，HTTP狀態和表單提交數據對JavaScript來說都是不可用的。另外，由于是在客戶端運行，JavaScript不能訪問服務器 端資源，比如數據庫、目錄信息等等。
Java很占內存嗎？
使用Java平臺進行嵌入式設備開發時，其對內在的使用量，會不會比使用原始語言如C/C++更大些呢？這取決于軟件的復雜性。Java由于虛擬機和內庫的原因，有可能會導致內存開銷的增大。下面比較一下Java平臺內存的占用情況（基于Sun的實現）：
CLDC（Connected Limited Device Configuration，運算功能有限、電力有限的嵌入式裝置，如PDA 、手機等）：可工作于100K（RAM），JIT（Just In Time,即時編譯技術）需要最大些。典型的部署要求500K-16M（RAM）。
CDC（Connected Device Configuration，運算能力相對較佳、并請在電力供應上相對比較充足的嵌入式裝置，如冷氣機、電冰箱等）：VM約為250K，JIT小于 300K，VM+JIT+基礎類庫約占2-2.5M。典型的部署要求：4M-32M。
當然，內存的占用量還取決于應用的大小及內在的使用情況。可以看出，其實Java平臺不會占用太大的內存。但是，這只是問題的一半。另一半 是，Java代碼最后部署時是以類文件來部署的，它主要是包括字節碼和元數據。通過對CVM數據的分析，可以看出，字節碼占據著大概30%的數據量。而采 用JIT編譯的代碼相對于字節碼而言，可以發現，內存的占有量增加了，并有一個7-8倍的ARM指令集。由于，可以估計：
Java類轉成字節碼的速度≈1/30%≈3.3x；
原始語言轉成字節碼的速度≈7x。
這意味著，Java代碼的內存使用量約為原始語言代碼的一半。當然這只是非常粗略的估算，但卻是合理的估算。
使用Java的JIT后，只有那些使用頻率高的代碼才會被編譯。而在系統中只是偶然被執行的代碼則采用解釋來編譯。同時，JIT盡量使被編譯的代碼 其內存占有量保持在一較小的范圍內。對CVM（CDC所使用虛擬機），默認值為512K。而在一些較優秀的程序中，可以發現，其值為100K-300K。
這也就是說，使用Java編寫的程序，只有使用頻率比較高的代碼才導致內存占用的增加。相反，使用C/C++編寫的程序，整個代碼都需要進行編譯。 因此，不能說使用Java語言編寫的程序占用的內存就會比使用C/C++編寫的程序大。這決定于軟件相對于平臺代碼的復雜度及大小。如果軟件規模比較 大，Java平臺所消耗的內存遠小于Java類文件簡潔性節約的內存，這種情況下，使用Java平臺將有利于節約內存。如果軟件的規模比較小，則Java 平臺消耗的內存就比較明顯了，可以考慮使用C/C++來開發，以節約內存。