Prodej projektu Duchod.cz - cena 550 tis Kč. Dále MojeFinance.cz, DuchodovaReforma.cz
Zobrazují se odpovědi 1 až 15 z 15

Kulometná palba HTTP requestů v HTTP/2

  1. Zaujal mě článek
    Why Turning on HTTP/2 Was a Mistake - Lucidchart

    a následná diskuse na
    https://news.ycombinator.com/item?id=19720962

    Mám teď podobnou zkušenost s HTTP/2, pokud máte na stránce větší množství dynamicky generovaných obrázků a klient se připojí přes HTTP/2, neposílají se HTTP requesty v 6 vláknech jako v HTTP 1.1 (u většiny prohlížečů; IE7 dokonce posílal requesty jen ve 2 vláknech), ale prohlížeč si otevře 1 spojení a v něm vyšle pomocí multiplexingu hodně HTTP requestů naráz.

    Jak to řešíte vy?

  2. Co se právě děje na Webtrhu?
  3. A co treba zakazat HTTP/2?
    Nebo CDNka nebo jiny cachovaci frontend?

  4. nezapínej http/2, když nemáš zkušeného admina, uživatelům spíše přitížíš. Http/2 je navržený, aby využil celou šířku pásma, kterou má prohlížeč, potřebuješ mít dobrou konektivitu na serverech a dostatečné množství zdrojů.

    http/2 i dnes je hodně nová, spousty funkcí se teprve dopisují a není vyjímka, kdy se používá kernel 4.9 nebo novější, na Redhat zapomeň, tam je moc bugů. Hlavní zbraň je správně využitý request prioritization a zvednutí bufferů (tcp, file atd.) dosf vysoko, aby udržely data ideálně pro celý web či alespoň stránku.

    Zatím nevidím význam proč nasazovat http/2 na malých webech, má to smysl na cdn, na webech se spoustou obsahu a návštěv a jen když máš po ruce admina, který o tom něco ví.

  5. Já jsem zatím na podobné problémy nenarazil a to HTTP/2 používáme na Centos prakticky od jeho standardizace a i před tím jsme používali SPDY. Ale umím si představit, že generování tuny dynamických obrázků najednou zvládne server zabít.

  6. někdo je prase, stačí mít na webu tisíce či desítky tisíc malých obrázků a http/2 udělá pěkný DoS na server. Ošetřuji to, ale takových webů jsem také viděl naprosté minimum. Setkal jsem se ale často s chybou, kdy se rekurzivně něco vykreslovalo, běžně to právě rate limiting na jednu doménu v prohlížeči dost zpomalí, s http/2 to vše proběhne neskutečně rychle a dělá to opravdu dost psí kusy. Blbé je, že stačí jeden klient na upc, web na slabém virtuálním serveru a jediný klient pošle do kolen celý web.

    Až si tohoto všimnou útočníci, začne nová doba útoků, kdy se přes http/2 multiplexing bude DoS server, protože v jednom tcp spojení poslat request na miliony souborů nestojí velkou šířku pásma, naproti tomu server musí všech miliony souborů dohledat...

  7. Ten web, Lucid Chart, vypadá, že se jeho služba skládá z mnoha malých obrázků/tvarů. U jiných, běžných informačních webů by HTTP/2 podle mě ten efekt zahlcení a přetížení mít nemělo.

  8. Citace Původně odeslal Martin Schlemmer Zobrazit příspěvek
    Ten web, Lucid Chart, vypadá, že se jeho služba skládá z mnoha malých obrázků/tvarů. U jiných, běžných informačních webů by HTTP/2 podle mě ten efekt zahlcení a přetížení mít nemělo.
    No ano, ale pokud bych si například vytáhl z Majestic.com seznam URL z domény Webtrh.cz a vytvořil bych stránku, kde by bylo jedno pro každé URL z Webrhu samostatné <img src=...>, v případě HTTP 1.1 by jeden webový prohlížeč udělal jen 6 paralelních spojení, zatímco v případě HTTP/2 by z jediného webového prohlížeče došlo k mnohem většímu náporu HTTP requestů.

    Hodně mi proti kulometné palbě HTTP/2 requestů pomáhá cachování obrázků na CloudFlare.

  9. HTTP/2 nepouzivam, nemel jsem jeste moc cas nastudovat o cem vsem je (jen vim ze podporuje stazeni vseho pres jedine spojeni), ale tohle mi prijde az absurdni, ze nekdo vyda a implementuje standard, ktery ma tak velky problem... To nikdo pri vyvoji neprisel anerekl - hele lidi a co se stane kdyz nekdo posle 10 tisic pozadavku naraz? A pokud jo, tak jake reseni je teda spravne? Tady vypadate skoro jako ze zadne reseni neni... whut?

  10. Aleš Jiříček: To je jednoduše na adminovi, jak v Apache, tak v Nginx se dá nastavit maximální počet konkurenčních streamů (default 128) - další pak padají jednoduše do fronty. Když moje aplikace nedá stovku konkurenčních spojení, tak můžu buď přesunout statické soubory na CDNku, nebo právě omezit počet konkurenčních streamů.

  11. Treba napsat na Internet Engineering Task Force, ze jsou to tupci a kluci z webtrh to vyresi lepe. Maji Twitter? Postnu jim tam URL na toto vlakno.

  12. Citace Původně odeslal Aleš Jiříček Zobrazit příspěvek
    ady vypadate skoro jako ze zadne reseni neni... whut?
    No napadá mě nějaký traffic shaping nebo umělé zpožďování packetů pro PŘÍCHOZÍ packety -- pak by nepřilétaly HTTP requesty tak rychle. To by mohlo pomoci zejména u obrázků servírovaných přes CloudFlare.

    ---------- Post added 24.04.2019 at 15:38 ----------

    Citace Původně odeslal smitka Zobrazit příspěvek
    Aleš Jiříček: To je jednoduše na adminovi, jak v Apache, tak v Nginx se dá nastavit maximální počet konkurenčních streamů (default 128) - další pak padají jednoduše do fronty. Když moje aplikace nedá stovku konkurenčních spojení, tak můžu buď přesunout statické soubory na CDNku, nebo právě omezit počet konkurenčních streamů.
    To jsme zkoušeli s kolegou. Jestlipak uhádnete, co se stalo, když jsme se pokusili Firefoxem načíst 1 stránku s 21.000 malými obrázky? ;-)

    (Na HTTP 1.1 s něčím takovým nevznikal problém.)

    ---------- Post added 24.04.2019 at 15:39 ----------

    Citace Původně odeslal vdusek Zobrazit příspěvek
    A co treba zakazat HTTP/2?
    Nebo CDNka nebo jiny cachovaci frontend?
    Cachovací frontend pomůže velmi.

  13. Citace Původně odeslal petrx Zobrazit příspěvek

    To jsme zkoušeli s kolegou. Jestlipak uhádnete, co se stalo, když jsme se pokusili Firefoxem načíst 1 stránku s 21.000 malými obrázky? ;-)

    (Na HTTP 1.1 s něčím takovým nevznikal problém.)
    No, já bych si tipnul, že se jich načetlo pár a zbytek vytimeoutoval, ale mohlo se klidně stát něco mnohem horšího a v tom případě mě to velmi zajímá :-) To by mě pak zajímal samotný webserver, jeho nastavení a asi i ta stránka pro otestování. Já to testoval maximálně s 1000 obrázky.

    ---------- Příspěvek doplněn 24.04.2019 v 19:33 ----------

    Zkoušel jsem to u sebe s cca 7500 obrázky a žádné zásadní problémy jsem nezaznamenal - samozřejmě se to načítalo docela dlouho (cca 11s), ale bylo to 3x rychlejší než po http. V Chrome i FF to jelo v pohodě, jen FF se trochu zavařil, když jsem mu nechal otevřenou devel konzoli. Kdyby někdo chtěl na test stránku se 7500 obrázky, tak je tady.

  14. zpožďování paketů je řešení na špatném místě, nesystémové, problematické atd.

    Máme tady http s drahými tcp spojeními pro každý request, aby nevznikal DoS na server, prohlížeče zavedly max. počet soubězných spojení (cca od 2 do 20 podle prohlížeče). Postupně přibyla hlavička keapalive jako pěkný hack. Věci jako pipeling nebo websocket byly dočasné a problematické.

    http/2 naopak chce výrazně zrychlit načítání webu a pokud se má celý web načíst místo 10s za 5, zatíží to pochopitelně více servery.

    http/2 tohle je specifikaci řeší, ať už to zmíněný počet souběžných streamů nebo request priority či je možné podle typu webového serveru nastavovat qouty (pro tcp spojení, pro ip, pro cely rozsah, pro web, typy zdrojů atd.), možnosti jsou široké, ale zatím tady platí, že výchozí nastavení je hodně benevoletní peo malé weby a musí se to více testovat.

  15. Zkusil jsem stáhnout v rámci 1 stránky hodně obrázků najednou pomocí HTTP/2 prostřednictvím významné české CDN, házelo mi to timeouty.

    Nakonec se jako jediné schůdné řešení ukázala CloudFlare v režimu reverzní proxy cache

  16. Citace Původně odeslal petrx Zobrazit příspěvek
    Zkusil jsem stáhnout v rámci 1 stránky hodně obrázků najednou pomocí HTTP/2 prostřednictvím významné české CDN, házelo mi to timeouty.

    Nakonec se jako jediné schůdné řešení ukázala CloudFlare v režimu reverzní proxy cache
    Díky za upřesnění. To chování, co popisuješ, je podle mě jen nevhodné nastavení (nebo jinak vhodné nastavení, které ale nepočítá s touto konkrétní situací). Když bych mluvil za NGINX, tak tyto problémy nejčastěji způsobuje (když vynechám jasné věci jako počet file descriptorů) nastavení http2_max_requests, které je v defaultu na 1000 a když spojením proteče (nemusí to být paralelně) tento počet požadavků, tak spojení resetuje a na to nemusí prohlížeč dobře reagovat.

    Je to známá věc: https://trac.nginx.org/nginx/ticket/1250 a podle mě je to pořád na adminovi, aby takové věci vyladil. Já se například snažím pravidelně (a před nasazením nové verze) pročítat tickety nástrojů, které používám, abych byl připraven.

Hostujeme u Server powered by TELE3