Vlákno názorů k článku HTTP/3 nebude postavené na TCP, základem bude QUIC používající UDP od singerko - no ak sa to bude dat v prehliadaci...
-
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ý podporovatelPokud 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.
