Vlákno názorů k článku Firefox s podporou QUIC a HTTP/3, KDE umožní vypnout offline aktualizace od LD - K tomu quic/http3, nepodařilo se mi vysledovat čím...
-
to je standardní vlastnost UDP. UDP nemá žádnou kontrolu toku ani zahlcení. QUIC pošle jak moc dat uzná za vhodné a jako správný agresivní protokol se pokusí zaslat jak jen moc to jde. Tím se staruje nejen linka, ale i buffery, které nejsou nekonečné a jakmile dojdou, tak se provoz zahazuje. Většina toho zahazovaného provozu je QUIC, ale samozřejmě se stejně tak zahazují i pakety TCP spojení a třeba zmíněného DNS provozu. Linuku saturovanou na 100% o což se snaží QUIC nikdy nechcete a podle mě nebude trvat dlouho než se toto svinstvo začne filtrovat na firewalech protože síťe nejsou určené jen na bordel z youtube, ale i na přenos jiných dat a toto agresivní chování sice nějak ustojí samo sebe, ale ostatní často neustojí ho.
Toto chování lze popsat i matematickými rovnicemi, ze kterých jde odvodit různé zajímavé horní a dolní hranice pro různé vlastnosti. Pěkný pohled na tuto problematiku je v knize https://www.albatrosmedia.cz/tituly/15757052/pocitacove-site/ Tato knižka už dnes existuje v novějšívm vydání, které není přeložené do češtiny. Ty prachy za co to prodávájí, bych už za ni dneska nedal, ale půjčená z knihovny může být fajn i dnes. Knížka popisuje sítě víc vědecky než prakticky. Matně si pamatuju že tam není zmíněná žádná konfigurace jakéhokoliv síťového prvku. Po přečtení si ale člověk uvědomuje sposutu faktorů, které ovlivňují různé vlastnosti provozu a nejsou na první pohled (ani pro některé zkušené síťaře) zřejmé. On ten vědecký pohledu taky není úplně k zahození.
-
otazkou je zdali ten protokol neni urceny hlavne pro komunikaci gRPC vramci datacentra kde se predejde zbytecnemu zpozdeni u handshaku a vyuzije se sily UDP. Tahat to internetem by potrebovalo dobre nastavene QoS na paterenich sitich. TCP bohuzel je velice neefektivni pri startu a nebo kdyz dojde k naplneni bufferu a google se tenhle problem rozhodl resit, viz napriklad https://en.wikipedia.org/wiki/TCP_tuning nebo https://en.wikipedia.org/wiki/TCP_congestion_control . TCP je v datacentrech s velmi spolehlivou optickou siti zbytecne. Overovaci mechanismy zdali paket dosel muzou byt jednodussi a uci se implementovat v ramci projektu napriklad i na bc studiu VUT FIT.
21. 4. 2021, 03:45 editováno autorem komentáře
-
J ouda (neregistrovaný)
Ono QUIC má specifikaci dobrou, ďábel je v detailech. Konkrétně v agresivnosti congestion control algoritmu, zvlášť pokud se server nedrží návrhu.
Konkrétně to co píšete spolehlivě dokázaly (na běžné i rychlejší vesnické wifině) dva klienti na youtube, důvodem byly obrovské batche které místo pacingu google posílal najednou - efektivně tím vyřadil jakýkoli další provoz (několik procent packet loss protože provider nemá na každého klienta megové buffery), za což si u mě doma zasloužil 443/udp do REJECTu.
Přitom pacing norma explicitně zmiňuje, ale holt don't be evil, že.19. 4. 2021, 22:34 editováno autorem komentáře
