Názory k článku HTTP/3 nebude postavené na TCP, základem bude QUIC používající UDP
-
Cohen (neregistrovaný)
Při vší úctě k IETF mi to nepřijde jako nejlepší nápad.
V dnešní době panuje masivně trend vše vkládat do HTTPS. Tomu se v podstatě přizpůsobuje každá nová služba, která nechce riskovat problémy s provozem. A spirálou se podle toho chovají správci ve firmách, takže se často stává, že "internet = tcp 80 a 443". Takže potřeba toto celé začít přepisovat na jiné principy, mi přijde minimálně celkem odvážné.
Volba UDP pro účely nového protokolu je jistě velmi výhodná z mnoha důvodů, radost z ní ale nebudou mít firewally, které mají v této oblasti výrazně míň možností hlídat provoz, než v případě TCP.
A v neposlení řadě to bude mít zásadní vliv na globální provoz. Nedávno tu byl článek o BBR a problémech, které by mohl přestavovat z pohledu řízení toku. QUIC může mít ještě mnohem větší dosah a ačkoliv je už určitě z YouTube k dispozici spousta dat z provozu, pochybuji, že to představuje dostatečně různorodou směs použití pro kvalifikovaný odhad všech budoucích rizik.
-
j (neregistrovaný)
Hlavne to ... nemuze fungovat, respektive muze, kdyz to potvrzovani a overovani ze data dorazila, reimplementujes komplet o layer vejs, takze to muze navrhovat leda debil.
UDP ma totiz smysl tam, kde ti ztrata paketu nevadi, a ses ochoten ji vymenit za trochu lepsi latenci, coz neni pripad http. I spousta routeru ti v pripade velky zateze zaccne nejdriv zahazovat udp - jednoduse proto, ze zahozeny tcp se jim obratem vrati v pozadavku na opakovany prenos.
Jinak se cela tahle demence vymejsi predevsim kvuli nesmyslu ala protlacime video pres http.
-
Však o garanci doručení nepřijdete, jen to bude implementovat jiná vrstva. Což sice není hezké, ale: Buď můžeme vymýšlet hezké řešení v podobě „TCP2“ a čekat na jeho implementaci a reálné nasazení v routerech atd., nebo můžeme už dnes použít UDP.
S videem přes HTTP to asi moc nesouvisí. A mimochodem, i u videa záleží, o co přesně jde. Já radši video stáhnu celé.
-
Petr M (neregistrovaný)
Ale PROČ je potřeba nahrazovat fungující a robustní část systému vlastní implementací? PROČ nevyhoví TCP + IPSEC? Tohle neřeší problém, jenom posune limity kapacity o 20% dál a za rok-dva jsme ve stejné žumpě. Zahození paketů na přetížené lince to nezabrání. Jenomže teď pokud mám MTU 1500 a buffer na čtyři pakety, opakuju při zahození max. 6kB, takhle budu hlásit chybu po 10MB a opakovat znova těch 10MB. No dík moc.
Jenom to přinese další bugy v implementacích a v postřezích bezpečnosti se dočteme o CVE na "packet injection" u Chrome...
-
> PROČ nevyhoví TCP + IPSEC?
TCP – výkon
IPSEC – až tak to neznám, ale funguje na jiné vrstvě a řeší ponékud jiný problém. Je to spíše řešení pro VPN než náhrada TLS: https://www.quora.com/In-what-cases-is-TLS-more-useful-than-IPsec-and-vice-versa
> jenom posune limity kapacity o 20% dál a za rok-dva jsme ve stejné žumpě
Nevím, odkud máte ten posun o 20 %, ono to především snižuje latenci u navázání spojení. Kapacitu teoreticky navýšíte jak chcete pomocí dostatečného počtu paralelních linek, latenci tak snadno neobejdete. Rychlost světla je konečná, můžete leda zkracovat dráhu, zpoždění při routování a počet round tripů. O to poslední se snaží právě QUIC.
> Jenomže teď pokud mám MTU 1500 a buffer na čtyři pakety, opakuju při zahození max. 6kB, takhle budu hlásit chybu po 10MB a opakovat znova těch 10MB.
Z čeho odvozujete těch 10 MB?
> Jenom to přinese další bugy v implementacích a v postřezích bezpečnosti se dočteme o CVE na "packet injection" u Chrome...
Bugy to přinést může (jako všechno nové), ale zrovna packet injection by mě s TLS moc netrápilo…
-
Petr M (neregistrovaný)
TCP má jednu krásnou vlastnost, jeho chování při přetížení linky a zahazování paketů. Dokud není potvrzeno doručení dávky, nic se nevysílá.
Kdežto s UDP bez potvrzování bude fikce doručení a prostě se tam UDP pakety s nějakou kadencí sypou. Když začne switch nebo router zahazovat kvůli plné cache, přijímač má timeout třeba 1s a za tu 1s zareaguje, že nic nechodí a pošle žádost o opakování. Mezitím vybleješ 120MB dat do gigové lajny. Při latenci 100ms už opakuješ 130MB - který byly zahozeny. A zase se potká 12 gigových linek na switchi s uplinkem 10G... Nebo ta gigová lajna vleze do 120mbps přípojky. A zase se zahazuje...
Prostě si neumím představit zaručený přenos většího balíku dat bez potvrzování. Linka totiž nemá zaručeno, že data doručí a nedokážu si představit přenos třeba 2048B PKI klíče s MTU 1500 bez garance, že dostanu oba pakety. A já chci obě půlky klíče.
Btw, pokud se ztrácí pakety, problém bude všude. Pokud to jde hladce a máš nějakou cache na straně přijímače, chodí potvrzení nezávisle na datech a potvrzuješ několik paketů zpětně, zbytek se skládá a cachuje podle propustnosti lajny.
Pokud jde o IPSEC, myslím, že by bylo vhodnější. HTTPS zcela nesystémově řeší ověření původu dat a šifrování (dvě nezávislý věci) jedním klíčem různýho typu. pak klíč musí vydávat nějaká CA i v situaci, kdy chci komunikovat v rámci LAN. Pro šifrování komunikace by bylo lepší IPSec s VK webu v DNS. Stáhnu klíč, zašifruju pomocí jejich VK svůj VK, dešifruje jej jenom ten web s pomocí PK a máme šifrovaný tunel. I pro IoT, kde si zařízení vygeneruje svoje klíče a nemusí se autentizovat (je v mé LAN, vím kdo to je).
Autentizace protistrany se teprve dá řešit tím, že ten VK serveru bude podepsaný někým důvěryhodným, ale volitelně. Pro šifrovanou komunikaci bez ověření protistrany stačí HTTP nad TCP nad IPSEC.
-
Ad TCP: je pravda, že dobrá implementace QUIC si tady asi vyžádá nějaké úsilí, ale nemyslím si, že by to nešlo. Ostatně iniciuje to Google, ne nějaká garážovka. A jakmile budou knihovny…
Nebo máte nějaký důvod předpokládat, že se to bude chovat takto hloupě?
Ad IPSEC: Ono to na první pohled vypadá možná jako správná cesta, ale je to komplikovanější. HTTPS pracuje s hostname, což na úrovni IPsec asi nemáte.
-
Karel (neregistrovaný)
QUIC ale packety potvrzuje. V tom funguje stejně jako TCP. Odesilatel, stejně jako příjemce, má paměť jen na X packetů. Dokud nepřijde potvrzení přijetí, tak se další nepošlou. Je to trochu složitější, protože v rámci jednoho spojení může být více streamů. Takže ztracený packet zablokuje jen jeden stream a ostatní (pokud tam nějaké ostatní jsou) mohou přenášet data dál.
Nepleťte si UDP a QUIC. QUIC garantuje doručení ve správném pořadí.
-
Adam KaliszStříbrný podporovatelVtipné je, že snížit latenci by se asi nejvíce "vyplatilo" změnou vlnovodů/ optických vodičů na mikrorourky. Světlo se vzduchem šíří oproti křemennému sklu asi 40-50% rychleji -> právě jste zkrátil latenci na skoro polovinu. Myslím, že na transatlantické kabely by to bylo zajímavé a jistý výzkum v tomto směru je...
Samozřejmě práce na přenosové nebo aplikační vrstvě je taky dobrá, ale ono to nakonec dopadne tak, že monopol Google a pár dalších větších hráčů budou mít technologicky tak trochu svůj internet s IPv6, QUIC a HTTP/3 a BGPSec atp. a ti ostatní (firmy v jiné branži, velkopodniky) pojedou vesele na CGNAT IPv4, TCP, HTTP 1.1 a občas TLS 1.2 max.
Doufám, že internet zůstane technologicky více homogenní, ale realita nejspíše bude jiná.
-
Jestli rychlost je o 50 % vyšší, pak to znamená zkrácení latence na dvě třetiny.
A hlavně, jsou to dvě nezávislé věci. Jestli to můž2te zrychlit lepším médiem, proč ne. Jestli to můžete zrychlit lepším protokolem, taky dobře. Bude-li to úsilí stát za to, klidně vyměňme obojí. Otázkou je snadnost nasazení (např. software se mění lépe než hardware + z pozice Googlu je ten rozdíl ještě větší).
(V přenosových médiích se nevyznám a jen slepě předpokládám, že by šlo o zlepšení bez negativních dopadů…)
-
mik (neregistrovaný)
Toto je omyl aj v samotnom clanku, ze hlavny dovod QUIC, je dlzka nadviazania spojenia.
Hlavny problem HTTP/2 je head-of-line blocking. Pretoze HTTP/2 ma v sebe niekolko paralelnych streamov tak by bolo pekne aby boli nezavisle, co nie su, lebo idu v jednom TCP streame. Cize strata/zdrzanie jedineho paketu sposobi zdrzanie vsetkych streamov. Tento problem pri HTTP/1.1 neexistoval, alebo bol aspon ovela menej viditelny.
Cim nechcem povedat ze pome naspat k HTTP/1.1!!!
Samozrejme, znizit pocet paketov na nadviazanie spojenia je vzdy pekne, ale pretoze user agent by mal nadvazovat HTTP/2 spojenia, ktore su na viacero requestov + mame 0-RTT v TLS1.3 tak prinos znizenia poctu round tripov je marginalny.
-
>> Hlavny problem HTTP/2 je head-of-line blocking. Pretoze HTTP/2 ma v sebe niekolko paralelnych streamov tak by bolo pekne aby boli nezavisle, co nie su, lebo idu v jednom TCP streame. Cize strata/zdrzanie jedineho paketu sposobi zdrzanie vsetkych streamov. Tento problem pri HTTP/1.1 neexistoval, alebo bol aspon ovela menej viditelny.
No a to by nestačilo, aby browser navázal několik spojení? Takový hybrid mezi mezi http/1.1 a http/2... Nemůžu si pomoct, mě vývoj nového protokolu přijde spíš jako obchodně-politický tah.
-
kraxna (neregistrovaný)
Vic spojeni.= vickrat resit cele TLS, handshake, ...
Je to zbytecne, proto je jednodussi pouzit spojeni jedno nad UDP a QUIC uz si to osetri sam.A hlavne, tohle neni zadna novinka boha jeho. 35 % veskereho mobilniho trafficu v USA je pomoci QUIC.
A zadne problemy se nekonaji, naopak. -
Dobrá poznámka.
Co jsem se díval na specifikaci TLS 1.3, vypadá to, že i TLS je na nějaké vynechání paketu připraveno – není-li kompletní record, nebrání to čtení dalších recordů. (Neúplný record by teoreticky šlo číst, ale nezkontrolujeme mu integritu…) Ale nejspíš QUIC musí mít nějaké požadavky ne dělení do recordů, jinak může být problém správně pokračovat…
-
Petr M (neregistrovaný)
V tom případě by to dávalo smysl, ale furt je to další srovnávák rovnáku na ohybák.
Primárně problém vznikl tak, že se místo jednoho html, několika obrázků a stylu začalo přenášet kikilión zbytečností navíc. Přitom co ten web <b>doopravdy</b> potřebuje?
Tracking uživatele obrázkama 1x1px, kvůli kterýmu se navazuje extra spojení a stahuje se soubor? To přece server tak jako tak vidí - stránku, kterou posílá, ví a session ID taky.
Fonty? To jako vážně osobní blog Buhumila Františka Ujetýho s pěti návštěvama ročně, nepočítáme-li autora, musí mít stejný font na Widlích i na Macu? Default systémový písmo nestačí? Pryč s tím, pokud není racionální důvod.
Hi res obrázky, který škáluješ na místě? Co kdyby prostě HTTP server dostal info "mám k dispozici rozlišení X x Y", vyrenderoval stránku a hotovo? Klidně může vygenerovaný prvky s konkrétním rozlišením hodit do lokální cache, pokud chce šetřit výkon.
Skripty pro G, FB, LinkedIn, ... stahovaný automaticky a bez souhlasu autora i tam, kde provoozovatel webu v OOP garantuje soukromí návštěvníka? To přece ani není legální, pryč s tím!
Pak se zjistí, že v reálu se stahuje pět souborů + nějaká reklama. Pokud pro reklamu bude extra stream s nějakým kontejnerem, 6x TCP už tak nebolí. Prostě řešit problémy by měli v rámci stávajícího standardu a až to nejde, hledat teprve jinou cestu.
-
A vážně to nějak ovlivní přenos velkých souborů (např. toho videa), kde se jednou naváže spojení (DNS, TCP, TLS, ...) a pak se přenáší proud obsahující velký objem dat?
Většina těch snah mi přijde namířená spíš na scénáře, kde je velký počet malých souborů a kde se cílí na minimalizaci latence. Ale když si pouštím video, tak je mi celkem jedno, jestli začne hned nebo za dvě vteřiny, protože má třeba dvacet minut nebo dvě hodiny -- a když už se tomu rozhodnu věnovat tolik času, nějaká ta režie na začátku je nepodstatná. A pokud to video za něco stojí, tak si ho stejně spíš stáhnu k sobě na disk, abych nebyl závislý na tom, zda ho někdo na serveru milostivě nechá.
Pokud jde o krátká videa, to budou právě většinou ty spamy, reklamy... Nebo to má být kvůli živým přenosům? Tam ale stejně nějaké latence jsou (komprese videa atd.). A hlavně mi většinou přijde vhodnější asynchronní způsob komunikace -- nevyžaduje, aby autor informace byl připojen ve stejnou dobu jako její příjemce.
-
Pokud zminujete banky, tak si clovek taky musi uvedomit, co se z jeho requestem opravdu deje. Ono totiz TCP vs UDP je analogicky stejne jako globalni transakce vs even sourcing. Globalni transakce vzdy byly problematicke, ale ok, na konci clovek vedel, ze co prislo je vyrizeno a zapsano vsude kde ma. To je pripad TCP, ale spousta nejenom bank prechazi/preslo na event driven architektury, resp. event sourcing, tj. eventualni konzistenci dat. Ma to svoje challenges, ale je to plne non-blocking (z vlastni perspecktivy, blocking tam prinasi protokoly typu http, apod.), takze super, ze se toho zbavime.
-
sasaQ (neregistrovaný)
tak sup zpatky do skoly a nastudovat rozdil mezi transportni a aplikacni vrstvou. aby z quicu nemeli radost middleboxy je zamer. a volba congestion control zavisi na servru a ten se rohoduje podle toho kam data posila. v clanku chybi uvaha o rychlosti adaptace zmen toho, co je v kernelu/user space. a ze se autor nezminil o early data je taky velky spatny.
-
Meh (neregistrovaný)
No, ja si radeji pockam tech 300ms na vytvoreni jaksi nove session, nez abych zrecykloval drive dohodnuta kryptograficka data a jen tak mimochodem druhe strane potvrdil, ze jsem ten samy clovek, co minule, ackoliv jsem mezi tim treba vymazal cookies, obsah vsech moznych DOM storage a databazi, zmenil IP a co ja vim, treba i prohlizec uplne, pokud se tato predem dohodnuta data budou ukladat na urovni OS misto prohlizece.
To by mel Google to smirovani hodne jednoduche.A kdyz uz jsme u toho prejmenovavani, muzeme prejmentovat IETF na Google Engineering Task Force,
-
f (neregistrovaný)
Sledovat uzivatele lze uz dnes s TCP+TLS: https://arxiv.org/abs/1810.07304
-
Co je na tomhle KISS nevím... četl jste to? Já se jen díval na diff toho "standardu" a na to že by to mělo být "KISS" tam je dost, opravdu dost, změ jen v říjnu... Úplně to vypadá, že ten co to prgá u chrome to zároveň píše do RFC :D
- Myslím, že
- Tenhle "HTTP/3" vznika protože google má velký podíl na Web provozu a Prohlížečích. Řeší jen úlohu jak za současného stavu Internetu zrychlit svoje služby.
- Např UDP je tam jen a jen proto, že nemají většinovou kontrolu nad NAT routerama a firewallama, a holt to vyvíjí primárně pro IPv4 svět. Podobně tam bude nejspíš plno dalších věcí "poplatných aktuálnímu stavu internetu a potřeb google".
-
Kylo (neregistrovaný)
HTTP/3 ale neznamena ze HTTP/2 je zrazu zastaraly a konci. Budou zit paralelne dal vedle sebe, akorat nektere casti webu si vystaci s rychlejsim HTTP/3 a nektere vyzadujici vetsi robustnost pojedou v HTTP/2.
Skoda jen, ze na internetu je pomerne velka demokracie a neni tu nekdo co by bacnul rukou po stole a konecne uz donutil vypnuti HTTP/1. Asi jedinou cesotu bude az se vyrobci browseru dohodnou, ze jej uz z prohlizecu vyhodi tak ja to udelali treba s Gopherem. -
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
-
Petr M (neregistrovaný)
Spíš "pokud to půjde dobře blokovat na firewallu, nemám nic proti".
Ono totiž pokud budu mít stupnici důvěryhodnosti paketu vstupujícího do sítě od 1 do 5 (nejdůvěryhodnější), tak paket co přijde v rámci TCP iniciovanýho z vnitřní sítě má 4, akceptovaný TCP zvenčí 3, UDP zvenku 1 (ke spojení se nedá přiřadit, pokud nebudeme cpát do DB firewallu odchozí UDP pakety a zjišťovat, jestli za poslední minutu zevnitř někdo komunikoval odesílatelem).
-
Seesa (neregistrovaný)
Zajímavé: u DNS se řešil problém, v souvislosti s DNSEC, že je potřeba přenášet větší množství dat (víc než 512b) tak se přišlo s implementací DNS over TCP. Viz RFC 7766 - https://tools.ietf.org/html/rfc7766
-
Za prvé: DNS přes TCP popisuje už RFC 883 z listopadu 1983, zatímco první RFC týkající se DNSSEC, které jsem našel (RFC 2065), pochází až z ledna 1997. Za druhé: to omezení na 512 B (ne 512 b) si stanovil protokol DNS sám s ohledem na tehdejší situaci. EDNS umožňuje používat delší dotazy a odpovědi i přes UDP.
-
j (neregistrovaný)
2Seesa: Az na to, ze DNS nad TCP funguje odjakziva. Protoze trebas pri prenosu cely domeny ze TCP zcela bezne pouziva. Proc? Protoze cena. Cena navazani TCP spojeni pro jednoduchou komunikaci typu dotaz/odpoved je nesmyslne vysoka. Cena reseni nedorucenych UDP paketu pri prenosu klidne MB dat, je prozmenu mnohem vyssi, nez navazani tcp spojeni.
-
SB (neregistrovaný)
MarSik:
„U UDP je ovšem problém to ESTABLISHED, RELATED poznat. Protože nemá SYN/ACK, který ten conntrack sleduje. Z pohledu kernelu a síťové vrstvy je tam prostě náhodný odchozí UDP paket.“Musím přiznat, že tuto úvahu moc nechápu (a nechám si ji vysvětlit) - nějaký SYN/ACK je záležitostí samotného TCP, firewall to nepotřebuje, tomu stačí znalost nějaké kombinace adres a portů. K čemu je mu vědět, v jaké fázi mají 2 počítače rozjednané spojení?
-
ehmmm (neregistrovaný)
"nějaký SYN/ACK je záležitostí samotného TCP, firewall to nepotřebuje, tomu stačí znalost nějaké kombinace adres a portů. K čemu je mu vědět, v jaké fázi mají 2 počítače rozjednané spojení?"
Myslim, ze jde o jakesi zvyseni bezpecnosti. Nejenze paket muze prijit pouze na povoleny port (nebo z povoleneho portu), ale u TCP lze hlidat, ze spojeni bylo zahajeno zevnitr. Pripadne ze nas nekdo nebombarduje nesmyslnymi pakety, ktere v danem stavu TCP spojeni nedavaji smysl a mohou zpusobit nejakou skodu.
-
Filip JirsákStříbrný podporovatel
Pokud nějaký protokol nerozlišuje stavy spojení, tak přece není možné poslat paket, který by byl nesmyslný vzhledem k aktuálnímu stavu spojení a tím pádem ani nemůže způsobit nějakou škodu. QUIC handshake spojení má, takže když chcete, můžete stav spojení na firewallu sledovat.
-
Filip JirsákStříbrný podporovatel
Hlavne ti u toho TCP muze kterakoli ze stran spojeni UKONCIT, coz je pro firewall jednoznacny info o tom, ze zadny dalsi pakety uz nema pustit.
To tradičně není pravda, spojení může být zcela legálně v polouzavřeném stavu, kdy jedna strana spojení ukončila, ale druhá strana dál posílá data. Navíc i když přijde paket ukončující spojení, ještě mohou docházet „zatoulané“ pakety, které ve spojení patří před ten ukončovací paket, akorát je ten ukončovací paket z nějakého důvodu v síti předběhl.Navíc třeba Internet Explorer při komunikaci s IIS spojení neukončoval, ale resetoval ho.
Na UDP je to na tom, jak je nastavenej timeout, a to muze bejt hodne dlouho.
Protokol realizující spojení nad UDP samozřejmě může definovat způsob, jak uzavřít spojení. Například v QUIC k tomu slouží rámecCONNECTION_CLOSE. -
Petr M (neregistrovaný)
To ale neřeší ten největší průšvih - že ten standard psal nějaký blackhat.
Ten průšvih je v tom, že si díky ušetřenýmu handshake můžu říct http3 serverům tvým jménem o doručení souborů na tvou IP adresu. A ty to tam prostě nastřílí. Pokud žádost bude 1kB, mám s 5MB souborem multiplikační efekt cca 5000x. Pokud najdu nějaký 5GB image instalaček, mám zesílemí 5E6x. Pro DDoS jak dělaný.
S http2 přitom odejde jenom hlavička, kterou oběť nechtěla (pár bytů) a je po všem. Bez aktivní spolupráce příjemce se přenos nekoná.
Takže jestli chtějí zrychlit navazování komunikace, tak ať místo DV certifikátu dovolí soukromý klíč v DNS + IPSEC + HTTP. Pak se nemusí ověřovat revokace klíče a ušetří tím čas i energii. Pro ostatní certifikáty je holt zpomalení daň za bezpečnost. A mimo rychlejšího navazování komunikace v tomhle případě UDP spíš škodí.
-
Petr M (neregistrovaný)
Slyšel jsi někdy o "DNS Amplification"? Pokud tam nebude nějaký extra neprůstřelný mechanismus na ochranu, tohle je nemlich to samý. S jediným rozdílem, místo párkilové DNS odpovědi ti to klidně nableje pár mega v souboru ani nemrkneš. Z jednoho paketu jich udělat (deseti)tisíce, to je sen každýho obchodníka, který nabízí "DDoS as a service".
A i s tím mechanismem, pokud se najde chyba, bude výsledek hodně zajímavý.
Důvod přechodu na UDP je totiž jediný - nezdržovat se dohadováním ohledně spojení a parametrů, server ví jenom co, na jakou IP adresu a jaký port vychrlit. Pokud je to něco větší než dotaz a současně se dá pokyn k odeslání podvrhnout, bude to zneužito k zesílení DDoSu. Nehledě na to, že pokud někdo bude server k zesilování používat opakovaně, odstřihnou od netu "čerti" i ten legitimní web server - další vektor útoku na službu.
-
Filip JirsákStříbrný podporovatel
Extra neprůstřelným mechanismem myslíte třeba potvrzování přijatých paketů, něco na způsob, jako používá TCP? Pořád se tváříte, jako kdyby QUIC neměl zaručovat přijetí všech paketů a ve správném pořadí na úrovni aplikačního protokolu – jenže bez toho by HTTP nefungovalo. Jenže ve skutečnosti QUIC zajišťuje spojení, stejně jako TCP, takže samozřejmě zaručuje doručení všech paketů a ve správném pořadí – akorát to dělá jinými prostředky, než to zajišťuje TCP.
Někomu připadá bláznovství, že by se mohlo přijít s něčím lepším po více než čtyřiceti letech používání TCP, zkušeností s ním a také po více než čtyřiceti letech změn ve spodních i vyšších vrstvách (před čtyřiceti lety se TCP spojení nepřenášela ani přes LTE, ani stogigabitovými spoji, nestreamovala se přes něj živá vysílání v HD ani přes něj malá čidla neposílala aktuální teplotu každých pár sekund). Někomu zase připadá, že při těch změnách a za tu dobu už se dalo zjistit, že některé něco nejsou ideální, a vymyslet, jak je zlepšit. A zrovna Google má s přenosy protokolem HTTP docela velké zkušenosti, vždyť na tom protokolu celá ta firma stojí.
-
Petr M (neregistrovaný)
Takže na tvoje přání to vezmu polopaticky znovu, pro ty, co neznají rozdíl mezi UDP a TCP:
Spojení UDP ze stroje A na stroj B (za dvojtečkou je port), např. DNS:
1) A:X -> B:53: Pošli záznam AAAA pro domena.cz
2) B:53 -> A:X: IP adresa je ...Většinou se posílá několik dotazů na několik serverů a co dojde, to se použije. DNS serveru je úplně šumák, jestli to došlo. Kdyžtak se zeptá znovu...
Spojení TCP na příkladu SSH:
1) A:X -> B:22: Prosím o spojení na A:X
2) B:Y -> A:X: Nabízím komunikaci na portu Y
3) A:X -> B:Y: Ok, můžeme komunikovat
A v téhle chvíli máme obousměrný tunel A:X <> B:Y se zaručeným pořadím dat a zaručeným doručením, pokud není přerušená linka.
No a teď něco k DDoS. Princip je zahlcení linky oběti. Pokud má 10Gbps uplink, pošlu jí 30Gbps a není tam kapacita pro zpracování legitimního provozu. Abych poslal 30Gbps, musím mít zdroj dat s minimálně 30Gbps. To má málo kdo, takže se používá zesílení přes některý služby (NTP, DNS, ICMP,...). Probíhá to takhle (C je oběť):
AC:X->B:Y: Pošli odpověď na ... // A změní svou IP adresu v paketu na IP adresu oběti
B:Y->C:X: Odpověď delší než dotazCelkem triviální záležitost a stačí, když ISP nekontroluje odchozí IP adresy, že patří do jeho rozsahu.
A teď si představme, že se někdo rozhodne po UDP přenášet balíčky souborů na jednu UDP žádost:
AC:X->B:443: Pošli stránku ..., do potvrzení smí odejít 10MB
B:Y->C:X: Stream až 10MBPři žádosti velikosti řekněme 5kB včetně klíčů pro šifrování (který si můžu vymyslet, server mě nezná) a podpisu (to samý, ví jenom IP adresu, ale ne veřejný klíč) získám až 10MB z jednoho stroje.
Když bude mít průměrný server k dispozici 20Mbps na odbavení dotazu a dá těch 10MB (cca 80Mb) na jeden dotaz, mám ten tok na 0,4s a na saturování 10Gbps linky stačí 10G/200M = 500 dotazů.
500x5kB dotaz = 2,5MB. Za sekundu to musím udělat 2.5x. To znamená, že na dotazy z toku 6.25MB/s ~ 50Mb/s takhle vyrobím DDoS 10Gb/s. To se opravdu vyplatí vyhodit úvodní handshake, že...<ironie>Ještě že 50mbps+ uplink nikdo nemá doma, dokonce ani ti s gigovou FTTH. </ironie>
-
Spojení TCP na příkladu SSH:
1) A:X -> B:22: Prosím o spojení na A:X
2) B:Y -> A:X: Nabízím komunikaci na portu Y
3) A:X -> B:Y: Ok, můžeme komunikovat
A v téhle chvíli máme obousměrný tunel A:X <> B:Y se zaručeným pořadím dat a zaručeným doručením, pokud není přerušená linka.Tohle myslíte naprosto vážně? Tedy ona je to v zásadě je to pravda, ale nerozumím tomu, proč tam zavádíte nějaké Y, když je stejně vždy 22.
A teď si představme, že se někdo rozhodne po UDP přenášet balíčky souborů na jednu UDP žádost:
AC:X->B:443: Pošli stránku ..., do potvrzení smí odejít 10MB
B:Y->C:X: Stream až 10MBJak konkrétně to hodláte v případě QUICu provést? Pokud ten falešný request chcete poslat jako nový request, pořád budete muset být schopen nejdřív odpovědět na paket od serveru (poslaný na C), stejně jako u TCP. Pokud se pokoušíte navázat na dřívější komunikaci mezi C a B, musel byste přesvědčit B, že jste C (ve smyslu jejich předchozího spojení), což bude ještě těžší.
-
Petr M (neregistrovaný)
"Tohle myslíte naprosto vážně?"
Já ne, specifikace TCP to myslí vážně.TCP funguje tak, že server POSLOUCHÁ na nějakým portu, na který se navazuje spojení. V reakci na žádost vytvoří proces/vlákno, to si otevře nějaký jiný port, přes který jde obousměrná komunikace s klientem. V další komunikaci už ten port 22, 80, 443,... nefiguruje!!!
A to je na TCP hezký a elegantní, vlastní vlákno na serveru, který se stará o jednoho klienta na jednom portu a všechno je hezky izolovaný...
"Jak konkrétně to hodláte v případě QUICu provést?"
Naprosto normálně, pošlu GET s podvrženou adresou příjemce. Jedna z ambicí http3 je totiž odbourat úvodní handshake kvůli latenci a jedna zpráva pak stačí k tomu, aby začal přenos ještě před potvrzením (to se řeší za běhu). Viz obrázek v článku. TCP chce tři paktery, QUIC jeden a nijak se nezalamuje s ověřením, že příjemce existuje a ty data chce. Pokud bude rychlost a objem dat jako parametr, dáš maximum a je problém. A pokud zavedou psedoochranu jako podpis požadavku, tak taky nic nevyřeší, protože klient není na serveru registrovaný (jaká je pravděpodobnost, že server z TLD .fr zná obecnýho klienta z .cz?), stačí jakýkoliv klíč na podpis požadavku a je vymalováno...
I kdyby délka dat během potvrzování byla fixní třeba 100kB, furt ten attack zesílím z 5kB GET na 100kB odpověď a furt to je lepší, než použít obyčejný DNS Amplification.
-
TCP funguje tak, že server POSLOUCHÁ na nějakým portu, na který se navazuje spojení. V reakci na žádost vytvoří proces/vlákno, to si otevře nějaký jiný port, přes který jde obousměrná komunikace s klientem. V další komunikaci už ten port 22, 80, 443,... nefiguruje!!!
Prosím vás, buď si (opravdu) přečtěte RFC 791 nebo se třeba na nějaké takové TCP spojení podívejte tcpdumpem nebo wiresharkem, ať se můžeme začít bavit vážně. Pokud budete na tomto tvrzení i poté trvat, poprosil bych o konkrétní místo nebo citaci, kde se v RFC 791 (nebo jiném RFC týkajícím se TCP) něco takového píše.
Naprosto normálně, pošlu GET s podvrženou adresou příjemce. Jedna z ambicí http3 je totiž odbourat úvodní handshake kvůli latenci a jedna zpráva pak stačí k tomu, aby začal přenos ještě před potvrzením (to se řeší za běhu). Viz obrázek v článku. TCP chce tři paktery, QUIC jeden a nijak se nezalamuje s ověřením, že příjemce existuje a ty data chce.
A tady si, prosím, dostudujte aspoň základní popis fungování QUICu, např. z toho odkazu, který jsem sem dával před chvílí. Handshake tam samozřejmě je, ale místo dvou roundtripů (jeden na TCP, jeden na TLS) stačí jeden.
-
Petr M (neregistrovaný)
RFC791 řeší "internet protokol". TCP a UDP jsou v IP stacku o level výš. UDP je RFC768, TCP je RFC793.
Nastuduj si https://tools.ietf.org/html/rfc793 - podívej se na "figure 1", kde je jeho místo. Mezi IP a aplikací.
V odkazovaným dokumentu bych navíc doporučoval přečíst a pochopit, co se myslí v kapitole jako párem IP adresa: port pro klienta a server a proč se tam navíc píše o listeningu na well known portu...
-
Jedna věc je splést si číslo (mimochodem, už 20 minut před vaším příspěvkem jsem se sám opravil), naprosto nepochopi základy fungování je něco úplně jiného. Takže ještě jednou: kde přesně se podle vás píše, že SYNACK paket (stejně jako všechny další) používá (nebo i jen může použít) na straně serveru jiné číslo portu než to, na které klient poslal SYN (a na kterém server poslouchá)? Nebo si prostě pusťte tcpdump/wireshark a podívejte se, jak to vypadá.
-
??? (neregistrovaný)
"TCP funguje tak, že server POSLOUCHÁ na nějakým portu, na který se navazuje spojení. V reakci na žádost vytvoří proces/vlákno, to si otevře nějaký jiný port, přes který jde obousměrná komunikace s klientem. V další komunikaci už ten port 22, 80, 443,... nefiguruje!!!"
Myslim, ze si pletete pojmy socket a port. Nebyl byste prvni ani posledni.
-
hm23 (neregistrovaný)
To myslíte vážně, že v další komunikaci port, na kterém služba poslouchá, už nefiguruje? Server vždycky poslouchá (i pro "další komunikaci") na jenom portu a z něj taky ta komunikace odchází. Jak by pak asi mohl fungovat NAT třeba. Snad si to proboha neplete s nějakým related a established, které na firewallu slouží k tomu, aby se odpověď od serveru dostala přes firewall i druhým směrem ke klientovi, kde logicky dopředu (při konfiguraci) není znám destination port.
-
kraxna (neregistrovaný)
> Já ne, specifikace TCP to myslí vážně.
> TCP funguje tak, že server POSLOUCHÁ na nějakým portu, na který se navazuje spojení. V reakci na žádost vytvoří proces/vlákno, to si otevře nějaký jiný port, přes který jde obousměrná komunikace s klientem. V další komunikaci už ten port 22, 80, 443,... nefiguruje!!!Tohle si zaslouzi oznaceni prvni TCP konspiracni teorie :-D
Co naplat, ze se tak TCP nechova (port 22 ci jiny tam zustane), ale pokud si myslis, ze se v reakci na zadost vytvori proces ci vlakno, tak to asi mluvi za vse :-)
>Naprosto normálně, pošlu GET s podvrženou adresou příjemce. Jedna z ambicí http3 je totiž odbourat úvodní handshake kvůli latenci a jedna zpráva pak stačí k tomu, aby začal přenos ještě před potvrzením (to se řeší za běhu).
Pro zmenu QUIC konspiracni teorie a opet stejny vysledek. QUIC se tak nechova. Smyslem QUIC je snizeni latence - tzn. neco podobneho jako TCP handshake tam je, akorat je to navic k necemu.
V ramci toho handshaku si navic domluvim parametry TLS, takze v momente, kdy skonci, tak uz mam pouzitelny kanal. Misto toho, abych ted zacal delat novy handshake pro sifrovani.
-
Moc to nepobírám. Nepobíral jsem ani HTTP/2.0 ale respektuju, že tu je.
Myslím si, že by web bylo možné provozovat i na klasickém HTTP/1.1 s dobře fungujícím keep-alive + pipelining, a určitě si vystačíme s dvěma spojeníma maximálně. Nevím proč dnešní prohlížeče mají zejména s pipeliningem problém. Možná že kdyby se nějakým způsobem HTTP protokol uzpůsobil tak aby pipelining byl jednodušší, ale ... nemyslím si, že je to potřeba.
Co je opravdu problém je narůstající objem webu a to, že web se skládá z obsahu jdoucí z mnoho serverů, tady myslím zejména reklamy. Samotný web, pokud je navíc dobře postaven, tedy spíš jako aplikace, jde velice rychle i po Http/1.1
HTTP/2.0 jako snaha implementovat TCP na TCP je faḱt zrůdnost. HTTP/3.0 jako implementovat vlastní TCP nad UDP a věřit si, že ho uděláme lépe, než TCP samotné, to už hraničí s bláznostvím.
-
+1
Pamatuji ještě web s 56 kbps modemy. Dnes máme linky o několik řádů rychlejší a nestačí to? Pořád čteme textové články, stahujeme obrázky... Textů je pořád zhruba stejně (nebo spíš méně kvůli snižování gramotnosti průměrného uživatele), obrázky jsou větší, to je pravda + přibylo video. Díky AJAXu by nároky měly být spíš menší (nemusí se po síti posílat celá stránka -- pošlou jsem jen změny).
Problém je spíš v tom, že dneska běžný web stahuje kdejaké hnoje klidně i z desítek domén/serverů + někde posílá zpátky i pohyb kurzoru myši, časy stisku kláves při psaní a další šmírovací data. Uživatel z toho nic nemá, nebo mu to přímo škodí.
U toho videa se jednou naváže spojení a pak se tahají desítky nebo stovky megabajtů -- oproti tomu je ta režie zanedbatelná. Nemluvě o tom, že většina těch videí jsou jen spamy a zbytečný obsah.
To už by mi přišlo smysluplnější mít nějaký decentralizovaný/p2p protokol pro distribuci statického obsahu (skripty, css, ikony, písma...). Web by se odkazoval na URL, ale uváděl by i hash obsahu a podle něj by se prohlížeč mohl podívat do své mezipaměti, potom na lokální distribuční server a až třetí možnost by byla stažení z daného URL.
-
j (neregistrovaný)
Ve skutecnosti si vpohode vystacis s http 1.0 ... jediny co pridava 1.1 je hlavicka s domenou, kterou nepotrebujes, pokud ma kazda domena svoji IP. Je to jednoduchy na implementaci, na strane serveru ti staci par kB, a na strane klienta telnet. A pokud mas kompletni ipv6 stack vcetne ipsec (coz jako povina soucast vypadlo pry prave kvuli IoT vecem, ktery na to nemaj parametry), tak muses vesele i sifrovat, a porad ti staci ten telnet.
Dtto email, posilas text a textovy parametry. Easy. Zakladni komunikaci napises za hodinu a bude to fungovat. A opet, pokud pod tim mas ipstack muzes to posilat pres ipsec. Ale aplikaci jako takovou to vubec nemusi zajimat, protoze to neni jeji starost.
Nepotrebujes zady stovky MB silenych a deravych knihoven na sileny, naprosto zbytecny a nepouzitelny protokoly.
Parada je, ze video pres http je ne jeden, ale 100 kroku zpet, protoze i ten prdlej flash umel RTMP. A fungovalo to paradne, stream se dynamicky a zcela bez vypadku prizpusoboval kvalite spojeni.
-
Když to moc nepobíráte, proč děláte závěry? Případů užití, kde by se nám HTTP/2 fakt, ale fakt hodilo, jenže jsme to pořád museli mlátit na HTTP/1 jsem jen za poslední dva roky zaznamenal tak pět. Multiplexing prováděný HTTP/2 funguje třeba na weby s mnoha obrázky (implementoval a optimalizoval jste někdy nějakou video-on-demand site? on ale stačí i obyčejný e-shop) skvěle a je to podstatný pokrok.
Jako samozřejmě, budete-li si přes HTTP číst textové dokumenty, můžete to dělat třeba přes Telnet. Jenže doba je jinde a spektrum služeb je daleko daleko širší než kdy dřív a bude ještě více. Myslet si o tom můžete co chcete. Stejně, jako o parním stroji, který dozajista máte ve svém automobilu.
Předposlední věta je už vůbec úlet, který celkem odpovídá první větě vašeho příspěvku. Ostatně poslední není o moc lepší: ano, představte si, že pokrok nastane, když se někdo rozhodne, že stávající technologii překoná něčím lepším a povede se mu to. To je, že?
-
Petr M (neregistrovaný)
Mě by s spíš líbilo udělat, když už jsou problémy s domlouváním šifrování, standardní TCP-Sec pro všechny. Chování jako TCP, jenom vyžaduje před spojením na obou stranách klíče. Pak je to taky jenom o výměně tří zpráv a jede se. Navíc v těch zprávách mít klíč a jeho typ a by default šifrovat.
-
Anonym (neregistrovaný)
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.
-
j (neregistrovaný)
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).
-
Anonym (neregistrovaný)
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.
-
j (neregistrovaný)
A co ty dutohlave nechapes na tommhle obrazku? https://i.iinfo.cz/images/607/quic.png
-
Tak to zkusím ještě jednou. Obrázek ukazuje situaci ("0-RTT"), kdy už někdy předtím (ne příliš dlouho) mezi klientem a serverem proběhla DH výměna a oba si ještě pamatují dohodnutý kontext. Takže není potřeba nový handshake a je možné rovnou použít ten původní (útočník to ale provést nemůže, protože nemá potřebné informace).
Pokud je to první spojení nebo už od předchozího uběhla příliš dlouhá doba, takže si aspoň jedna ze stran původní kontext nepamatuje, je potřeba provést handshake. I v tom případě ale ušetříme čas, protože stačí jeden handshake místo dvou (TCP a TLS).
-
V reálné praxi se (HTTP) keepalive spojení moc dlouho neudržují. Na načtení obrázků, stylů nebo skriptů v rámci stránky to stačí (pokud dotazy vůbec jsou v jednom spojení), na to, abych si přečetl stránku a vyžádal si další, obvykle ne. Stejně tak když budu procházet různé weby a načítat pořád dokola soubory ze stejného reklamního systému (ano, jistě, je to zlo, fuj, fuj, ale takhle dnes web prostě funguje).
-
SB (neregistrovaný)
„V reálné praxi se (HTTP) keepalive spojení moc dlouho neudržují.“
A kdyby se udržovaly, tak by to splňovalo požadované chování QUICu?
„...abych si přečetl stránku a vyžádal si další...“
Tak pozor, držení údajů o předchozím spojení jsem si představoval v řádech sekund, nanejvýš desítek sekund, aby se nasypala stránka. Jestli budu další stránku načítat za 10 minut, až si přečtu tu předchozí, pak je mi úplně u pr-dele, že to bude trvat o 200 ms déle!!! Prodlužování platnosti údajů o spojení snižuje bezpečnost (i když zde nechci rozebírat, jak moc).
-
A kdyby se udržovaly, tak by to splňovalo požadované chování QUICu?
Jen částečně. Nebude sice potřeba nový handshake (přesněji dva) v rámci téhož spojení, ale nacpat všechno do jednoho spojení není prakticé ani efektivní. Navíc udržovat navázané TCP spojení a nechat si položku v cache security kontextů je docela rozdíl.
Jestli budu další stránku načítat za 10 minut, až si přečtu tu předchozí, pak je mi úplně u pr-dele, že to bude trvat o 200 ms déle!!!
Vám možná ano, ale to neznamená, že to nebude vadit nikomu. Tím spíš, že z těch 200 ms může snadno vznknout třeba sekunda, kvůli návazným dotazům, z nichž některé mohou vést na další servery.
Prodlužování platnosti údajů o spojení snižuje bezpečnost (i když zde nechci rozebírat, jak moc).
Klidně rozebírejte. Podle mých zkušeností je lifetime dojednaných klíčů v řádu hodiny nebo dvou naprosto běžný i v aplikacích, kde jde o výrazně víc než u typického HTTPS spojení.
-
Filip JirsákStříbrný podporovatel
SB: Řekl bych, že není povinností každého obrázku zobrazovat kompletně celý vesmír. Myslím, že je oprávněn existovat i obrázek ukazující navázání QUIC spojení v jednom ze tří možných stavů komunikace. Vedle něj pak mohou existovat obrázky, které ukazují ty další dva případy – když kontext nezná klient a když ho nezná server. Pokud chcete vidět všechny tři případy vedle sebe, také na to existuje obrázek, najdete ho třeba zde: https://blog.acolyer.org/2017/10/26/the-quic-transport-protocol-design-and-internet-scale-deployment/
-
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ý podporovatel
Můž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.
-
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ě.
-
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.
-
Matas (neregistrovaný)
VxLAN a SDN bych sem vubec netahal, protoze to se typicky pouziva na propojeni datacenter nebo v ramci datacenter a prakticky vyhradne na pronajatych neverejnych okruzich.
AD porty 80 a 443, zajimalo by mne jak si nekdo predstavuje reseni bezpecnosti - rozumneno inspekci obsahu - nad protokolem jako je QUIC ktery je nad bezstavovym protokolem jako je UDP.
Ze budou utoky i na tento prokolol resp. jeho UDP porty se jasne, secure session init v QUIC tomu nezbrani.
Za mne to dopadne tak ze ze startu na firewallu zariznu UDP port 443 (popr. jakykoliv jiny na kterem bude detekovan QUIC protokol) a prinutim prohlizec udelat fallback na TCP ktery jsem schopen ridit a delat nad nim nejakou bezpecnost... -
Filip JirsákStříbrný podporovatel
AD porty 80 a 443, zajimalo by mne jak si nekdo predstavuje reseni bezpecnosti - rozumneno inspekci obsahu - nad protokolem jako je QUIC ktery je nad bezstavovym protokolem jako je UDP.
Úplně jednoduše – stačí místo inspekce obsahu řešit bezpečnost. Nebezpečnému obsahu je totiž úplně jedno, jakým transportním kanálem se do počítače dostal, zda to bylo přes HTTPS, souborem na flash disku nebo e-mailem jako zaheslovaná příloha. Takže pokud chcete řešit bezpečnost, musíte to stejně řešit až v okamžiku, když se to vybalí z transportního kanálu a je to připravené k použití. -
Filip JirsákStříbrný podporovatel
Nebezpečnému obsahu je totiž úplně jedno, jakým transportním kanálem se do počítače dostal, zda to bylo přes HTTPS, souborem na flash disku nebo e-mailem jako zaheslovaná příloha. Ale to už jsem psal, že? A transportní kanály budou vždy směřovat k tomu, aby se do nich nikdo z venčí nedostal, ono to mimo jiné právě zvyšuje bezpečnost. Takže pokoušet se řešit bezpečnost tím, že se budete vloupávat do transportní vrstvy, je krátkozraké – všichni se budou snažit, aby to nešlo, a každý způsob, který můžete využít vy „v zájmu bezpečnosti“ může využít i útočník. Takže je v zájmu bezpečnosti, abyste se do transportního kanálu vloupat nemohl.
-
ehmmm (neregistrovaný)
Tak asi tady budu za kacire, ale ja je trochu chapu.
Pred hodne lety jsem programoval nejake embedded zarizeni, se kterym se melo komunikovat po ethernetu, a take jsem prisel na to, ze je pro me vyhodnejsi si vymyslet vlastni protokol nad UDP, kde si muzu vyresit timeouty, potvrzovani a opakovani po svem a nemusim to nechavat na TCP. Takze jestli je pro nekoho vyhodnejsi UDP, tak at si ho pouziva.
Ale jinak souhlas se spoustou diskuteru, ze dnesni svet www je na hony vzdalen puvodni jednoduche myslence. Tady uz to nejake UDP nevytrhne.
-
Anonym (neregistrovaný)
Možná, pro lepší pochopení jak QUIC funguje je vhodné shlédnout video https://youtu.be/wCa5nylzJCo , mají tam to docela dobře vysvětleno.
-
madloki (neregistrovaný)
Specifika UDP z pohledu sitovych prvku a firewallu:
- restransmisi resi klient
- nejde o kriticka data, mohou se ztracet, navrzene to bylo pro realtime video a audio (kde se ztracena data neopakuji)
- nelze pouzit a obvykle se nepouziva plna packet size
- sitove prvky musi u ACL sloziteji nez u stavoveho UDP resit, zda pustit, ci ne. V dusledku toho je UDP provoz zatezuje
podstatne vice, nez provoz TCP
- transparentni proxy a aplikacni proxy jdou totalne k certu, bud nebudou schopny fungovat, nebo se vykonove utavi
- u 95% pripadu napadeni PC je vstupni bod http/https provozChapu, ze kdyz je 85% provozu na internetu http a https, muze 3% provozu http/https pomoci UDP profitovat co do rychlosti, ale co se stane, az se tim svinstvem opre o servery tech 85% provozu ?
Kvuli snizeni vypocetni zateze na distribuovane klienty s cim dal vykonnejsimi procesory zabijeme sitove prvky po ceste ?
Sifrovani vseho, cloudove a CDN zdrojove IP a zprisnena pravidla pro certifikaty znamenaji, ze se tento obsah mezi serverem a klientem presouva bez moznosti in-the-middle kontroly. Pro firemni nasazeni zabijak. Druhy zabijak jsou plany na sifrovani uz uvodni vymeny certifikatu (na gateway uz neuvidite ani ten certifikat), totez se chysta pro SNI, a zbyva uz jen nahradit spojovanou sluzbu sluzbou nespojovanou pro majoritni internetovou sluzbu http/https. Pak uz bude bezpecnost kazde workstation z pohledu jinych nez na workstation instalovanych prostredku uplne neriditelna. Pridejte IPv6 a eliminaci NAT, a to, ze vetsina firemnich workstation jsou prenosna zarizeni (tudiz bezpecnost a udrzba jejich software vybaveni je z pohledu centralni spravy problematicka), a mate drasticke zhorseni bezpecnostni situace pro firmy.
Zapomnel jsem jeste na win10, ktere se aktualizuji kdy chteji, a ze zavirovaneho MS Store si instaluji, co chteji, bez ohledu na MS AD a jeho nastaveni.
-
restransmisi resi klient
To je na konkrétním protokolu, jak bude navržen. Jinak se samozřejmě nabízí otázka, co přesně v té vaší větě znamená "klient".
sitove prvky musi u ACL sloziteji nez u stavoveho UDP resit, zda pustit, ci ne. V dusledku toho je UDP provoz zatezuje podstatne vice, nez provoz TCP
A nebo také ne. Když se třeba podíváte na to, jak je implementovaný linuxový connection tracking, zjistíte, že UDP ho bude zatěžovat méně, protože se toho nekontroluje tolik.
transparentni proxy a aplikacni proxy jdou totalne k certu
Nemíním pro ně uronit jedinou slzičku. :-)
-
Při vší úctě, kolik zde diskutujících se profesionálně zabývá vývojem aplikací pro web? Podle toho, co čtu, bych tipoval, že tak slabá pětina. Teoretik ve dle teoretika. Na HTTP/2 čekali weboví vývojáři (v některých případech dost zoufale) v některých ohledech deset let.
QUIC dořešuje ještě některé další vyskytující se problémy a dobře tak. Oni totiž ti frontendisté píší převážně pro věžné koncové uživatele, nikoliv sysadminy. A tak se musí obtěžovat řešit jejich potřeby. Totéž platí pro Google.
-
HTTP/2 v podstatě nic neřeší. V rámci jednoho spojení se posílají fragmenty dat nutných k sestavení stránky. Fragmeny samy o sobě nafukují provoz. Stejnou službu udělá HTTP/1.1 pipelining s tím, že snižuje fragmentaci. Problém je, že na pipeliningu se prostě svět nebyl schopen dohodnout a tak není spolehlivý.
HTTP/2 v zásadě řeší jen pomalost serverů, tedy dlouhou odezvu serveru na požadavek. Důvodem je to, že se serverové komponenty píšou v pomalých jazycích. A tak zatímco se čeká na ruby nebo python nebo nedejbože node.js až se uráčí vygenerovat odpověď, může server po HTTP/2 poslat zatím statická data, který klient taky chce.
Pipelining by přitom bohatě stačil a zjednodušil by implementaci obou konců protokolu. Pokud se přidá možnost předbíhání odpovědí, je to už skoro jako HTTP/2 s tím, že je to mnohem méně komplikované. Používám to třeba u RPC kdy se na serveru musí vyřídit v rámci spojení tisíce požadavků. Každá message má ID a každá odpověď má ID. Implementace je primitivní, linka jede jak ďábel, žádné prodlevy z pingu na ní nejsou znát.
-
Jste si jist, že jste pochopil, co vlastně HTTP/2 dělá? Ano, řeší "jen" pomalost serverů. Jenže kdyby rostly na stromech ryby, nemusely by být rybníky nemluvě o tom, že často je velmi výhodné říci, že uživatel něco dostane dříve, něž něco jiného případně nečekat, až se na to browser stejně zeptá poté, co naparsuje všechno, co je potřeba a další a další requesty s pánbůhví jakým roundtripem dorazí znovu na server a rovnou mu to poslat. Váš kdybyzmus je fascinující, ale tohle je problém řešící praxi.
A mimochodem, v okamžiku, kdy do pipeliningu přidáte "předbíhání odpovědí", dostanete v podstatě multiplexing, který provádí HTTP/2. Čili jen víceméně tvrdíte, že HTTP/2 je špatné, protože vy jste to přece už vynalezl sám. (Přeháním, samozřejmě nevynalezl, ale jde o princip.)
Takže teoretizujete hezky, ale od moderního vývoje pro webové prohlížeče jste poněkud odtržen. Dnešní transakce mezi internetovým prohlížečem a serverem probíhají už značně jinak a hlavně komplexněji, než v době, kdy bylo HTTP/1 navrženo čemuž HTTP/1 přestává stačit. Ostatně až tolik se od sebe stejně neliší.
-
https/2 předně vytváří rámce a streamy, který zbytečně nafukují přenos a zesložiťují zpracování dat jdoucí ze spojení. Předbíhání odpovědí není https/2 to bych zase já mohl mít podezření, že netušíte, jak funguje. Hlavně rozsekání na rámce dost pravděpodobně narušuje rozsekání na packety a proto celkem logicky se hledá cesta formou UDP, což je ale hledání rovnáku na vytvořený ohýbák.
Pipelining umožňuje nasypat všechny requesty hezky za sebou bez čekání na odpověď, proto vaše námitka s roundtripem neplatí
-
kraxna (neregistrovaný)
> https/2 předně vytváří rámce a streamy, který zbytečně nafukují přenos
Nafukuji prenos 9 (pokud me pamet neklame) byty na frame? :-)
> Předbíhání odpovědí není https/2
To je pravda, protoze HTTP/2 je kompletni multiplexing vc. moznosti definovani vztahu a priorit mezi streamy a moznosti server push :-) Tedy reseni, ktere je technicky mnohem silnejsi, nez pouhe predbihani odpovedi :-)
> Hlavně rozsekání na rámce dost pravděpodobně narušuje rozsekání na packety a proto celkem logicky se hledá cesta formou UDP
Nikoliv, s tim neni problem. Problemem je zbytecna latence a HOL blocking dany TCP kanalem.
Jinak receno, TCP dela veci, ktere nejsou potreba, ani nejsou uzitecne - diky multiplexingu neni nutne, abych data dostaval striktne sekvencne, ani neni nutne mit handshake (TCP) a potom dalsi handshake (TLS).Jinak receno, transportni vrstva, ktera ma znalost toho, co prenasi a je optimalizovana pro tento typ prenosu, je efektivnejsi nez obecna transportni vrstva pro vse. To je cely duvod za HTTP/3 / QUIC.
> Pipelining umožňuje nasypat všechny requesty hezky za sebou bez čekání na odpověď, proto vaše námitka s roundtripem neplatí
Jasne a umi mi taky poslat to, co budu potrebovat nez si o to reknu (server push)? Ne -> round trip.
Umi mi posilat vice requestu soucasne (krasny priklad - 2 vetsi obrazky na strance - s HTTP/2 mi je server muze posilat soucasne - coz je velmi vyhodne, protoze pravdepodobne pro jejich progresivni zobrazeni je nepotrebuji cele). Opet ne.
> ale hledání rovnáku na vytvořený ohýbák.
Hledani rovnaku na vytvoreny ohejbak spis popisuje snahy naroubovat staricky HTTP protokol na potreby moderniho webu. A z tech rovnaku na ohejbaky vzniklo pozehnane - chunked encoding, long polling, css sprites, nutnost kombinace JS/CSS do jednoho souboru, ... Jeden workaround vedle druheho, ktere HTTP/2 nepotrebuje a pipelining je neresi.
-
Jen chci podtrhnout, ze QUIC je jiz bezne pouzivan a nemam s nim (doposud) zadne problemy.
Moje zkusenost je spise pozitivni. Pouzivam Untangle, ktery ma sice v defaultu nastaveno "Block QUIC (UDP port 443)", ale po povoleni QUIC jsem vypozoroval jsem, ze videa skutecne bezi znatelne rychleji a opravdu se i rychleji spousti nebo pretaci.
Ve QUIC spojenich vidim pouze 443 porty (reakce na definici internetu vyse 80/443), v protochainech vidim napr.
/UDP/QUIC/YOUTUBE
/UDP/QUIC/GOOGVIDO
/UDP/QUIC/GOOGAPIS
/UDP/QUIC/GOOGLE
tedy DPI funguje a dokonce jsem schopny nastavovat QOS priority a skrtit stejne jako TCP/HTTP.Nejsem takovy expert jako nekteri diskutujici vyse, jen chci rict, ze se asi neni ceho bat a ze se opravdu nejedna o nic noveho.
-
Matas (neregistrovaný)
Tim DPI bych si nebyl moc jisty. Zavisi na tom na zaklade ceho ten firewall dela klasifikaci. Udaje ktere uvadi date dohromady i bez toho ze bude koukat dovnitr paketu nebo delat full DPI...
UDP dle protokol c. 17, QUIC dle portu 443(?). Youtube atd. pres rrDNS nebo WHOIS dotaz.... coz jsou vsechno udaje ktere zjistim uz na zaklade informaci v zahlavi paketu a to sem se dovnitr ani nepodival... -
pajac (neregistrovaný)
Fundamentalni problem QUICu je, ktery sebedumyslnejsi implementace nevyresi, ze funguje az na aplikacni vrstve.
Pro vsechna zarizeni, pres ktera jeho data potecou, to budou jen a pouze UDP pakety se vsemi slabostmi a omezenimi tohoto internetoveho protokolu. K tomu neni potreba uz co dodavat.. -
Filip JirsákStříbrný podporovatel
Ona taky všechna ta zařízení, přes která ta data tečou, nemají dělat nic jiného, než je předat dál. Do obsahu těch paktů jim nic není (navíc je šifrovaný).
-
kraxna (neregistrovaný)
To je asi jako rict, ze fundamentalni problem HTTP 1.1 je to, ze pro vsechny zarizeni na cest jsou to jenom IP pakety se vsemi slabostmi a omezenimi :-)
Data jsou sifrovana, binarni, necitelna jak v H1 (pokud nekdo neni prasatko), H2, tak v QUIC / HTTP3.
Neni v tom zadny rozdil a hlavne tak je to naprosto v poradku.
-
Anonym (neregistrovaný)
Poslechněte si přednášku na BlackHat2016, UDP je vlastně nejlepší volba. Důvod proč aplikační úroveň je rychlost a jednoduchost nasazení. Na síťové vrstvě nasazujeme IPv6 dekádu (za chvíli dvě), plná závislost na mrtě výrobců, kolik jich vlastně existuje a je jakkoliv ochotno podporovat legacy zařízení. Na relační vrstvě jste závislý na operačním systému, a záleží tedy na výrobci operačního systému, jak se mu bude chtít nebo také jestli vůbec ještě existuje. Tak relativně nejjednodušší implementace je na aplikační úrovni. Je to čistě ve vašich rukou. "Blbé" UDP staré 40 let zvládne jakékoliv zařízení. Jak říkají v přednášce, odpor k této implementaci je spíše ze zcela jiného filozofického přístupu. Zcela nové a neotřelé řešení. Teď jen záleží, jak se s tím poperem. Co vidím jako zásadní úskalí je složitější inspekce QUIC. Zvláště, pokud se potřebuji dívat, co se mezi klientem a serverem přenáší.
-
S většinou souhlasím, jen to, že odpor je způsoben jinou filosofií a neotřelým přístupem, mi připadá podobně zavádějící, jako když každý, kdo je obviněn z nekalých praktik, prohlásí "V Čechách se holt neodpouští úspěch." IMHO podvědomý odpor odborné veřejnosti pramení spíš z toho, že přejdeme-li v masovém měřítku na řešení typu QUIC, dáváme tím najevo, že jsme rezignovali na snahu neutěšený stav síťové infrastruktury řešit a místo toho problém obejdeme. To aspoň vadí mně (plus ta neprůhlednost, o které jsem se už zmiňovala o které píšete i vy). Chápu ovšem, že většina lidí potřebuje fungovat v rámci Internetu, který tu máme, ne snít o tom, jaký by mohl (měl) být.
-
kraxna (neregistrovaný)
> dáváme tím najevo, že jsme rezignovali na snahu neutěšený stav síťové infrastruktury řešit a místo toho problém obejdeme
Tady by se hodil nejaky link na clanek o adopci IPv6 :-D
Ale tolik stranou, v podstate souhlasim, ale na druhou stranu rici si, ze nejdulezitejsi / nejpouzivanejsi aplikacni protokol, potrebuje (vyuzije) moznosti specialniho transportniho protokolu, ktery je optimalizovany pro jeho potreby, mi neprijde nic divneho.
-
Pro mne třeba nejzajímavější, co jsem si odnesl z té prezentace, na kterou jsem dával odkaz ve svém prvním příspěvku, bylo zjištění, že po 35 letech práce na TCP a vymýšlení sofistikovanějších algoritmů pro congestion control a loss recovery lze dosáhnout lepšího výsledku, když celou komunikaci schovám do UDP a flow control si udělám (end to end) po svém. (Byť samozřejmě přiznávají, že ve skutečnosti většinou používají techniky známé z TCP.) To není moc povzbudivé a IMHO je to zřetelný signál, že s těmi "chytrými" krabičkami po cestě je něco zásadně v nepořádku.
-
kraxna (neregistrovaný)
Popravde, dovolim si nesouhlasit.
Zasadni problem TCP je to, ze si musi domyslet veci, protoze pracuje na ciste transportni vrstve, tedy bez znalosti aplikacni vrstvy, navic jeho urceni je obecne. QUIC ma obrovskou vyhodu, ze neni obecnym protokolem, ale prave protokolem resicim konkretni ulohu pro konkretni aplikacni vrstvu.
Prijde mi to podobna situace, jako kdyz si nechas udelat kuchyn na miru vs koupis skladacku v IKEA. Ta namiru vyuzije kazdy cm prostoru, ktery je k dispozici, tak, jak ty chces / potrebujes. Skladacka jako obecne reseni to z principu udelat nemuze.
-
Matas (neregistrovaný)
Ano, souhlas, pokud se potrebujete podivat co se prenasi mate problem. A v dnesni dobe je pomerne bezne ze kontroluje obsah prenaseny pres HTTPS, zejmena pokud se bavime o korporatnim prostredi. Co se nepodari zkontrolovat na rozhrani site, musi zvladnout ochrana na endpointu.... (o potrebe kontroly ve vsech vrstvach sem psal jiz vyse).
Osobne chapu pohnutky autoru QUICu, jedna z veci ktere mne na nem vadi je ze implementuje/supluje handshake do vrstvy kde nema co delat a trochu tim dela bordel v OSI modelu. Proc se misto cpani hanshake do aplikacni vrstvy nepokusili pouzit treba DTLS se mi nepodarilo rozumne vycist...
ČLÁNKY DO MAILU
