Dotaz: Zrychlení přístupu k serveru ze zahraničí

[Zdeněk Zámečník]

Neřešil jste někdo, jak zrychlit přístup k síťovým službám jako je nap.ř IMAP, SMTP a HTTP ze zahraničí? Klasická modelová situace je, že mám v nějaké zemi server na které přistupují uživatelé z celého světa. Už se mi několikrát stalo, že došlo k nějakým problémům někde v tranzitu a z některých zemí (nejčastěji UK, Francie a Maďarsko) bylo prakticky nemožné nebo strašně zdlouhavé se na server dostat. Improvizovaně tyhle problémy řeším tunelováním skrz jiné servery.

Existují nějaké možnosti, jak tyhle průšvihy řešit autonomně bez uhánění jednotlivých ISP? V souvislosti s tím se mi moc líbí CDN, ale to je z principu použitelné jen pro statický obsah. Napadlo mne, jestli neexistuje nějaká služba, která by pomocí DNS dokázala spojení distribuovat nejkratší cestou (tunelem) přímo na cílový server? Dávalo by něco takového smysl? Provozujete někdo něco takového?

Zkoušel jsem něco hledat, ale nenapadají mne asi ta správná klíčová slova. Stačilo by mi jen malé popostrčení. Jako jediná (levná) možnost mne napadlo pronajmout si VPS ve strategických zemích, propojit je nějakým tunelem (OpenVPN, IPsec...) s cílovým serverem, nastudovat a rozchodit si DNS anycast. Nerad bych ale znova vynalézal kolo. Neexistuje již nějaká služba, která tohle celé umí?

A jako třešnička na dortu by mě zajímalo, jestli jste někdo řešil třeba takové spojení s Čínou...? Ten úžasný Great Firewall of China je něco otřesného, šifrovaná spojení mezi Čínou a Evropou mají často neúnosnou ztrátovost.

Odpovědi

[Jendа]

V souvislosti s tím se mi moc líbí CDN, ale to je z principu použitelné jen pro statický obsah.

Dá se zrychlit minimálně handshake, který znamená několik roundtripů na TCP + několik na navázání TLS. Řeší se to tak, že lokální akcelerátor má tato spojení „předpřipravená“, a v okamžiku připojení klienta mu udělá handshake lokálně a následně propojí se vzdáleným serverem.

která by pomocí DNS dokázala spojení distribuovat nejkratší cestou (tunelem) přímo na cílový server?

Takhle funguje normální routing v internetu, ne? :) Naopak tvoje tunely to budou posílat delší cestou. Což se teda může hodit v případě nějakých lokálních výpadků.

[Zdeněk Zámečník]

Představuju si, že by tak normální routing měl fungovat, ale ne vždy vše funguje ideálně. Řeším incidenty, že to nefunguje správně několikrát do roka a to nejsme kdovíjak velká firma. Typický problém je, že připojení z některých zemí na náš server v ČR vůbec nejde anebo má v lepším případě obrovskou ztrátovost (ICMP nad 50%). Je poměrně zdlouhavé tento problém řešit s ISP v dané zemi, protože to obvykle nepovažují za jejich problém. Prošťouchnout to z druhé strany také není nejrychlejší. Někdy to přiznají nebo opravdu aktivně řeší se svými peeringovými uzly. Problém je, že to obvykle trvá několik hodin nebo dokonce dny (!!!) než problém vyřeší.

U jednoho našeho zákazníka jsem pro změnu řešil velkou ztrátovost při připojení na jejich mail server do Číny. Tam bylo pro změnu krásně vidět, jak od některých českých ISP byla ztrátovost blížící se 0%, ale u některých i přes 40%. S jedním z těch ISP jsem to řešil několik týdnů a nevyřešil. Osobně to vnímám tak, že je to o tom, jaký peering si který operátor zaplatí než že to jde to nejrychlejší a nejspolehlivější cestou. Nejsem odborník na sítě, je to jen moje osobní domněnka. Proto se ptám, jestli se dají tyto problémy řešit nějak elegantně jinak než mít třeba nějakou službu replikovanou napříč servery po celém světě. Neumím si představit, jak to řeší opravdoví hráči jako je např. Google s jejich Youtube anebo Facebook.

Každopádně díky za komentáře. To zrychlení handshake mě vůbec nenapadlo, asi nějaké CDN vyzkouším a porovnám časy načítání, jestli to pro nás má smysl.

[OldFrog {Ondra Nemecek}]

Mimo řešení na úrovni sítě (které nevím zda existuje) můžete mít distribuovanou tu službu, kterou chcete z více míst využívat. Mít třeba svůj lokální čínský mailserver atd. případně nějaký cloud.

[lertimir]

Velcí hráči to samozřejmě řeší na lokální úrovni replikací. Pro mne pokud jdu na google s fakulty tedy z CESNETu je www.google.com

12 prg03s02-in-f4.1e100.net (216.58.201.100)  1.153 ms  1.101 ms  1.170 ms

všimni si času. za 1 milisekundu se ani tím světlem ve skle nedostaneš dále než tak 70-100km a díky routerům ještě méně. Takže server je v Praze. ( pro porovnáni Muni tedy Brno je fw5.bb10.muni.cz (147.251.240.52) 4.655 ms 4.572 ms 4.854 ms Facebook je

15  edge-star-mini-shv-01-ams3.facebook.com (31.13.91.36)  14.498 ms  14.425 ms  14.454 ms

asi amsterdam. a youtube.

12  prg03s05-in-f206.1e100.net (172.217.23.206)  1.063 ms  1.151 ms  1.102 ms

Také praha. Totéž z domu tedy VDSL T-mobile dá google

12  fra16s25-in-f4.1e100.net (216.58.207.68)  16.634 ms  16.039 ms  16.664 ms

tedy Frankfurt. Facebook

10  edge-star-mini-shv-01-frt3.facebook.com (31.13.92.36)  21.265 ms  21.159 ms  21.079 ms

také Franfurt. A youtube

10  prg03s05-in-f206.1e100.net (172.217.23.206)  8.285 ms  7.923 ms  7.946 ms

je na stejném místě v Praze.

V podstatě potřebuješ mít server o dobrého poskytovatele, který má dostatečně známou a populární adresu Autonomního systému, aby nějaký vzdálený ISP s bůhví jak nastaveném routingu v BGP ho neignoroval.

[Jendа]

O ničem hotovém nevím. Protože na anycastové adresy asi nedosáhneš, koupil bych si pár VPSek a vracel jejich IP adresy v DNS - podle GeoIP, podle ručních pravidel „uživatel od tohoto ISP si stěžoval, že se na tuhle VPS nedostane, ale tahle mu funguje“ (tohle by šlo snad i řešit automaticky, např. poslouchat tcpdumpem a pozorovat, jak rychle ti chodí od uživatele TCP potvrzení a kolik se toho musí poslat znovu -- což samozřejmě nezaručuje, že chyba není až úplně na konci v zarušené wifi a přehození na jiný server to nevyřeší) a podle měření kondice (VPSky si mezi sebou každou minutu pingnou a podle výsledku se vybere, které IP adresy stojí za to propagovat).

Co se týče Číny, tak tam přímo CloudFlare nabízí hotové řešení. A vůbec, to fakt CloudFlare dělá jenom web? Neuměli by CDNkovat i ten IMAP? (pak je samozřejmě ještě otázka, jestli chceš nechat TLS terminovat prostředníka, nebo bys to radši táhl až k sobě)