Vlákno názorů k článku HTTP/3 nebude postavené na TCP, základem bude QUIC používající UDP od martinpoljak - Při vší úctě, kolik zde diskutujících se profesionálně...

Při vší úctě, kolik zde diskutujících se profesionálně zabývá vývojem aplikací pro web? Podle toho, co čtu, bych tipoval, že tak slabá pětina. Teoretik ve dle teoretika. Na HTTP/2 čekali weboví vývojáři (v některých případech dost zoufale) v některých ohledech deset let.

QUIC dořešuje ještě některé další vyskytující se problémy a dobře tak. Oni totiž ti frontendisté píší převážně pro věžné koncové uživatele, nikoliv sysadminy. A tak se musí obtěžovat řešit jejich potřeby. Totéž platí pro Google.

HTTP/2 v podstatě nic neřeší. V rámci jednoho spojení se posílají fragmenty dat nutných k sestavení stránky. Fragmeny samy o sobě nafukují provoz. Stejnou službu udělá HTTP/1.1 pipelining s tím, že snižuje fragmentaci. Problém je, že na pipeliningu se prostě svět nebyl schopen dohodnout a tak není spolehlivý.

HTTP/2 v zásadě řeší jen pomalost serverů, tedy dlouhou odezvu serveru na požadavek. Důvodem je to, že se serverové komponenty píšou v pomalých jazycích. A tak zatímco se čeká na ruby nebo python nebo nedejbože node.js až se uráčí vygenerovat odpověď, může server po HTTP/2 poslat zatím statická data, který klient taky chce.

Pipelining by přitom bohatě stačil a zjednodušil by implementaci obou konců protokolu. Pokud se přidá možnost předbíhání odpovědí, je to už skoro jako HTTP/2 s tím, že je to mnohem méně komplikované. Používám to třeba u RPC kdy se na serveru musí vyřídit v rámci spojení tisíce požadavků. Každá message má ID a každá odpověď má ID. Implementace je primitivní, linka jede jak ďábel, žádné prodlevy z pingu na ní nejsou znát.

Jste si jist, že jste pochopil, co vlastně HTTP/2 dělá? Ano, řeší "jen" pomalost serverů. Jenže kdyby rostly na stromech ryby, nemusely by být rybníky nemluvě o tom, že často je velmi výhodné říci, že uživatel něco dostane dříve, něž něco jiného případně nečekat, až se na to browser stejně zeptá poté, co naparsuje všechno, co je potřeba a další a další requesty s pánbůhví jakým roundtripem dorazí znovu na server a rovnou mu to poslat. Váš kdybyzmus je fascinující, ale tohle je problém řešící praxi.

A mimochodem, v okamžiku, kdy do pipeliningu přidáte "předbíhání odpovědí", dostanete v podstatě multiplexing, který provádí HTTP/2. Čili jen víceméně tvrdíte, že HTTP/2 je špatné, protože vy jste to přece už vynalezl sám. (Přeháním, samozřejmě nevynalezl, ale jde o princip.)

Takže teoretizujete hezky, ale od moderního vývoje pro webové prohlížeče jste poněkud odtržen. Dnešní transakce mezi internetovým prohlížečem a serverem probíhají už značně jinak a hlavně komplexněji, než v době, kdy bylo HTTP/1 navrženo čemuž HTTP/1 přestává stačit. Ostatně až tolik se od sebe stejně neliší.

https/2 předně vytváří rámce a streamy, který zbytečně nafukují přenos a zesložiťují zpracování dat jdoucí ze spojení. Předbíhání odpovědí není https/2 to bych zase já mohl mít podezření, že netušíte, jak funguje. Hlavně rozsekání na rámce dost pravděpodobně narušuje rozsekání na packety a proto celkem logicky se hledá cesta formou UDP, což je ale hledání rovnáku na vytvořený ohýbák.

Pipelining umožňuje nasypat všechny requesty hezky za sebou bez čekání na odpověď, proto vaše námitka s roundtripem neplatí