Apache HTTP Server (httpd) 2.4.51

Byla vydána nová verze 2.4.51 svobodného multiplatformního webového serveru Apache (httpd). Řešena je bezpečnostní chyba CVE-2021-42013 (Path Traversal and Remote Code Execution) ve verzích 2.4.49 a 2.4.50. Oprava chyby CVE-2021-41773 v předchozí verzi 2.4.50 byla nedostatečná.

8.10.2021 09:00 | Ladislav Hagara | Nová verze

Komentáře

[okno]

Ok, no, další chyby co by nevznikli kdyby byl projekt dávno přepsán do rustu.

[SiouXngN]

Tak ono tam uz neni co noveho vymyslet, svou bohatou a historickou pout ma jiz za sebou a neni duvod to vylepsovat. Tak diky alespon za ty bugfixy.

[Max]

To samozřejmě není pravda, nové práce je spousty, podobně jako vylepšování a opravy chyb.
Zdar Max

[~]

vzdyt je

[okno]

právě jsi poslal že neni, tak ti hrabe?

[-----------------]

Já bych byl raději kdyby přepsali Nginx. Apache HTTPD nemusím.

[Max]

Proč?
Zdar Max

[proto]

Protoze budicek, apache jsem nepouzil uz snad 10 let. To snad uz pouzivaji jenom phpckari. V dobe CDN frci ngnx, tomcat a node.

[Ehm]

Vlákno bylo přesunuto do samostatné diskuse.

[Max]

Aby byl Ngixn použitelný, je třeba si platit verzi Plus za těžký many, nebo si udržovat vlastní sadu patchů a nechávat si je auditovat.
V tom pokrok opravdu nevidím, takže jedině Apache

Každopádně zajímal by mě ten budíček. Zeptal jsem se na důvod. Ty jsi uvedl takový, že ho nepoužíváš. To má být nějaký argument?
Provozuji vše zmíněné, jak Nginx, tak Apache, tak Tomcat, tak Node.js. A budu právě předělávat reverzní proxyny s Nginx na Apache, abych se dostal k fcím, které potřebuji, ale Nginx je nemá.
Zdar Max

[proto]

1. Kdo potrebuje Ngnix Plus? Vzdyt to je relikt co dela veci jako Apache - tedy po staru. Kdo to ppotrebuje pouzivat dela neco fundamentalne hodne spatne, nebo mu je pres 50 a staryho psa novym trikum... Nebo provozuje vlastni pornoserver! :D

2. Asi se budu opakovat ale K\kdo v roce 2021 potrebuje reverse tak dela neco fundamentalne hodne spatne...

[Max]

Load Balancer je Nginx v režimu reverzní proxyny. Chceš říci, že balancery nepoužíváš a máš jednotlivé služby napřímo vystaveny a terminuješ tls komunikaci na každém zvlášť? Takže máš pak bezpečnostní nastavení u každé služby zvlášť a né na jednom místě?
Zdar Max

[proto]

O loadbalance se stara CDN. Spawnuje nove instance dle potreby, regionu a zateze, detekuje DDoSy atd. vubec se o to nemusis starat jen nastavis mantinely. Ale kdyz takove veci nevis tak te ani nezatezuji, zij si svuj zivot spravce skanzenu a modli se at na to neprijde sef ze to jde levneji, rychleji a moderneji...

[Max]

Jasně, lidi bez znalostí, co si myslí, že sežrali šalamounovo hovno.
Ta tvoje slavná CDN, bývá většinou postavená na Nginx a milionu dalších aplikací okolo, aby to šlo automatizovat a mělo to super trúpr face pro klienty. Si někdy přečti, jak taková CDN funguje na core úrovni. A nemusíš chodit daleko, třeba kluci z CDN77 jsou celkem sdílní.
Takže vtipný, nejdříve opovrhuješ reverzníma proxynama a pak jako příklad moderní technologie uvedeš CDN, což je reverzní proxyna.
A pak je tu ta věc, že CDN není všespásná a stejně musíš balancovat a kešovat na více úrovních, aby jsi svůj obsah mohl té CDN také nějak stabilně naserírovat.
Zdar Max

[proto]

Bud tomu nerozumis nebo nechces rozumet. Ja psal, ze ten kdo resi reverse proxy (rucne) tak dela neco spatne protoze CDN to dela za tebe a mnohem lepe. Nesetkal jsem se s problemem, ze bych musel resit dodatocny balans, maximalne tak DB cluster. To ale s Apache nesouvisi, za mne proste uz 10 let retro technologie a kdo jej pouziva dnes by se mel vazne zamyslet.

[MP]

A tu CDN zaplati kdo?

[proto]

U nas zakaznik, je to soucast smlouvy kde je obvykle zvlast cena za dilo a zvlast cena za provoz. V pripade "modernich" continuos-rolling-release aplikaci se cena za dilo v podstate ani neresi a plati sa to cele jako sluzba. Dokonce mame i zakazniky, kteri si ani nenarokuji vlastnictvi zdrojovych kodu.

[Max]

Co to je "ručně"? Tím myslíš, že když to má webové klikátko nebo možnost api, tak to není ručně? Mě to celé totiž přijde tak, že když jsem správcem CDN, tak jsem fosil, sto let za vopicema, ale když jsem klient CDN, tak jsem super cool?
A když jsem správcem Kubernetu, tak jsem co? Tam je totiž také Nginx jako reverzní proxyna, jen se tomu říká obecně Ingress a konfiguruje se přes alternativní konfiguraci (je tedy nutné znát jak syntaxy Nginx, tak syntaxy Kubernetu, podle které se generuje ten config pro Nginx).
Také by mě zajímalo, jak tedy řešíš servírování dat pro CDN? To máš 100 aplikací, každou vystavenou na jiné IP, u každé nastavený sólo politiky (tls, cert, access pravidla) atd.? Nebo to neřešíš, protože používáš all-in-one solution pro běh aplikací včetně cdn? Tj. nepoužíváš externí CDN?

A nebo je celý tvůj příběh jen o tom, že jsi nahipovanej z Azure/AWS a protože ty to děláš takto, tak ostatní, kdo nepoužívají Azure/AWS jsou out?
Zdar Max

[proto]

Hele hele brzdi, ty vytahujes fakta. To neni fer, ja jsem jen obycejnej troll co si nasel fosila jako vdecny cil, protoze to doted nechapes ze te jen trolim. Toz mir a laska Winnetou, at zijou Apaci, howgh

[Heron]

To máš 100 aplikací, každou vystavenou na jiné IP, u každé nastavený sólo politiky (tls, cert, access pravidla) atd.?

V tomto nevidím problém, adminoval jsem mnohem víc než 100 aplikací a všechny vystavené rovnou do netu. Včetně tls, crt apod. Centrální tls proxy sice vypadá jako jednodušší na údržbu, ale zase je to SPOF. Je rozdíl zbořit webserver pro jednu službu a zbořit tu centrální proxy. Když nejede jedna služba z x tisíc, je to menší problém, než když nejede nic. Ta proxy samozřejmě musí být HA, což je další věc ke konfiguraci, co se může rozbít apod. Takže bych tohle řešení vůbec nezatracoval.

[Max]

To je samozřejmě pravda, ale i to jde řešit.
Zdar Max

[Max]

Jinak abych odpověděl na to, kdo potřeuje Nginx Plus. Právě třeba ten, co staví Load Balancer pro HA řešení, nebo pro Kubernetes aj. služby.
S klasickým Nginx to nejde, protože neobsahuje nutnou funkcionalitu.
Dále Ingress v Kubernetes je jen obyčejný Nginx v režimu reverzní proxy. Takže kdo používá Kubernetes, používá Nginx a reverzní proxy.
Jenomže řešit balancování ze strany klientů čistě jen na Kubernetu, to není moc vhodné, takže je před něj potřeba hodit externí balancer. Což člověk postaví buď na Nginx, nebo na Apache, menší okruh lidí pak na HAProxy a nebo něčem jiném, podobném.
Zdar Max

[trekker.dk]

Aby byl Ngixn použitelný, je třeba si platit verzi Plus za těžký many

Takhle všeobecně je to dost odvážné tvrzení. Nginx používáme a verzi Plus si platit nemusíme. Právě na reverzních proxy - ta placená verze by uměla pár věcí navíc, které by se hodily, ale není to nic, bez čeho se nedá žít.

Apache je pomalý moloch se spoustou nevýhod, HTTP/2 umí jen dodatečným modulem, modul pro správu FastCGI procesů by potřeboval dost vylepšit. Jediná jeho výhoda je, že podporuje .htaccess, což je velkou částí webových věcí vyžadováno. Vlastně takový vendor lock-in.

[proto]

Normalne nostalgie .htaccess jsme obsoletli nekdy pred 10ti lety a tak 8let je nepouzivame uz vubec. Par zakazniku odeslo ale vetsina se s tim smirila, protoze rychlostni benefit pouzivat pouze globalni konfig nebo inapp reseni je jasne presvedcil. Dnes uz tak jako tak frci AWS Secrets a tyhle starozitnosti nikomu nechybi.

[Max]

Pomalý je jen v určitých případech, jedním z nich já právě povolený ".htaccess".
Nginx nikdy nic takového podporovat nebude, vyjadřovali se k tomu vývojáři.
Důvodem je právě ten obrovský performance impact, co taková věc vyžaduje.
Zdar Max

[trekker.dk]

Pomalý je jen v určitých případech, jedním z nich já právě povolený ".htaccess".

To nepochybně. Ale lid si to žádá...

Nicméně to fakt není všechno, co je na Apache blbě. Zkuste si provozovat hodně živý server vystavený do internetu, najednou koukáte a desítky tisíc threadů. Proč? Protože nějaké síťové spojení zůstalo ve vytuhlém stavu (klient na mobilní síti, jednou za občas z toho přijde bajt, takže se to samo nerozpadne) + proces, který ho vlastní, dělá graceful restart (ukončuje se) + Apache nemá žádné nastavení, kterým by se dalo říct "časový limit na graceful restart je X". A najednou server nejede, protože kernel odmítá spustit další procesy (nebo co to vlastně bylo, to už jsem neřešil, šel jsem řešit příčinu.)

Dokonce jsem to jednou ladil a mám zato, že se v nějakých případech Apache takhle vytuhl sám. Proces v jednom vlákně čeká na uzavření file descriptoru, který sám drží otevřený, takže na to nikdy nedojde.

To je mpm_worker, pak máme mpm_event, ten je o něco lepší. Ten do limitů na počet procesů počítá i ty, které se ukončují, takže na desítky tisíc threadů nedojde. Bohužel dojde na to, že z x desítek povolených procesů je x desítek bez dvou ve stavu, kde se ukončují a neberou nová spojení, a celý webserver jede (moc nejede) na zbylé dva. O mpm_prefork se ze zjevných důvodů nebudu ani vyjadřovat.

Každopádně jsem psal skript, který hledá procesy v divném stavu a zabíjí je SIGKILLem, protože nic menšího na to neplatí. O tom, jak nedobrý nápad je zabíjet procesy, které používají SYSV sdílenou paměť a semafory a jánevímco ještě, signálem, který jim neumožní po sobě tyhle věci uklidit, asi nemusím psát.

A tohle není problém .htaccess, to je problém v základním kódu Apache a jeho různé variace se v tom serveru objevují už léta. O jednom-za-občasném SIGSEGV ani nemluvit.

Oproti tomu Nginx používám bez supervizoru, který by ho restartoval, protože narozdíl od Apache to snad nikdy nebylo potřeba. Samozřejmě, jak jsem psal, nemůžu ho použít všude, protože .htaccess

Jinak by mě zajímalo, co je na Nginx tak nepoužitelné bez Plus. Když teda odhlédnu od toho, že když máte na Oracle, tak moc a moc pochybuju, že by peníze za Nginx byly "těžký many"

[trekker.dk]

Jinak by mě zajímalo, co je na Nginx tak nepoužitelné bez Plus.

Never mind, přehlídl jsem #24

[Max]

Já Nginx používám čistě jen jako LoadBalancer / Reverzní proxy, na kterém terminuji klienty. Na nic jiného. A za Nginxem pak běží Apache, Tomcat, Jboss, Kubernetes a další.
S tebou popsasnými porblémy jsem se nesetkal, ale možná je to tím, že mám malý počet klientů.
Kaýdopádně aby člověk mohl provozovat stabilní load balancer, tak musí podporovat aktivní health checky. A to je jedna z věcí, kterou má Ngix jen ve verzi Plus.
Zdar Max

[trekker.dk]

Dobrá, sám tohle neprovozuju, takže jak myslíte. Jenom říkám, že moje zkušenosti jsou takové, že kdybych měl řešit load-balancer (což je něco, co si spojuju s velkou zátěží), tak bych spíš zkoumal, co zvládne HAproxy - a určitě neřešil Apache.

[Max]

Tak zrovna loadbalancer je flákač, protože jen terminuje tls a vše přeposílá dál a veškerou těžkou práci obstarají ty servery na backendu.
Zdar Max

[trekker.dk]

"Jen terminuje TLS" pro kolik klientů? To je to zásadní. Jestli je to nějakej intranet, kterej kdovíproč potřebuje balancer, nebo firemní web, kam se přijde jednou za den podívat Google, tak je to skutečně fuk, dejte si tam klidně Apache. Pokud tam běhají stovky požadavků za sekundu, tak to je přesně situace, kde bych se Apache zkusil vyhnout, pokud to je jenom trochu možné.

[Max]

Mám dva clustery pro reverzní proxy, jeden pro externí komunikaci (služby publikované do netu), druhý pro interní služby (pro interní provoz firmy, která jede 24/7). Celkem tedy 4 servery.Teď nevím, kolik requestů jede, ale málo, něco jako 10/s. Ty proxyny se flákají, užší hrdlo je na backendu.
Při jednom né zcela chtěném testu to zvládlo 50k/s, než začaly docházet lokální tcp zdroje, nikoly fyzické (ram i cpu to dávaly, ale vyžralo to všechny zdroje v rámci kernelu a tcp/ip protokolu)
Zdar Max

[trekker.dk]

Při jednom né zcela chtěném testu to zvládlo 50k/s, než začaly docházet lokální tcp zdroje, nikoly fyzické (ram i cpu to dávaly, ale vyžralo to všechny zdroje v rámci kernelu a tcp/ip protokolu)

Ano, to je přesně ten problém, který v Apache je. A narazíte na to i při provozu, který není ne zcela nechtěným testem.

[Max]

Ten test nebyl u Apache, ale u Nginx. A souvisí se zdroji kernelu a tcp/ip obecně. Byl to limit default nastavení kernelu v Debianu. Při troše tuningu parametrů kernelu to jde navýšit.
Zdar Max

[trekker.dk]

Aha. Akorát jak jsem psal, podle mě se Apache chová tak, že to nejde navýšit dost na to, abyste na ty limity v zátěži stejně nenarazil. Respektive podle toho, jak často se ten server restartuje, ty procesy tam zůstávaly viset fakt dlouho...

[Ptr]

Nginx je obecně větší kamarád se zero-downtime přístupem (třeba že když se graceful reload po změně konfigurace nepovede, pořád máte běžící staré worker procesy, nebo že configtest v Nginxu umí odhalit o dost více chyb).

Jinak by mě zajímalo, co je na Nginx tak nepoužitelné bez Plus.

Pokud se bavíme o load balancingu, tak absence sticky cookies (3rd party modul sehnaný pod rukou někde na Githubu není to samé) může být dost velký problém.

[Max]

Ano, kromě aktivního health checku jsou tu ještě ty sticky session, které jde ale tak nějak řešit krkoloměji i na free verzi, ale podobně jako 3rd pluginy na githubu to také není úplně ideální. Teda pokud člověk potřebuje sticky session (pokud je aplikace na backendu dobře postavená, tak nejsou třeba).
Zdar Max

[Heron]

Aby byl Ngixn použitelný, je třeba si platit verzi Plus za těžký many, nebo si udržovat vlastní sadu patchů a nechávat si je auditovat.

Ano, bohužel. Je to další z řady "OSS" produktů, které jsou jen výtahem pro prodej komerčního balíku. Stejně jako třeba kdysi dobré Mongo a celá ta mašinerie kolem ELK.

Na Apache je sice ten věk vidět (nesedí mi moc způsob konfigurace), ale je to asi nejlepší volba. (Používám apache, nginx a někde snad i lighttpd.)

[trekker.dk]

Bohužel? Pokud je cenou za to, že mnoho lidí má "zdarma" (práce něco stojí) k dispozici velice dobrý - v mnoha ohledech nejlepší - webserver, to, že někdo musí platit za vychytávky, bez kterých se lze relativně snadno obejít, tak je to snad bohudík, ne?

Na Apache je sice ten věk vidět (nesedí mi moc způsob konfigurace), ale je to asi nejlepší volba.

Proč? Teda proč praktické důvody, ideologické viz výše.

[Heron]

Bohužel, protože to typicky končí tak, že z free části zůstane chudá příbuzná a celé je to jen lákadlo na tu komerční část. A je to otázka motivace těch lidí. Jestli to dělají jen pro ty funkce (aby byly nejlepší apod.), nebo jako lákadlo.

Proč? Teda proč praktické důvody, ideologické viz výše.

Moc mi nesedí jeho způsob konfigurace, ale tj čistě individuální. Nemám moc rád xml like configy, ani moc yaml.

Co se týče té nejlepší volby, tak je tam všechno. Dokonce i ten event z nginxu. Tj mám na výběr různé workery, můžu (nemusím) použít moduly (v nginx jen proxy), tj umí to servírovat nejen statické soubory, ale i třeba perl, python, (ano, i to php), udělat to proxy na backendy apod. Nginx umí vlastně jen event a proxy.

Navíc jsem se na apache začal dívat jinak po přechodu na freebsd. Na linuxu dřív, to bylo kompilované se vším (a dokonce povolené v konfigu) a byl to prostě moloch. Potom postupně to kompilovali jako dynamické moduly (a byly by default vypnuté). Ve Freebsd si kompiluju pouze to, co skutečně potřebuju. Takže na něterých instalacích je to v podstatě jen event pro statické soubory. (Jasně jo, tohle se dá dělat i na linuxu, ale ne všechny distra mají tradici a řádnou podporu pro kompilace a konfiguraci balíčků.)

[Max]

Pod Nginxem můžeš provozovat php přes fastcgi, python přes uwsgi.
Zdar Max

[Heron]

Opravdu si myslíš, že to nevím? Ale to je právě ta proxy funkce. To už je v některých příkladech lepší to mít přímo připojené do těch webserverů v těchto programech. Služeb napsaných v golangu takto běží hodně. V pythonu ostatně také.

[Max]

Apache je na tom ale podobně, tam není moc best practicles to provozovat v rámci něho, ale php jede také v režimu fpm, Apache stejně jako Nginx se bindují na jeho socket apod.
Zdar Max

[Heron]

Jasně, že to jde a že je to tak správně. Ale nasazení modulu je nejjednodušší a v určitých instalacích nic dalšího nepotřebuješ. Jako je zvykem zatracovat prefork worker a phpmod, ale vsadil bych se, že právě tato kombinace si na internetu odpracovala suverénně nejvíc práce, zejména na těch malých webech, kterých je ale většina.

Ostatně, proč se za to stydět, v minulé firmě jsme takto provozovali stovky instancí software, byli jsme největší (podíl 40-60% dle produktu) a velmi často první. Elektronické tržiště nové generace jsme v roce 2012 na zatracovaném PHP měli v provozu jako první. Ano, samozřejmě, že existují lepší jazyky apod, ale tohle je prostě fakt. Apache, phpmod, php, postgresql, bez výpadků, slušný výkon. Srovnej si, kolik stojí takový NEN. Souhrnná cena našeho systému nebyla ani 10% ceny za nen.

[trekker.dk]

Jako je zvykem zatracovat prefork worker a phpmod, ale vsadil bych se, že právě tato kombinace si na internetu odpracovala suverénně nejvíc práce, zejména na těch malých webech, kterých je ale většina.

To sotva. Vzhledem k tomu, že prefork nedokáže odvést hodně práce, nemohl na internetu odpracovat nejvíc.

Apache, phpmod, php

Dokud v celém webserveru běží jedna aplikace a nepotřebujete do toho moc vidět, co to dělá, když něco nefunguje dobře, fajn. Jinak jsou všechny mod_jazyk prasárna.

[trekker.dk]

Bohužel, protože to typicky končí tak, že z free části zůstane chudá příbuzná a celé je to jen lákadlo na tu komerční část. A je to otázka motivace těch lidí. Jestli to dělají jen pro ty funkce (aby byly nejlepší apod.), nebo jako lákadlo.

No, zatím to vypadá tak, že ať už je to jakkoliv, tak z toho vypadl velice dobrý webserver. Toho, že by Apache něco dohnal, jsem si teda moc nevšiml, ale pokud to tak je, tak další plus. Samá pozitiva a i kdyby se nakonec stalo to, co popisujete, tak jsme furt v plusu. Bohužel tady prostě není správné slovo.

Dokonce i ten event z nginxu.

To jsem popsal vedle, funguje hůř.

můžu (nemusím) použít moduly (v nginx jen proxy), tj umí to servírovat nejen statické soubory, ale i třeba perl, python, (ano, i to php)

Hm, to bych jako výhodu nebral, provozovat interpreter ve webserveru nepovažuju za dobrej nápad. Maximálně v prostředí, kde v tom webserveru běží jen ta aplikace a nic jiného.

[Heron]

No, zatím to vypadá tak, že ať už je to jakkoliv, tak z toho vypadl velice dobrý webserver.

Zatím. To je přesné. Takto jsem před x lety chtěl nasadit mongo, potom začali cosi dělat s licencema (rozdělení na free a komerční) a člověk nemá jistotu, co s tím bude dál. Nasazovat to na nový projekt je risk. Nebo třeba MySQL. Oracle začal dělat nekompatibilní změny a zavřel testovací tooly. Takže maria si jen těžko ověří kompatibilitu. Já si buduju stabilní stack, apache tady byl před 20 lety, postgresql tady taky byl před dvaceti lety, oboje je použitelné konstatně těch 20let. To že třeba to není neustále první na pásce co se týče výkonu nebo vlastností je možná méně důležité, než být nucen projekt rychle přestěhovat jinam. (Možná je to nuda, jak o mě někdo napsal, ale já doporučuju co nejstandardnější funkce, třeba psát SQL dle normy a moc nepoužívat extension dané db, aby bylo možné snadno přejít, kdyby něco. Zatím ta potřeba nebyla.)

Maximálně v prostředí, kde v tom webserveru běží jen ta aplikace a nic jiného.

No přesně. Já taky provozuju nginx s proxy na backend (čím dám častěji tedy už přímo nasazujeme přímo ten backend bez další mezivrstvy), ale apache s modulama se hodí přesně na (malé) servery s jednou appkou. Stačí instalace jedné služby. Jednoduché na nastavení, rychlé na instalaci.

[trekker.dk]

Zatím. To je přesné.

Ale to přece není špatně. I kdyby čase začali cosi dělat a situace se změnila, že by Nginx už nebyl tak dobrou volbou, pořád za sebou nechává to, že jste jej mohl mnoho let ke spokojenosti používat a že (možná, já to nevidím) dokopal konkurenci, aby začala něco dělat.

oboje je použitelné konstatně těch 20let

Ne, není. Provoz, který byste před 10 lety považoval za obrovský, je dneska relativně normální a Apache to nedá. Máme nějaké HTTP/2, v Nginx normální funkcionalita, v Apache dodatečný modul, který sice funguje, ale dobře navržené to rozhodně není - https://httpd.apache.org/docs/2.4/mod/mod_http2.html#how-it-works . (Nějakou dobu zpátky tam bylo taky varování, že vám nebude fungovat mod_status)

To že třeba to není neustále první na pásce co se týče výkonu nebo vlastností je možná méně důležité, než být nucen projekt rychle přestěhovat jinam.

Dobrá, to je rozhodování podle neexistujícího rizika. (Ukažte mi jediný scénář, kdy se vývojáři Nginx rozhodnou k něčemu, co by vyžadovalo projekt rychle přestěhovat jinam, tj. co by způsobilo, že ze všech distribucí najednou Nginx zmizí a nebude jej možné bezpečně používat dalších několik let v rámci podpory ze strany distributora.)

[Heron]

Ale to přece není špatně. I kdyby čase začali cosi dělat a situace se změnila, že by Nginx už nebyl tak dobrou volbou, pořád za sebou nechává to, že jste jej mohl mnoho let ke spokojenosti používat a že (možná, já to nevidím) dokopal konkurenci, aby začala něco dělat.

Jo. Tak rozhodně přinesli nový koncept těch event a už to není klasickej fork model. Na druhou stranu (nevím jak je to dneska, dneska se to dá uhnat výkonem HW a počtem jader), ve své době (tím neříkám, že dnes je to výrazně jinak) měl linux strašně rychlý forky a na centos5 jsme fakt neměli problém to uforkovat. Ale jako mým úkolem nikdy nebylo udělat 50krq/s na 486, my jsme to vždy ubyli HW, protože co si budem, ten backend je vždy minimálně o dva řády pomalejší než pomalej apache. Takže jestli se něco zadýchávalo, tak to nebyl webserver, ale naše appka. Nemá smysl řešit 1ms na apache vs nginx, když backend má 100ms per rq (nad velkou db apod.). Jsme řešili výkon úplně jinde, než na webserveru.

Máme nějaké HTTP/2, v Nginx normální funkcionalita, v Apache dodatečný modul, který sice funguje, ale dobře navržené to rozhodně není - https://httpd.apache.org/docs/2.4/mod/mod_http2.html#how-it-works .

Viz výše. Ono to strašně záleží na tom, co se servíruje. Jestli někdo staví CDN pro css, js, webp soubory, tak je to trochu jiné, než když je zatím backend, který skutečně něco počítá a skutečně to trvá.

(Ukažte mi jediný scénář, kdy se vývojáři Nginx rozhodnou k něčemu, co by vyžadovalo projekt rychle přestěhovat jinam, tj. co by způsobilo, že ze všech distribucí najednou Nginx zmizí a nebude jej možné bezpečně používat dalších několik let v rámci podpory ze strany distributora.)

Několik let nemusí vždy stačit. U velkých nonstop provozů je výměna nějaké technologie vždy problém, i když se snažíte sebevíc. Aktuálně pracuju pro lidi, kteří před několika lety přešli z jiné db na postgresql a ten proces stále není dokončen. Změna se vyplatila, vývoj je svižnější, nasazení díky OSS snadnější apod, ale toto není komponenta, kterou lze vyměnit ze dne na den kus za kus. Ani když je to napsané přesně dle SQL normy. Vyměnit webserver a zrovna nginx by bylo snadnější, ale pokud má někdo například v apache masivně nasazené htaccesy a rewrity, tak to taky nebude sranda. Do budoucna si stejně myslím, že důležitost webserverů bude klesat a zůstanou z nich jen HA proxy. Dneska se čím dál častěji nasazují rovnou backendy do internetu. Ostatně proto google přišel s golangem, protože napsat jednoduchou rest api (micro)service je fakt trivka a nepotřebuju k tomu na serveru nic jiného, než tu jednu staticky zkompilovanou binárku (a možná konfig).

[trekker.dk]

Viz výše. Ono to strašně záleží na tom, co se servíruje. Jestli někdo staví CDN pro css, js, webp soubory, tak je to trochu jiné, než když je zatím backend, který skutečně něco počítá a skutečně to trvá.

Jasně, taky jsem to tady někde psal - pokud je za tím pomalá aplikace a hlavně na ten web nechodí moc lidí, tak si s Apache samozřejmě vystačíte.

Několik let nemusí vždy stačit.

Já teda nevim, ale třeba kdyby se teď vývojáři třeba Postgresu rozhodli, že budou debilové, tak (Debian) máme 2 roky za stable + 1 rok oldstable + 2 roky LTS + 2 roky ELTS. To je 5 nebo 7 let. (Ty poslední dva roky nejsou zadarmo, ale velký nonstop provoz asi beztak neprovozuje Debian nebo přinejmenším nebude mít problém prosponzorovat se k ELTS.) U takového RHELu by to dost možná bylo ještě víc. To mi přijde dost i na to, aby se s takovou změnou dokázal vyrovnat velký nonstop provoz.

Plus se tady bavíme o webserveru, který ve stejném modelu pracuje už nějakých 17 let, zatímco Apache 26 let. Tj. relativně vzato si důvěru na základě "existují dlouho" oba.

A to všechno za předpokladu, že by to nedopadlo podobně jako u (naposledy) ElasticSearch, kdy vývoj pod původní open-source licencí okamžitě převzal někdo jiný a nebylo potřeba řešit téměř nic.

[Max]

Ty placené fce se postupně začínají dostávat i do požadavků běžných nasazení. Stačí, když chceš mít dva servery a dělat si triviální HA a s Nginx můžeš mít problém. Nebo pokud chceš balancovat nějakou app na localhostu, která třeba díky špatnému návrhu neumí více threadů, ale jde to řešit vícenásobným spuštěním. V podobných případech pak s Nginx nejsi moc dobře schopen zjistit, zda ta aplikace žije a může to skončit tak, že tě odřízne od funkční aplikace. Jsou to jen příklady, reálných druhů nasazení, kde může nastat problém, bude více.
A upřímně řečeno, já Nginx provozuji čistě jako proxy řešení podobně jako většina lidí. Tj. na samotném Nginx neprovozuji snad nic (možná servírování pár statických souborů). A podobně je Nginx využíván i dalšími lidmi a projekty.
Apache v tomto ohledu dokáže zajistit podobnou funkcionalitu jako má Nginx plus. Ze začátku Apache ujížděl vlak, ale Nginx ho donutil a myslím, že toho Apache hodně dohnal.
Zdar Max

[Alois]

Když už musíš všude trolovat o Rustu, tak se alespoň nauč psát pořádně česky a bez tak okatých hrubek ty demente....

[okno]

Umym česky jsem punk demente