Názor k článku HTTP/3 nebude postavené na TCP, základem bude QUIC používající UDP od kraxna - > https/2 předně vytváří rámce a streamy, který...

> https/2 předně vytváří rámce a streamy, který zbytečně nafukují přenos

Nafukuji prenos 9 (pokud me pamet neklame) byty na frame? :-)

> Předbíhání odpovědí není https/2

To je pravda, protoze HTTP/2 je kompletni multiplexing vc. moznosti definovani vztahu a priorit mezi streamy a moznosti server push :-) Tedy reseni, ktere je technicky mnohem silnejsi, nez pouhe predbihani odpovedi :-)

> Hlavně rozsekání na rámce dost pravděpodobně narušuje rozsekání na packety a proto celkem logicky se hledá cesta formou UDP

Nikoliv, s tim neni problem. Problemem je zbytecna latence a HOL blocking dany TCP kanalem.
Jinak receno, TCP dela veci, ktere nejsou potreba, ani nejsou uzitecne - diky multiplexingu neni nutne, abych data dostaval striktne sekvencne, ani neni nutne mit handshake (TCP) a potom dalsi handshake (TLS).

Jinak receno, transportni vrstva, ktera ma znalost toho, co prenasi a je optimalizovana pro tento typ prenosu, je efektivnejsi nez obecna transportni vrstva pro vse. To je cely duvod za HTTP/3 / QUIC.

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

Jasne a umi mi taky poslat to, co budu potrebovat nez si o to reknu (server push)? Ne -> round trip.

Umi mi posilat vice requestu soucasne (krasny priklad - 2 vetsi obrazky na strance - s HTTP/2 mi je server muze posilat soucasne - coz je velmi vyhodne, protoze pravdepodobne pro jejich progresivni zobrazeni je nepotrebuji cele). Opet ne.

> ale hledání rovnáku na vytvořený ohýbák.

Hledani rovnaku na vytvoreny ohejbak spis popisuje snahy naroubovat staricky HTTP protokol na potreby moderniho webu. A z tech rovnaku na ohejbaky vzniklo pozehnane - chunked encoding, long polling, css sprites, nutnost kombinace JS/CSS do jednoho souboru, ... Jeden workaround vedle druheho, ktere HTTP/2 nepotrebuje a pipelining je neresi.