logo
22.04.2019 22:18
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?

Co se právě děje na Webtrhu?

22.04.2019 22:26
2
A co treba zakazat HTTP/2?
Nebo CDNka nebo jiny cachovaci frontend?
22.04.2019 22:55
3
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í.
23.04.2019 16:02
4
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.
23.04.2019 16:16
5
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...
23.04.2019 19:44
6
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.
24.04.2019 13:42
7
Původně odeslal Martin Schlemmer
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.
24.04.2019 13:47
8
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?
24.04.2019 14:11
9
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ů.
24.04.2019 14:15
10
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.
24.04.2019 15:36
11
Původně odeslal Aleš Jiříček
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 ----------

Původně odeslal smitka
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 ----------

Původně odeslal vdusek
A co treba zakazat HTTP/2?
Nebo CDNka nebo jiny cachovaci frontend?
Cachovací frontend pomůže velmi.
24.04.2019 16:29
12
Původně odeslal petrx

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.
24.04.2019 20:50
13
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.
25.04.2019 14:51
14
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
26.04.2019 09:22
15
Původně odeslal petrx
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.