Prodej 3D tiskárny - kov
Zobrazují se odpovědi 1 až 10 z 10

HTTP/3 - dočkáme se někdy?

  1. Včera jsem psal o HTTP/3.
    Máte s tím někdo zkušenosti? Co si o této technologii myslíte?
    Díky za názory. Sbírám data k dalšímu článku na toto téma.

  2. Co se právě děje na Webtrhu?
  3. Nevim, CF to zatim jisti a podpora ze strany browseru tak nic moc. Tu novou sablonu mas pomalou docela :(

  4. Používáme to zatím u mobilních aplikacích, kde je strana klienta a serveru pod kontrolou, výrazně se zlepšuje odolnost spojení při špatném signálu nebo pomalejší síti. Daleko levnější je i servová strana při řešení load balancingu, mohli jsme vynechat drahé f5 kvůli stavovému tcp a používat levnější řešení přímo na aplikační úrovni a sezení řešit přes klasicky ODS.

    Stejně tak jsme http/3 začali experimentálně používat při komunikaci mezi servery, k tomu mám poměrně velké množství zkušeností, ale je to asi za potřebami zdejšího fóra. Zatím to hodnotím pozitivně.

    Samotné nasazení na weby zatím není na pořadu dne u žádného klienta, jen testujeme interně, velice se hodí možnost řídit datový tok ze strany serveru a posílat obsah v pořadí, v kterém víme, že bude potřeba. Velké zlepšení je v případě stránek s velkým množstvím malých souborů (typicky galerie nebo video služby), ale to už bylo s http/2. Chvilku bude trvat než se stabilizuje klientská část, zatím v implementacích jsou velké mezery a nerovnosti, složitě se řeší debuging a problémy. Negativním efektem je složité ovlivnění šířky pásma na straně serveru (QoS), i malé množství klientů dokáže u horšího hostingu saturovat zdroje a omezit službu, při velkých službách se zase daleko lépe řeší rozložení zátěže.

  5. @Oleg je rychlejší než ta před tím právě..
    @Tomaš můžeš se podělit o zkušenosti? Docela mě to chytlo a chystám se na další článek. Info bych uvítal.

  6. Souhlasím s Olegem. Je hezké, že řešíš HTTP/3, ale jiné aspekty webu ti to zpomalují víc než je teoretický přínos HTTP/3.

  7. Nebudu si konvertovat všechny obrázky na webu, jen proto, že to říká nějaká online služba.
    Tohle není o mém blogu, tak se prosím držte tématu.

  8. Citace Původně odeslal Wladass Zobrazit příspěvek
    @Tomaš můžeš se podělit o zkušenosti? Docela mě to chytlo a chystám se na další článek. Info bych uvítal.
    A co potřebuješ vědět?

    Http/3 dává vývojářům silnou sadu technik a nástrojů, jak mohou komunikaci přesunout na novou úroveň (kratší RTT při zachování RTD, nižší režii, šifrování a datovou integritu hlaviček, libovolnou velikost payloadu, konfiguratovatelné timeouty a znovu poslání paketu atd.), ale zároveň to bere jistoty, které http nad tcp poskytuje (stabilní load balancing, routing podle hlaviček, stabilní trasu u established spojení - routery jsou stavové, snadný debuging, ověřenou a rozšířenou implementaci, predikovatelné chování).

    Http/3 jde ruku v ruce s ipv6, multihoming, dynamické trasování a podporou více cílů. Výrazně se s tím zjednodušuje komunikace při změně sítí (dá se plynule bez výpadku přecházet např. mezi wifi a lte tam a zpět klidně každou minutu). Dává ale velkou zodpovědnost na stranu aplikací, tady vzniká nejvíce problémů a chvilku bude trvat než vzniknou ověřené znovupoužitelné implementace a je to za mě největší bolístka. Na straně aplikací se tím mění pattern request-response a najednou klientská a servová část aplikace navzájem oboustranně spolupracují, aby přichystaly obsah pro zobrazení a zpracování. Tím se ale výrazně zvyšují nároky na straně klienta, na to pozor, mám problém nacházet schopné vývojáře na backend, u frontendu to je katastrofa.

    Velké zkušenosti s tím mám na straně serverů a backend aplikací, kdy jsme u HA služeb (99,997 % dostupnost) mohli vyhodit drahé routery a celý problém vysoké dostupnosti aplikací a balancingu mohli založit na bezstavovém udp a eventual consistency databázích (něco jako mongodb, cassandra nebo celá rodina databází nad rocksdb). Tady vidím obrovskou výhodu, doteď jsme sice dělali event-driven koncové aplikace, event-driven zpracování dat a požadavků, ale měli stavové tcp balancery, který celý ten systém ponižovali a tvořily úzké hrdlo ve špičkách (viz. např. věčné výpadky iVysílání od ČT, to je celé způsobené i nerovnoměrným rozložením zatížení na tcp balancerech, kdy při inicalizaci spojení ještě není jasné jak dlouho bude trvat a pak dochází k potkání se spousty dlouhých spojení na jednom serveru/routeru/síti, přepojení na jinou trasu a znovuvytvoření spojení trvá spousty sekund a to způsobuje nepříjemné lagy při přehrávání nebo právě ucpání celé infrastruktury neustálým přepojování hodně klientů).

    http/3 má ale i stinné stránky, blbě se řeší bezpečnost, doteď páteřní routery byly schopni spousty závadného provozu sami filtrovat (jsou stavové a mají dostatek informací o komunikaci z hlaviček), ale s http/3 jim ty informace chybí, takže je nutné provoz pouštět na backend, tam ho zpracovat a pokud je závadný, dát vědět routerů a pro příště ho zablokovat. To s sebou ale nese zvýšené náklady na backend a zvyšuje reakční dobu a odvrácení útoků, už to nelze tak snadno řešit a je potřeba s tím při návrhu počítat. Vhodné technologie k tomu teprve vznikají a útoků je zatím také pomálu.

  9. Citace Původně odeslal TomášX Zobrazit příspěvek
    Díky za zajímavý komentář. Je vidět, že je to za základě zkušeností.

  10. Díky Tome. Dal bych bezvýznamnou rep, ale z mobilu nejde.
    Dostat tu směrodatnou odpověď je skoro zázrak.

  11. Citace Původně odeslal Wladass Zobrazit příspěvek
    Nebudu si konvertovat všechny obrázky na webu, jen proto, že to říká nějaká online služba.
    Tohle není o mém blogu, tak se prosím držte tématu.
    No ono jsou dve hlavni urovne teto problematiky:
    1) Jak pise TomasX - usnadnuje to spoustu veci, ale zarovnen ma svoje problemy. Opravdu efektivne resi TCP head-of-line-blocking.
    2) Mel by teoreticky byt rychlejsi pro komunikaci server-klient HTTP over QUIC, ale je to jen teorie, sice to ma nejake pozitivni vysledky a predpokladam, ze to bude mit velky dopad na rychlost nacitani pro uzivatele, ale musime se pockat masivni podporu a implementaci.

    Takze, v jake rovine resit HTTP/3? Jeho dopad na rychlost prenosu nebo bezpecnost a efektivitu?

    Momentalni podpora viz: https://caniuse.com/#feat=http3
    Cloudflare to ted poskytuje experimentalne, muzes si to zaplnout, ale k cemu, pro experimentovani s Chrome Canary, Edge dev? U Cloudflare se ted vyplati spise Argo tunel, je lepsi nez H3oQ, fakt megalne lepsi.

    Zkus u hostingu zjistit zda pouzivaji TLS 1.3, Wedos napriklad ne.

Spolupracujeme: Jooble.org, Aximum - profesionální překlady Hostujeme u Server powered by TELE3