Tag: internet

Opublikowane w

SLA 99,5% – so what?

SLA na poziomie 99,5% robi wrażenie, prawda? Przy okazji dyskusji pod wpisem u Boniego poleciało 99.5% jako synonim jakości (czegoś tam). Co z kolei skłoniło mnie do sprawdzenia, jak to się ma do danych dotyczących dostępności łącza, które wystawiam przy pomocy PUM. No i w skrócie: 99,5% dostępności w skali miesiąca to żaden wyczyn.

Na początek disclaimer: nie jest to wyraźnie napisane w FAQ, ale z tego co się dowiedziałem od autorów/supportu. Uptime Robot w wersji darmowej nie zlicza (poprawnie?) uptime dla okresu powyżej jednego miesiąca. Co niestety nie przeszkadza mu zwracać jakichś wartości dla okresów powyżej 30 dni.

The Free Plan can return uptime ratios back to 1 month due to the limit of the logs kept. The Pro Plan supports back to 1 year. And, the alltimeuptimeratio variable in the API currently returns 1-month uptime (and it’ll be removed from the APIv2).

I jak widać z powyższego, All uptime to tak naprawdę, w przypadku planu darmowego, uptime dla poprzedniego miesiąca.

Spójrzmy na the domek. Komputer Linuksem, dokładnie, Seagate Dockstar robiący za router, więc trochę embedded w porównaniu z typowym PC, czyli bardziej niezawodny. Za to z dyskiem w kieszeni USB, bez jakiegokolwiek podtrzymania prądu przy pomocy UPS. Łącze przez wiekowy modem USB, 3rd party dostawca over linia TPSAOrange (BSA).

Aby było weselej: połączenie resetowane raz dziennie, skrypt podnoszący/sprawdzający uruchamiany co 4 minuty , a PPPoE trochę wstaje…

I cała ta rzeźba, łącznie z przerwami po stronie 3rd party usługodawcy, Orange, dostawcy monitoringu (czyli Uptime Robot), zwłoką przy odświeżaniu dyndns (monitoring jest po domenie) i problemami w globalnym internecie daje radę. Generalnie, bo oczywiście są miesiące, że nie da.

SLA 99,5% my ass… 😉

[1] Nie pamiętam już, czemu tak, zdaje się, że musiał mieć chwilę na sprawdzenie albo ubicie pppd. Albo nie chciało mi się pisać obsługi lockfile’a, bo parę minut przerwy w nocy i tak jest pomijalne w tym zastosowaniu…

Opublikowane w

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ł.

Opublikowane w

PUM działa

Doprowadziłem PUMa do takiej postaci, że daje się używać i generuje w miarę strawny i używalny HTML. Przykładowy wynik działania. Oczywiście wszystko jest na GitHubie, który mnie drażni ostatnio, bo pisze (w związku z zupełnie innym projektem, notka leży w szkicach, których coraz więcej, upał taki, że nawet pisać się nie chce), że Can’t automatically merge. Don’t worry, you can still create the pull request. No niby mogę, ale autor upstreamu umiarkowanie nalega na wyprostowanie (się nie dziwię), a ja szczerze mówiąc nie widzę, co mu przeszkadza w automatycznym merge. Pewnie jakbym wiedział, to łatwiej byłoby mi pomóc gitowi ogarnąć się… W każdym razie będę doszkalał się z gita.

Wynikami nie ma się co sugerować zbytnio – sporo hostów zostało dodanych bardzo niedawno, stąd 100%. Jest też rozbieżność pomiędzy wynikami dla All time i jednego roku. Nie bug w skrypcie, tylko tak zwraca dane polecany niedawno Uptime Robot. Zgłosiłem buga i (szybka!) odpowiedź trochę martwi:

The Free Plan can return uptime ratios back to 1 month due to the limit of the logs kept. The Pro Plan supports back to 1 year.

And, the alltimeuptimeratio variable in the API currently returns 1-month uptime (and it’ll be removed from the APIv2).

Mój nos mówi mi, że idzie monetyzacja i z fajnej, darmowej usługi może być wkrótce coś niezbyt fajnego/używalnego. Ale może to tylko moje czarnowidztwo.

Poza tym, po niedawnej awarii (jak ktoś nie zna serwisu downdetector.pl do określania, czy jest awaria u dostawcy, to dość entuzjastycznie polecam) u mojego ISP wylądowałem za NAT (jak wielu innych abonentów). Po telefonie przywrócony publiczny IP, ale od tego czasu dla hosta w domu Uptime Robot pokazuje dziwne rzeczy – host znika, pojawia się, znowu znika… Podejrzewałem jakiś autosuspend w momencie, gdy żadne urządzenie nie jest aktywne, ale raczej nie o to chodzi. IP się nie zmienia, więc nawet w przypadku problemów z odświeżaniem dyndns nie powinno rzutować (ale nie wykluczę…). Problemy z routingiem? Może się zbiorę, ustalę IP z którego Uptime Robot monitoruje i zdiagnozuję… Póki co po prostu pauza, aby się śmieci nie generowały.

UPDATE Odnośnie problemów z git – stupid me, czyli niewiedza w temacie gita i podchodzenie do problemu od zadniej strony. Swoją drogą, namierzenie/szukanie rozwiązaniach po objawach mogłoby trwać długo… Przyczyna to złe forkowanie. Na szczęście GitHub ma świetną pomoc. Robienie forka repo git, następnie synchronizacja forka i wszystko działa.