Vlákno názorů k článku HTTP/3 nebude postavené na TCP, základem bude QUIC používající UDP od Petr M - Je to řešení dotahující svou kvalitou morálku našeho...
-
Petr M (neregistrovaný)
Je to řešení dotahující svou kvalitou morálku našeho premiéra. Protože:
1) Protokol, po kterým každý e-shop uzavírá kupní smlouvy, stahuješ úřední dokumenty atd. musí mít konzistentní data.
2) Pokud mám v systému odladěnou a funkční součást, která řeší můj problém (v tomto případě TCP), je to lepší, než to patlat několikrát znovu a pokaždý s jinýma chybama.
3) Svět je plný NATů. TCP je z tohoto pohledu lepší - prostě NAT ví o spojení a jede se trvale, bez navazování furt dokola.
4) Pokud jim jde jenom o to, že TCP nešifruje, mají pod to strčit standardní IPSEC, ne vymýšlet TCP over UDP.
5) Firewall u UDP neví, kdo a co posílá a neví, jestli ten UDP paket souvisí se spojením zvenčí, nebo ho někdo jenom zkouší prostřelit.A proč ty opičárny? Protokoly HTTP i TCP jsou OK, ale problém je v tom, co přenáší. Pokud si chci přečíst 10kB textu, tak u běžné stránky mám
- 10kB textu,
- 100kB CSS stylů
- 1MB JavaScritpu na všelijaký nesouvisející chvostoviny jako šmírování atd., ze kterýho se i tak využije maximálně 0,5%
- 10MB obrázků s rozlišením 20MPix, který se pak na místě škálují na velikost ani ne 1Mpix
- 100MB reklam
(vlastní fonty každé stránky a podobný pársetkilový detaily nepočítám)Spláchněte ty lejna z webu do septiku a je po problémech s přetížením linek.
-
j (neregistrovaný)
Ale vubec ne. Je sice pravda, ze doba a technologie pokrocily a to se do urcite miry projevilo i na tom, jak vypadaji dnesni weby, ale to vubec nevylucuje, ze v nich je tuna (pro uzivatele) neuzitecneho a zbytecneho balastu, ktery se projevuje na zbytecnem objemu prenasenych dat a rychlosti nacitani stranek (resp. celkove zatezi CPU vlivem vsudypritomnych hromad javascriptu).
-
Petr M (neregistrovaný)
Řeší leda tak prd s šaltpákou.
TCP i UDP ti na internetu jedou nad IPv4 nebo nad IPv6. Ani jeden z nich nezaručuje ani doručení paketů, ani jejich pořadí. Bez toho, že by vysílací strana měla potvrzený, že to v pořádku došlo a přijímající strana měla možnost říct, že nemá konzistentní data od bytu X po byte Y nikdy nemáš garanci, že má protistrana validní data. Text, skripty, klíče v rámci D-H, soubory atd. nejsou data typu "no a co, tak kus chybí".
TCP to řeší tím, že po navázání spojení vysílající strana začne vysílat a pokud vynechá paket (jedno jestli se zamění pořadí, nebo je zahozen), hned si o něho řekne a novější data láduje do cache, dokud je nemůže navázat na chybějící paket. A ten dojde buďto zpožděně (použije se a opakovanou odpověď zahodí), nebo dojde ten na opakovanou žádost. Vysílač ví, kolik maximálně toho může být nepotvrzenýho "na cestě" a pokud nepřijde potvrzení, dá si pauzu a olehčí linku. Není to tak, že si řeknu o 100MB dat a nestarám se, když tak si někdo řekne znovu.
-
j (neregistrovaný)
A nepride ti zbytecny se vo tom dohadovat s lidma ktery netusej jak IP funguje? Paac UDP ma tu uzasnou vyhodu, ze ti muzu rvat data na fullspeedu linky, aniz by se neco zpomalovalo kvuli takovy prkotine, ze protistrana nestiha prijimat. No neni to krasny?
A vubec, spravne by mel mit kazdej browser svuj IP stack, svoje DNS, svoje ... hlavne aby to mohlo usera smirovat.
-
UDP nic takového nenutí, ono to jen umožňuje. To neznamená, že to tak bude fungovat.
Podobné implementace celkem zákonitě budou mít velkou míru retransmissions v obou směrech. Typicky spojení mobil/laptop <–> Wi-Fi bude rychlejší nez Wi-Fi <–> poskytovatel a podobně v rámci serverovny k prvnímu routeru to taky poběží rychleji než ven. Takže nepůjde o edge case netypického prostředí, ale o celkem běžnou situaci, na kterou narazíte nejspíš dlouho před ostrým provozem.
-
j (neregistrovaný)
Ale ono to presne tak funguje vime? UDP jaksi od prirody nema nic jako potvrzovany okno, ktery kdyz pretece, tak vysilajici strana prestane vysilat (a pripadne upravi velikost). TCP funguje pri zahajeni komunikace uplne stejne, akorat ze je odeslano jen to omezene mnoztvi dat (a az po vyjednani spojeni), a ceka se na jejich potvrzeni. Pokud jsou prubezne potvrzovana, pokracuje posilani dalsich dat, pokud nejsou, tak se okno zmensi = zpomali se odesilani a naopak.
Aplikace (zadna) nevi, a pokud nema vlastni ipstack tak ani vedet nemuze, na kolik paketu se to GB dat rozseka, kolik jich uz je nebo neni odeslano ... jediny co muze aplikace udelat je to, ze rozseka ta data ve vlastni rezii(nesmyslnej a zbytecnej overhead navic) ... a posila je po blocich. A zase, na UDP nema otevreny zadny spojeni, takze ti klidne muzu udelat to, ze potvrzeni poslu misto tebe.
-
Karel (neregistrovaný)
"Jak? /jak se tomu říká? sice o tom nic nevim ale brutálně mně to zajímá"
Jestli to byla otázka, jak je možné se vlomit někomu do TCP, tak hledejte "tcp session hijacking". Pokud jde komunikace přes vás, tak je to velmi snadné. V zásadě jde o to, že když vidíte packet od A pro B, tak vidíte všechno, co potřebujete na vyrobení odpovědi s potvrzením. Pokud navíc tu komunikaci můžete ovlivnit (zastavit packety), tak je únos triviální.
Moderní viry napadající routery tohle dělají běžně. Proto nelze samotnému TCP věřit a vždy je potřeba spojení zabezpečit ve vyšší vrstvě.
-
Filip JirsákStříbrný podporovatelZabezpečovat to na nižší vrstvě má tu výhodu, že je to automaticky dostupné pro všechny vyšší vrstvy, a tu nevýhodu, že to poskytuje nějakou minimální sadu vlastností, která se asi bude hodit každému. Z čehož samozřejmě plyne, že to často nebude příliš efektivní, protože vyšší vrstva by ty vlastnosti potřebovala mírně modifikované, takže si to musí vyřešit sama – a ta obecná implementace na nižší vrstvě tam je zbytečná nebo dokonce kontraproduktivní. Je to úplně stejné, jako u programování – z hlediska údržby a rozšiřování je lepší mít pěkně oddělené vrstvy, kde se každá stará o to své. Ale když něco potřebujete optimalizovat na výkon, musíte často ty vrstvy zrušit, protože kvůli výkonu musí jedna vrstva nekoncepčně vědět o něčem, co by mělo patřit do výhradní sféry jiné vrstvy.
Takže to není otázka koncepce. Pro spoustu protokolů se vyplatí používat TCP/IP, protože je to slušný základ. Jenže protokol HTTP je na dnešním internetu dost výjimečný, žádný další protokol nemá takový podíl na objemu internetového provozu – takže se vyplatí pro HTTP udělat něco extra, na míru tomuto protokolu.
-
> Z čehož samozřejmě plyne, že to často nebude příliš efektivní, protože vyšší vrstva by ty vlastnosti potřebovala mírně modifikované, takže si to musí vyřešit sama
Ono by to možná šlo, ale zbytečně by to tu situaci komplikovalo. Bezpečná komunikace z podstaty věci se snaží zajistit i integritu, což třeba UDP vzdává ve prospěch latence. Pokud chceme bezpečné spojení před UDP, je otázka, jak budeme chtít vyřešit kompromis mezi integritou a latencí. To může mít více správných řešení, každé ale vhodné pro jinou situaci.
A když půjdeme ještě níž, možná tím některé problémy vyřešíme, ale komunikace bude šifrovaná mezi síťovými prvky, čímž posuneme trust boundary.
> takže se vyplatí pro HTTP udělat něco extra, na míru tomuto protokolu.
Ale QUIC je – pokud to dobře chápu obecnější, ne zaměřený pouze na HTTP…
-
Filip JirsákStříbrný podporovatel
S tou bezpečností a integritou jste to napsal přesně opačně. U bezpečné komunikace obvykle potřebujeme zajistit i integritu, takže je zbytečné, aby integritu zajišťovala duplicitně i vrstva pod tím (TCP). Proto vůbec nevadí, že UDP nezajišťuje integritu, protože QUIC si jí zajišťuje sám (a pro své potřeby lépe, než TCP).
Vždyť diskutujeme pod zprávičkou o přejmenování QUIC na HTTP/3. QUIC není zaměřený na HTTP, QUIC je (příští verze) HTTP.
-
kraxna (neregistrovaný)
Mate trochu pravdu (a trochu ne) oba.
To, co se stane HTTP/3, je formalne nazvane "Hypertext Transfer Protocol (HTTP) over QUIC".
QUIC je definovany na nejake urovni obecne, na nejake urovni poplatne HTTP a ta predchozi specifikace prave resila adaptaci QUIC na HTTP/2 (kde QUIC resi nektere veci, ktere resilo primo HTTP/2 - tudiz by se jednalo o redundanci).
V praxi se k tomu ale pristupuje jako k celku, QUIC byl od pocatku navrzeny pro provoz HTTP(like) protokolu.
-
> U bezpečné komunikace obvykle potřebujeme zajistit i integritu, takže je zbytečné, aby integritu zajišťovala duplicitně i vrstva pod tím (TCP). Proto vůbec nevadí, že UDP nezajišťuje integritu, protože QUIC si jí zajišťuje sám (a pro své potřeby lépe, než TCP).
Souhlas, ale psal jsem o něčem jiném. Psal jsem o nějaké teoretické vrstvě na úrovni TCP/IP, která by zajišťovala zabezpečené spojení. Pokud máte use-case pro UDP, ale navíc chcete zabezpečené spojení, máte těžší úkol, než když chcete totéž pro TCP. U TCP nevadí, když budete trvat na retransmisi atd. U UDP to obecně jde proti smyslu UDP (samozřejmě mohou existovat výjimky). Najednou na vrstva by tedy měla počítat s vynecháním nějakého paketu, změnou pořadí atd. Pak se ale nebízí otázky:
1. Bude takovéto řešení vyhovovat všem use-cases?
2. Bude to stále vhodné i pro TCP?Neříkám, že neexistuje řešení, které by to splňovalo, ale je to určitá komplikace.
Mimochodem, k TLS existuje DTLS, varianta pro UDP. Podle https://stackoverflow.com/questions/15331294/difference-between-dtls-and-tls to vypadá, že si to například vyžádalo jiné ciphersuites. (Nechme stranou, že RC4 je obsolete. Šlo mi o příklad, k čemu to může vést.)
-
Filip JirsákStříbrný podporovatel
Smysl UDP ale není v tom, aby se používalo tam, kde není potřeba zajistit integritu spojení. Smysl UDP je v tom, že samotné UDP to nezajišťuje, ale je úplně v pořádku použít ho tak, že si integritu spojení zajistí nějaká vrstva nad ním. Dělá to tak například i OpenVPN nebo různé herní protokoly.
Ono kdyby se důsledně dbalo na oddělování jednotlivých vrstev, tak by TCP nestálo vedle UDP, ale bylo by na něm založené. UDP by řešilo porty a kontrolní součty, a nad tím by byla vrstva TCP, která by k tomu přidala integritu spojení. Takže pokud někomu vadí, že QUIC je založené na UDP a TCP není, je dobré připomenout že nekonzistentnost je v tomto případě na straně TCP, nikoli QUIC.
-
> Smysl UDP ale není v tom, aby se používalo tam, kde není potřeba zajistit integritu spojení.
I to může být use-case pro UDP. Třeba realtime video/audio – na chvilku vypadne, tak radši kousek vynecháme, než abychom video/audio zpozdili. V mém chápánóí pojmu integrita je to určité narušení integrity. Mohu chtít jen částečnou integritu, třeba asi nechci, aby mi někdo mohl data libovolně modifikovat, jen ztratit.
> Ono kdyby se důsledně dbalo na oddělování jednotlivých vrstev, tak by TCP nestálo vedle UDP, ale bylo by na něm založené.
Dobrá poznámka, nad tím jsem moc nepřemýšlel, ale asi ano.
-
kraxna (neregistrovaný)
Nedostaneme a nebylo. IPsec se hodi na VPN, ne jako nahrada HTTPS.
1. IPsec OE ma obecne problem s overenim identity druhe strany (takovou jakztakz pouzitelnou variantou je IPSECKEY - coz ale vyzaduje DNSSEC VSUDE - nesplneno)
2. IPsec neeliminuje zbytecny roundtrip pri prvnim navazani spojeni (naopak, zvysuje ho)
3. IPsec OE v zadnem mainstream OS nefunguje defaultne
4. IPsec ma obecne problemy s NAT-Traversal
5. IPsec nema standardnizovane API pro specifikaci / zjisteni policy na urovni socketu
6. IPsec OE neumoznuje (jednoduse) pouzivat vice klicu na jednu IP, protoze SA se vytvari na IPJinak receno, pro pouziti IPsec (abysme se dostali alespon priblizne na to, co je mozne ted), vyzaduje zmenu:
1. OS a socket API
2. Knihovnach / programovacich jazycich
3. Aplikacich
4. Vsech DNS serverech a resolverech (povinna podpora DNSSEC, nemoznost fallbacku)
5. NATProti tomu zavedeni IPv6 vypada jako mala drobnost :-)
-
Lol Phirae (neregistrovaný)
https://twitter.com/fr3ino/status/1000166112615714816
Because of #GDPR, USA Today decided to run a separate version of their website for EU users, which has all the tracking scripts and ads removed. The site seemed very fast, so I did a performance audit. How fast the internet could be without all the junk! 5.2MB 500KB
