Vlákno názorů k článku HTTP/3 nebude postavené na TCP, základem bude QUIC používající UDP od Anonym - Ono to není úplně "blbý" nápad. Jen mám...

Ono to není úplně "blbý" nápad. Jen mám pocit, že část žhavě diskutujících ne zcela správně chápe současné fungování TCP, jak vlastně funguje dnešní web, a v neposlední řadě "trendy" = co vlastně uživatelé chtějí (rozuměj. za co mě uživatelé jak síťaře platí).

QUIC řeší určitě problém se zpožděním. Asi praxe ukáže, jak řeší problém se ztrátovostí. Plně chápu, že implementace nového protokolu trvá opravdu dekády, IPv6 budiž reálným příkladem. Zde se použije poměrně chytře legacy protokol, do něj se zapouzdří QUIC jako opět protokol, ale na aplikační vrstvě. Protože se jedná o aplikaci, tak její update je podstatně rychlejší.

QUIC je určitě výsledkem požadavku uživatele. Dnešní uživatel chce pracovat na počítači, plynule přejít se stejnou prací na mobil a dokončit jej na tabletu. Tedy, není možné data skladovat na koncovém zařízení. Máme zde jednoznačně lehký klient-server architekturu. Uživatel je netrpělivý, nechce čekat. Jsme brutálně konzumní společnost, odnaučili jsme se čekat.

Dnešní uživatel chce sledovat videa. Nejlépe v HD, ještě lépe v 4K. Jenže před mnoha a mnoha lety jsme udělali chybu, jmenuje se NAT. Jeho špatnou implementací jsme způsobili, že dneska není prakticky možné, aby server posílající data viděl přímo na klienta, server tedy nemůže posílat video stream na přímo, ale prostřednictvím navázaného spojení, obvykle TCP, i když konkrétně u videa výpadek paketu by vůbec neměl vadit. NAT je ten problém, proč dneska většina IoT zařízení nekomunikuje na přímo, ale vždy prostřednictvím nějakého serveru. Tento problém má řešit IPv6 (všimli jste si chybějícího NATu?), ale dekáda pryč a NATujeme stále jak šílení.

Nečetl jsem návrh QUIC detailně, ale nevypadá jako DDoS nástroj. Naopak, spíše optimalizuje. Jen ne na síťové úrovni, jak jsme všichni zvyklí, ale na aplikační. Ze síťového hlediska vidím jen problém v tom, že u TCP jsem na síti schopen "řídit" klienta, jak moc datového pásma využívá. Prostě mu pár paketů zahodím, TCP window se zmenší, klient používá méně pásma, než postupně zase stoupá nad hranici, kdy opět pár paketů zahodím. U QUIC je to co je neznámé v tom, že UDP je naprosto zcela jedno, kolik paketů zahodím. Žádné window, žádné potvrzování na síťové vrstvě. Vše se děje na aplikační vrstvě, kam jako síťař "nevidím". To je to riziko.

Neni, je to tak maximalne vysledek pozadavku guuglu. Uzivatel chce flash, s 0 zatezi CPU a plynulym prehravanim videi. Uzivatel rozhodne nechce MB javascriptu, GB nesmyslne velkych obrazku, a mazanice na youtube (mel sem tu pochybnu cest opakovane videt co nekdo na yt nahral, a co tam pak bylo ... strasny).

Protokolu pro prehravani videi existuje cela rada, pres NAT funguji temer vsechny a http je zni ze vsech zdaleka nejhorsi. Totez samo plati pro prenos souboru atd.

A co se myslis asi tak stane, kdyz ti na nepotvrzovanym UDP odeslu paket na server, a do SRC dam TVOJI IP. Ten server se te totiz uz ptat nebude (protoze proc by mel) a naladuje ti tam data. Na TCP tohle udelat nejde, protoze server neposle data dokud neprobehne kompletni handshake. A protoze ty (logicky) na jeho vyzvu nijak reagovat nebudes (respektive to ani neprojde pres tvuj NAT, protoze si zadny spojeni nezadal) tak zadny data nebudou ze? Na UDP ti mezi tim dorazi klidne i par stovek MB, nez si to aplikace serveru rozmysli. Takze kdyz poslu YT req tak na 10x video, tak ti sejmu linku ani se nebudu muset moc snazit (a protoze me tech par paketu nijak netrapi, muzu je tam posilat i par mesicu).

A proč by měl server chrlit data na moji IP na základě podvrženého paketu? QUIC má samozřejmě úvodní handshake klient - server. Každé QUIC spojení má svůj pak 64 bit connection ID, tím se dané spojení identifikuje, proto server začne posílat data. A pokud neznáte správný 64 bit connection ID, tak ty data nespustíte.

A co ty dutohlave nechapes na tommhle obrazku? https://i.iinfo.cz/images/607/quic.png