Vlákno názorů k článku HTTP/3 nebude postavené na TCP, základem bude QUIC používající UDP od Michal Kubeček - Sice nejsem z takové vize moc nadšený,. hlavně...

Sice nejsem z takové vize moc nadšený,. hlavně proto, že je to další posun od snadno debugovatelného a přehledného protokolu k nepřiliš průhlednému blackboxu, nad některými komentáři v této diskusi jen nevěřícně kroutím hlavou. Takže bych chtěl poprosit, jestli by si ti, kteří tu tak zasvěceně vysvětlují, proč je to celé úplně špatně a jak by to způsobilo naprostou katastrofu, mohli poslechnout třeba tenhle talk, aby získali základní představu, jak to celé funguje? (A třeba i zjistili, že se to vlastně už nějakou dobu v nezanedbatelné míře používá.)

K jednoduchosti původního HTTP: Ona ta jednoduchost je IMHO do jisté míry iluzí. Ano, z dumpu pouhým okem poznám, co se posílá. Teda pokud to není šifrované ani komprimované, což ale dnes celkem běžně bývá. Dále textový protokol ale IMHO přináší spíše problémy. Už standard je celkem benevolentní (vizte https://stackoverflow.com/a/50180173 ) a navíc redundantní (vizte https://stackoverflow.com/a/38814078 – nechce se mi teď hledat související zranitelnosti), implementace ještě víc – třeba podpora LF místo CRLF. Čím je standard benevolentnější v tom, co jedna strana posílá, tím je benevolentnější, co druhá musí být schopna zpracovat. A čím je jedna strana benevolentnější, tím je větší prostor pro „jen u mě to funguje“.

HTTP/1.1 samozřejmě není ideální (co je?), jde mi spíš o ten praktický aspekt. U klasického HTTP/1.1 většinu problémů můžu debugovat bez nějakých speciálních nástrojů, ať už tím, že se na komunikaci jen podívám pomocí (tcpdumpu a) wiresharku, nebo třeba tím, že v krajním případě použiju netcat/socat a request serveru pošlu sám. U HTTP/2 už to mám podstatně těžší a tahle vize HTTP/3 zatím naznačuje, že (v tomto ohledu) bude ještě hůř.

Totéž platí pro TCP vs QUIC. Když vím, jak to má fungovat, tak se můžu podívat na TCP spojení a měl bych poznat, kdo se chová nekorektně. Do QUICu takhle jednoduše vidět není. Sice chápu, proč se vývoj ubírá tímhle směrem, ale radost z toho nemám.

Ono je to vůbec strašně smutné, když si člověk uvědomí, že nebýt hloupých (a vlezlých) middleboxů, mohli jsme pro takové featury jako multiplexing nebo multihoming (i s handoverem) už dávno používat SCTP (možná v nějaké pokročilejší variantě) a nebylo by potřeba vymýšlet obezličky na aplikační vrstvě.

Ono je to otázka – co by třeba SCTP znamenalo pro TLS. Přinejmenším by zvenku bylo vidět rozdělení do streamů, což možná není kritické, ale je to side channel, který je lepší nemít…

Dokážu si představit, že pokud by se SCTP s více streamy ve větším měřítku (v globálních sítích) používalo, vznikla by varianta TLS (možná pod jiným jménem), která by umožnila zabezpečit celé spojení, aniž by to vynutilo serializaci paketů z různých streamů (koneckonců, něco takového vlastně dělá i ten QUIC). Ale to už se asi bohužel nedozvíme.