Vlákno názorů k článku HTTP/3 nebude postavené na TCP, základem bude QUIC používající UDP od Patrik - To co se děje kolem webu obecně v...
-
Patrik (neregistrovaný)
To co se děje kolem webu obecně v poslední době mě stále vic a víc překvapuje.
Přechodem http na UDP se jen vytvoří vynikající zdroj pro DDoS na malinký Get požadavek začnu klientům posílat 10G soubory, to bude skvělé. Teda nečetl sem specifikaci ale při frekvenci s jakou Google zavádí a ruší různé výtvory je teď na to stejně ještě brzo. -
Filip JirsákStříbrný podporovatelMůžu se na něco zeptat? Na tohle jste přišel sám, přečetl jste si to tady v diskusi od spousty ostatních, nebo jste dostal nějaké instrukce? Připadá mi totiž nemožné, aby tolik lidí nezávisle na sobě napsalo takovou hloupost, která buď svědčí o tom, že vůbec netuší, jak vlastně funguje TCP/IP a vlastně ani IP, a nebo se při psaní svého komentáře porovnávajícího QUIC s TCP ani na milisekundu nezamysleli nad tím, jaký je mezi nimi rozdíl.
Pořád dokola se tu objevuje argument, že server přijme požadavek od klienta a začne na jeho základě odesílat bez jakékoli kontroly a limitů obrovské objemy dat. A protože zdrojová IP adresa paketu může být zfalšovaná, mohou ta data mířit na nic netušící oběť.
Hm. Tak si to zkusme představit s TCP. Klient začne navazovat spojení, pošle SYN paket serveru. Server na zdrojovou IP adresu toho SYN paketu (která může být zfalšovaná) začne chrlit obrovské množství dat. Úplně stejně, jako s tím QUIP protokolem. Technicky mu v tom vůbec nic nebrání. A proč by vlastně ten server musel čekat na nějaký SYN paket? Klidně může začít chrlit data do prostoru jen tak, bez vnější příčiny. Jenže servery to obvykle nedělají. Nedělají to bez příčiny, nedělají to na základě SYN paketů TCP, a nebudou to dělat ani na základě QUIC paketů navazujících spojení. Nedává to totiž z pohledu serveru žádný smysl, právě naopak.
Zájem serveru je doručit klientovi data. Server je zpravidla k internetu připojen mnohem tlustší linkou, než jednotlivý klient, zároveň se obvykle k jednomu serveru zároveň připojuje velké množství klientů. Pokud by server vychrlil data pro jednoho klienta jak nejrychleji umí, klient z toho většinu nepochytá a odpoví serveru „hm, dobrý, chytil jsem z toho tak 2 %, pošli mi zbytek znovu“. Server má zájem data klientovi doručit, takže začne znovu chrlit maximální rychlostí – a takhle by se to opakovalo do té doby, než by klient posbíral všechny části. A server by toho odeslal třeba desetkrát nebo stokrát víc, než kolik by bylo potřeba. Ano, server má sice tlustší linku, než klient, ale zase má těch klientů víc – a kdyby odeslal zbytečně stokrát víc dat, než bylo potřeba, potřeboval by také stokrát tlustší linku. Který pak provozovatel serveru by asi takovou implementaci serveru chtěl provozovat?
Takže je ve vlastním zájmu provozovatele serveru a tedy i implementace serveru, aby server odesílal data takovou rychlostí, jakou je dokáže klient přijímat. Jakékoli odeslání paketu, který klient nedokáže přijmout a vyžádá si ho znova, je pro server zbytečný náklad navíc. Takže jakýkoli protokol, který doručuje proud dat a server (resp. jeho provozovatel) má zájem na tom, aby byl doručen klientovi kompletní (protože bez toho se mu ta webová stránka nezobrazí, nebo zobrazí špatně), musí mít implementováno řízení toku dat. Takže ho musí mít i QUIC. Na to nepotřebujete číst ani specifikaci, ani zprávičku, na to stačí provést triviální úvahu předvedenou výše.
Chrlit data bez potvrzování by mohlo mít význam pro video, pokud se používá kodek, kde nějaký ztracený paket nevadí. Jenže i tam jsou pro server náklady navíc, pokud chrlí data, která klient zpracovat nedokáže, nebo je možná už vůbec nechce. Navíc pokud se ztratí půlka paketů, tak už se to na tom videu pozná. Takže i tam má server zájem na tom posílat data jenom tak rychle, jak je klient dokáže zpracovávat,a tak dlouho, dokud o ně má zájem. To povolení jisté ztrátovosti paketů znamená jenom to, že server může být lehce agresivnější při zjišťování limitů spojení.
A teď mi někdo vysvětlete, proč je tu 80 % diskutujících (na začátku diskuse to bylo dokonce 100 %), kteří takovouhle základní úvahu neudělají, a místo toho píšou do diskuse bláboly.
-
Filip JirsákStříbrný podporovatel
Když ono vlastně ani není potřeba vědět, jak funguje IP protokol. Ono by úplně stačilo, když dotyčný dojde k přesvědčení, že by se to takhle strašně snadno dalo zneužít k DDoS útokům, aby si položil otázku: kdo by dobrovolně migroval server na protokol, který umožní takhle jednoduše využít celou kapacitu linky k serveru k DDoS útokům? Nebo, pokud dotyčný četl celý článek – jak to že k těm útokům už nedochází, když to Google už v praxi používá?
Že je ta diskuse jenom nějaký sociologický experiment a první skutečný diskutující, který se zde objevil, je Vít Šesták, a všechny ty příspěvky před ním byli jen najatí herci?
-
null null (neregistrovaný)
@kraxna
Ale já napsal že to nevím a ani mě to nezajímá. Jenom ze zájmu pročítám i diskuze pod články - jako tato diskuze. kde se člověk něco dozví třeba tím že je někomu něco vyvráceno - a všiml jsem si, že ta neshoda mezi nimi je někde jinde než @Filip Jirsák popsal - což by jako zjištění mohlo lépe vést k vyřešení neshody - s tím jak QUIC funguje to myslím nemá nic společného a jak jsem napsal, stejně je mi to celkem šumák - QUIC přímo nepoužívám a HTTP 3 prostě používat budu muset. Až bude. To je celé.
Ale k tomu co si myslím. Nemyslím si že by to nechali jenom tak, odstranili handshake a nechali jenom tak nějak něčím nějaké děcko bombardovat servery a kdoví co. Jediná relevantní otázka je podle mě jestli je správně to že odsunuli handshake na aplikační vrstvu, což má samozřejmě obvyklé pro a proti a bude o tom rozhodovat klasicky požadavky okolního prostředí nasazení - třeba poptávka pro konkrétní omezení latence, hw možnosti apod. které se mohly v čase prostě zaměnit a už se nevrátí .... Bez mučení přiznávám že to neumím úplně posoudit abych za to dával ruku do ohně. Takže se k technické stránce neyjadřuji.
-
Filip JirsákStříbrný podporovatel
Většina diskutujících (hlavně ti, co psali do diskuse hned na začátku) vychází z předpokladů o QUIC, které nejsou pravdivé – například že QUIC nemá handshake. Když vycházíte z chybných předpokladů, závěry jsou samozřejmě k ničemu.
Pokud používáte Chrome nebo jiný prohlížeč postavený na jádru Blink, tak QUIC nejspíš používáte.
-
null null (neregistrovaný)
@Filip Jirsák
Měl jsem na mysli používání jako při vývoji aplikací apod., to že si zapnu browser a on někde pošle QUIC dotaz aniž bych to tušil jsem na mysli neměl ... Úplně stejně by moje mamka používala AJAX, ale pochubuju že by věděla že to je něco jiného než prostředek na mytí ... Ale to je detail ...
V podstatě je jedno z čeho vychází, jenom jsem si všiml toho, že jste milně v tu chvíli identifiovali bod, ve které se neshodujete:
Neshoda totiž nebyla v té komunikaci má nebo nemá být handshake, obě strany tvrdiliy že je poteba, nybrž jedna strana - ne tvá - tvrdila že tam není. A to je podle mě rozdíl.
-
Filip JirsákStříbrný podporovatel
Neshoda totiž nebyla v té komunikaci má nebo nemá být handshake, obě strany tvrdiliy že je poteba, nybrž jedna strana - ne tvá - tvrdila že tam není. A to je podle mě rozdíl.
Ano, spousta lidí tu bůhvíproč tvrdila, že v QUIC handshake není, a někteří (mezi nimi já) to vyvraceli a tvrdili, že tam handshake samozřejmě je (protože by to bez něj nemohlo rozumně fungovat). -
null null (neregistrovaný)
@Filip Jirsák
Já vím. Poctivě jsem přečetl tvůj text [1] a ty jsi tam popsal problém v tom, že vůbec neuvažovali o tom že řízení toku dat tam být musí [2]. Já upozornil na to že oni netvrdí že by tam být nemělo nebo o tom neuvažovali jak uvádíš, ale že tam není (tvrdí oni, ne já). Pouze jsem upozornil na tento rozdíl ve vidění toho kde je zde neshoda, ne kdo snad má nebo nemá pravdu. To je celé.
[2] "Takže jakýkoli protokol, který doručuje proud dat a server (resp. jeho provozovatel) má zájem na tom, aby byl doručen klientovi kompletní (protože bez toho se mu ta webová stránka nezobrazí, nebo zobrazí špatně), musí mít implementováno řízení toku dat. Takže ho musí mít i QUIC. Na to nepotřebujete číst ani specifikaci, ani zprávičku, na to stačí provést triviální úvahu předvedenou výše."
-
Filip JirsákStříbrný podporovatel
@Nick Sekáč Magor: Já jsem se v tom textu podivoval, proč neustále někdo předpokládá, že tam řízení toku není, když 1. tam řízení toku je a za 2. i kdyby dotyčný nevěděl, zda tam je nebo není, tak jednoduchou úvahou dojde k tomu, že tam být musí, jinak by to nefungovalo. Pokud dotyční věděli, že tam být musí a přesto bezdůvodně tvrdili, že tam není, je to ještě větší záhada.
-
null null (neregistrovaný)
@Filip Jirsák
Právě že nikdo netvrdil že tam někde nemá být (pointa), jenom že tam či támhle není. Proč? Nevím a ani mě to nijak nezajímá ... Celé toto vznikolo protože jsem se musel obhájit vůči @kraxna který těch někoilk mých řádků absolutně nepochopil a vyloži si je jako trošku oleje do ohně jedné verze ... hmmm
-
Petr M (neregistrovaný)
Vycházím a argumentace autorů QUIC, že právě ten handshake odpárali. Když není úvodní handshake, ale jenom GET, tak kdy má server začít s přenosem? Logicky po tom GETu a potvrzování jede až za běhu, aby se snížila latence.
A píšou, že GET má mít parametry. Tzn. klíče pro šifrování, kapacita linky a asi i velikost dat, kterou může poslat. klíče si můžu vygenerovat (jejich ověření by bylo dražší, než ten handshake, takže tam nebude), na DDoS dám kapacitu linky nesmyslně vysoko a velikost bufferu stejně tak, protože chci poslat maximum dat maximální rychlostí. Že to server utne, když mu dojdou data nebo dosáhne požadované velikosti je hezký, ale i tak tu lajnu krásně zahltíš.
-
On tam samozřejmě handshake je. Jen místo toho, aby nejdřív proběhl TCP handshake, pak TLS handshake a pak se teprve poslal request, udělá se jen jeden QUIC handshake (který řeší spojení i kryptografii) a pak se rovnou pošle request. Třeba tady to máte i s obrázky.
-
ESP neřeší kryptografický handshake vůbec, ESP můžete použít až ve chvíli, kdy už nějakou sadu algoritmů a klíčů dohodnutou máte. Takže byste nejdřív potřeboval IKE/isakmp nebo nějaký ekvivalent a ve výsledku byste vlastně jen prohodil pořadí těch dvou handshaků (nejdřív kryptografie, pak TCP). Navíc zrovna u IKE IIRC s jedním roundtripem nevystačíte.
Je samozřejmě pravda, že pro konkrétní dvojici klienta a serveru stačí IKE handshake provést jen jednou (za zvolenou dobu), ale pak stejně zůstane TCP handshake, zatímco QUIC pro následné dotazy handshake potřebovat nebude. A hlavně byste narazil na problémy s existující infrastrukturou, přes kterou by to neprošlo. (Navíc i spoustu problémů s IPsecem jako takovým, třeba nutnost definovat nějakou univerzálně povinnou sadu parametrů, aby se opravdu každý byl schopen a ochoten domluvit s každým.)
QUIC není dokonalý, to ani zdaleka. Souhlasil bych i s tvrzením, že místo aby problémy řešil, spíš je obchází. Je to prostě způsob, jak zlepšit komunikaci mezi webovým prohlížečem a serverem při zachování existující infrastruktury a respektování jejích omezení. Místo aby se tvůrci snažili "protocol ossification" řešit, vzali ji jako fakt a pokusili se dosáhnout co nejvíc v daných mantinelech.
-
Filip JirsákStříbrný podporovatel
Vycházím a argumentace autorů QUIC, že právě ten handshake odpárali.
Jenže oni ho nezrušili. Oni ho jen dělají trochu jinak, než TCP/IP.Všechny ty vaše komentáře jsou založené na tom, že jste si nezjistil ani základ toho, jak to funguje, a ignorujete, i když vám to někdo napíše do diskuse.
-
Petr M (neregistrovaný)
Jak je to "jinak"?
Buďto mám handshake hned, ale pak se několikrát (min. 3x) musí protáhnout zpráva skrz spojení (ne jeden paket, třeba doma mám MTU 1496 B a holý klíč má třeba 2048 B) bez záruky doručení, tj. s latencema, timeoutama, případným opakováním a vším, co k tomu patří. Nebo prostě začnu komunikovat ještě dřív, než ten handshake doběhne. Není jiná možnost.
Jedinej rozdíl v navázání může být v tom, že se zprávy sloučí, ale pak je každá složená z několika paketů bez záruky pořadí a doručení. A jsme tam, kde jsme byli.
-
Filip JirsákStříbrný podporovatel
V článku máte odkaz na standard a na video, v diskusi máte další odkazy, které fungování QUIC popisují. To, co si vy myslíte o tom, jak to určitě musí fungovat, bych nepovažoval za směrodatné, když si nejste ochoten o tom cokoli zjistit. Navíc už vám to vysvětlil Michal Kubeček, a vy to vysvětlení stejně ignorujete.
-
j (neregistrovaný)
Na odpoved protistrany se musi pockat pokud se chce navazat spojeni, pokud se nechce cekat, musi se rovnou ladovat data. Zadne jine reseni neexistuje.
A zase, celej problem spociva vyhradne vtom, ze to navrhuji idioti a pouzivaj sroubovak k zatlouhani hrebiku. Protoze to sifrovani ma bejt pod tcp a ne nad nim ani vnem. A hlavne a primarne jde o snahu guuglu zcela ovladnout idealne cely internet, a kdyz ne ten, tak alespon ten web.
