HOVD 2016 - Kedvenc HTTP szerver

 ( trey | 2017. január 8., vasárnap - 11:24 )
apache
53% (373 szavazat)
beépített http szerverek (simplehttpserver, webrick stb.)
3% (18 szavazat)
h2o
0% (3 szavazat)
hiawatha
1% (7 szavazat)
java servlet container-ek (pl.: tomcat, jetty, ...)
5% (38 szavazat)
lighttpd
6% (40 szavazat)
litespeed
0% (1 szavazat)
microsoft iis
2% (16 szavazat)
nginx
28% (196 szavazat)
thttpd
1% (6 szavazat)
Összes szavazat: 698

Hozzászólás megjelenítési lehetőségek

A választott hozzászólás megjelenítési mód a „Beállítás” gombbal rögzíthető.

Bárcsak ugyanazt a célt szolgálnák a szereplők, gondolom mindenki arra szavaz amit ismer / használ :)

--
arch,debian,retropie,osmc,android,windows

Nem az volt a kérdés, hogy milyen objektív ismérvek alapján melyik miben jobb, hanem az, melyik a kedvenc.


tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Jaja, mi pl szinte mindegyiket hasznaljuk valamire. Vacillaltam is nagyon az nginx es az apache kozott, de aztan meglett a gyoztesem. :D

Statikus fájlkiszolgálásra nginx, java servletek futtatására meg jetty.. szerintem értelmetlen a kérdés, ezek nem pokémonok vagy házikedvencek.

--
arch,debian,retropie,osmc,android,windows

+1

jo jo, de ez extrem eset. vegyunk egy egyszerut: haverod megker hogy a 300Ft-os vpsre a wordpress oldalahoz pattints ma' fel egy webserver+php+mysql-t

--
A vegtelen ciklus is vegeter egyszer, csak kelloen eros hardver kell hozza!

Nem az. A feleségem bevásárlólista alkalmazása egy 5$-os linuxos szerveren: nginx + ASP.NET Core MVC

Fuszenecker Róbert

Wordpress -t inkább szolgáltatásként venném meg, pl. https://wordpress.com/

--
arch,debian,retropie,osmc,android,windows

Milyen objektiv elony szol az Apache mellett? Az nginx-et kb 800szor jobbnak latom.

Sub.

Fuszenecker Róbert

Nem trolkodok, miert? Csak apache-ot hasznalok jelenleg de boven eleg jo nem ismerek okot a valtasra.

Én régen úgy hallottam, hogy az apache ellen nagy érv a lassúsága szemben mondjuk az nginx-szel. Főleg, ha az emberek .htaccess-t meg ilyesmit használnak.

Ez részben most is így van, de csökkent a különbség.
Az Nginx a statikus tartalmat szolgálja kis sokkal gyorsabban, a php,... scripteket mindkettő ugyanolyan lassan (külön modul, külső feldolgozás,...).

A sok wordpress szaki+.htaccess ignore kombó "google:// inurl:wc-logs" aztán gyűjtögesd a bankkártyaszámokat. :P

1. .htaccess
2. ~userhome
3. suphp

Ezeket nem tudja az nginx. Egyiket sem tartom jó technológiának, de van olyan felhasználási terület, ahol nem lehet őket kiváltani.

1. https://www.nginx.com/resources/wiki/start/topics/examples/likeapache-htaccess/
2. Teljesen jól megoldható. Igaz, nem annyi, hogy egy modult behúzol, de néhány sorral megúszod.
3. A suphp helyett a php-fpm pool internetes okos(kod)ok szerint jó alternativa.

+1

Általában teljesen egyet értek veled, de van olyan környezet ahol ezek nem válthatóak ki nginx-el.

Egyetemi/középiskolai környezet, közös szerver amin a diákok a saját oldalaikat tárolják, és terminál-szolgáltatásokat használhatnak. ~1200 felhasználó

1. Nem szeretném 1000 felhasználó konfigurációját beolvasztani az nginx konfig fájlokba. Egy ilyen megoldásnak már a support költsége is több lenne, mint a .htaccess overhead.
2. Nem teljesen oldható meg, ugyanis más-más hibát kell kiszolgálni ha nem létezik felhasználó, vagy ha csak nincs weboldala.
3. A php-fpm nagyon jó, de egyrészt ~1200 poolt nem szeretnék futtatni, illetve nem szeretném ha poolok újrakonfigurálódnának minden egyes felhasználó törlésekor/hozzáadásakor. Ilyenkor csak a suphp marad.

Szóval általában igazad van, de vannak olyan ritka helyzetek ahol maximum modulok írásával lehetne az nginxet rávenni az elvárt működésre. Ilyenkor marad az apache, pedig hacsak lehet én is nginxet használok.

Mondjuk az is elég sajtreszelő-feeling hogy 1000+ usert htaccess-ből menedzselsz. :)
/off

Nem vagyok egy nagy nginx guru, de a 2.-at így meg lehet oldani:

location ~ ^/~(.+?)(/.*)?$ {
    if (!-d /home/$1) {
        return 405;
    }
    alias /home/$1/www$2;
    autoindex on;
}

Ha nincs user (/home/user könyvtár), akkor 405-ös hiba (Not Allowed), ha van, de nincs weboldala, akkor 404 (Not Found).

A felhasználók home mappája nem feltétlenül /home/username. A helyes útvonal csak a profiljukból derül ki. Ilyet is tudok olvasni nginx-el?

Persze, sokféleképp szopathatjuk magunkat! ;)
Boldog karácsonyt!

És biztos, hogy egy rossz tervezést egy webszervernek kellene kijavítani?

Egyébként olyanra gondolsz, hogy valakinek /home/teacher/jozsi, a másiknak meg /home/student/pisti a home-könyvtára?

Ha pár eltérés van akkor még kezelhető a konfigban is, de még akár linkkel is könnyen áthidalható ez a probléma, de szerintem is a megfelelő tervezés (egész pontosan a direkt rossz tervezés elkerülése) a jó megoldás.

Ami webszerver szempontjából rossz tervezés, az más szempontból ideális lehet. Egyébként az általad vázolton kívül még gyakori a /home/jo/jozsi, /home/pi/pisti elrendezés is.
(Valószínűleg a 3 problémából ezt lenne a legkönnyebb áthidalni, csak suphp hiányában nem érdemes.)

Idézet:
Általában teljesen egyet értek veled

Nem is gondoltam, hogy valaki ennyire követi a "munkásságomat". Igazán megtisztelő :)

Előrevetítve: nem vagyok/voltam rendszergazda, így a véleménye(i)m inkább elméletiek, mintsem gyakorlatiak, azaz a tévedés jogát fenntartom.
1. Nem feltétlen a plusz "költségre" gondolok. Valaki itt a HUP-on írta, hogy a .htaccess gyakorlatával azért nem ért egyet, mert a felhasználó ne próbálja befolyásolni a webszerver működését. Szerintem ebben a meglátásban van valami. Persze ettől az nginx még nem támogatja a .htaccess-t :)
2. Fentebb már írták, amit kb. írni akartam.
3. Ebbe nem mennék bele megfelelő szintű tudás hiányában, nem lennék értelmes vitapartner :( Max. csak annyi, hogy nem látom, hogy egy 1000+-os középiskolai/egyetemi környezetben miért lehet jó a suphp.

dupla

Fedora 25, Thinkpad x220

A suphp jó dolog. Van benne plusz security feature ami biztonságosabbá teheti a futtatást, főleg ott ahol sok user van. Ugye CGI miatt mindenkinek saját php.ini. Valamint csak akkor fut amikor kell. Viszont mivel CGI lassu, de valamit valamiért. 10 éve használom ott ahol kell. Kiválóan működik. Sőt néha jobban mint más.

Legutóbb pl php-fpm + nextcloud al vannak szívások. suphp-vel kicsitt lassabb de legalább működik.

Fedora 25, Thinkpad x220

1. Nem szeretném 1000 felhasználó konfigurációját beolvasztani az nginx konfig fájlokba. Egy ilyen megoldásnak már a support költsége is több lenne, mint a .htaccess overhead.

Egyik megkozelites ez.
En a masik oldalrol kozelitem meg: jo otletnek tartod, hogy a felhasznaloknak legyen befolyasuk a webszervered konfiguraciojara?
En ezt nem igazan tartom jo otletnek. Egy egyetemi-kozepiskolai kornyezetben, pedig kifejezetten ellenjavallottnak talalom, ahol nem egyszeru banki adminisztrator mancikak lesznek a felhasznaloid, de sokkal nagyobb az eselye, hogy a felhasznaloid kozott olyan is akad, akik a reseket fogjak keresni az egesz rendszeren.

2. Nem teljesen oldható meg, ugyanis más-más hibát kell kiszolgálni ha nem létezik felhasználó, vagy ha csak nincs weboldala.

Nem tudom milyen adatbazisban tartod a felhasznaloidat, de ilyen esetben en inkabb egy include-olt fajl generalnek valamilyen template alapjan.
template lehet akar valami jinja.
passwd / ldap / egyeb valtozas alapjan lehet triggerelni.
de akar az is lehet modszer, hogy 5 percenkent lefut egy script, ami a legutolso exportalt sorba-rendezett felhasznalolistat osszeveti az aktualissal. ha elteres van, ujrageneralja az include fajlt, majd reload az nginx-nek.

A php-fpm nagyon jó, de egyrészt ~1200 poolt nem szeretnék futtatni, illetve nem szeretném ha poolok újrakonfigurálódnának minden egyes felhasználó törlésekor/hozzáadásakor. Ilyenkor csak a suphp marad.

Miert tartod problemasnak 1200 pool futtatasat?
En sokkal kevesbe erzem biztonsagosnak, hogy fut egyazon uid alatti processzel valami, ami aztan at-suzhat masra, mint ha eleve minden pool kulon, mar eleve dropped cap-ekel inditott processzekbol all.
+ reload is letezik, ha hozzaadsz / elveszel pool-t.

Rendszergazdakent par scriptet osszerakni, ami cronbol (vagy mas triggerre) lefut, es templete alapjan ujrageneral fajlt / fajlokat nem kellene nagy ordongosseg legyen.

Szerintem.

1) Lehet szolgáltatni, vagy lehet helyette a felhasználókat szívatni. Rések mindig is voltak, lesznek, tudni kell őket kezelni.

2) Igen, van amit lehetne, bár nem annyira egyszerű mint gondolod. De tudod, lustaság fél egészség :-)

3) Erőforrások. Túl gyakori a reload és túl sok a user, miközben a hasznos webkiszolgálás terhelése szinte nulla. Többe kerül az állandó reloadolás, meg a poolok bizerálása, mint amit az egész web megeszik.

Elég komoly dolgokat integráltam már, jóval az egyszerű scriptelésen túlmutatókat is. Van hogy egyszerűen nem szabad küzdeni, mert felesleges.

Ez a konkrét eset is először nginx + php-fpm alapon volt integrálva a saját AD-re, működött is, de annyi volt a support nyűg meg instabilitási gond, hogy visszaállítottuk apache alá. Ez nem túl elegáns, de ezred annyi munkaidő alatt működik. Eközben az nginxnek ilyen alacsony terhelés mellett nincs érdemi előnye.

Eközben az nginxnek ilyen alacsony terhelés mellett nincs érdemi előnye.

Egyet azért tudnék mondani: Biztonság.

Az nginx-ben azt a unix szemléletet látom tükröződni webszerver szinten, amit az mta-knál először a qmail-nél, meg később a postfixnél láttam:
Szedjük szét a szolgáltatást kisebb komponensekre, és mindenki csak a saját dolgát csinálja.
Csak az nginx nem akarja maga egy nagy monolitikus bloatware-rel lefedni a teljes stacket.
Az analógiát követve, az nginx kb. csak annyit csinál, mint a postfix master processe + smtpd része.
A többi meg... Azt oldd meg php-fpm-el, meg amivel szeretnéd, az nginx remek kapcsolódási felületeket kínál.

És igen, az hogy eventdriven-re van tervezve ekkora terhelésnél nem ad észrevehető előnyt. De amikor elkezdik kicsit nyírni kívülről a rendszered...
Na akkor lesz nem mindegy! ;-)

Probald meg osszeszogelni ra a SAML-t. Lehet persze, csak fordits modult (ha mar van olyan verziod es meg nem a modul nelkuli regebbi). Ezzel szemben ott van a mod_auth_mellon.
Lehet hogy az nginx gyorsabb, jobb reverse proxyra, de van amiben az apache sokkal kenyelmesebb.

Nalunk nagyon jol megfer a ketto. Ha az nginx-et egeszen 800szor jobbnak tartod, akkor az apachot nem ismered elegge szerintem. Max 2-3szor jobb es csak egyes teruleteken. Masokon meg az apache jobb.

Ha az nginx-et egeszen 800szor jobbnak tartod[...] Max 2-3szor jobb

Kiszámoltad? :DD


tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Ugyanazzal az algoritmussal, amivel neki a 800 jott ki :)

SAMLt meg nem raktam ossze vele, de egy OAUTH eleg egyszeru proxyval lasd https://github.com/bitly/oauth2_proxy. De hogy megnyugtassalak, nem tartom rossznak az Apache-t, de nincs ra use-casem.

Akkor viszont nem 800szor hanem millioszor jobb :)

Pölö nagyon sok már létező plugin, amiből kevés van megoldva nginx esetén és az is rosszul működik... :)

Egyébként egy dolog amit nem szeretek az apache-ben az, hogy sokak számára egyenlő a webszerverrel és sikerül úgy elkészíteni egy kódot, hogy ne működjön más környezetben (lásd php apache specifikus függvények) vagy úgy megírni a telepítési útmutatót, hogy a htaccess fájlok kezelésének engedélyezéséről ír oldalakat, és meg se említi még csak felületesen sem, hogy más webszerverek esetén mi a teendő. Ez nem az apache hibája, inkább a fejlesztőké. Hasonló, mint ahogy kliensoldalon mindenki webkitre fejleszt, és leszarják, hogy létezik más böngésző :)

Ismerem. Ennyi. (valamennyire az nginx-et is, mert nagyreszt azt hasznalunk mindenhol, de az apachet meg ismerem, ergo jobban kedvelem)

--
http://www.micros~1
Rekurzió: lásd rekurzió.

Az uj igenyeket mar nginx-el oldom meg, de apachet is szeressem :)

---------------------------------------------------
Hell is empty and all the devils are here.
-- Wm. Shakespeare, "The Tempest"