Vlákno názorů k článku
ČSÚ: Za výpadek volebních webů může DDoS na infrastrukturu O2 [AKTUALIZOVÁNO] od Jan Holík - Za výpadky webu může za prvé přímo ČSÚ,...

Za výpadky webu může za prvé přímo ČSÚ, protože web má napsaný takovým způsobem, kdy dochází vzhledem k účelu - což je jen VEŘEJNÁ NÁSTĚNKA a hromadné sdělení nějaké informace veřejnosti k naprosto zbytečné zátěži serveru, kdy se hodně stránek GENERUJE.

ČSÚ mělo volby.cz udělat jenom jako čisté a minimalizované HTML + minimalizované CSS a nedělat takové prasečiny jako tam třeba barevný TEXT(!!!!!!!) "VOLBY.CZ" dávat jako GIF. Pokud očekávám takovou brutální zátěž, tak je nejlepší je zkrátka NIC NEGENEROVAT, nedávat tam ani žádné obrázky (pokud vyloženě nemusím), vše dělat statické a grafické ztvárnění dělat v CSS a i tam se moc "nerozšoupnout", protože každý kód navíc jsou data, která se musí stahovat...

Aktualizace už si pak mohli dělat na své straně čímkoliv, co jen přepíše údaje v HTML celý soubor pak aktualizuje přepsáním na serveru.

Samozřejmě, kdyby použili mozek, tak je ještě nejlepší dát dočasně průběžné celkové výsledky voleb (které lidi zajímají nejvíc), přímo na HLAVNÍ STRANU, protože tím se zátěž serveru a přenosů ještě sníží, jelikož nikdo nemusí už dál klikat a načítat třeba 2 další stránky zbytečně, ale většina lidí má přímo to, co hledá hned před sebou.

Server pak není nijak zatěžovaný, protože stránka se negeneruje, ale jenom se čistě stahuje.

V O2 to zase podělali rychlostí připojení! Rychlost připojení pak musí být nejrychlejší možná. Osobně bych to viděl minimálně na 1 Gbit/s a nejspíš by to chtělo udělat ty servery i zrcadlené, aby zátěž z celého světa nešla do jednoho místa.

Na web, který funguje jako množství mirrorů připojených gigabitem do různých sítích a jen se z něj stahuje HTML a CSS kód o velikosti do 300 kB se opravdu velice těžko dělá útok, protože nicnedělající server jenom těžko přetížíte a pořádně rychlou linku s takto malým přenosem taky nezahltíte.

Už na škole jsme psali jednoduchý http server, který generované stránky cachuje v paměti.

Takže řešení je prosté. Pro každou stránku nastavit timeout třeba 5/10 minut a máte staticky vygenerované stránky, které se průběžně aktualizují. Odhaduji, že jde jen o pár řádek v konfigu.

Ovsem pozadavek na zobrazeni vysledku voleb nezni "dostupne online v ms intervalech". Procez se primitivne trivialne zcela libovolne (je uplne jedno zda pouzijete java/php/c/...) vygeneruje staticke html, ktere se 1x za rekneme 10 minut obnovi. Pokud pak server posila spravne a nikoli fake informace o stari dokumentu, zadny z beznych browseru nebude stranku obnovovati drive nez prave za tech 10 minut.

To "ohromne" mnoztvi stranek je mozna nekolik stovek, a to zvladne zcela libovolny i hodne letity HW vygenerovat do nekolika sekund. Pricemz to znamena o nekolik radu mene prace, nez delat totez v reakci na request zajemce.

Pro CSS pak plati, ze pri svepravne nastavenych informacich o cachovani si jej browser bude stahovati 1x mesicne.

Já jsem weby nikdy nedělal (kromě nějaké osobní stránky v prehistorické době a nedávno rozchození wordpressu :-) ), tak se asi blbě zeptám: jak byste tedy principiálně řešil zobrazení výsledků, pokud jsou data někde v databázi, průběžně (prakticky nonstop) se mění a zobrazují se nejen hlavní výsledky (Strana X získala Y%), ale je možno se podívat na výsledky podle různých hledisek (stran, kandidátů, okrsků, neplatné hlasy a kdoví, co všechno tam ještě je) a uživatel má možnost se proklikat od nejvyšší úrovně (stát, kraj, ....) až po okrsek.

Já si myslím, že pokud by generovali jednotlivé stránky, které by pak strčili na server, museli by nonstop generovat ohromné množství stránek, které by pak uploadovali na web.

Pokud vezmu, že nekoukají furt všichni na každou poslední podstránku, tak bych si tipnul, že ta zátěž by mohla být u vašeho systému docela vyšší. Pravda, zatěžovaly by se jiné servery (ty co počítají, ne ty, co prezentují - ale ty by as vytěžovalo stálé I/O), ale je otázka, jak moc by to byla výhra.

Navíc - když má i blbý Wordpress cachovací plugin, je hodně fantasitcké předpokládat, že by měli nějakou podobnou technologii ve "velké" firemní verzi? Z toho by mi totiž vyšlo, že nejčastější stránky by skončili v cache a y méně obvyklé by se sice generovaly, ale pouze ty, o které by byl zájem.

Takže - v čem dělám ve své úvaze chybu?

Zdali ono to nebude tim, ze obrazky lze vkladat i pomoci stylopisu (pripadne js).

aktualizace je v řádu minut, což v IT je věčnost, stejná stránka je pro všechny shodná, tohle není žádná komplikace. Buď si napíšu cache sám nebo použiji cachující reverzní proxy s invalidací z backendu, používáme k těmhle účelům varnish.

Existuje řada optimalizačních technik, např. data vykresluji až v prohlížeči a z backendu jde statická stránka s js a data v jsonu. Backend renderuje každou stránku pouze jednou a vracím ji tisícům klientů, nedává smysl pro všechny požadavky renderovat to stejné znovu a znovu atd.

A teď už budu úplně za blbého - jak jste poznal, že tam jsou obrázky? Když na to kliknu pravým, tak u obrázků to v kontextovém menu nabízí i "Zobrazit obrázek v samostatném okně/tabu" a "Stáhnout obrázek" a nic z toho to nenabídlo. A když jsem nechal zobrazit zdrojový soubor stránky, tak jsem dal hledat gif a nikde to tam nenašlo.