Szybkość polskich stron internetowych cz. 2

Opisywany w poprzednim wpisie nt. badania szybkości polskich stron internetowych system trochę okrzepł, skończył się miesiąc, więc pora na konkrety. Co prawda listę badanych serwisów było widać na zrzucie ekranu, ale nie było dostępu do danych , więc teraz to naprawiam.

Zdecydowałem, że nie będę się bawił w wyciąganie średnich miesięcznych itp.  Jeśli ktoś jest zaintersowany, to w historii są linki do danych źródłowych (CSV), można sobie wyciągnąć samodzielnie. O ile ktoś będzie potrzebował, bo to, co domyślnie daje GTmetrix, z ładną wizualizacją, jest IMO w zupełności wystarczające.

Tak więc badanie wywoływane jest dla 10 wybranych serwisów (najpopularniejsze polskie oraz ecommerce, przy czym znaczenie miała domena) co 12h,  wykonywane z Londynu, przy pomocy Chrome, bez AdBlocka i na nielimitowanym paśmie.

Oto serwisy, po kliknięciu linka dostęp do wszelkich zebranych danych:

Jest jeszcze pomysł na uruchomienie testów za pośrednictwem innego serwisu, ale pozostaje to w sferze pomysłów, póki co bez planów na implementację.

UPDATE: Pomysł wyglądał fajnie, ale tylko przez miesiąc. Po pierwsze, okazało się, że dostępne są dane tylko z miesiąca, mimo obiecujących wartości „1y” i „all” w historii. Po drugie, skrypt wymaga poprawki – przez parę dni dane się nie zbierały, potem samoistnie zaczęły. Pewnie do poprawy obsługa wyjątków plus dodanie wysłania powiadomienia, choć założenie, że mógłbym coś zrobić i że by mi się chciało jest mocno optymistyczne. Po trzecie i najważniejsze, zmieniły się linki do raportów, powyższe już nie działają, co oznacza, że nawet wersja miesięczna jest średnio używalna dla kogokolwiek poza mną. Pomyślę jak to wszystko rozwiązać, pewnie skończy się na powrocie do oryginalnego pomysłu i zbierania danych samodzielnie.

Pomiar szybkości polskich stron internetowych

Podczas pewnej dyskusji nt. kondycji stron internetowych powołane zostało jako argument badanie szybkości stron internetowych robione przez firmę Hostersi. Jest to ciekawe badanie, prowadzone od lat ale… ma wady.

Pomiarów niby jest dużo, ale są one przeprowadzane przy pomocy autorskiego narzędzia uruchamianego ad hoc, przez tydzień, samo badanie publikowane raz na rok. Wszystko to powoduje, że wyniki trudno jest weryfikować samodzielnie, a jakaś zmiana na stronie obecna w danym tygodniu, czy chwilowe problemy wydajnościowe serwisu mogą zaburzać wyniki dla całego roku. Co widać nawet w raporcie po niektórych dziwnych danych.

Dla jasności – szanuję wykonaną pracę, ale gdyby to zależało ode mnie, wolałbym mieć dane częściej, choć może rzadziej zbierane. I tak narodził się pomysł, żeby zbierać i publikować w miarę na bieżąco dane dotyczące szybkości działania polskich stron internetowych samodzielnie, hobbystycznie, w sposób umożliwiający każdemu chętnemu samodzielną weryfikację wyników pomiarów.

Stawianie własnej infrastruktury oczywiście odpadło w przedbiegach. Zbyt zasobochłonne, zarówno jeśli chodzi o koszt, jak i o samą czasochłonność utrzymania. Poza tym, odpadnie możliwość peer review. Jednak serwis GTmetrix daje ciekawe możliwości badania szybkości ładowania stron i daje API, postanowiłem z niego skorzystać, co sprowadza pracę do napisania prostych skryptów w Pythonie. Dodatkowo pozwala dzielić się zebranymi danymi przy pomocy udostępniania unikatowych URLi.

Niestety, w wersji darmowej można robić tylko 20 zapytań po API dziennie, co wymusiło ograniczenie się do jednej lokalizacji (Londyn, jako najbliższy Polsce), jednej przeglądarki (Chrome bez AdBlocka), okrojenia liczby badanych serwisów do 10 (wybrane na podstawie raportu Hostersi z najpopularniejszych i ecommerce) i wykonywania dla każdego 2 testów dziennie. Wybrałem okolice godziny 8 rano oraz 20. Z doświadczenia o 8 jest już jakiś – choć niewielki – ruch w sieci, a 20 to szczyt. Wyniki planuję publikować co miesiąc, jako średnie wartości z danego miesiąca.

Badane strony w GTmetrix

Póki co, uruchomiłem skrypt, który przy pomocy crona robi „taktowanie”, czyli zleca uruchomienie testów. Dane zbierają się od paru dni. Pomyślę jeszcze, czy zamieszczać jakieś statystyki co miesiąc, czy po prostu ograniczyć się do zbierania. Raczej stanie na tym drugim… Stay tuned!

Zmiany w czasie

W odpowiedzi na inicjatywę obywateli Komisja Europejska przeprowadza ankietę dotyczącą ew. zmian w zmianach czasu z letniego na zimowy. W skrócie – każdy obywatel UE może się wypowiedzieć, czy woli obecny model, czy pozostanie przez cały rok przy jednym czasie. A jeśli pozostanie przy jednym, to przy którym. Zachęcam do głosowania – ankieta trwa do 16. sierpnia.

Źródło: https://pixabay.com/en/business-time-clock-clocks-257911/

Nie jest to pierwsza próba jakiejś tam reformy, zupełnie niedawno czytałem wpis, który niechcący przybliżył mi ideę Swatch Internet Time. Temu projektowi nie wróżę akurat sukcesu z powodu przywiązania do firmy, ale niesie on jeszcze jedną zaletę – likwidację stref czasowych. Oznacza to, że podanie czasu wg SIT jest jednoznaczne dla całego świata; czy to Tokio, Nowy Jork, czy Warszawa @833 oznacza ten sam moment.

Osobiście wolałbym po prostu jeden czas na całym świecie, ale w formie tradycyjnej. Pewnie UTC. Czemu? Prostota, odpada przeliczanie, a coraz więcej wydarzeń ma charakter globalny. Notowania akcji, transmisje na żywo wydarzeń kulturalnych i sportowych. Wydaje mi się, że strefy miały sens, gdy większość wydarzeń była lokalna, ograniczona powiedzmy do jednego kraju, a to się nieco zmieniło.

Tak czy inaczej, uważam rezygnację ze zmiany czasu za krok w dobrym kierunku.

UPDATE: Są wyniki. 84% ludzi, którzy wzięli udział, opowiedziało się za zniesieniem zmiany czasu. Szczegóły tutaj.

Jak usprawnić sieć w domu? cz. 5

Wpis, który chronologicznie powinien pojawić się jako drugi, ponieważ dotyczy stanu wyjściowego, czyli WiFi. Oczywiście sprzęt to opisywany niedawno TP-Link WR841 z OpenWrt. Banana Pi wpięte do portu LAN, czyli na 100 Mbps, ale głównym ogranicznikiem jest sieć bezprzewodowa. Jasności dodam, że są to wyniki sprzed optymalizacji, ale o poprawianiu WiFi napiszę innym razem. Warto też zaznaczyć, że wyniki jako jedyne są przeprowadzane na środowisku nieizolowanym, „produkcyjnym”, tj. z podłączonymi innymi urządzeniami. O ile nie powinny specjalnie rzutować na wynik, bo nie korzystały intensywnie, to na pewno wpływały w jakiś sposób ujemnie.

1.
[ ID] Interval           Transfer     Bandwidth       Jitter    Lost/Total Datagrams
[  4]   0.00-60.04  sec   125 MBytes  17.5 Mbits/sec  10.997 ms  1908/16040 (12%)  
[  4] Sent 16040 datagrams

2.
[ ID] Interval           Transfer     Bandwidth       Retr
[  4]   0.00-60.00  sec  67.7 MBytes  9.46 Mbits/sec  186             sender
[  4]   0.00-60.00  sec  67.6 MBytes  9.45 Mbits/sec                  receiver

3.
— 192.168.0.139 ping statistics —
600 packets transmitted, 598 received, 0% packet loss, time 61057ms
rtt min/avg/max/mdev = 0.766/2.303/42.995/4.036 ms

4.
— 192.168.0.139 ping statistics —
600 packets transmitted, 596 received, 0% packet loss, time 60280ms
rtt min/avg/max/mdev = 1.918/3.953/42.202/3.747 ms

5.
[ ID] Interval           Transfer     Bandwidth       Jitter    Lost/Total Datagrams
[  4]   0.00-3600.04 sec  6.27 GBytes  15.0 Mbits/sec  4.305 ms  71880/822270 (8.7%)
[  4] Sent 822270 datagrams
[…]
9.
Inea Orange

Jak widać stan wyjściowy nie był imponujący. Rzekłbym nawet, że zaskakująco słabe wyniki. Widać też, że brakuje części testów – przyznaję, że nie miałem ani cierpliwości, ani warunków. Ponieważ ustawienia lekko się zmieniły w międzyczasie, zostawię z brakiem, żeby nie fałszować. Zaskakuje słaby wynik transmisji w teście syntetycznym, w szczególności w porównaniu z testem do internetu.

Jak usprawnić sieć w domu? cz. 4

Kolejnym PLC, który otrzymałem na testy, był D-Link PowerLine AV Network Starter Kit DHP-307AV. Bardziej niż konkretny sprzęt jest to przedstawiciel starszego standardu, takiego, do którego przymiarkę robiłem zawodowo, wiele lat temu, pod kątem IPTV (i nie zdecydowaliśmy się wtedy).

W stosunku do opisywanego poprzednio główna różnica widoczna na pierwszy rzut oka, to brak gniazdka sieciowego w urządzeniu. Zaprawdę powiadam wam, pomyślcie dwa razy, nim coś takiego kupicie. Jednak główna zaleta PLC to przesył danych po sieci energetycznej obok prądu, a nie zamiast. Okazało się, że większość gniazdek w domu jest pojedyncza, w szczególności te, na których przeprowadzałem testy. Chciałem mieć równe testu warunki, więc stanęło na tym, że PLC było wpięte w gniazdko, a prąd do urządzeń doprowadzałem przy użyciu przedłużaczy z innych gniazdek, zalegających malowniczo po domu.

Detali typu wygląd, czytelność sygnalizacji, umiejscowienie portów czy przycisków pomijam – nie tego dotyczy test. Zatem do rzeczy. Błędów nie będę powielał, testy tylko w optymalnym zestawieniu, dwa gniazdka w tym samym pokoju, PLC bezpośrednio w gniazdku:

1.
[ ID] Interval           Transfer     Bandwidth       Jitter    Lost/Total Datagrams
[  4]   0.00-60.01  sec   402 MBytes  56.2 Mbits/sec  1.923 ms  25/51490 (0.049%) 
[  4] Sent 51490 datagrams

2.
[ ID] Interval           Transfer     Bandwidth       Retr
[  4]   0.00-60.00  sec   279 MBytes  39.0 Mbits/sec    0             sender
[  4]   0.00-60.00  sec   278 MBytes  38.9 Mbits/sec                  receiver

3.
--- 192.168.10.126 ping statistics ---
600 packets transmitted, 600 received, 0% packet loss, time 60295ms
rtt min/avg/max/mdev = 3.273/3.939/8.552/0.749 ms

4.
--- 192.168.10.126 ping statistics ---
600 packets transmitted, 600 received, 0% packet loss, time 60235ms
rtt min/avg/max/mdev = 2.885/3.943/8.002/1.000 ms

5.
[ ID] Interval           Transfer     Bandwidth       Jitter    Lost/Total Datagrams
[  4]   0.00-3600.00 sec  21.0 GBytes  50.1 Mbits/sec  2.687 ms  9031/2754740 (0.33%) 
[  4] Sent 2754740 datagrams

6.
[ ID] Interval           Transfer     Bandwidth       Retr
[  4]   0.00-3600.00 sec  16.0 GBytes  38.3 Mbits/sec    0             sender
[  4]   0.00-3600.00 sec  16.0 GBytes  38.3 Mbits/sec                  receiver

7.
--- 192.168.10.126 ping statistics ---
36000 packets transmitted, 36000 received, 0% packet loss, time 3622284ms
rtt min/avg/max/mdev = 2.715/4.149/75.146/1.069 ms

8.
--- 192.168.10.126 ping statistics ---
36000 packets transmitted, 36000 received, 0% packet loss, time 3620695ms
rtt min/avg/max/mdev = 2.862/3.903/83.121/1.154 ms

9.
brak danych

Jak widać, w porównaniu z poprzednim testem sprzętu nowszej generacji, urządzenia starszej generacji zapewniają znacząco mniejszy transfer. Choć działają stabilnie, nawet przy niższych opóźnieniach. O ile zaczną działać, bo brak danych w punkcie dziewiątym wynika z tego, że połączenia między pokojem a przedpokojem zwyczajnie nie udało mi się zestawić, mimo kilku prób.

Jeśli chodzi o pobór prądu to zarejestrowałem na pojedynczym urządzeniu od 3,2 W pod obciążeniem, przez 2,7 W przy braku przesyłu danych i podłączonych urządzeniach, do minimalnie 2,3 W parę minut po wypięciu kabla ethernet. Producent obiecuje poniżej 1 W w idle, jak widać jest więcej. Albo kwestia firmware, albo za krótko czekałem, albo urządzenia nie potrafią.

Jak usprawnić sieć w domu? cz. 3

No i z uwagi na lekkie zamieszanie zapomniałem uzupełnić brakujące wpisy. Pora nadrobić. Tym razem ponownie  będzie o TL-PA4010P kit. W poprzednim wpisie opisałem test w niekomfortowych warunkach, pora napisać, co potrafią te PLC wpięte jak należy, czyli bezpośrednio w gniazdka. Dodatkowo gniazdka znajdowały się w tym samym pokoju (poza testem do internetu), czyli warunki optymalne.

1.
[ ID] Interval           Transfer     Bandwidth       Jitter    Lost/Total Datagrams
[  4]   0.00-60.01  sec   679 MBytes  94.9 Mbits/sec  0.959 ms  2399/86899 (2.8%) 
[  4] Sent 86899 datagrams

2.
[ ID] Interval           Transfer     Bandwidth       Retr
[  4]   0.00-60.00  sec   596 MBytes  83.3 Mbits/sec  165             sender
[  4]   0.00-60.00  sec   595 MBytes  83.2 Mbits/sec                  receiver

3.
--- 192.168.10.126 ping statistics ---
600 packets transmitted, 600 received, 0% packet loss, time 60244ms
rtt min/avg/max/mdev = 3.265/4.578/43.719/5.233 ms

4.
--- 192.168.10.126 ping statistics ---
600 packets transmitted, 600 received, 0% packet loss, time 60215ms
rtt min/avg/max/mdev = 22.191/24.164/75.595/5.495 ms

5.
[ ID] Interval           Transfer     Bandwidth       Jitter    Lost/Total Datagrams
[  4]   0.00-3600.00 sec  39.7 GBytes  94.6 Mbits/sec  1.226 ms  166115/5197940 (3.2%) 
[  4] Sent 5197940 datagrams

6.
[ ID] Interval           Transfer     Bandwidth       Retr
[  4]   0.00-3600.00 sec  36.3 GBytes  86.6 Mbits/sec  7730             sender
[  4]   0.00-3600.00 sec  36.3 GBytes  86.6 Mbits/sec                  receiver

7.
--- 192.168.10.126 ping statistics ---
36000 packets transmitted, 36000 received, 0% packet loss, time 3621137ms
rtt min/avg/max/mdev = 2.621/4.664/94.389/5.156 ms

8.
--- 192.168.10.126 ping statistics ---
36000 packets transmitted, 36000 received, 0% packet loss, time 3618021ms
rtt min/avg/max/mdev = 21.802/23.793/196.067/5.318 ms, pipe 2

9.
Inea Orange

Jak widać jest zauważalnie szybciej, zarówno po sieci, jak i do internetu. W przypadku serwera Inea (czyli dostawcy), można uznać, że osiągnięte zostało deklarowane 60/10, przynajmniej w przypadku serwera testowego znajdującego się u dostawcy. Czyli zdecydowanie warto wpiąć w sposób zalecany przez producenta.

5 porad na lepszy internet u wirtualnego operatora komórkowego

Od jakiegoś czasu korzystam w telefonie z wirtualnego operatora komórkowego (Virgin Mobile). Wcześniej korzystałem już z Aero2, który jest miksem operatora tradycyjnego i wirtualnego, a który z powodzeniem funkcjonuje jako podstawowy internet u rodziców. W stosunku do tradycyjnego operatora GSM jest trochę zmian o których warto wiedzieć bo wpływają na działanie internetu przez komórkę.

Główna zmiana to nadajniki. O ile w przypadku tradycyjnego operatora sprawa jest prosta – korzystamy z jego nadajników i zmieniać możemy najwyżej tryb – to w przypadku operatora wirtualnego możliwości i opcji po stronie sprzętu jest więcej. Poniżej kilka rad, które mogą pomóc uzyskać lepszy internet mobilny. Nic specjalnego i niezwykłego, ale chciałbym, żeby mi to wszystko ktoś rok czy dwa temu powiedział…

  1. Sprawdź, z jakich trybów i nadajników pozwala korzystać operator wirtualny. Zwykle jest to opisane w FAQ, jeśli będzie problem ze znalezieniem, można zapytać w BOK. Przyda się już za chwilę, w punkcie trzecim.
  2. Sprawdź w urządzeniach (w każdym z osobna), czy jest dozwolony roaming dla danych. Niektóre urządzenia zezwalają osobno na roaming krajowy (ten nas interesuje) i zagraniczny, w innych jest to proste włącz/wyłącz. Poza szczególnymi przypadkami, włączenie roamingu poprawia działanie internetu, a przynajmniej jego zasięg.
  3. Wymuś ręcznie połączenie z sieciami operatorów znalezionymi w pierwszym punkcie. Mój telefon uparcie twierdził, że T-Mobile jest forbidden i nie przełączał się automatycznie, mimo włączonego roamingu dla danych. Dopiero po ręcznym podłączeniu do nadajnika T-Mobile zapamiętał (na szczęście na stałe), że może się na nie przełączać.
  4. Jeśli planujesz przebywać w danym miejscu dłużej i potrzebujesz szybkiego lub stabilnego dostępu do internetu, również warto ręcznie przełączyć się między dostępnymi nadajnikami i sprawdzić w praktyce jak działa internet. Niestety nie ma prostej reguły – w jednym miejscu działa lepiej za pośrednictwem nadajników jednego operatora, w innym za pośrednictwem innego.
  5. Jeśli obserwujesz okresowe zrywanie połączenia z internetem, pomóc może tymczasowe wyłączenie roamingu dla danych i wybór operatora ręcznie.

Jeśli mamy lub planujemy kupić lepszy sprzęt i zależy nam na prędkości, można orientacyjnie zerknąć na mapę zasięgu LTE, jednak prawdę powie nam dopiero sprawdzenie empiryczne, niestety. Przy czym trzeba pamiętać, że sytuacja się zmienia, operatorzy planują wprowadzić (albo już wprowadzili) ograniczenia prędkości internetu przy dostępie w roamingu.

Bonus: jeśli ktoś korzysta z lokalnego proxy DNS i miewa problemy z dostępem do sieci to polecam lekturę tego wpisu na mikroblogu. Użycie DNS Google zamiast odpytywania bezpośrednio zdecydowanie poprawia sprawę. Zostawiam jako plotkę/ciekawostkę, bo nie drążyłem tematu póki co.

Internet bez kabla

Raspberry Pi radzi sobie w połączeniu z modemem Huawei 3131 (stara wersja) zaskakująco dobrze jako router do Aero2 (wariant płatny). Przesiadka z Banana Pi nie była całkiem bezproblemowa – internet w domu co prawda działał, ale straciłem zdalny dostęp przy pomocy autossh. Diagnostyka była prosta – okazało się, że nie wystarczy skopiować skrypty i crony, warto jeszcze sprawdzić, czy autossh jest w ogóle zainstalowane…

Prawdopodobnie przez brak nawiązanego połączenia SSH zmienia się IP i przesyłanych (a w zasadzie zliczanych) jest więcej danych podczas okresowego (co 5 minut) wywoływania wget w ramach namiastki dyndns. Znaczy zamiast jednego pakietu 3GB po 5 zł sztuka miesięcznie schodzą dwa. Można kupić więcej od razu, więc żaden problem, zresztą i tak raczej się zdziwiłem, że na początku mieścili się w jednym.

Internet z GSM działa przyzwoicie. Nie zauważyłem ani specjalnych lagów, ani spowolnienia. Co prawda może to być kwestia porównywania ze starym pakietem, ale póki co skłaniam się ku teorii, że jestem w stanie przesiąść się w domu całkowicie na internet bezprzewodowy, po GSM. Przynajmniej technologicznie, bo ceny wyższych pakietów jeszcze nie zachwycają. Poza tym, LTE działa podobno jeszcze lepiej…

Pozostało dołożenie drugiego modemu z internetem od innego operatora, uruchomienie abcc do wybierania aktualnie lepszego (i działającego) łącza i… tyle. No, muszę przerobić jeszcze wywoływanie autossh, bo zrobiłem proste @reboot w cronie, co słabo się sprawdza w przypadku zerwania sesji – raz się jednak pakiet Aero2 skończył i trzeba było doładować, a jak się nie zrobi tego od razu, to się zapomina.

Oczywiście można kombinować jeszcze z wyniesieniem modemów GSM w lepsze miejsce, podpięciem anten itp. ale… po co komplikować, skoro działa? Z drugiej strony byłby pretekst do zabawy z antenami i potestowania wpływu siły sygnału GSM na prędkość działania internetu.

Terroryści wszystkich krajów, łączcie się!

Parę dni temu mignęła mi wiadomość na stronach Debiana, że jeden z developerów, Dmitry Bogatov, został zatrzymany. Przez moment zastanawiałem się, cóż takiego mógł zrobić i czy przypadkiem nie chodzi o zbieg okoliczności i działalność poza projektem Debian i pozainformatyczną w ogóle, bo trochę mi się w głowie nie mieściło jak projekt Debian może powodować aresztowanie. Nawet w Rosji.

Sprawa się wyjaśniła, chodzi o terroryzm[1]. Dokładniej, o prowadzenie węzła Tor. W dodatku wyjściowego, czyli tzw. exit node. Projekt Tor uruchomił akcję, w której wzywają do uruchomienia węzła wyjściowego lub jakiegokolwiek węzła Tor w geście solidarności z aresztowanym. Uruchomione w ramach akcji węzły powinny mieć w nazwie Bogatov lub KAction.

O ryzyku prowadzenia węzła Tor pisałem jakiś czas temu, miałem też notkę o konfiguracji relay node, czyli wersji bezpiecznej, w wersji z eleganckim monitoringiem w konsoli.

[1] Gdyby ktoś miał wątpliwości: w dzisiejszych czasach każda nieprawomyślność względem rządzących może być podciągnięta pod terroryzm, niezależnie od miejsca na świecie.

Dlaczego wyłączyłem reklamy AdSense?

Z niewiadomych dla mnie powodów sporą popularność zyskał ten artykuł nt. wyłączenia reklam AdSense. Sprawdziłem fakty i niemal dwa lata temu pisałem o odchudzaniu bloga, w tym o wyłączeniu reklam Google. Przeczytałem jeszcze raz, skonfrontowałem z ww. artykułem i stwierdziłem, że warto dodać parę słów.

We wpisie poruszyłem tylko jeden aspekt – niskie zarobki (tak niskie, że trudno tu mówić o zarobkach – tu polecam artykuł, bo ja zupełnie niekomercyjnie i amatorsko podchodziłem do tematu), ale powodów było tak naprawdę więcej i uważam Google AdSense za bardzo słaby produkt. Po pierwsze, notoryczne problemy z pojawianiem się reklam w językach innych, niż polski i ew. angielski. Jeśli nawet nie robią detekcji języka, to deklaracja języka jest jasna czy to w samym HTML, czy w Google webmaster tools. O ile „międzynarodowy” angielski jeszcze bym od czasu do czasu zrozumiał, to notorycznie pojawiały się języki takie jak niemiecki, turecki czy jakieś skandynawskie. Nie pomagało ani blokowanie reklam, ani dostawców. Czyli z mojego widzenia wyświetlane były śmieci.

Druga sprawa, to niedostosowane tematycznie reklamy połączone z brakiem jakiegokolwiek uczenia się, których kategorii nie chcę widzieć na blogu. Oczywiście można wybrać kategorie wrażliwe, ale nawet przy wyłączeniu wszystkich notorycznie pojawiały się na blogu preparaty na łysienie itp. paramedyczne atrakcje. Jawnie zablokować tego nie sposób, przy blokowaniu pojedynczych żadna korelacja nie jest stosowana. Czyli znowu śmieci.

Kolejna sprawa to reklamy wprowadzające w błąd. Przede wszystkim chodzi o reklamy krzyczące na urządzeniach mobilnych o tym, że na urządzeniu są wirusy. Raczej nie widziałem tego u siebie, ale widać to zwykle na urządzeniach mobilnych, a tak raczej nie zdarzało mi się oglądać bloga, natomiast temat znam zarówno z innych stron, jak i aplikacji ze sklepu Play. Zupełnie nie wiem, czemu nie jest to blokowane na wejściu globalnie. Żeby było weselej, chyba korzystał z tego któryś bardziej znany producent antywirusa. Albo po prostu domena była podobna… Problem jest taki, że ktoś to w końcu kliknie (mi się zdarzyło) i zainstaluje jakiś syf na telefonie. Czy to świadomie, czy nieświadomie…

Z punktu widzenia Google, na krótką metę, nie ma znaczenia, czy reklamy wyświetlają z sensem, czy bez sensu. Bardziej opłaca im się wyświetlić reklamę zupełnie niedopasowaną, niż nic nie wyświetlić. Jeśli nikt nie kliknie, to nie płacą, jeśli ktoś kliknie, nawet przez pomyłkę to zarabiają. A że Internet wygląda coraz bardziej jak zawalone bez ładu i składu reklamami polskie miasta? Nie ich problem…

Wskaźniki jakości łącza

Dumałem trochę nad parametrami łącza internetowego, które abcc mógłby mierzyć, poza tym, komentarze pod wpisem o założeniach abcc trochę pomieszały mi szyki, jeśli chodzi o chronologię, więc najwyższy czas przejść do rzeczy.

Techniczne wskaźniki jakości łącza internetowego to:

  • Opóźnienie – czyli potocznie lag albo ping, zrozumiała chyba dla każdego miara i dość powszechnie używana do określenia, czy łącze jest sprawne. Im jest mniejsze, tym lepiej. Ma znaczenie przy korzystaniu interaktywnym, czyli SSH/remote desktop albo graniu w gry online (zwł. FPP). Niezbyt istotne przy pobieraniu danych czy strumieniowaniu.
  • Straty pakietów – na sprawnym łączu strat nie ma. W przypadku łącz bezprzewodowych lub awarii, straty mogą się pojawiać. Wiążą się z koniecznością retransmisji pakietów lub utratą danych. Mają znaczenie praktycznie wszędzie. Im niższa wartość, tym lepiej.
  • Jitter – zmienność opóźnienia pakietów, czyli dokładniej statystycznie, wariancja opóźnienia pakietów. Ma znaczenie przy korzystaniu interaktywnym, szczególnie przy transmisji głosowej/video. Im niższa wartość, tym lepiej.
  • Prędkość pobierania – określa, jak szybko można pobierać dane. Ważne przy pobieraniu danych.
  • Prędkość wysyłania – określa, jak szybko można wysyłać dane. Ważne tylko przy wysyłaniu większych maili itp.

W wariancie minimum planuję mierzyć tylko dwie pierwsze miary. Waham się nad jitterem – prawdopodobnie kiedyś zaimplementuję, ale wymagałoby zmiany bibliotek i/lub liczenia wszystkiego samodzielnie. Wykonalne, ale na początek mało istotne. Z uwagi na pierwotne zastosowania (GSM) i możliwość opłat za transfer, rezygnuję z badania prędkości pobierania i wysyłania. Zresztą, jest szansa, że same pomiary mogłyby tu wpłynąć na funkcjonowanie łącza, szczególnie słabszego. Dodatkowo wymagany jest host zdalny, udostępniający określoną zawartość (w przypadku downloadu) lub pozwalający na wysyłanie treści (w przypadku uploadu). Nie skreślam zupełnie, ale zdecydowanie nie pojawi się w pierwszej wersji, a jeśli się pojawi, to domyślnie będzie wyłączony.

Na koniec pozostała część zasadnicza, czyli formuła określająca jakość łącza. Ponieważ dla większości parametrów im niższa wartość, tym lepiej, stwierdziłem, że najprościej jest liczyć tylko koszt, czyli sumować „punkty karne”, łącze o najniższej wartości „wygrywa”. W przypadku dwóch ostatnich parametrów łatwo zamienić je na analogiczne miary – im niższy czas przesyłania znanej ilości danych, tym lepiej.

Ostatecznie na razie wyszło coś takiego:

f(route)= suma(mnożnik_IP * (mnożnik_strat_route * straty_IP + mnożnik_opóźnień_route * opóźnienie_IP))

Dodatkowo całość należałoby przemnożyć przez mnożnik dla danego łącza[1] i wprowadzić, czy to do wzoru, czy przy podejmowaniu decyzji o przełączeniu, koszt przełączenia. Docelowo przydała by się pewnie jeszcze jakaś normalizacja względem ilości IP, żeby dodanie dodatkowych IP do sprawdzania nie powodowało zmiany wartości, bo to zmienia rolę kosztu przełączania. Najprostsza byłaby średnia, ale gryzie się z mnożnikami dla poszczególnych IP. Te z kolei chciałem mieć, bo wyobrażam sobie sytuację, że ktoś chce sprawdzać jakość łącza do różnych IP docelowych, ale niektóre (np. IP firmy) są bardziej istotne przy podejmowaniu decyzji.

Mnożniki dla route wprowadziłem z uwagi na możliwość ustawiania nie tylko routingu domyślnego, ale dla poszczególnych tras. Może się zdarzyć, że do sieci, do której łączymy się przez SSH ruch będzie wysyłany innym łączem, niż podstawowe, ze względu np. na mniejsze opóźnienia. Raczej na wyrost w tej chwili, ale kiedyś pewnie się przyda.

Przechodząc do spraw praktycznych: pobawiłem się chwilę w weekend, jest PoC – czytanie konfiga, część przykładowego konfiga, przepingowanie IP, liczenie kosztu (niedoskonałe). Czekam na zamówiony modem GSM. 56 linii kodu, commit do repo pewnie w tym tygodniu, ale o tym następnym razem. 😉

[1] Koszt łącza miałby być dodatkowym parametrem, dzięki któremu użytkownik może w jakiś sposób odwzorować parametry pozatechniczne, choćby koszt transmisji za pośrednictwem danego łącza.

Porządki

Od jakiegoś czasu noszę się – niezbyt intensywnie, ale jednak – z zamiarem zmiany dostawcy internetu u rodziców, czyli rezygnacji ze starego, wolnego łącza ADSL, ale taniego w wartościach bezwzględnych, będącego zaszłością na rzecz czegoś nowego, szybszego i przede wszystkim tańszego. Bo 1 Mbps ssie coraz bardziej. Klasyczne radiówki-osiedlówki odpadały zawsze w przedbiegach. Prędkość OK, ale za dobrze znam realia, więc wiem, że ze stabilnością może być… różnie, a na prędkości aż tak mi nie zależy. Do tego dochodzi jednak konieczność montażu anteny i to, plus brak istotnych różnic w cenie przeważa szalę. Żeby był sens cokolwiek zmieniać, to cena musiałaby spaść do jakichś 25 zł/m-c.

Potem pojawił się internet od operatorów GSM. Początkowo drogi, ale ceny już spadły, transfery i opóźniania są niższe, niż na obecnym rozwiązaniu. Jedynym problemem, który pozostał, są pakiety ruchu. Na routerze mam odpalonych trochę własnych gratów (backupy, wykrywanie spamu na Blox itp. itd.), do tego dochodzi ruch generowany przez komputery. Z logów pppd wynika, że wysyłane dane to 50-100 MB/dobę, a pobierane to 500-1000 MB. Gdyby któryś operator dawał 30 czy 50 GB w pakiecie za grosze, to nie byłoby problemu, ale niczego takiego nie znalazłem (TBH nie szukałem jakoś intensywnie).

Zatem do tej pory głównym blokerem było ustalenie, co generuje transfer. O ile ustalenie, czy ruch powstał lokalnie, czy pochodzi z końcówek nie jest problemem (wystarczy sprawdzić liczniki na interfejsach), o tyle totalnie odbiłem się od możliwości ustalenia, które procesy generują ruch sieciowy w Linuksie. Tzn. problemu nie ma, jeśli są to działające cały czas demony, ale jeśli mamy – jak w tym przypadku – wiele skryptów uruchamianych z crona, w dodatku korzystających z zewnętrznych poleceń to jest… ciężko. Wyszło mi, że można albo zrobić wrapper, podpiąć go pod wszystkie skrypty i zliczać ruch przy wywołaniu, albo – jeśli uruchomione procesy działają dłużej – uruchamianie z crona skryptu, który sprawdzi dane dla aktualnie uruchomionych procesów w /proc. Tak czy inaczej, trochę za dużo pracy w stosunku do potencjalnego zysku, bo ostateczne i tak nie wszystkie skrypty chcę wynieść na obcą infrastrukturę.

Dziś siadłem, rzuciłem okiem w crona i odpowiedziałem sobie na zajebiście ważne pytanie: co jest tak naprawdę niezbędne? Zbieranie danych o Blox i spamie – z tego nic się nie urodzi. Backupy blogów – przeniesienie w inne miejsce jest trywialne. Więc nie będę zliczał ruchu, tylko wyłączę rzeczy, które raczej generują spory transfer, a które były kiedyś fajne i zajmujące, ale są już nieprzydatne i działają z rozpędu. Za tydzień zaś po prostu sprawdzę, ile jest wygenerowanego ruchu i jak to się ma do pakietów danych w GSM.

I tu pytanie do czytelników. Jakie rozwiązania (operatorzy, pakiety) do transmisji danych po GSM polecacie? Warunki brzegowe: cena oraz brak abonamentu (dokładniej: lojalki). Na razie na oku mam:

  • Aero2 z pakietami 30 GB za 30 zł (to na wypasie, starczyłoby i teraz, ale jak mówiłem, bez sensu zmiana cenowo) oraz 3 GB za 5 zł (brzmi bdb i jest spora szansa, że po porządkach dwa czy trzy takie wystarczą w zupełności)
  • Virgin Mobile z pakietami 3 GB za 15 zł oraz 10 GB za 25 zł (gdybym mieścił się w odpowiednio dwóch i jednym pakiecie). Niby drożej, ale jest szansa, że opędzę wszystko na kodach USSD plus dochodzi normalny numer głosowy, co może nie być głupie.

Aero2 – powiadamianie o konieczności wpisania CAPTCHA

Kolejny wyjazd na urlop i znowu dostęp do internetu sponsoruje Aero2. Oczywiście w wariancie z kompresowanym tunelem i proxy cache’ującym. Pewnie gdyby nie to rozwiązanie, to po prostu kupiłbym pakiet w Aero2, bo są naprawdę tanie, a jak testowałem przy okazji awarii netu u mojego ISP – śmiga to bardzo dobrze. Tak czy inaczej, gołe Aero2 jest nieprzyzwoicie wolne do WWW, po włączeniu ww. proxy śmiga na tyle dobrze, że stwierdziłem, że nie ma sensu kupować, tym bardziej, że nie pamiętam, czy aktywują od razu itp., a po włączeniu rozwiązania z tunelem wszystko działało. Przy czym najwięcej czasu przy włączaniu zajęło odszukanie wpisu z opisem.

W związku z użyciem ww. proxy WWW pojawia się jeden problem: nie działa przekierowanie i podstawowa przeglądarka nie wyświetla w takiej konfiguracji pytania o captchę. Zresztą, nawet gdyby przekierowanie działało, to mało ono pomaga przy czynnym korzystaniu z internetu, tj. nie przy biernym przeglądaniu, ale np. podczas pisania komentarza na jakiegoś bloga. Co prawda dzięki dodatkowi Lazarus do przeglądarki (polecam!) treść komentarza nie zginie nawet jeśli funkcja cofnij w przeglądarce nie działa i nastąpi przekierowanie, ale postanowiłem sobie sprawę ułatwić, przez napisanie prostego skryptu w Perlu, który sprawdzi dostępność zdefiniowanych hostów, a przy braku dostępności zadanej ilości wyświetli wyskakujące powiadomienie (xmessage). Przy czym sprawdza dość często (co 15 sekund), a jak brak łączności, to przerwa jest dłuższa.

Wyszło trochę ciekawiej, niż się spodziewałem. Wiadomo, że mocną stroną Perla są moduły, więc postanowiłem oprzeć się na dedykowanym module. Po pierwsze, okazało się, że Net::Ping domyślnie korzysta z TCP, nie ICMP, którego planowałem użyć, ale wydało się nawet lepsze. Niestety tylko do czasu, gdy okazało się, że przy podaniu hostów w formie domen i sprawdzaniu portu 80, za sprawą mechanizmu przekierowania Aero2 strona nadal jest dostępna. Tyle, że jest to strona mówiąca o konieczności wpisania captcha.

Rozwiązania są trzy. Pierwsze, to sprawdzanie zawartości strony, tj. czy nie pojawił się tekst mówiący o konieczności wpisania kodu captcha. Po pierwsze komplikuje to budowę skryptu, po drugie, zmniejsza jego uniwersalność (będzie działał tylko dla Aero2), po trzecie, możliwe, że przestanie działać przy jakiejś zmianie komunikatu. Drugie rozwiązanie, to podanie IP zamiast nazw domenowych. Przy takim rozwiązaniu przekierowanie dokonywane przez Aero2 nie będzie miało wpływu. Mniej czytelne i… zwyczajnie nie wpadłem w pierwszej chwili.

Zamiast tego postanowiłem skorzystać z wersji najoczywistszej i pierwotnie zamierzonej: wykorzystać jednak ICMP do sprawdzania osiągalności hostów. I tu największa niespodzianka: Net::Ping (ogólnie Perl) do wykorzystania ICMP wymaga uprawnień roota. Zdziwiłem się, ale po prostu tak jest i nie jest to feature Perla, a systemu – zwykli użytkownicy nie mają dostępu do tworzenia socketów. Z tego co znalazłem w sieci, polecane/najprostsze rozwiązanie na obejście tego to… wykorzystanie systemowego polecenia ping, do którego zwykle użytkownicy mają dostęp (SUID). Tak też uczyniłem.

Efekty można zobaczyć na mojej ulubionej sieci społecznościowej (hrhrhr), czyli w repo aero2-watch na GitHubie. Grupa potencjalnych użytkowników bardzo wąska (Linux + Aero2), ale może się komuś przyda…

Gdyby ktoś się zastanawiał, czemu klepię skrypty/siedzę na necie na urlopie to: lubię i zawsze to robię, poza tym, do porannej kawy jak znalazł; robię też inne, typowo urlopowe rzeczy; napisanie ~50 linii w Perlu trwa znacznie krócej, niż napisanie tego wpisu.

IPv6 w 2016 – zmiany w tunelach

Pierwszego kwietnia SixXS wysłał do swoich użytkowników maila, w którym poinformował, że

We are now fully stopping accepting signups and tunnel & subnet requests.

Czyli że ograniczają świadczenie usług do istniejących klientów i usług. Decyzja jest motywowana brakiem czasu oraz tym, że część ISP uważa, że darmowe tunele IPv6 są dla nich alibi do nie wdrażania IPv6 swoim klientom końcowym.

Unfortunately it seems a large number of ISPs think that our service is
a free pass for them to not deploy IPv6, as they direct their (paying)
customers who want IPv6 to our service.

Trudno się z tym nie zgodzić. Wdrożenia IPv6 są rzadkością, także – czy może raczej: zwłaszcza – w Polsce (tu ciekawa prezentacja z Orange z komentarza do innego wpisu, dzięki za podrzucenie).

Piszę o tym z dwóch powodów. Po pierwsze, gogoNET ogłosił, że się zamykają:

After 5 years we are closing down gogoNET on April 23, 2016.  Freenet6 will continue to work for some time but we can’t guarantee for how long.

Po drugie, umknęła mi dość istotna akcja pt. zadzwoń do ISP po IPv6. Jest też uruchomiona wiki, gdzie można wpisywać co udało się osiągnąć w sprawie IPv6.

Nie jestem do końca przekonany, czy rewolucję należałoby faktycznie zaczynać od ISP, ale faktem jest polscy dostawcy treści nadal nie dystrybuują treści po IPv6 (brak rekordów AAAA, źródło ww. prezentacja), a IPv6 w większości przypadków jest poruszane jedynie od święta, na spotkaniach branżowych typu PLNOG.

Warto w tym momencie przypomnieć (nieco zbyt ambitne IMO) stanowisko prezesa UKE, zakładające, że końcowi użytkownicy otrzymają publiczne adresy IPv6 od stycznia 2012 (stacjonarni, mobilni rok później). Tymczasem otwarte pozostaje pytanie kiedy nadejdzie era IPv6?

To co, „zadzwonimy” do ISP? Wpisujcie na wiki i w komentarzach, co usłyszeliście. A cudzysłów, bo może być zgłoszenie emailem czy zapytanie w social media. Kto wie, czy to ostatnie nie jest najlepsze…