Byla vydána nová major verze 28.0 programovacího jazyka Erlang (Wikipedie) a související platformy OTP (Open Telecom Platform, Wikipedie). Přehled novinek v příspěvku na blogu.
Český telekomunikační úřad zveřejnil Výroční zprávu za rok 2024 (pdf), kde shrnuje své aktivity v loňském roce a přináší i základní popis situace na trhu. Celkový objem přenesených mobilních dat za rok 2024 dosáhl dle odhadu hodnoty přibližně 1,73 tis. PB a jeho meziroční nárůst činí zhruba 30 %. Průměrná měsíční spotřeba dat na datovou SIM kartu odhadem dosáhla 12,5 GB – v předchozím roce šlo o 9,8 GB.
Z novinek představených na Google I/O 2025: Přehledy od AI (AI Overviews) se rozšiřují do dalších zemí. Užitečné, syntetizované přehledy od generativní AI jsou nově k dispozici i českým uživatelům Vyhledávače.
Šestice firem označovaných jako „MAMAAN“ – tedy Meta (Facebook, Instagram), Alphabet (Google), Microsoft, Apple, Amazon a Netflix – je zodpovědná za více než padesát procent světového internetového provozu. Dalšími velkými hráči jsou TikTok a Disney+. Společně tak zásadně určují podobu digitálního prostředí, spotřebitelského chování i budoucích trendů v oblasti technologií. I přesto, že se podíl těchto gigantů od roku 2023 o něco snížil, jejich dominantní postavení zvyšuje volání po regulaci.
Evropská komise (EK) navrhuje zavést plošný poplatek ve výši dvou eur (zhruba 50 Kč) za každý malý balík vstupující do Evropské unie. Poplatek se má týkat balíků v hodnotě do 150 eur (zhruba 3700 Kč), které v EU nepodléhají clu. V loňském roce bylo do EU doručeno kolem 4,6 miliardy takovýchto balíků. Poplatek má krýt náklady na kontroly rostoucího počtu zásilek levného zboží, které pochází především z Číny.
Dnes a zítra probíhá vývojářská konference Google I/O 2025. Sledovat lze na YouTube a na síti 𝕏 (#GoogleIO).
V Bostonu probíhá konference Red Hat Summit 2025. Vybrané přednášky lze sledovat na YouTube. Dění lze sledovat na síti 𝕏 (#RHSummit).
Společnost Red Hat oficiálně oznámila vydání Red Hat Enterprise Linuxu 10. Vedle nových vlastností přináší také aktualizaci ovladačů a předběžné ukázky budoucích technologií. Podrobnosti v poznámkách k vydání.
Tuto sobotu 24. května se koná historicky první komunitní den projektu Home Assistant. Zváni jsou všichni příznivci, nadšenci a uživatelé tohoto projektu. Pro účast je potřebná registrace. Odkazy na akce v Praze a v Bratislavě.
Troy Hunt představil Have I Been Pwned 2.0, tj. nový vylepšený web služby, kde si uživatelé mohou zkontrolovat, zda se jejich hesla a osobní údaje neobjevily v únicích dat a případně se nechat na další úniky upozorňovat.
Daniel Stenberg, autor nástroje curl, publikoval knihu s názvem HTTP/3 Explained (pdf, GitHub) věnovanou nadcházející major verzi protokolu HTTP aneb HTTP nad protokoly QUIC a UDP.
Tiskni
Sdílej:
28.11.2018 09:26
Grunt | skóre: 23
| blog: Expresivní zabručení
| Lanžhot
Velice solidní prdel bude až se to fakt implementujeRok 2012 už byl, pokud je mi známo…
někdo si přes to UDPčko dá tahat něco co nevleze do páč paketů (třeba gigový soubor)Videa na YouTube se podle vás vejdou do pár paketů, nebo aspoň ta delší, třeba hodinová, splňují vaše představy o velkém souboru? Nebo že byste vůbec netušil, o čem je řeč? Že by vás třeba nenapadlo, že řízení toku nemusí být implementováno jen v protokolu TCP, ale může být implementováno i v jiných protokolech?
29.11.2018 19:20
Grunt | skóre: 23
| blog: Expresivní zabručení
| Lanžhot
Rok 2012 už byl, pokud je mi známo…HTTP/2 bylo standardizováno v roce 2015. Holt to je tak když si svoje novinky tlačí do svého prohlížeče a pak je následně standardizuje.
Videa na YouTube se podle vás vejdou do pár paketů, nebo aspoň ta delší, třeba hodinová, splňují vaše představy o velkém souboru?To bych nesměl používat youtube-dl
Jenže jak se tak dívám i ten YouTube přehrávač má implementovaný jakýsi protokol, protože si nabuferuje pár paketů dle toho jak se přehrává, pak to potvrzuje, zas si něco málo nabufferuje, atd. To je ještě v pohodě (ostatně UDP se používalo na přehrávání videa už dávno před tím než vůbec nějaký YouTube vznikl).
Že by vás třeba nenapadlo, že řízení toku nemusí být implementováno jen v protokolu TCP, ale může být implementováno i v jiných protokolech?Jenže nemusí být implementováno rozumně. TCP používá velmi solidní algoritmus a zahození paketu v některé queue způsobí okamžitou reakci a uzpůsobení šířce pásma. Naopak u některých najmenovaných „chytrých“ protokolů to způsobí tak akorát požadavek o opakování rámce. Připočtu-li k tomu šoupání v různých distribuovaných hashovacích tabulkách občas z toho může být solidní DDoS na router o kterém vlastní klient ani nemusí vědět. Proto z toho nejsem nějak extra nadšený. U videa není UDP problém protože např. živý stream má určitou pevně danou šířku pásma a zahození jednoho a pár paketu v něm nehraje roli (pakety se už neopakují). Naopak u služeb jako je web je prostě doručení kompletního obsahu povinnou podmínkou pro zobrazení vlastního obsahu. Ale jak říkám, já jsem akorát rád že to naštěstí nemusím řešit, takže nech si implementuje a standardizuje Google co chce, jak uzná za vhodné.
Holt to je tak když si svoje novinky tlačí do svého prohlížeče a pak je následně standardizuje.Mně to připadá jako velmi dobrý způsob, protože se pak standardizuje něco, co už je v praxi odzkoušené, a ne něco, co si někdo od zeleného stolu vymyslel, že takhle by to možná mohlo fungovat, tak to standardizujeme a uvidíme, jak to dopadne.
To bych nesměl používat youtube-dlNejde o to, zda to používáte zrovna vy, ale o to, že už to používá docela dost lidí – a žádný DoS se nekoná.
Jenže nemusí být implementováno rozumně.To nemusí být implementováno ani TCP. Akorát že ani na straně serveru ani na straně klienta nemá nikdo zájem používat nerozumnou implementaci, která bude akorát zahlcovat linku zbytečnými pakety. Protože na obou stranách to znamená jen zvýšení nákladů na konektivitu nebo výkon, a žádný přínos.
U videa není UDP problém protože např. živý stream má určitou pevně danou šířku pásma a zahození jednoho a pár paketu v něm nehraje roli (pakety se už neopakují). Naopak u služeb jako je web je prostě doručení kompletního obsahu povinnou podmínkou pro zobrazení vlastního obsahu.Ale tady se bavíme o protokolu HTTP, který neumožňuje vynechávat pakety – v HTTP komunikaci musí dorazit všechny pakety, i u videa, kde už by třeba nebyly potřeba. Takže i když jde o video, doručuje se to pořád stejně, jako pro jakýkoli jiný web.
29.11.2018 19:47
Grunt | skóre: 23
| blog: Expresivní zabručení
| Lanžhot
Akorát že ani na straně serveru ani na straně klienta nemá nikdo zájem používat nerozumnou implementaci, která bude akorát zahlcovat linku zbytečnými pakety.Proto HTTP/2 implementuje něco jako Server Push. Znám pouze jednu ještě lepší věc, distribuovaný Server Push se kterým brzo určitě nějaký chytrák přijde. Ale jo. Třeba bude QUIC standardizovaný do HTTP/3 super nádherný.
29.11.2018 20:09
Grunt | skóre: 23
| blog: Expresivní zabručení
| Lanžhot
Server Push ovšem neslouží k zahlcování linky zbytečnými pakety.Jasně, slouží ke zrychlení zobrazování s tím že při natažení stránky začne tlačit data i bez requestů, jenže v podání UDP to bude mít jeden jediný výsledek: namísto uspořádaných streamů bude HTTP série burstů s tím jak klient bude procházet stránky a posílat requesty jeden za druhým. Za kolik procent celkového provozu na internetu je HTTP zodpověděno? Googlu myslím můžu pogratulovat už teď.
Nemáte s tím v životě problém, když u všeho očekáváte, že to bude implementované tím nejhorším možným způsobem, který bude všem jenom škodit?Že by zkušenost?
Server Push ovšem neslouží k zahlcování linky zbytečnými pakety.Jistě, protože data, která mi tlačí, i když už je mám v cache prohlížeče, jsou velice užitečná.
Preco by to robil? (ignorujuc fakt, ze prehliadac ma moznost taky stream odmietnut)To může, problém je v tom, že na pomalém mobilním připojení s latencí v řádu sekund je v době, kdy prohlížeč ten stream odmítne, už přinejlepším několik desítek kilobytů na cestě a prostě budou přeneseny - to bude trvat jednotky i desítky sekund a všechno to budou data, která prohlížeč zahodí. Odmítnout lze pouze to, co webserver server nepředal síťovému stacku pod sebou.
Inak toto je presne vec ktoru sa snazi HTTP/2 riesit - momentalne je bezna prax take skripty, css a ktovie co este vkladat inline priamo do html.Pletete si pojmy a dojmy. HTTP/2 nic takového neřeší, je to přenosový protokol pro (dneska občas i) HTML a pokud skripty a css inline vložíte přímo do HTML, bude to fungovat i na HTTP/1.1. (A naopak pokud to neuděláte, HTTP/2 vás nijak nevytrhne.)
HTTP/2 ti umoznuje ich poslat/vyziadat ako jednotlive subory, ktore vies normalne ulozit do cache bez toho aby si musel robit tonu spojeni na server a opakovat handshake na urovni TCP, SSL a HTTP.Tak tohle od doby, co existuje keep-alive, HTTP/1.1 umí taky.
To může, problém je v tom, že na pomalém mobilním připojení s latencí v řádu sekund je v době, kdy prohlížeč ten stream odmítne, už přinejlepším několik desítek kilobytů na cestě a prostě budou přeneseny - to bude trvat jednotky i desítky sekund a všechno to budou data, která prohlížeč zahodí. Odmítnout lze pouze to, co webserver server nepředal síťovému stacku pod sebou.Proč by něco takového server dělal? Vy si myslíte, že mají provozovatelé serverů výkon a kapacitu linky zadarmo, aby do ní chrlili data, která se pak zahodí? Pokud chce webserver řídit tok dat (jako že v případě spojení přes UDP musí), nemůže síťovému stacku předat velký objem dat a nechat to neřízeně odeslat.
Tak tohle od doby, co existuje keep-alive, HTTP/1.1 umí taky.Ne zcela. HTTP/1.1 odesílá odpovědi v takovém pořadí, v jakém přišly požadavky. Takže když přijde požadavek na stránku a za ním požadavky na styly, skripty, obrázky, aplikace nejprve kontaktuje databázi, získá příslušná data, vyrenderuje stránku a pak jí webserver začne odesílat. Teprve když jí odešle, začnou se posílat další soubory v pořadí, v jakém byly požadovány. Přitom ty už se mohly odesílat v té době, když se čekalo na databázi a vyrenderování stránky.
Aplikace může pomocí chunked encoding poslat začátek stránky, který odkazuje na všechny externí dokumenty, a až si server spočítá data, může poslat zbytek.Jak? HTTP/1 neumí prokládat odpovědi na jednotlivé requesty, a to ani jako chunky. Důvod je jednoduchý: v chunku není napsáno, ke kterému requestu patří.
Více spojení si samozřejmě můžete založit, ale hezky se to chovat nebude: čekáte na sestavení spojení, TCP nějakou dobu trvá, než dokonverguje k dobrému odhadu propustnosti linky atd.
2.12.2018 10:27
Grunt | skóre: 23
| blog: Expresivní zabručení
| Lanžhot
To může, problém je v tom, že na pomalém mobilním připojení s latencí v řádu sekund je v době, kdy prohlížeč ten stream odmítne, už přinejlepším několik desítek kilobytů na cestě a prostě budou přeneseny - to bude trvat jednotky i desítky sekund a všechno to budou data, která prohlížeč zahodí. Odmítnout lze pouze to, co webserver server nepředal síťovému stacku pod sebou.Stale sa ale bavime o teoretickej situacii kedy server posle nieco, co uz ma klient v cache, co je v zasade miskonfiguracia servera, pretoze normalne nema dovod to robit. Plus ma klient moznost nastavit mnozstvo in-flight dat (obdoba TCP window size), takze napriklad mobilny klient vie pre take pripady toto nastavit na minimum pre push objekty. (aby napriklad dostal len hlavicku na zaklade ktorej vie posudit, ci ma najnovsiu verziu v cache) Inak prakticky, pokial sa nebavime o uplnych extremoch je vo vacsine pripadov lepsie nejake data prijat a potencionalne zahodit nez stravit ten cas cakanim a robenim requestov. Je to proste dane tym, ze bezne pripojenie nie je vytazene na 100% stahovanim dat pre stranku, ale je vacsinu casu nevyuzite cakanim medzi requestmi. (ak si spravne spominam niekde od 5Mbps, pri mobilnom pripojeni uz niekde od 2Mbps tu linku zvycajne nevyuzivas na 100%)
Pletete si pojmy a dojmy. HTTP/2 nic takového neřeší, je to přenosový protokol pro (dneska občas i) HTML a pokud skripty a css inline vložíte přímo do HTML, bude to fungovat i na HTTP/1.1. (A naopak pokud to neuděláte, HTTP/2 vás nijak nevytrhne.)Pri HTTP/1.1 nevies robit multiplexing, cize v zasade vies stahovat viac objektov naraz len tak, ze otvoris viac spojeni. Ten pocet spojeni je prakticky limitovany niekde na urovni 5-7. (bavime sa o praktickom limite danom browserom a zariadeniami po ceste) Cize pri HTTP/1.1 sa toto riesi viacerymi sposobmi - napriklad mas zdroje na viacerych domenach (domain sharding), alebo zlepis vsetky javascripty/css/obrazky do jedneho suboru aby si znizil pocet nutnych requestov. Pri zdrojoch ktore predpokladas ze klient nutne potrebuje pri kazdom nacitani stranky sa to casto riesi tak, ze to CSS/javacsript vlozis priamo do stranky. Toto vsetko su workaroundy, ktore maju svoje nevyhody. Domain sharding vyzaduje viac domen a casto sa to riesi stylom *.cdn.example.com kde potom webstranka odkazuje na ${random}.cdn.example.com objekt, cize tym zabijas cache. Zlepovanie suborov dokopy potom znamena, ze pri zmene jedneho suboru musis nacitat cely objekt znova. Pri obrazkoch (tzv sprites) musis tiez potom v css riesit to, aby si pouzil spravny vyrez na spravny element. Vkladanie css/js inline samozrejme vylucuje cache uplne, pretoze tie data dostanes ci sa ti to paci, ci nie. HTTP/2 vsetky tieto workaroundy robi zbytocnymi, pretoze si mozes v ramci jedneho spojenia vyziadat omnoho viac objektov naraz a nie len to, vies si tiez nastavit a menit prioritu. (napriklad nacitas hlavicku obrazku s vysokou prioritou aby si vedel rozmery a vedel vypocitat rozlozenie stranky a data uz dotahas pomalsie lebo napriklad vies, ze obrazok bude mimo zaberu) Ale dolezite je, ze ti to opat umoznuje mat tam tie objekty jednotlivo a nechat browser rozhodnut co a kedy stahovat. Tiez ti to umoznuje ich ukladat jednotlivo v cache a nemusis robit CSS triky aby ti fungovali sprity. A sice je pravda, ze pokial bude autor webu stale pouzivat spominane HTTP/1.1 workaroundy, tak sa situacia zasadne nezlepsi, ale tiez je pravda, ze s HTTP/2 uz nebude nuteny ich pouzivat.
Tak tohle od doby, co existuje keep-alive, HTTP/1.1 umí taky.Multiplexing a keep-alive su dve rozne veci. Keep-alive ti umoznuje poslat cez jedno spojenie viac requestov, ale stale su limitovane tym, ze su seriovo za sebou, cize nevies riesit dynamicky prioritu. Tiez HTTP/2 vie robit kompresiu hlaviciek napriec requestmi, takze nie si nuteny posielat komplet hlavicky s kazdym jednym poziadavkom ako HTTP/1.1.
Stale sa ale bavime o teoretickej situacii kedy server posle nieco, co uz ma klient v cache, co je v zasade miskonfiguracia servera, pretoze normalne nema dovod to robit.
Server má křišťálovou kouli, která mu řekne, jestli prohlížeč má v cachi styly a ikonky z včerejší návštěvy?
Ten pocet spojeni je prakticky limitovany niekde na urovni 5-7. […] Cize pri HTTP/1.1 sa toto riesi viacerymi sposobmi - napriklad mas zdroje na viacerych domenach (domain sharding)
Krásně jste si popřel svých 5–7 spojení. To číslo není nějaká vlastnost protokolu, ale výchozí nastavení Firefoxu, aby uživatelé nezabili server, případně si sobě neucpali linku. Číslo poplatné době zanesení do zdrojového kódu.
Server má křišťálovou kouli, která mu řekne, jestli prohlížeč má v cachi styly a ikonky z včerejší návštěvy?Tak trochu - vola sa to ETag.
Krásně jste si popřel svých 5–7 spojení. To číslo není nějaká vlastnost protokolu, ale výchozí nastavení Firefoxu, aby uživatelé nezabili server, případně si sobě neucpali linku. Číslo poplatné době zanesení do zdrojového kódu.Za prve, nie je to len vlastnost firefoxu, vsetky ostatne prehliadace su limitovane podobne. Za druhe aj ked pouzijes domain sharding, tak mas limit niekde na urovni 30-40 spojeni. Pre porovnanie - relativne jednoduche abclinuxu.cz so zablokovanymi reklamami robi cca 50 requestov. Bezne je to aj okolo stovy requestov - a to aj napriek tomu ze sa pouzivaju spomenute triky na znizenie poctu suborov. Za tretie, keby si aj nastavil pocet spojeni na nejaky vyssi limit, tak prakticky su casto prehliadace limitovane na pomerne maly pocet spojeni zariadeniami po ceste. Prehliadace maju taky limit nie len preto, aby nerobili DDOS na server, ale aj preto aby nenarazili na tieto limity. A stale plati, ze keby si mal k dispozicii nekonecno spojeni tak by si stale platil dan v podobe TCP/SSL/HTTP handshake.
Tak trochu - vola sa to ETagKterý se vztahuje k tomu požadavku na stránku, nikoliv nutně k CSS a dalšímu bordelu okolo. A o tom, že to reálné aplikace budou vůbec nějak řešit, bych si dovolil s úspěchem pochybovat.
Který se vztahuje k tomu požadavku na stránku, nikoliv nutně k CSS a dalšímu bordelu okolo.Nie je ziadny technicky dovod preco by sa Etag nutne musel vztahovat len na konkretnu poziadavku a nie na extra subory.
A o tom, že to reálné aplikace budou vůbec nějak řešit, bych si dovolil s úspěchem pochybovat.Co som videl, tak sa to zvycajne riesi tak, ze server sa rozhoduje pushnut obsah na zaklade cookie ktora drzi poslednu verziu ktoru ma klient potencialne v cache a ak by mohol mat, tak sa push nekona. (cize worst case scenario je ze si to proste klient normalne vyziada) A stale si dovolim tvrdit, ze ked sa push pouziva na veci kde to ma zmysel, (css, js, ikony pre interface a podobne) tak aj keby si pomerne hlupo posielal vsetko bez ohladu na cache, tak vo vacsine pripadov bude cena za zahodenie tych dat pre koncoveho pouzivatela zanedbatelna. (v tom zmysle ze vyuzije o kusok viac prenosove pasmo, ktore by inak bolo nevyuzite) Obzvlast ak to berieme v tom svetle, ze dnes defacto ten push robi vela stranok aj tak - a sice vo forme js a css vlozenych priamo v html. Tam uz ani nemas ako povedat serveru aby ti to neposielal a napriek tomu to vela stranok robi, lebo je to zvycajne aj tak rychlejsie.
v tom zmysle ze vyuzije o kusok viac prenosove pasmo, ktore by inak bolo nevyuziteŘekl člověk, který zjevně nemá praktické zkušenosti s přenosovým pásmem mobilního internetu. A tím myslím mobilní internet, tj. zařízení se pohybuje a ne zrovna uprostřed Prahy, kde je LTE.
29.11.2018 19:35
Grunt | skóre: 23
| blog: Expresivní zabručení
| Lanžhot
Náhodné krabice filtrující provoz bohužel znemožňují další rozvoj protokolů.Řekl bych, že tady by se slušelo napsat další nekompatibilní rozvoj. Což už není chyba jenom těch krabic.
Podobně jsou ještě dnes běžné middleboxy, přes které neprojde Path MTU Discovery.Pokud se bavíme o IPv6, tak bych to viděl jako oddělený problém, PMTU discovery IMO není rozvoj, RFC je datováno cca půl roku po samotném IPv6 - v roce 1996. To bych spíš považoval za blbou implementaci než co jiného.
Řekl bych, že tady by se slušelo napsat další nekompatibilní rozvoj. Což už není chyba jenom těch krabic.Nie, HTTP protokol umoznuje pomerne jednoducho a kompatibilne upgradovat protokol na HTTP/2 aj bez SSL, ale v praxi cca 20% takych requestov zlyha, alebo antivir/firewall/whatever taky request zablokuje lebo neimplementuje HTTP spravne.
Řekl bych, že tady by se slušelo napsat další nekompatibilní rozvoj. Což už není chyba jenom těch krabic.Často byl protokol už na počátku navržen jako rozšiřitelný, takže je v jeho zprávách prostor na různé options, nové flagy apod. Specifikace přitom dost přesně říká, jak se má implementace chovat, pokud potká neznámý option/flag. Ovšem middleboxy toto naprosto běžně porušují a například všechny pakety, ve kterých je neznámý option, zahazují.
Pokud se bavíme o IPv6, tak bych to viděl jako oddělený problémNikoliv, měl jsem na mysli PMTU discovery pro IPv4. To je například standardní součást dnešních implementací TCP, ale některé middleboxy to kazí tím, že negenerují či nepropouštějí zprávy ICMP MTU Exceeded.
Často byl protokol už na počátku navržen jako rozšiřitelný, takže je v jeho zprávách prostor na různé options, nové flagy apod.Mám takový dojem, že EDNS zrovna nebyl tenhle případ - nebo jo?
Nikoliv, měl jsem na mysli PMTU discovery pro IPv4. To je například standardní součást dnešních implementací TCP, ale některé middleboxy to kazí tím, že negenerují či nepropouštějí zprávy ICMP MTU Exceeded.Ok, pravda je, že co všechno lidi považují za dobrý nápad při filtrování ICMP, to člověku hlava nebere. Nejenom u middleboxů.
30.11.2018 17:07
Grunt | skóre: 23
| blog: Expresivní zabručení
| Lanžhot
No tak zrovna přechodem na UDP si teda pomůžou.Cílem Google - někdo od nich to tak IIRC prezentoval na nějaké přednášce - je nejenom přechod na UDP, ale také měnit ten protokol tak často a tak hodně, aby se takové filtrovací krabice nedaly postavit.
AbcLinuxu.cz
ITBiz.cz
HDmag.cz
AbcPráce.cz
28.11.2018 12:04