Łatwe sprawdzanie szybkości internetu mobilnego

Zwykle do sprawdzania szybkości działania internetu korzystałem ze Speedtest.net rozwiązania popularnego i… takiego sobie. Wady są dość oczywiste – dużo reklam, na telefonie (Android) chyba nie udało mi się skorzystać, bo strona nachalnie promuje appkę.

Dziś dowiedziałem się o mającej łatwą do zapamiętania nazwę stronie Fast.com. Serwis dostarcza Netflix. Nie ma reklam, wygląd jest minimalistyczny i wszystko bez problemu działa na przeglądarce Firefox Focus pod Androidem. Przy okazji, po wybraniu show more info ładnie pokazuje nie tylko opóźnienia i prędkość uploadu, ale także ilość przesłanych danych podczas testu. Uruchomienie testu w obie strony to jakieś 50-100 MB przesłanych danych (na WiFi). Pierwsze wrażenie bardzo pozytywne.

Przyspieszyć hashcata

Na blogu nfsec.pl pojawił się wczoraj wpis dotyczący crackowania hashy md5crypt[1]. Spojrzałem na sprzęt i moją uwagę przykuła wydajność karty Intela Intel(R) Iris(TM) Graphics 650:

Hashmode: 500 - md5crypt, MD5 (Unix), Cisco-IOS $1$ (MD5) (Iterations: 1000)
Speed.#2.........: 423.2 kH/s (53.30ms) @ Accel:256 Loops:250 Thr:8 Vec:1

Mam Intel Corporation Skylake GT2 [HD Graphics 520] widzianą jako Intel(R) Gen9 HD Graphics NEO i hashcata w wersji v5.1.0 (binarka, stable), na potrzeby zabaw z platformami CTF, o których wspominałem niedawno. Część zadań wymaga użycia brute force, i chociaż nie było do tej pory okazji wyjść poza coś typu gotowy słownik, to pewnie jeszcze się przyda. Rzecz w tym, że moja karta jest znacznie wolniejsza:

Hashmode: 500 - md5crypt, MD5 (Unix), Cisco-IOS $1$ (MD5) (Iterations: 1000)
Speed.#1………: 156.1 kH/s (76.04ms) @ Accel:256 Loops:250 Thr:8 Vec:4

Rozumiem, że to inny sprzęt i inny system (u mnie Debian w wersji unstable), ale postanowiłem podrążyć temat.

Po pierwsze, zauważyłem, że mam starsze pakiety OpenCL dla Intela. Aktualizacja nie przyniosła co prawda poprawy wydajności, ale na innym sprzęcie (Ubuntu) była w ogóle niezbędna do poprawnego działania hashcata – bez najnowszej wersji md5crypt w ogóle nie dawał się tam łamać.

Po drugie, użyłem hashcata w wersji z GitHub (wersja development) v5.1.0-951-g6caa7869 (również niezbędny na Ubuntu do poprawnego łamania md5crypt). Efekt okazał się całkiem przyjemny:

Hashmode: 500 - md5crypt, MD5 (Unix), Cisco-IOS $1$ (MD5) (Iterations: 1000)
Speed.#1………: 232.7 kH/s (51.57ms) @ Accel:256 Loops:250 Thr:8 Vec:4

Niemal połowę szybciej. Warto aktualizować soft i sterowniki, nawet, jeśli wersja wygląda na tylko nieznacznie nowszą. Co ciekawe, przyrost wydajności jest tak duży tylko dla niektórych algorytmów, w tym md5crypt. Inne, jak zwykłe md5 różnice mają jedynie symboliczne:

Hashmode: 0 - MD5
Speed.#1………: 476.6 MH/s (51.75ms) @ Accel:128 Loops:32 Thr:256 Vec:4

Hashmode: 0 - MD5
Speed.#1………: 493.4 MH/s (50.09ms) @ Accel:512 Loops:128 Thr:16 Vec:4

Tyle tym razem – trochę o instalacji i uruchomieniu hashcata, trochę o przyspieszeniu na poziomie softu. Mam świadomość, że to trochę takie wyścigi ślimaków, ale… jak się nie ma co się lubi, to się lubi co się ma. Może kiedy indziej będzie o doborze parametrów i budowie skutecznych słowników do crackowania hashy przy pomocy hashcata.

[1] Ładnie po polsku, owinięte w bawełnę, nazywa się to audyt haseł. Ewentualnie, mniej owijając w bawełnę, łamanie funkcji skrótu haseł. Zostanę jednak przy brzydkiej, potocznej wersji angielskiej.

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 zbierane z dłuższego okresu, choć z mniejszą rozdzielczością. Czyli patrzeć na trendy powiedzmy kwartalne, kosztem podatności na błąd pojedynczego pomiaru. Ale w dłuższym okresie i tak się to uśredni.

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!

HTTP czy HTTPS?

Wszystko zaczęło się od tego, że Wampiryczny blog zmienił sposób dostępu, wymuszając HTTPS. Skomentowałem pół żartem, pół serio. Dostałem odpowiedź w komentarzu, przeczytałem i trochę mi się włos zjeżył na głowie. Bo zdecydowanie o zużyciu energii ktoś nie pomyślał. Jak jestem zwolennikiem udostępniania treści po HTTPS i bardzo sobie ostrzę zęby na projekt letsencrypt.org, tak uważam, że wybór powinien być po stronie odbiorcy, a jedynie miejsca, gdzie są przesyłane wrażliwe dane (np. hasła) powinny mieć wymuszony HTTPS.

Postanowiłem zrobić mały test, czyli pobrać stronę po HTTP i zobaczyć, ile zostało pobranych bajtów (i w jakim czasie), a następnie to samo dla HTTPS. Jako system został użyty base system Debiana, uruchomiony w wirtualce (KVM), uruchomionej na laptopie. Jako stronę serwującą dokładnie to samo po HTTP i HTTPS dobrzy ludzie podrzucili stronę OVH. Google.com na ten przykład serwowało wgetowi nieidentyczną zawartość.

HTTP

$ ifconfig eth0 | grep "RX bytes" ; time for NUM in {1..20}; do wget --no-check-certificate -qO - http://ovh.pl/ >> out_http.txt; done ; ifconfig eth0 | grep "RX bytes"RX bytes:11251203 (10.7 MiB)  TX bytes:495042 (483.4 KiB)real    0m9.471suser    0m0.000ssys     0m0.772sRX bytes:14173253 (13.5 MiB)  TX bytes:583042 (569.3 KiB)

Jak widać wysłano 88000 bajtów, odebrano 2922050.

HTTPS

$ ifconfig eth0 | grep "RX bytes" ; time for NUM in {1..20}; do wget --no-check-certificate -qO - https://ovh.pl/ >> out_https.txt; done ; ifconfig eth0 | grep "RX bytes"RX bytes:14173313 (13.5 MiB)  TX bytes:583102 (569.4 KiB)real    0m13.938suser    0m0.000ssys     0m0.904sRX bytes:17387531 (16.5 MiB)  TX bytes:739702 (722.3 KiB)

Z kolei tutaj wysłano 156600 bajtów, a odebrano 3214218.

Podsumowując: HTTPS w tym teście był wolniejszy o 46%, przy korzystaniu z niego wysłane zostało o 78% więcej danych, a odebrano o blisko 10% więcej danych. Efekt, czyli pobrana zawartość jest dokładnie taka sama. Oczywiście ww. narzut procentowy będzie się różnił w zależności od rozmiaru pliku wynikowego, ale jak widać narzuty są spore.

Do prędkości bym się zbytnio nie przywiązywał, bo o ile za brak ruchu na wirtualce ręczę, to na lapku różne rzeczy się dzieją, choć generalnie idluje, a sam lapek zapięty po wifi. Niemniej, pomiarów było kilka, także dla mojej strony ze stanem rowerów na stacjach Nextbike. Wyniki podobne – wolniej i więcej przesłanych danych po HTTPS.

Dlatego przerażają mnie zmiany planowane zmiany w Chromium powodujące, że strony po odwiedzane po HTTP będą oznaczone jako niezaufane. Podobnie robi Mozilla. Rozumiem, że jeśli wysyłamy dane, zwł. z kamery czy mikrofonu, ba, jeśli cokolwiek wprowadzamy na stronie czy wysyłamy pliki. Ale sam odbiór? Trochę przesada. Tym bardziej, że istnieją narzędzia, do wymuszania HTTPS, jeśli ktoś ma taką potrzebę – choćby HTTPS Everywhere.

Zupełnie nie rozumiem podejścia Google do wykorzystania HTTPS jako sygnału rankingowego. Zdobycie certyfikatu nie jest problemem, a jak ruszy Let’s Encrypt, to już w ogóle. Znaczy rozumiem ideę, ale do sprawdzenia autentyczności, wystarczyłoby np. pobierać po HTTPS sitemap.xml. Czy tam robots.txt. Czy stronę główną.

Trochę zastanawiam się, po co ta nagonka. I mam wrażenie, że nie tyle o bezpieczeństwo chodzi (dobry pretekst, fakt), a o pieniądze. O ile certyfikaty tanieją i będą za darmo (ale czy wszystkie?), o tyle pewnie jest to pretekst do kolejnego wzrostu narzutu na ruch, nowych usług (terminowanie SSL na proxy czy CDN), wymiany pudełek itp. Nawiasem, jest nawet strona zachwalająca, jaki to TSL jest szybki, na współczesnych procesorach i nowym oprogramowaniu. Tyle, że nie. Ale nie omieszkam sprawdzić (na najnowszym Debianie), jak tylko Let’s Encrypt ruszy…

Zachęcam do polemiki. Polecenia podałem wyżej, można samemu sprawdzić, podać kontrprzykłady, pochwalić się konfiguracją z minimalnym narzutem na wersję szyfrowaną.

UPDATE: Poprawione polecenia (było dwa razy HTTP, zamiast raz HTTP i raz HTTPS). Bug przy przeklejaniu, wyniki są i były prawidłowe. W sumie jestem rozczarowany, że tak długo nikt tego nie zauważył.