Minimál HTTP szerver

Fórumok

A legújabb munkámhoz ki kellene választanom egy megfelelő http szervert. Amolyan embedded cuccról van szó, és arra szolgálna, hogy távolról lehessen megtekinteni az aktuális állapotot és néhány vezérlési és konfigurációs funkciót el lehessen végezni. HTTP szempontból egy kis SOHO router -hez hasonló felületet kellene megjelenítenie. Ideális az amelyik egy "egylapos" ARM processzoron is elszalad.
A Debian számos ilyet tartalmaz, van javaslatotok, tapasztalatotok, amit megtudtok velem (velünk) osztani?

Hozzászólások

Csak a Debian csomagkezelő szerint:
busybox armel/572KB i389/480KB amd64/548KB - ez nem csak httpd

mini-httpd armel/196KB i386/188KB amd64/136KB
boa armel/344KB i386/344KB amd64/356KB
micro-httpd armel/68KB i386/68KB amd64/68KB

nginx armel/764KB i386/780KB amd64/856KB

A memória felhasználás, nem minden, de embedded rendszerekben eléggé fontos. Miért éppen nginx?

SZERK: ha valaki megsúgná, hogy lehet azt elérni, hogy a beszerkesztett space, tab ne tűnjön el a hozzászólásból, azt nagyon megköszönném - a különféle szerverek memória foglalása egy kis táblázat, nem egy ilyen összef'sott valami :( Súgja meg valaki, tényleg nem tudom.

* Én egy indián vagyok. Minden indián hazudik.

Eszembe jutott, ránéztem az OpenWrt -s routeremben mi is szolgáltat busybox!? Na ezt nem is tudtam.

* Én egy indián vagyok. Minden indián hazudik.

Nem védeni akarom - én is random találtam, nem én írtam, semmi okom védeni - de:

A memória igény szempontjából a csomag mérete nem használható érték, mert abban a doksi is benne van, azt is felteszi a csomaggal a Debian. A bináris mérete nálam kb 56k. Ez az, ami a flashen, és a RAM-ban is helyet foglal. Futás közben pedig szinte semmi heap memóriát nem használ:

Inicializáláskor és néhány oldal kiszolgálása után:


$ ps -eo fname,rss |grep webfsd
webfsd     264
$ ps -eo fname,rss |grep webfsd
webfsd     892

$ ls -la /usr/bin/webfsd 
-rwxr-xr-x 1 root root 56512 2010-06-16 00:23 /usr/bin/webfsd

"A memória igény szempontjából a csomag mérete nem használható érték"
Tudom. Csak "becslésre" jó, vagy arra sem.
Ha megfigyeled te voltál az első, aki valami olyat is mondott ami mérhető. Mindenki dobott egy csomag nevet, és ha kérdeztem miért ez vagy az akkor hallgatás.

* Én egy indián vagyok. Minden indián hazudik.

$ps -eo fname.rss | grep busybox
busybox 644

A busybox fájl mérete pedig 505K, viszont ez az embedded cuccoknál alapból ott van, a más web szerver ehhez csak plusz.
Lehet hogy úgy kéne feltennem a kérdést, hogy kell jobb a "busybox httpd" -nél egy ilyen kaliberű feladathoz? Érdemes egy külön, csak http szervert felraknom?

* Én egy indián vagyok. Minden indián hazudik.

Szerintem ami szempont:
* Mennyi idő konfigurálni - főleg a keresgetés tart sokáig általában. A Busybox már megvan, tehát oké.
* Mennyit kér enni - ebből a szempontból a Busybox fejlesztők nagyon odafigyelnek, tehát gondolom oké.
* Milyen teljesítménye van. A CPU terhelés, és a latency a két legfontosabb kérdés. Mindkét kérdés leginkább a mögé rakott CGI-ken múlik leginkább, a http szervert nagyon nehéz elrontani ebből a szempontból.

Azért javasoltam a RAMfs-ből való kiszolgálást, mert azzal lehet a legjobb válaszidőt elérni a legkisebb CPU terhelés mellett. Plusz nem kell interprocessz kommunikációt írni - ott a fájlrendszer. Ha CGI-t is használsz, érdemes úgy megcsinálni, hogy minden frissítés egyetlen CGI-vel lefusson, ne kelljen többet hívni, mert a legnagyobb overhead a processz indítás.

Ha dinamikus tartlamat kell kiszolgálni, és a teljesítmény is fontos, akkor pedig valami C/C++ alapú alkalmazásba ágyazott http kell. De ha erre lenne szükséged, akkor valószínűleg (remélhetőleg) már többet tudnál a témáról :-)

"valószínűleg (remélhetőleg) már többet tudnál a témáról :-)"
Bár így lenne, egyenlőre tapogatózom. Ugyan dinamikus tartalmat is kell tudni, de legfeljebb néhány klienst kellhet kiszolgálni egyidejűleg - pont mint a routerek és hasonló eszközök (ott sem százan egyszerre akarják piszkálni a cuccot). Viszont a http programozásban még a zöldfülűségig sem jutottam el - többrendbeli fogalomzavarral is küzdök.

* Én egy indián vagyok. Minden indián hazudik.

A GoAhead cucc tényleg jónak tűnik :) A licensz kicsit érdekes de majd beleásom magam.
A busybox http funkciója még mindig jobbnak tűnik, bármilyen embedded cuccban ez alapvetően ott van (de a Debian telepítés alapjában is ott van) mondhatni "must have". CGI -t tud. A nagy kérdés, hogy ezt hogy kell megoldani: http://hup.hu/node/101012

* Én egy indián vagyok. Minden indián hazudik.

Apró eszközökre én thttpd-t szoktam tenni.
Néhány soros C kód. Apró hackeléssel még php-t is hozzá lehet drótozni.

+1 én is azt használom.

Asszem nem is hackelés az a PHP dolog, van egy (talán 5-ös?) PHP alverzió, amit támogat, csak úgy kell fordítani. CGI-k simán mennek vele, legalábbis amit én csináltam magamnak, az jó volt.

Egy nagy baját találtam eddig, ha van pl. egy 100MB-os fájlod, amire van egy URL, kattint rá a felhasználó, hogy letöltse, akkor a thttpd lefoglal szépen 100MB RAM-ot, és úgy kezdi odaadni a fájlt... nyilván ez kevés memóriájú rendszereken gond. Ha nagyon ráérek, írok rá egy patch-et :D
--
http://www.open-st.eu

[MEGOLDVA]
$busybox httpd -fvvv -p 10080 -h /home/tovis/www
Kell a "h" bötü! A busybox honlapján lévő leírás inkább hasonlít egy felsorolásra mint kézikönyvre - pl. a httpd.conf fájl szintakszisához pont nincs semmi :(

Nem egészen ide tartozik.
Debian Squeeze:


$busybox httpd -fvvv -p 10080 /home/tovis/www
  ..connected
  ..url:/
  ..response:404
  ..closed

Tény, hogy mindenütt a rootba tesznek egy www könyvtárat és csinálnak egy /etc/httpd.conf -ot. Én a saját home könyvtáramon belül csináltam ilyet és nem készítettem httpd.conf -ot. Viszont látszik, hogy kapcsolódik. A www/index.html egy mondhatni bárakármi kis html doksi.
Van ötlet mit nem talál?

* Én egy indián vagyok. Minden indián hazudik.

A httpd.conf "leírása" a forrásban, jelesül a httpd.c elején lévő kommentben olvasható.


 * Typical usage:
 *   for non root user
 * httpd -p 8080 -h $HOME/public_html
 *   or for daemon start from rc script with uid=0:
 * httpd -u www
 * This is equivalent if www user have uid=80 to
 * httpd -p 80 -u 80 -h /www -c /etc/httpd.conf -r "Web Server Authentication"
 *
 *
 * When a url starts by "/cgi-bin/" it is assumed to be a cgi script.  The
 * server changes directory to the location of the script and executes it
 * after setting QUERY_STRING and other environment variables.
 *
 * Doc:
 * "CGI Environment Variables": http://hoohoo.ncsa.uiuc.edu/cgi/env.html
 *
 * The applet can also be invoked as a url arg decoder and html text encoder
 * as follows:
 *  foo=`httpd -d $foo`           # decode "Hello%20World" as "Hello World"
 *  bar=`httpd -e "<Hello World>"`  # encode as "&#60Hello&#32World&#62"
 * Note that url encoding for arguments is not the same as html encoding for
 * presentation.  -d decodes an url-encoded argument while -e encodes in html
 * for page display.
 *
 * httpd.conf has the following format:
 *
 * H:/serverroot     # define the server root. It will override -h
 * A:172.20.         # Allow address from 172.20.0.0/16
 * A:10.0.0.0/25     # Allow any address from 10.0.0.0-10.0.0.127
 * A:10.0.0.0/255.255.255.128  # Allow any address that previous set
 * A:127.0.0.1       # Allow local loopback connections
 * D:*               # Deny from other IP connections
 * E404:/path/e404.html # /path/e404.html is the 404 (not found) error page
 * I:index.html      # Show index.html when a directory is requested
 *
 * P:/url:[http://]hostname[:port]/new/path
 *                   # When /urlXXXXXX is requested, reverse proxy
 *                   # it to http://hostname[:port]/new/pathXXXXXX
 *
 * /cgi-bin:foo:bar  # Require user foo, pwd bar on urls starting with /cgi-bin/
 * /adm:admin:setup  # Require user admin, pwd setup on urls starting with /adm/
 * /adm:toor:PaSsWd  # or user toor, pwd PaSsWd on urls starting with /adm/
 * .au:audio/basic   # additional mime type for audio.au files
 * *.php:/path/php   # run xxx.php through an interpreter
 *
 * A/D may be as a/d or allow/deny - only first char matters.
 * Deny/Allow IP logic:
 *  - Default is to allow all (Allow all (A:*) is a no-op).
 *  - Deny rules take precedence over allow rules.
 *  - "Deny all" rule (D:*) is applied last.
 *
 * Example:
 *   1. Allow only specified addresses
 *     A:172.20          # Allow any address that begins with 172.20.
 *     A:10.10.          # Allow any address that begins with 10.10.
 *     A:127.0.0.1       # Allow local loopback connections
 *     D:*               # Deny from other IP connections
 *
 *   2. Only deny specified addresses
 *     D:1.2.3.        # deny from 1.2.3.0 - 1.2.3.255
 *     D:2.3.4.        # deny from 2.3.4.0 - 2.3.4.255
 *     A:*             # (optional line added for clarity)
 *
 * If a sub directory contains a config file it is parsed and merged with
 * any existing settings as if it was appended to the original configuration.
 *
 * subdir paths are relative to the containing subdir and thus cannot
 * affect the parent rules.
 *
 * Note that since the sub dir is parsed in the forked thread servicing the
 * subdir http request, any merge is discarded when the process exits.  As a
 * result, the subdir settings only have a lifetime of a single request.
 *
 * Custom error pages can contain an absolute path or be relative to
 * 'home_httpd'. Error pages are to be static files (no CGI or script). Error
 * page can only be defined in the root configuration file and are not taken
 * into account in local (directories) config files.
 *
 * If -c is not set, an attempt will be made to open the default
 * root configuration file.  If -c is set and the file is not found, the
 * server exits with an error.

Van ötlet mit nem talál?
Persze, az index.html-t, mert kihagytad a -h kapcsolót, pedig pár sorral korábban magad mondtad, hogy kell :)

Melyik "egylapos" ARM processzoros cuccról van szó?
Engem is érdekel a téma. ( subscribe )
--
üdv: virtualm

Még én sem tudom ki lesz a "befutó".
Kell kamera és GSM/GPRS/HSDPA és egyéb, vezérlések. A fő gondot a kamera képezi.
http://hup.hu/node/98932
Azóta még lett egy olyan mint a a www.m2msolution.eu Quicktel M33.
De próbálkoztam a Telit -el nekik van GSM -el összeépített cuccuk ( a Rutronik képviselné őket, írtam egy szívhez szóló levelet nekik de semmi válasz).
A Makró is forgalmaz néhány típust. De van olyan lehetőség is mint a Vivotek IP7361 -es kamerája ami OS Linux 2.6 és van hozzá SDK.
Van olyan ami open(!) http://www.ime.usp.br/~fr/sbc/ hw gyártós kollégával konzultáltam, a doksi elegendő ahhoz hogy a NYÁK -ot le lehessen gyártani.
Szóval van lehetőség.

* Én egy indián vagyok. Minden indián hazudik.