Vlákno názorů k článku
Chrome zapíná všem podporu HTTP/3 od Ondřej Novák - Žádný zázračný protokol nezrychlí načítání špatně udělaných stránek,...

Žádný zázračný protokol nezrychlí načítání špatně udělaných stránek, plné zbytečného obsahu a zejména pak velice datově náročných reklam.

Můj názor na HTTP/2 a HTTP/3 je ten, že vyšší komplexita celého řešení nepřináší adekvátní hodnotu. Prostě je to kanón na vrabce.

Napsat rychlé a přitom bohaté stránky nad primitivní "jedničkou" přitom jde i v dnešní době, dokonce i tak, že povýšení na HTTP/2+ se už na zrychlení nijak neprojeví.

Jenomže protokolem HTTP už se dávno nepřenášejí jenom stránky. Přenáší se jím také aplikace, aplikační komunikace, video… Přenos stránek nejspíš už dávno objemově tvoří menšinu přenosu přes HTTP.

Aplikační komunikace si právě vystačí s HTTP/1, a pokud ne, stejně potřebuje Websocket. Vím to, protože v tom dělám. Zpravidla si člověk vystačí s jedním spojením s maximálně dvěma, multiplex je kanón na vrabce. Pokud se používá websocket, stejně to jede formou pipelingu, v případě JSONRPC dokonce i na přeskáčku, bez vynuceného multiplexu. A jako provozovatel serveru __nechcete__ aby vám jeden klient posílal informace moc rychle, protože by vám mohl přetížit server. Když mu dáte jedno spojení s očekávanou latenci, je to často dostatečné aby on nepocítil nějaká omezení a vám to neshodilo server, až jich tam takových přijde 100.

Opravdu skutečná režie na přenos aplikačních dat je nula nula nic. Největší latenci dělá samotný server tím, že zpracování požadavku prostě nějaký čas zabere.

na video jsou jiné protokoly.

Nevím, jestli http/2 a /3 řeší websockety, ale i tak je to kanón na vrabce. A když už bych na aplikační úrovni použil UDP rozhraní přímo (i když teď z hlavy nevím jestli něco takového už v JS existuje nebo ne)

Největší latenci dělá samotný server tím, že zpracování požadavku prostě nějaký čas zabere.

Však je taky smutné, jak se dnes často programuje. Činnosti, které mají trvat milisekundy, se zpracovávají dlouhé sekundy. Nicméně, používat protokol za tím účelem, aby brzdil přístup do aplikace (aby ta se z toho neopupínkovala) není dobrá cesta.

Vím to, protože v tom dělám.
To ale po vás nikdo nechtěl, abyste se přiznával k tomu, že nerozumíte technologiím, které používáte.

Představte si třeba takový GMail, kde se načítá seznamy e-mailů, seznam úkolů a položky kalendáře. Není důvod, aby se to načítalo sériově za sebou, a co dorazí, to se může rovnou zobrazit. Nebo Facebook – načítají se příspěvky na zdi, jejich obrázky, uživatelé v chatu, odkazy, příběhy. Proč by se to mělo načítat za sebou?

Zpravidla si člověk vystačí s jedním spojením s maximálně dvěma
Dvě je divné číslo. Proč ne tři nebo čtyři? Samozřejmě je nejlepší jedno spojení, přidávání dalších spojení vám nic nepřinese, jenom režii.

na video jsou jiné protokoly.
Jenže v praxi funguje nejlépe HTTP. Navíc ve webovém prohlížeči moc velký výběr protokolů nemáte.

i když teď z hlavy nevím jestli něco takového už v JS existuje nebo ne
No, hlavně že v tom děláte. JavaScript neumí nic, jenom z něj můžete volat různá API poskytovaná prohlížečem. A prohlížeč samozřejmě neposkytuje API pro síťovou komunikaci na úrovni TCP nebo UDP. Umožňuje jen odeslat HTTP požadavek nebo komunikovat přes WebSocket (povýšením HTTP spojení). Trochu bokem je pak ještě WebRTC.

Jako vývojář nejmenovaných velkých e-shopů a několika dalších na assety náročných (například VoD) aplikací vám mohu říci jen jediné: na HTTP/2 bylo pozdě už před deseti lety. Obcházet na frontendu neustále omezení HTTP 1.x je opravdu komplikované a otravné.

12. 10. 2020, 10:36 editováno autorem komentáře