Vlákno názorů k článku Continuation Flood vystavuje implementace HTTP/2 útokům DoS od Ondřej Novák - Od začátku považuju HTTP/2.0 za tak komplexní protokol,...
-
Od začátku považuju HTTP/2.0 za tak komplexní protokol, že v tom bude hromada zranitelností už na úrovni protokolu. A tyto zranitelnosti je třeba hlídat komplexním kódem, který sám může zanášet další zranitelnosti. A vždycky se člověk ptá... proč?
Protože kdysi někomu přišlo, že uměle udělaný limit 2 SSL spojení na doménu zpomaluje přenos dat?
-
Filip JirsákStříbrný podporovatelTohle ale není žádná zranitelnost na úrovni protokolu, úplně ten samý útok můžete udělat i na HTTP/1.1. Jediný rozdíl je v tom, že parsery HTTP/1.1 protokolu už ta omezení mají, protože se na ten problém už narazilo dříve, zatímco některé parsery HTTP/2 protokolu to nemají, protože se holt někdo nepoučil.
-
Filip JirsákStříbrný podporovatel
Kód, který má řešit komplexnější problém, se obvykle píše v komponentách nebo vrstvách, a tohle je součást jedné vrstvy, která není o nic složitější, než u HTTP/1.1.
HTTP/2 řeší problémy „ze života“, které s pomocí HTTP/1.1 řešitelné nejsou. Když se narazilo na limity HTTP/1.1, nebyl jiný způsob, jak se posunout dál.
-
Byla spousta způsobů.
Problém jak to vnímám já je, že internet byl (je) rozdělen na tři tábory
- těm co to nevadilo
- těm co to vadilo, ale nic neudělali
- GoogleNe všechno, co vypadne z Google byl dobrý produkt, a tohle řešení, prostě dobré není.
Pro mě takové potvrzení, že to je slepá cesta je existence HTTP/3.0. (která jede na UDP). I to je podle mne trochu slepá cesta, ale v zásadě to háže celý HTTP/2.0 přes palubu. (Nicméně přechod UDP bych raději označil za zcela jiný protokol a nedával tomu HTTP značku).
-
Filip JirsákStříbrný podporovatel
Způsobů, jak to řešit, byla spousta – a všechny znamenaly opustit HTTP/1.1 a udělat něco podobného, jako je HTTP/2.
Zapomněl jste na čtvrtý velký tábor – ty, kteří to uvítali.
HTTP/3 vychází z HTTP/2. Kdyby HTTP/2 byla slepá cesta, vychází HTTP/3 z HTTP/1.1, ale tak to není. HTTP/3 se především zbavuje TCP/IP, protože už i to se ukázalo jako příliš omezující.
-
Že je TCP/IP omezující jsem věděl už když se zaváděl Speedy. Ale to je jedno.
HTTP/3 ukazuje, že je třeba úplně jiný protokol
Jinak já si dost pohrávám s web aplikacemi, které potřebují 1x HTML a všechny ostatní resource stahuje websocketem, včetně grafiky
"Zapomněl jste na čtvrtý velký tábor – ty, kteří to uvítali."
Bavíme se o situaci _před_Pokud jde o situaci _po_, tak moc lidí, kteří z toho skákali radostí jsem nepotkal. Možná ti, co tomu až tak nerozumí, a nacpou stránku hromadou zbytečných malých souborů, nedokážou optimalizovat stránky pro maximální využití cache, atd.
Ostatním je to spíš jedno.
Já beztak všude používám HTTP/1.1, propojení mezi prohlížečem a nginxem je mi vlastně putna. Jediným požadavkem je, aby to bylo bezpečné.
-
Filip JirsákStříbrný podporovatel
Že je TCP/IP omezující jsem věděl už když se zaváděl Speedy.
Otázka je, zda by to prošlo. Co řečí bylo už jenom kolem toho, že se z textového protokolu přešlo na binární. A kdyby se ještě z TCP/IP přešlo na UDP s vlastním řízením toku…HTTP/3 ukazuje, že je třeba úplně jiný protokol
Vždyť se tam používá to samé, co je v HTTP/2.Bavíme se o situaci _před_
Před čím? Kdy byla nějaká situace, kdy byl samostatný tábor Google?Možná ti, co tomu až tak nerozumí, a nacpou stránku hromadou zbytečných malých souborů, nedokážou optimalizovat stránky pro maximální využití cache, atd.
Hezky jste se popřel v jedné větě. Tak co chcete – optimalizovat pro využití cache, nebo nechcete malé soubory? Ono se to totiž navzájem vylučuje.Já beztak všude používám HTTP/1.1, propojení mezi prohlížečem a nginxem je mi vlastně putna. Jediným požadavkem je, aby to bylo bezpečné.
Tak do toho nekecejte těm, kteří chtějí i to, aby to bylo rychlé. -
ano HTTP/3.0 je HTTP/2.0 nad UDP - odpadá jen to, že se nemusí parsovat framy a že framy chodí celé, a celá ta logika parsování framů je mnohem jednodušší. Zato složitější je pak potvrzovací schéma. Ale to je jedno, já se nechci pouštět do moc odborné diskuze v tomhle vláknu.
Jen pro srovnání ROOT stránka na H2 protokolu nabíhá (s cache) asi 1.2sekundy. IDNES stránka na HTTP/1.1 nabíhá 300ms. Jestli někdo čekal, že HTTP/2.0 nahradí dobře udělanou optimalizaci stránky, tak se asi šeredně spletl. Ne, nenahradí.
Jinak co je třeba si všimnout, tak hromada stránek se stahuje s mnoha domén, často se stahuje jeden nebo dva requesty. Jsou to různé reklamy, pingy, statistiky, těžko říct, proč na téhle stránce vidím 240 requestů a 225kB necachovatelných dat (celé HTML má jen 157kB). Navazování HTTP/2.0 kvůli dvou requestů rozhodně nebude rychlejší, spíš naopak. Keep Alive nad HTTP/1.1 by tady plně dostačoval
-
Filip JirsákStříbrný podporovatel
Jestli někdo čekal, že HTTP/2.0 nahradí dobře udělanou optimalizaci stránky, tak se asi šeredně spletl. Ne, nenahradí.
To je ale chybné očekávání. HTTP/2 umožní dál optimalizovat i tam, kde jste s HTTP/1.1 narazil na limity protokolu.Jinak co je třeba si všimnout, tak hromada stránek se stahuje s mnoha domén, často se stahuje jeden nebo dva requesty.
HTTP/2 ale nemělo vyřešit všechny problémy světa. HTTP/2 řeší situaci, kdy se z jedné domény stahuje hromada souborů (což je dobré kvůli využití cache a zmenšení objemu stahovaných dat). Což také hromada stránek dělá.5. 4. 2024, 20:48 editováno autorem komentáře
-
Pridal by som este, ze http/2 riesi aj problem live streamingu, ci asynchronicity. Niekde nie je vhodny websocket a pouzival sa preto napr longpoling... to sa uz daaavno, nahradilo SSE a ak ma clovek na stranke par sse streamov, tak http/2 je vpodstate nutny.
PS: ano, vzdy sa to da spravit inak... ale vzdy sa da web robit aj ako cgi skript v asembleri a z nejakeho dovodu sa to nezvykne...7. 4. 2024, 07:19 editováno autorem komentáře
-
No hlavní problém je/byl v tom, že možná je HTTP3 dobrý, ale bohužel v podání Googlu (tak ještě před rokem určitě, prakticky od začátku) klasika be evil, nastavení jejich serverů poněkud neodpovídalo specifikaci, což by mě samo o sobě netrápilo, ale potíž byla v tom, že na pomalejší lince přes wifinu se to "ustálilo" na víc burstech dat plnou rychlostí, které se u providera nevešly do paměti některého routeru kde měl shaping (byly to řádově stovky kB), takže efekt byl ten, že začaly vypadávat pakety a cokoli dalšího na klasickém tcp se prostě zasekávalo, takže udp/443 šlo do dropu a vše, včetně onlinovek, začalo být svižné.
-
> Jinak já si dost pohrávám s web aplikacemi, které potřebují 1x HTML a všechny ostatní resource stahuje websocketem, včetně grafiky
Takže na ostatní si stěžujete, že vyrobili nový protokol (bohužel občas s chybama v implementacích), zatímco vyrábíte nový protokol nad potenciálně zastaralým protokolem. Jenom se zeptám, jestli jste přemýšlel, zda ten protokol nad websocketem nemá taky nějaké díry? ;-)
> Pokud jde o situaci _po_, tak moc lidí, kteří z toho skákali radostí jsem nepotkal.
HTTP/2 byla prakticky nutnost pro microservices, kde lítají klidně tisíce requestů za vteřinu mezi servery. Ty benefity pro běžnou browser-server komunikaci jsou tam nicméně taky. Stránky by se neměly optimalizovat podle technických omezení, ale podle jejich logické struktury, které vede případně i k přímočarému využití cache.
-
Filip JirsákStříbrný podporovatel
Myslím, že primárním účelem byla komunikace prohlížečů, microservices se jen svezly. U microservices by ostatně nebyl takový problém nasadit jiný protokol, u prohlížečů byla jediná možnost vylepšit HTTPS.
