HOVD 2023 - Kedvenc http szerver

HUP

  Itt a HUP Olvasók Választása Díj 2023 szavazás. Az idei HOVD immár a tizennyolcadik a sorban.

  A HOVD 2023-on minden HUP olvasó szavazhat. A HOVD 2023 választás ideje - két hónap - alatt a 20 kategóriában állított jelöltekre lehet majd szavazni.

  Szavazz az alábbi kategóriákban! Kedvenc ...

apache
42% (342 szavazat)
beépített http szerverek (simplehttpserver, webrick stb.)
2% (14 szavazat)
h2o
0% (0 szavazat)
hiawatha
0% (1 szavazat)
java servlet container-ek (pl.: tomcat, jetty, ...)
3% (27 szavazat)
lighttpd
5% (37 szavazat)
litespeed
0% (4 szavazat)
microsoft iis
2% (20 szavazat)
nginx
45% (359 szavazat)
thttpd
0% (1 szavazat)
Összes szavazat: 805

( DirtY_iCE | 2023. 06. 27., k – 16:41 )

Nginx-re nyomtam, bar tobbnyire az csak reverse proxy a gepen futo tobbi 6*10^23 random app random frameworkjenek random http szerverehez.

Mondjuk a static fajlokat azokat o szolgalja ki magatol.

I hate myself, because I'm not open-source.

Nem biztos, hogy a sysadminon múlik, hogy mi lesz. Egyes körökben, a tudjukhol, például a .htaccess hiánya hisztériás rohamot okoz (okozott már többször), hiszen a statikus nginx konfigot nem lehet random észnélkül módosítgatni. Arról nem beszélve, hogy sharedhostingon próbáld meg leváltani...

Még az ngxinx-szel vagy varnish-shal reverse proxyzott, illetve nginx esetén a statikus file-okat nginx-el kiszolgálást se igazán veszik be.

Az volt előzőleg, hogy meglepte mennyire népszerű az apache.

Így van. Sok embernek az apacs a kedvence. Ez volt meglepő. Semmi köze ahhoz, hogy hány helyen van telepítve kényszerből.

Nekem hiába az nginx a kedvencem, ha a gépek kb. 10%-án sincs, mert apache-ot követelnek.

Ha az nginx a kedvenced, akkor arra szavazol. Teljesen mindegy, hogy hány gépen van.

disclaimer: ha valamit beidéztem és alá írtam valamit, akkor a válaszom a beidézett szövegre vonatkozik és nem mindenféle más, random dolgokra.

Egy csomagból felszórt nginxnek ugyanez lesz a baja, de nem azért mert nem tudja, hanem mert rendre belepakolnak valamilyen max connection értéket. Ha a webszervered bírná, akkor előtte a csomagszűrőd fog hamar elfogyni. Másrészt egy 20 éve valaha létező dolgot nem biztos, hogy nem javítottak, stbstb...

igen, huszonvalahany eve... azota az apacheban is implementaltak ugyanazokat a technikakat, mint ami anno az nginx-ben ujdonsag volt. pont ugyanazt meg lehet ma mar apaccsal is csinalni, ugyanolyan gyorsan, sot tobbet is, mert apachenal valogathatsz tobbfele implementacio es threading technika (mpm prefork etc) kozott, attol fuggoen mi a cel. fastcgi is megy ugyanugy php-fpm-el mar ugy 10 eve, tehat mar nem kell a mod_php korlataival se kuzdeni.

Mivel állapot tartó, a kiszolgáló szálak száma véges, az ezek által lefoglalható TCP portok száma is véges és nem nulla ideig tart a kiszolgálás, így megfelelő kérésekkel le lehet foglalni az összes kiszolgáló szálat, és a következő kérést el fogja hajtani definíció és tervezett működés szerint. Ennek ékes példája a slow-loris szerű kérésekkel bombázás, amikor lassan csorgatod a kérést és lassan fogadod be a választ. Nem annyira, hogy mondjuk az IPS slow-loris érzékelése ideges legyen, de már szemmel látható ideig fogva egy-egy kiszolgáló szálat. Ha nagyon ki van hegyezve egy nagy apache kiszolgáló, akkor is max 50k porton tud fizikailag kommunikálni (itt már a kernel anyáz, hisz 65535 port az elméleti limit), ha 5 másodperces lassított kérésekkel bombázod, akkor már 10k req/s elég hogy kiüsd, arra pedig egy noti is elég. És ennyire nem sok ember tudja kihegyezni, alapból valami 2k szálat kezel, tehát akár már 400 req/s elég a bedugításhoz. 

De ettől az apache nem rossz, sőt. Pont ez az állapot tartó működés például kifejezetten kívánt ahhoz, hogy megvédje pl a mögötte ülő még kisebb párhuzamosításra képes alkalmazás szervereket. Csak tudd mikor melyik eszközt miért használod. 

A "jobban" szót nem használnám, inkább "másképp". Az nginx "állapotmentes", akkor izgul rá egy kérésre amikor az már az utolsó bit-ig bejött, és tolja is ki a választ ahogy a csövön kifér kvázi fire and forget alapon. Emiatt a lassú kérések nem/nehezen tudják betelíteni, cserében a mögöttes infra terhelés elleni védelmére sem jó (illetve lehet az, de másképp). 

A TCP is csak a pufferek és a státusztáblák méretéig állapottartó, ami oda nem fér be azt elhajtja, és egyben a protokoll sajátosságai miatt a fogadó le tudja szabályozni a küldőt hogy "hé, lassítsál már". Ha az leszarja, akkor meg el lesznek dobálva a csomagjai. A webszerverek és a webes kliensek közt nincs ilyen szabványos szabályzó protokoll (ha lenne, a támadók úgyis letojnák), így L7-be az L3 réteg sebességével megérkeznek a kérések. 

A hívó böngészők és a kiszolgáló webszerver közt általában csak hálózati eszközök vannak, azok pedig csak addig pufferelnek, amíg a csomag darabkái megérkeznek, azaz L7 szempontjából kvázi sehogy. Amikor sok hívó van, ezek sebessége különbözik, vagy a hívások alkalmazásszerverben végződnek, ahol vannak lassabb válaszidők is, és mondjuk peak-ben több kérés jön be mint amennyit egyszerre kezelni tudsz, valakinek a kéréseket késleltetnie kell hogy ne dögöljön bele a backend infra. Ha nincs ilyen a láncban, akkor ha nem korlátoztál hálózati eszközön, megdöglik a backend és annak a helyreállása hosszú idő (mire kipörögnek a kérések), ennél jobb, ha a hálózati eszközökön forgalmi korlát van a backend kiszolgálási képesség alá kicsivel belőve. Viszont mindkét esetben a felhasználók oldalán mindenképpen megjelenik a hiba (connection reset, timeout, még a http error code sem tud visszamenni). Ami nem szép, mert ugye kultúráltabb, ha vissza tudsz adni legalább egy hibaoldalt hogy "bocs, túlterhelés van, próbáld meg később". Persze mint mindent ezt is meg lehet oldani sokféleképpen, pl ha SPA-t tolsz ki kliens oldalra hosszú local cache idővel és az maga inti türelemre a felhasználót. 

ez igy bullshit!

> akkor izgul rá egy kérésre amikor az már az utolsó bit-ig bejött

es addig megis ki fogja parsolni a beerkezo byteokat? azaz honnan tudja bejott-e mar az utolso bitig? azaz megnezi hogy ha GET akkor az elso ures sorig, ha POST akkor a Content-Length-ben megadott mennyiseg vegeig bejott-e? Valakinek meg kell ezt csinalnia, es a kernel nem fogja, tehat marad az nginx-re a feladat. magyarul az elso bittol kezdve ra kell izgulania...

> tolja is ki a választ ahogy a csövön kifér kvázi fire and forget alapon

hat ha statikus a tartalom akkor oke, elintezi egy sendfile-al, de amugy?

> webszerverek és a webes kliensek közt nincs ilyen szabványos szabályzó protokoll

hat ha nem is szabvanyos, de amugy van ilyen, en web scraping kozben tapasztaltam eleg gyakran, hogy az elso nehany 100 request utan hirtelen durvan belassult, es 1-5 masodpercet vart a szerver minden valasszal onnantol kezdve.

Pongyolán fogalmaztam, de attól még így van.

Az nginx async non-blocking módon működik, a lehető legkevesebb erőforrással félre rakja ami még nem érett feldolgozásra. Így nem tart futó dedikált szálat a kapcsolat kezelésére. 

Persze így is vannak elfogyó erőforrások, csak nagyságrendileg tovább tuningolható, mint az apache. 

> de attól még így van.

csak en nem ertem ennek a jira foshalomnak (ami amugy tomcat-al megy) mi koze az nginx vs apache vitahoz?

> Az nginx async non-blocking módon működik

ha akarod, az apache is:  The event MPM handles some connections in an asynchronous way

Egyrészt ez a változtatás csak néhány éves, másrészt a mögöttes architektúra nem változott, így ugyanúgy drága thread-ek indulnak csak kevesebb, ezzel sok esetben egész közel jut az nginx teljesítményéhez, de el nem tudja érni. Kiemelném hogy onnan indult az egész hogy megvédtem az apache-ot, mert jó cucc, és sok esetben könnyebb/jobb használni mint nginx-et. A különbség ott jelentkezik hogy funkcióban vagy határterhelésnél kell versenyezni, mert előbbinél az apache nyer, utóbbiban az nginx. Átlagos terhelésű sima webszerver vagy alap proxy funkció esetén pont semmi különbség.

A slow-loris vagy "szerű" működés sajnos valós probléma, nem is kell támadó, elég ha van pármillió felhasználód és vagy egy részük purgyé hálózaton van, vagy már tele a sávszélesség és emiatt lassan jönnek be a kérések. Ha túl érzékenyre állítod a védelmet, akkor a valós de lassú neten ülő felhasználók is szívnak, ha kevésbé érzékeny, akkor meg radarhatár alatt be lehet repülni támadással is. 

Valójában nincsenek is igazán képben, hogy mi miért történik, csak a zinternet kidobta.

Ez amugy az egesz IT vilagat is nezve sajnos igaz a legtobb dologra, hogy sokszor meg az az ember akinek elvileg ertenie kene hozza, az is csak beirja gugliba/chatgptbe/anyamkinjaba, es az elso talalat jo lesz gondolkodas nelkul.

I hate myself, because I'm not open-source.

Az Apache pont azon szoftverek egyike, amivel kb. semmi bajunk nem szokott lenni. A statikus tartalmakat a mai vasakon röhögve kiszolgálja, a dinamikusakhoz pedig nagyjából semmi köze, legfeljebb reverse proxy előttük.

Az erőforrások 99%-át pedig úgyis a dinamikus tartalom, meg az adatbázis backend viszi el.

Engem nem lep meg, hogy népszerű. Sok tutorial van hozzá, meg sokan azzal indítottak LAMP/WAMP keretek között, így ragaszkodnak ahhoz, amit ismernek.

“Windows 95/98: 32 bit extension and a graphical shell for a 16 bit patch to an 8 bit operating system originally coded for a 4 bit microprocessor, written by a 2 bit company that can't stand 1 bit of competition.”

( Nyosigomboc v | 2023. 06. 27., k – 22:20 )

Igazabol nemtom. Nincs nagy forgalmu oldalam, hobbira meg jo a lighttpd meg az apacs is. Elobbi a telefonomon is elfut.

A strange game. The only winning move is not to play. How about a nice game of chess?

Én is így vagyok vele. A lighttpd elég arra az alap dolgokra, amire nekem hobbistának hirtelen kellhet, kis szutyok, elfut mindenhol. Persze a thttpd se annyira rossz alternatíva erre. A klasszik nginx, Apache (ebben a preferenciasorrendben) ellen sincs kifogásom épp, nagyon mellényúlni azokkal se lehet. Ami a lista többi részét illeti, azoknak az egyik felét bottal sem piszkálnám meg (IIS, Tomcat), a másik feléről meg bevallom, hogy nem hogy nem használtam, de sose nem is hallottam róluk (h2o, hiawatha, litespeed). Persze ez hibám is, mert ebből a szempontból lusta vagyok, a webszerver az, ahol nem célszerű a kereket újra feltalálni, és az ember szívesebben marad egy jól bejáratott, ismert megoldásnál. Meg valahogy ahogy öregszem, egyre inkább belefáradok abba, hogy épp új hájpvonatra felszálljak, meg mindig újat tanuljak, amiben a kerék újra fel van találva, próbálok a legegyszerűbb, de még működő, nagy múltú megoldásoknál maradni, amik később sem mennek valószínű a süllyesztőbe.

“Windows 95/98: 32 bit extension and a graphical shell for a 16 bit patch to an 8 bit operating system originally coded for a 4 bit microprocessor, written by a 2 bit company that can't stand 1 bit of competition.”

( arpi_esp v | 2023. 06. 27., k – 22:30 )

apachre nyomtam mert a php webszervereken azt hasznalunk, de amugy python projektekben mostanaban tornado-t hasznalok.

( artifex | 2023. 06. 28., sze – 00:32 )

Nem olyan régen felfigyeltem erre, még nem tudom megmondani, hogy kedvencem vagy sem: https://caddyserver.com/

"Az élet tele van kérdésekkel. Az idióták tele vannak válaszokkal."

"Its easier to fool a man than it is to convince they have been fooled"

( tothaa | 2023. 06. 29., cs – 05:32 )

az én kedvencem ORDS + Oracle APEX

Airconditioned terminal, do not open Windows.