Dotaz: Cache server jako mají velcí poskytovatelé internetu

[truefriend-cz]

Dobrý den. Chtěl bych poradit s výběrem nějakého vhodného Cache serveru na Linuxu.

Zaujal mne způsob cachování jaký dělají operátoři T-Mobile a Vodafone kdy cachují způsobem ... když stahuji soubor z internetu a někde v půlce ho přeruším a pak začnu soubor stahovat znovu třeba i z jiného zařízení v LAN tak se stahuje někde od operátora a ne z internetu kde až v místě kde se soubor přerušil začne pokračovat stahováním souboru z internetu. Před stahováním si pouze ověří zda soubor na internetu ještě existuje.

Věděl by někdo jaký používají mobilní operátoři proxy/cache server? Případně mohl by mi někdo poradit Cache server s touto vlastností nebo jak se tato vlastnost jmenuje?

Díky

---

---

Odpovědi

[Petr Šobáň]

Nejsem si vědom toho, že by operátoři takto zasahovali do komunikace, naopak se jakémukoli zasahování brání. Dnes je navíc vše šifrováno, takže těžko ti budou zasahovat do šifrovaného spojení (to ti pak ten proxy server nijak nepomůže).
Myslím si, že máš špatné informace.
Zdar Max

[truefriend-cz]

Nemyslím si, že mám špatné informace. Přišel jsem na to tak, že když stahuji soubor z nějakého serveru kde je omezení stahování ze strany serveru a nechtěně jsem přerušil stahování tak po jeho opětovném navázání se do té úrovně stahoval plnou rychlostí (maximální rychlostí dle balíčku) a když dosáhl stejné úrovně procent tak se opět stahoval tou pomalou rychlostí. Postupem času jsem tento jev zaregistroval právě u T-Mobile a u Vodafone (ostatní operátory jsem nezkoušel).

Vzhledem k tomu, že jsem měl k dispozici VPS a hostingu tak jsem to zkusil ověřit i na straně VPS serveru a hostingu. Na straně klienta i na straně serveru jsem spustil sledování rychlosti přenosu sítě a povtvrdilo se mi to.

Z toho co jsem vyčetl na internetu existují různé služby Proxy serverů na které se někteří mobilní operátoři mohou připojit. Zdroj: https://www.scraperapi.com/blog/10-best-mobile-3g-4g-proxy-providers-for-web-scraping/

[truefriend-cz]

...oprava: soubor se stahoval plnou rychlostí ne když jsem navázal na soubor ale když jsem ho smazal a začal stahovat znovu.

[Josef Kufner]

To je cache tvého prohlížeče.

[j]

Nedelaji to ISP, delaji to nekteri provozovatele nekterych sluzeb. Typickou ukazkou je treba guugl. U vetsich ISP ma vlastni HW, a pokud se vyskytne nejaky obsah, o ktery je v dany lokalite zajem, tak se proste zreplikuje na to lokalni zelezo. Pozorovat to muzes trebas na youtube.

Typicky kdyz si vyberes nejaky video ktery neni v nasich luzich a hajich zrovna zadany, tak ho mozna ani bez ohledu na svoji linku neprehrajes, ale aktualni "hity" ti pojedou naprosto vpohode.

---

Dete s tim guuglem dopice!

[truefriend-cz]

A víte o nějakém konkrétním takovém řešení na Linux nebo Windows platformě? Nebo tedy HW.

[Max]

Asi tomu nerozumíš, ti dodavatelé obsahu mají své servírovací cache. Tzn., že data se netahají vždy z core systému, ale co je v cache, tahá se z cache (dokud nevyprší, nebo jí někdo nesmázne). A pokud to řeší hloupě, tak pro cache se nemusí vztahovat stejné politiky jako pro data z core systému. Tzn., nemusí se pro ně vztahovat limit pro stahování atd.
Takže ISP s tím nemá nic společného a pokud ty sám chceš někomu servírovat data a toto servírování urychlit (tím, že snížíš zátěž core systému), tak řešením je kešující reverzní proxy server, což může být Nginx, Apache, HAProxy, Varnish...
Zdar Max

[Filip Jirsák]

Dneska je každá smysluplná komunikace šifrovaná, takže ISP její obsah nevidí, tudíž ho nemůže cachovat.

Dříve se to používalo, ale spíš na úrovni firemních sítí, ne na úrovni ISP. Asi nejčastěji používaný software je Squid. Obecně se ten software jmenuje proxy server nebo web proxy server. Ta vlastnost žádné speciální jméno nemá, je to prostě cacheování.

[Bugsa]

Takového chování jsem si nikdy v T-Mobile nevšiml. Nechci sýčkovat, ale nezkouší na tebe někdo man-in-the-middle attack, že by ti dešifroval komunikaci a jeho proxy pak cachuje? :D Nebo není to nějaká služba, co sdílí soubory přes P2P? Například Windows Update něco takového umí.

[truefriend-cz]

To netuším. Ale všiml jsem si toho na Free Wi-Fi v několika OC (OC Nisa Liberec a OC Globus Liberec (od roku 2015 kdy to převzal T-Mobile)) kde konektivitu zajišťuje právě T-Mobile. Nedávno jsem měl chvíli i neomezený tarif od T-Mobile kde jsem se s tím setkal také.

Pak jsem si toho všiml na síti UPC (dnes Vodafone) a u dalších osob, kterým jsem dělal nějakou formu servisu (které mají UPC) plus na náhodných sítích UPC na sdílené službě domácností "UPC Wi-Fi Free" kam se přihlačovalo pokud měl člověk certifikát... (tato služba "Wi-Fi Free" u UPC byla nedávno zrušena). Pohybuji se dost často "na sítích", dělám IT outsourcing, webhosting, apod. a stále něco testuji.

Tedy nepředpokládám, že by se jednalo o nějaký ojedinělý případ.

Z praxe s tím s čím mám zkušenost tak mohu vyloučit tyto Firewally s Proxy a Cache (ty to neumí):

IPFire CacheGuard pfSense artica-proxy Squid

[Filip Jirsák]

Squid to samozřejmě umí. Ale musí to být komunikace, kde vidí do obsahu – tedy HTTP. Např. pomocí volby range_offset_limit můžete určit, aby si Squid stáhnul celý soubor, i když klient bude požadovat jenom jeho část. Volba quick_abort_max určuje, v jakém okamžiku má Squid dotáhnout celý soubor vyžádaný klientem, i když klient přerušil spojení.

[truefriend-cz]

Díky, konečně jedna kloudná odpověď na to na co jsem se ptal :) Ještě jednou díky, nastuduji si o tom něco.

[Petr Šobáň]

Squid ti je k prdu, protože dnes je vše šifrováno, veškerý webový obsah. Takže ti squid nic nenakešuje a jeho implementace dává smysl jen k ochraně a řízení přístupu na internet ve firemní síti.
Jak už jsem zmínil, tvůj pocit neodpovídá skutečnosti, ISP ti do komunikace nesahá, veškerou cache ti řeší buď prohlížeč, nebo ten, co ti servíruje obsah (google apod.)
Zdar Max

[BigBRAMBOR]

Ona muze byt komunikace i https kdyz o tom vi prohlizec, tedy v nem vyplnit proxy nebo autokonfigurace, u transparentni proxy (nekde flow control) potom hezky MITM ktery delaji napr firemni routery pomoci firemni CA.

[Filip Jirsák]

Když je to proxy nakonfigurovaná v prohlížeči, do obsahu HTTPS komunikace se stejně nedostane. Když je to MitM proxy s podvrženými certifikáty, používá se to pro inspekci obsahu (antivirová kontrola) – používat to pro kešování by mi připadalo zvrácené a nebezpečné.

[Filip Jirsák]

Nahoď si někde server s omezenou rychlostí downloadu (můžeš zkusit HTTP i HTTPS), umísti na něj nějaký větší soubor a pak ho zkus v té síti, kde podle tebe dochází k nějakému cacheování, opakovaně stáhnout wgetem. Liší se nějak výrazně rychlosti mezi jednotlivými pokusy? Nevěřím tomu: kromě toho, že na šifrované komunikaci by to vůbec nemělo fungovat, jak píšou ostatní, tak si vem, jaké problémy by to přineslo a kolik by se toho rozbilo. Museli by řešit expiraci té cache, popř. zjišťovat, které stránky raději vůbec necacheovat (abych např. na tomto webu viděl komentář po odeslání okamžitě, ne až se ISP uráčí skutečně přenést nějaká data přes Internet) atd.

[truefriend-cz]

Já tu neprodávám nějaké hrnce abych nejen Vás o něčem přesvědčoval ale popisuji něco s čím se setkávám a ptám se jak nebo čím je to možné udělat. Pokud mi nevěříte nemohu Vás o tom přesvědčovat i kdybych se přetrhl. Přesvědčit se o tom co píši se můžete sami třeba stejně jak jsem popsal já, tedy testováním. Ze sedačky židle to nejspíš nepůjde tak zkustě zvednou zadek.

Pokud řešíte věřit nebo nevěřit napište mi rovnou co chcete, abych Vás laskavě přesvědčil a mohli jsem se hnout někam dál!!! Z toho co Vám mohu nabídnout je, že přijeďte do Liberce kde se můžeme sejít a sledujte jakým způsobem to testuji. Případně se můžeme domluvit online pro sdílení plochy kde je ale problém ten, že to mi neutáhne zařízení.

O výhodách/nevýhodách takového řešení můžeme spekulovat do aleluja každopádně řeším to co jsem popsal. Řešíte-li něco jiného třeba na úrovni věřte/nevěřte pravděpodbně mi nedokážete pomoct.

[Bugsa]

Neber to od nás nijak zle. I dle reakcí ostatních je tebou popisované chování sítí "zvláštní" a určitě by nás zajímalo, čím je tebou popisované chování sítí způsobeno. Protože jak píšou výše, toto se dalo efektivně a transparentně dělat jen při HTTP spojeních.

[truefriend-cz]

Pokud to zní zle tak budu reagovat zle jinak rád bych se držel tématu. Mě by to také zajímalo proto tu jsem. Já to co popisuji však nezpůsobuji. Pouze jsem to vypozoroval, otestoval a popisuji. Z toho co zatím znám tak mi přijde, že je to na nějaké úrovni Cachování nějaké Proxy ale netuším jaká by to mohla být nebo zda existuje něco podobného i v úrovni SW. Předpokládám, že jde o nějaký HW firewall, možná Cisco, apod. Nevím.

[Filip Jirsák]

Už vám tu několik lidí vysvětlilo, že vaše domněnky jsou chybné. Vy nepíšete, co jste vypozoroval, otestoval a popisujete. Píšete jen vaše domněnky. Vyvrátit vám je nějak konkrétně nejde, protože jste nenapsal jedinou URL, na které by se to tak chovalo. Takže nemůže nikdo vzít tu samou URL, vyzkoušet to a vysvětlit vám, jak se to chová.

ISP nic použitelného kešovat nemůže, protože nevidí do šifrované komunikace. Nešifrovanou komunikaci nemá smysl řešit.

Takže pokud vás skutečně zajímá, co se děje, přestaňte psát vaše domněnky a napište fakta – zejména konkrétní URL.

[Jendа]

Takže nemůže nikdo vzít tu samou URL, vyzkoušet to a vysvětlit vám, jak se to chová.

Ještě by potřeboval to stejné připojení, kde je ta domnělá cachovací proxy, a URL, kterou předtím nikdo nepoužil, protože jinak bude nacachovaná, a/nebo ideálně přístup na druhou stranu, aby se podíval, jestli ty soubory stahuje klient, nebo je jednou stáhla proxy.

ISP nic použitelného kešovat nemůže, protože nevidí do šifrované komunikace. Nešifrovanou komunikaci nemá smysl řešit.

Teoreticky by se to mohlo vyplatit třeba pro balíčky linuxových distribucí. Ty se stahují přes HTTP a nepozměněnost se ověřuje podepsaným seznamem balíčků s jejich hashi. Ale linuxáků je asi relativně málo na to, aby to bylo potřeba řešit, a mirrory populárních distribucí jsou dostupné přes NIX, takže takový provoz je pro ISP levný a rychlý, takže ho taky nemusí řešit.

[Filip Jirsák]

Ještě by potřeboval to stejné připojení, kde je ta domnělá cachovací proxy, a URL, kterou předtím nikdo nepoužil, protože jinak bude nacachovaná, a/nebo ideálně přístup na druhou stranu, aby se podíval, jestli ty soubory stahuje klient, nebo je jednou stáhla proxy.

Čistě teoreticky ano. Jenomže kdyby to čistě náhodou byl jediný server, který má zpomalování stahování implementované tak, že součástí URL je časová značka počátku stahování a data poskytuje způsobem uplynulý čas * velikost bloku (aby zamezil podvádění s paralelním stahováním), nic z uvedeného nepotřebujete, protože se to bude chovat stejně při připojení přes libovolného operátora. Ono se to teda ve skutečnosti bude chovat stejně bez ohledu na operátora tak jako tak, protože operátor do toho provozu nijak nezasahuje a pozorované chování má na svědomí klient nebo server.

balíčky linuxových distribucí. Ty se stahují přes HTTP

Která distribuce? HTTP končí a pro tyhle okrajové případy nemá smysl nešifrovaný protokol zachovávat.

[Jendа]

data poskytuje způsobem uplynulý čas * velikost bloku

Ha, to jsem neznal.

Která distribuce?

No minimálně v Debianu a Ubuntu je default HTTP, HTTPS se dá doinstalovat, ale mnoho mirrorů ho nepodporuje (například ftp.cz.debian.org nemá certifikát pro toto jméno a cz.archive.ubuntu.com na portu 443 vůbec neběží).

HTTP končí

To se mi nezdá, znáte třeba nějakou distribuci, kde balíček s webserverem defaultně konfiguruje HTTPS-only?

[Filip Jirsák]

To se mi nezdá, znáte třeba nějakou distribuci, kde balíček s webserverem defaultně konfiguruje HTTPS-only?

Jak jsem psal, kvůli pár výjimkám nebude mít smysl udržovat potřebný software (především servery).

Pokud vím, Gentoo používá i HTTPS (ale tam je to samozřejmě složitější, protože se balíčky tahají všude možně).

[Filip Jirsák]

Prrr, mladý muži! Pár lidí ti tu napsalo co si o tom myslí, tak zapoj hlavu též a ověř si nejprve to co ti napsali. Neuvedl jsi na čem to stahuješ, přes co to stahuješ, ani odkud to stahuješ. Po cestě je milión neznámých, takže trochu pokory by to chtělo.

[truefriend-cz]

Stačí nebrat to co píši jako fráze. Je to u různých klientů... Různých OS... Je to jak wget, ať je to prohlížečem v Linuxu (terminálu), Windows a Android. U všech to vykazuje stejný symptom, tedy tohle už ani neřeším.

[Aleš Kapica]

Připoměl jsi mi jednoho finského zoufalce, kterého se mi nedávno zželelo. Chtěl si rozběhat wikibase, mezi dvěma virtuálníma doménama, v kontejneru, kde mu běželo dalších 150 domén a nebyl schopen pochopit, že za daných podmínek nikdy nedosáhne stejně rychlé odezvy, jako má Wikipedia.

[Jendа]

Pokud řešíte věřit nebo nevěřit napište mi rovnou co chcete, abych Vás laskavě přesvědčil a mohli jsem se hnout někam dál!!!

Stejně jako u skoro všech ostatních síťových problémů a záhad se tohle řeší tak, že pořídíš packet capture, pokud možno na obou koncích současně, a pak do toho koukáš.

[Bherzet]

Hledáš něco, o čem ti tu X lidí tvrdí, že by to z dobrých důvodů nemělo fungovat. Buď si to můžeš ověřit, a nebo si dál trvat na svém a hledat neexistující řešení. S takovýmto přístupem do bezplatné poradny, kde ve svém volném čase odpovídají dobrovolníci, opravdu nelez.

[PetebLazar]

Myslím, že transparetní cache nebyla v dobách "http-only" Internetu až tak neobvyklou věcí. Myslím, že to využívali (při volbě klienta) i někteří mobilní operátoři, kteří kromě cachování byli schopni i zmenšit stahovaný obsah (ke klientovi tak šel např. místo originálu obrázek menšího objemu s vyšší kompresí). S cílem ušetřit bandwith operátora a FUP klienta.

Mám pocit, že middle-man-attack byl(je) využíván u některých antivirů, které rozšíří systémové(prohlížečové) repository o svůj * certifikát a následně jím v převzatém spojení předstírají protější stranu. Prohlížeč spojení důvěřuje.

[Max]

Ano, middle-man-attack využívají antiviry, bohužel stále. Pak člověk řeší (já už tedy ne), proč tomu nejde web, proč tomu nejde email a proč tomuto se nepřekládají dns z interní domény atd..
Zdar Max

[PetebLazar]

Já tedy na nefunkčnost nenarazil, ale chvíli mi trvalo než mi došlo proč je AVG "nejúspěšnější CA" (všechy navštěvované weby měli certifikáty vystavené právě od ní).

[Max]

Narazil jsem na Avast Antivirus v jedné škole, kde sahal do DNS dotazů a nešlo překládat interní doménová jména. Po dočasné deaktivaci AV se vše rozfunkčnilo. V rozšířeném nastavení pak podobné security ochrany byly zmíněny (do té doby jsem žil v tom, že čistě Antivirus bez označená Security Suite apod. tyto fce nemá, ale on už měl).
A nedávno jsem řešil, že jedna firma měla problémy posílat v určitých případech maily. V logu smtp bylo, že spojení se zařízlo. Poté, co jsem je upozornil na možný problém s Antivirem (bylo to nejlogičtější vysvětlení, další pak už bylo jen problém s MTU/MSS, který se mi ale nepotvrdilo) se už neozvali.
Avast i AVG běžně dělaly problémy emailovému klientovi (sahaly do smtp/imap/pop3 komunikace a podvrhovaly vlastní cert). Jaký je stav nyní nevím, jaký byl stav s jinými AV nevím.
Jedno ale vím jistě, MTM útok od AV je prasárna největší úrovně, která se vždy nějakým problémem projeví.
Zdar Max

[PetebLazar]

Docela častý případ je, že po aktualizaci AVG (programová část) se neobnoví činnost procesů zajišťující popsanou transparentní kontrolu (funkce "unesení" spojení je přitom stále aktivní), takže nejde například odesílat/přijímat e-maily. Zajímavé je, že někdy k nápravě nepomůže první, ale až druhý restart OS. To je prakticky k dokonalosti dovedené "Have You Tried Turning It Off and On Again?", kteréžto v dnešní době díky "Fast StartUp" částečně ztrácí na své účinnosti (vypnutí dnes není ekvivaletní restartu jako v minulosti).

[BigBRAMBOR]

Uz to taky pomalu konci, aplikace uz zacinaji overovat vydavatele certifikatu, zacinaji s tim uz nejake weby, banky napr. Takze vyjimky pribyvaji a pribyvaji a zbude jenom opruz.

[Jendа]

Jak web ověří vydavatele certifikátu? Když jsem se naposledy díval, tak javascriptu nebyla tato informace dostupná (a i kdyby byla, tak by to MITM stejně mohl přepsat).

Mimochodem proč antiviry furt dělají tohle „tupé“ MITM přes vlastní CA? Když už tak strašně chtějí koukat na provoz z prohlížeče, tak bych čekal, že si nainstalují extension. Podobně jako je třeba nějaký AdBlock.

[Filip Jirsák]

rozšíří systémové(prohlížečové) repository o svůj * certifikát

Není to hvězdičkový certifikát, to by nefungovalo – hvězdička zastupuje jenom jeden token v DNS názvu. „Antiviry“ přidají do systému vlastní certifikační autoritu, certifikátem této autority pak podepisují certifikáty pro příslušný web.

[PetebLazar]

Správná připomínka, v navazujícím příspěvku mi to již taky docvaklo.

[Peter Golis]

Takže toto riešenie od firmy Websupport je nefunkčné?

$ wget --debug https://doprirody.sk
...
Initiating SSL handshake.
Handshake successful; connected socket 3 to SSL handle 0x0000565462b3e330
certificate:
  subject: CN=*.*,O=WebSupport\\, s.r.o.,L=Bratislava,ST=Slovakia,C=SK
  issuer:  CN=WebSupport ROOT CA,O=WebSupport\\, s.r.o.,L=Bratislava,ST=Slovakia,C=SK
ERROR: cannot verify doprirody.sk's certificate, issued by ‘CN=WebSupport ROOT CA,O=WebSupport\\, s.r.o.,L=Bratislava,ST=Slovakia,C=SK’:
...

Tak to by ma zaujímalo, prečo vymýšľajú taký hviezdičkový certifikát.

[Filip Jirsák]

Ano, je nefunkční, ale z jiného důvodu – v certifikátech je povolena jenom jedna hvězdička.

[Peter Golis]

Po toľkých rokoch čo to používajú v rámci internetu...

[Filip Jirsák]

Vzhledem k tomu, že té jejich certifikační autoritě stejně nikdo nedůvěřuje, je celkem jedno, jak jejich certifikáty vypadají. Stejně musí uživatel ten certifikát ručně povolit.

[BigBRAMBOR]

Opravdu je tak strasne tajne napsat co, kde a cim stahujes?

Podobne se chovaly opticky treba ruzne downloadery, po padu probehl velmi rychle zacatek a pak navazaly tam kde se souborem skoncily.

[motyq]

Řešil jsem "cache" v domácí síti rok zpátky hlavně kvůli dětem/hrám/steamu, aby nemusel každý klient sosat updaty a jelo to z lokální cache.

Nejdříve jsem to nějak kutil sám, no nakonec jsem našel hotovou věc: steamcache (původně jen pro steam) nyní přejmenováno na https://lancache.net/

K dispozici rovnou docker image - provozuju doma v LXD a maká to. A jak už tu bylo zmiňováno - tak samozřejmě to je pouze pro HTTP provoz - ale kupodivu herní studia ve většině případů posílají updaty/chunky jako http, takže to je cachovatelné a co mě překvapilo nedávno - EpicGames upravil svůj obchod/launcher tak, aby to bylo tímto cachovátkem cachovatelné.

Sice teda nemám křišťálovou kouli a netuším co tazatel chce cachovat, ale na herní updaty v lokální síti lze použít toto a mě to doma vyřešilo/ušetřilo docela dost času/trafficu. Musím pouze hodit cache na SSD, protože s dnešními xGB updaty mě brzdí HDD, kdy to nginx má rozsekané do tisíců souborů a nestíhá. Aktuálně udržuju cache 100GB s expire 14dní.

[Max]

Co tak koukám, tak ten projekt balí několik projektů do dockeru a zjednodušuje tak nasazení. Nebo se v něčem pletu?
Z Docker Hubu to tahá neověřený Alpine jako base a do něj to lije nginx, bind, SNI Proxy a další věci.
Zdar Max