Wpis, który przeleżał jako szkic ponad rok. I bardziej go już nie skończę, więc publikuję, jak jest. Miały być testy i dokładne konfiguracje, ale z braku czasu będzie czysta teoria. Tak czy inaczej myślę, że przyda się ludziom z wolnymi łączami lub korzystającym z WWW (i nie tylko…), a chcącym zminimalizować ilość przesłanych danych do urządzenia końcowego. Do rzeczy.
Na podstawie doświadczeń z Aero2, czyli łącza zarówno wolnego (niska przepływność) jak i zlagowanego (duże opóźnienia pakietów), postanowiłem popełnić krótki poradnik, jak przyspieszyć działanie sieci na wolnym łączu internetowym. Zwykle zakładam w tym poradniku, że użytkownik korzysta z Linuksa, ale nie zawsze i część sposobów przyda się niezależnie od systemu.
Krok pierwszy – przyspieszanie zapytań DNS
Ważna sprawa, bo serwery DNS odpytywane są coraz częściej. Otwarcie pojedynczej strony internetowej to w dzisiejszych czasach często kilkanaście, a nawet kilkadziesiąt zapytań do serwerów DNS. W przypadku zlagowanego połączenia do każdego zapytania dochodzi opóźnienie łącza. Można sobie pomóc poprzez wykorzystanie lokalnego cache DNS. Z prostych w konfiguracji polecam opisany kiedyś dnsmasq lub lekki i wydajny unbound. Cache DNS działa dla całego systemu, nie tylko dla stron WWW, ale w ich przypadku różnica powinna być najbardziej widoczna. Dodatkowa zaleta to uniezależnienie się od potencjalnych problemów z serwerami DNS naszego dostawcy łącza.
Krok drugi – kompresja danych
Mechanizm kompresji danych na wolnym odcinku nie jest niczym nowym. Od dawna z powodzeniem stosuje go Opera w swojej funkcji turbo. Pierwsza obróbka strony odbywa się na ich serwerach, które dysponują szybkimi łączami. Dodatkowo może się odbywać redukcja zbędnych elementów. Zaletą rozwiązania jest łatwość uruchomienia – wystarczy kliknąć przycisk w Operze. Wadą rozwiązania jest to, że wymaga korzystania z Opery i działa tylko dla stron WWW.
Kompresja danych – DIY
ziproxy
Jeśli mamy dostęp do serwera (może być VPS) z Linuksem, możemy w prosty sposób stworzyć podobne rozwiązanie samodzielnie, korzystają z programu ziproxy. Instalujemy je na serwerze, konfigurujemy, jak bardzo mają być redukowane grafiki (60-70% wygląda znośnie), ustawiamy adres IP i port serwera jako proxy w przeglądarce i.. tyle. Od tej pory przez wolne łącze przesyłane są zredukowane (stratnie, zatem gorzej wyglądające) obrazy. Reszta danych jest przesyłana w postaci skompresowanej.
Zaleta jest taka, że działa z każdą przeglądarką i – dla paranoików – że nasze dane nie błądzą po serwerach Opery.
Wady: działa tylko dla WWW, stopień redukcji obrazów ustala się raz, nie ma możliwości dynamicznej zmiany jakości (np. obejrzenie wybranych obrazów w lepszej jakości).
sshuttle
Jeśli mamy dostęp do serwera z Linuksem i dodatkowo ma on zainstalowanego Pythona, to możemy skorzystać z VPN over SSH, czyli shuttle. Rozwiązanie powstało jako namiastka VPN i miało pierwotnie bardziej zapewniać bezpieczeństwo transmisji (szyfrowanie) w przypadku otwartych hotspotów. Można je jednak skonfigurować tak, aby ruch był kompresowany (wykorzystanie kompresji SSH).
Zaletą jest to, że działa dla całego ruchu (TCP), nie tylko dla WWW. Można określić, do których sieci ruch ma być obsługiwany przez to rozwiązanie.
Wada: działa tylko dla TCP (oraz zapytań DNS), wymaga zainstalowanego Pythona na maszynie pełniącej rolę serwera.
ssh + socks proxy
Jeśli nie chcemy instalować dodatkowego oprogramowania, a mamy dostęp do serwera z Linuksem, możemy w prosty sposób wykorzystać tunelowanie SSH oraz – podobnie jak w poprzednim przypadku – wykorzystać kompresję oferowaną przez SSH. W tym celu ustawiamy socks proxy w przeglądarce na localhost oraz port 9000, oraz uruchamiamy ssh -CND 9000 user@serwer. Od tej pory ruch WWW tunelowany jest przez SSH do serwera. Jeśli zależy nam nie tylko na wydajności, ale i na prywatności, warto sprawdzić ustawienia przeglądarki dotyczące przesyłania zapytań DNS przez proxy.
Zaleta: łatwość uruchomienia (na systemach *nix).
Wady: działa tylko dla ruchu WWW (lub jawnie przetunelowanego z innych aplikacji), wymaga przeglądarki WWW ze wsparciem dla socks proxy (praktycznie każda sensowna ma tę opcję dostępną w ten lub inny sposób).
OpenVPN
Ostatni sposób to wykorzystanie OpenVPN oraz wbudowanej kompresji. Wymaga skonfigurowanego OpenVPN zarówno po stronie klienta jak i serwera.
Zalety: działa dla wszystkich rodzajów ruchu.
Wady: wymaga zainstalowania i skonfigurowania OpenVPN. Dochodzi narzut CPU na szyfrowanie (domyślnie będzie włączone, zwł. u zewnętrznych providerów).
Oczywiście cudów nie ma i ww. sposoby pomogą jedynie dla treści, które przesyłane są jako nieskompresowane i dobrze się kompresują. Nie ma co liczyć, że filmy na YouTube zaczną działać szybciej. Osobiście idę na łatwiznę i korzystam zwykle z ssh i socks proxy.
Zawsze uwazalem, ze vpn ma swoj narzut i sumarycznie wychodzi wiecej danych niz pierwotnie. Trzeba byloby to sprawdzic. Do tego dochodzi kwestia wiekszych opoznien na lini my->vps->serwer, ciezko o dobrego i taniego vpsa w polsce. Osobiscie stawiam na proste i uniwersalne rozwiazanie typu squid z ssl (w Fx 33 wreszcie jest wsparcie) i kompresja na porcie, ktory nie blokuja przecietne darmowe accesspointy (443/80). Ale to bardziej do usypiania mojej paranoi. Problem jest ze swiezym squidem z sslem w debianie, a dokladnie jego brakiem.
Co do cache dns na stacji roboczej to to sie nie sprawdza jak dla mnie ze wzgledu na korzystanie z roznych darmowych internetow i problemow z tym zwiazanych. A flushowanie cache’ow co chwila gdzies tam z konsoli i restartowanie uslug mnie nie bawi.
Szkoda. W sensie, że publikujesz protezę, zamiast dopracować wpis. Internet jest pełen ogólników, które do niczego nie prowadzą. Ja osobiście nie lubię takiego blogowania, wolę odwlec coś jeszcze bardziej, niż napisać „po łebkach”. Mam dzięki temu 3x większe zaległości w pisaniu niż się przyznaję, ale przynajmniej sobie nic do zarzucenia. Fajny wpis techniczny to taki, z którego się coś dowiem i który ma przykłady użycia/zastosowania. Poszedłeś na skróty. Dostajesz -1 do przydatności ;o)
@nbb Każdy tunel będzie miał narzut. Nie zmienia faktu, że kompresja rekompensuje taki narzut z nawiązką.
Z ciekawości: jaki port nie jest blokowany przez darmowe accesspointy? Bo byłem przekonany, że TCP tną całe (choć nie sprawdzałem).
Którego squida potrzebujesz (w Debianie)?
Cache DNS – co ma do tego darmowy internet i jakie dokładnie problemy?
@Monter Nie protezę, a częściówkę. „Konkrety” w stylu przepisania manuala IMO wiele nie wnoszą. Ja szukając materiałów do wpisu dowiedziałem się o shuttle oraz o ziproxy. Kiedyś szukałem tego drugiego i zwyczajnie nie było (a dokładniej było coś w tym stylu, ale w Javie). Zwykły user dowie się o DNS cache i – przede wszystkim – Operze i trybie turbo. A że nie każdemu się wpis przyda – cóż, życie.
Problem jest też taki, że dopisać bym musiał naprawdę bardzo dużo, by to miało sens. Bo różne rozwiązania dadzą różny zysk w zależności od typu strony (kompresja ssh czy VPN na łączu z dużymi grafikami w dobrej jakości wiele nie da), minimalizować można ilość przesłanych danych lub szybkość wczytywania (i może to być rozłączne!) itd. Czyli cała masa testów i parę h zabawy. Sorry, to się nie wydarzy, po prostu. Jedyna szansa na dokończenie to jakaś gazeta zamawiająca artykuł za kasę. Ja w tym czasie wolę napisać parę kolejnych wpisów.
Nawiasem, to z tego wpisu poniekąd i dyskusji na IRCu urodził się temat na kolejny. A może i prezentację.
Cytuję: „Miały być testy i dokładne konfiguracje […]” No offence :o) Poza tym nie wiedziałem, że piszesz notki na ilość.
Zajrzyj do mnie, mam dla Ciebie wyzwanie 😉
Jak masz squida to klient sie z nim laczy i przesyla dane w sposob niezaszyfrowany (z docelowa strona squid potrafi sobie zestawic polaczenie https). Jezeli chcesz miec zaszyfrowana komunikacje klient-squid musisz uzyc przy kompliacji enable-ssl czego debian nie robi.
W jakim sensie tcp jest tnięty cały przez darmowe accesspointy? Np: https działa bez zarzutu (i bez bledow certyfikatow) co oznacza, ze dziala. http przeciez tez dziala chociaz moze byc postawione jakies niewidzialne proxy itp. Inne porty raczej zablokowane.
Otoz dostawca darmowego internetu moze wymuszac na tobie uzywanie jego serwerow dns (i da sie zrobic tak, by cache dns sie dostosowal), ale bywa tak, ze zanim zaakceptujesz regulamin itp (przejdzisz przez captive portal) wszystkie nazwy sa tlumaczone na adres IP wspomnianego captive portal, przez co Twoj cache dns jest `zatruty` i musisz go wyczyscic.
A da się te sposoby zastosować na Androidzie? Nie licząc Opery Turbo, która w wersji mini jest dostępna na Andka. Generalnie większość osób, która używa Aero2 – a jak rozumiem do nich jest głównie skierowany ten poradnik – korzystają z sieci na tabletach, czyli w Polsce najczęściej na Androidzie.
@nbb Jeśli chodzi tylko o flagę kompilacji, to proponuję zgłosić błąd w pakiecie. Czasem maintainer „zapomni” albo wyda mu się to niepotrzebne.
Co do wymuszania serwerów – tak, da się to zrobić bez problemu. Ale w podanej wersji to DNS poisoning. BTW możesz się przed tym zabezpieczyć w prosty sposób – włączając DNSSEC na swoim DNS cache (polecam unbound). Jeśli implementacja jest poprawna, to błędne wpisy nie trafią do cache. Do sprawdzenia, planuję wpis na ten temat.
@Androidowy Poradnik jest dla wszystkich, którzy mają wolne łącze, niekoniecznie Aero2. Na Androidzie oczywiście da się zastosować te metody. Jeśli rootowany (i są odpowiednie pakiety), to na pewno wszystkie, jeśli nie jest rootowany albo nie ma pakietów, będzie gorzej. Ziproxy to w kliencie czysto po stronie przeglądarki ustawienia. OpenVPN – albo działa, albo nie. SSH + socks proxy – w Firefox powinno dać się ustawić, myślę, że jakiś klient SSH z odpowiednimi opcjami też się znajdzie. Tak naprawdę odpadnie prawdopodobnie tylko sshuttle.
@nbb Niestety, sprawdziłem i nie mam racji. Unbound z DNSSEC co prawda zabezpieczy przed wyświetleniem spoofowanej strony, ale sprawdziłem i wpisy z nieprawidłowym podpisem lądują niestety w cache. Przynajmniej w domyślnej konfiguracji.