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
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. IneaOrange
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.
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
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ą.
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
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.
W poprzedniej części było o genezie cyklu, sposobach pomiaru i najlepszym możliwym połączeniu, czyli bezpośrednio skrętką. Ze względu na zainteresowanie paru osób wynikami testów PLC, przeskakuję WiFi i przechodzę do wyników testów PLC.
Na testy dostałem TL-PA4010P kit. Z tego co widzę, w wyszukiwarce znajduje zarówno, że jest to AV500 jak i AV600, ale na opakowaniu było AV600, więc link jest prawdopodobnie prawidłowy. Do podłączenia podszedłem zupełnie laicko - z tego miejsca w mieszkaniu internet ma trafić do tamtego - zupełnie nie wnikałem w to jakie są fazy i czy po drodze są listwy.
Błąd. Zalecane jest wpięcie w ten sam obwód i bezpośrednio do gniazdka, z pominięciem listew zasilających. W związku z tym wykonałem kilka testów, w tym wpisie zajmę się tylko wynikami pierwszej, najgorszej topologii - jeden kontroler bezpośrednio w gniazdku, drugi za listwą z włącznikiem i wpiętej w nią listwą zwykłą. Od razu podaję link do wskazówek jak najlepiej podłączyć PLC. Wyniki z optymalnego połączenia są lepsze i będą w kolejnym wpisie, ten to bardziej "jakoś wpiąłem i tak działało".
Na wstępie miałem małe rozczarowanie, które rozwiewa dopiero lektura powyższego linka. AV600 oznacza 600 Mbps. I jakkolwiek przypuszczałem, że będzie to 300 upload, 300 download, to aby taki wynik osiągnąć, trzeba by mieć w urządzeniu port 1 GE. Tymczasem jak widać są tam porty 100 Mbps i taką prędkość linkowania się z urządzeniami osiągałem. Nie jest to dla mnie wielki problem, bo mój router także ma porty 100 Mbps, ale jeśli ktoś liczy na szybkie połączenie z NAS itp., to może się zawieść.
Samo podłączenie jest proste - sprowadza się do włożenia urządzeń w gniazdka, wpięcia ethernetu i naciśnięciu przycisku do parowania.
Wyniki z testu w niekomfortowych warunkach:
1. [ ID] Interval Transfer Bandwidth Jitter Lost/Total Datagrams [ 4] 0.00-60.00 sec 547 MBytes 76.5 Mbits/sec 1.195 ms 0/70059 (0%) [ 4] Sent 70059 datagrams
Jak widać nawet w tych niekomfortowych warunkach zestaw radził sobie przyzwoicie. Brak strat pakietów, niskie i stabilne opóźnienia. Widać wzrost czasu odpowiedzi w zależności od wielkości pakietu i jak sprawdziłem empirycznie pojawia się on przy rozmiarze pakietu między 900 a 1000 i jest to jedyna istotna różnica w stosunku do zwykłęgo ethernetu.
Niezła szybkość transmisji danych między urządzeniami nie wzbudziła mojej czujności; to, że coś chyba jest nie w porządku zacząłem podejrzewać dopiero po ostatnim teście, po podłączeniu jednego z końców kabla do routera. Dane z internetu pobierały się zwyczajnie wolno i... nie miało to pokrycia w testach syntetycznych. W tym momencie uprzedzę fakty i od razu napiszę, że przy zalecanym połączeniu wyniki w ostatnim teście były identyczne jak na kablu. Ale to już w kolejnym wpisie.
Na koniec słowo o zużyciu energii, ponieważ są to urządzenia aktywne. Podłączyłem urządzenie do watomierza. Bez podłączonego komputera pokazał 1,5W, po podłączeniu komputera i podczas transmisji danych 2,2-2,3W. Jeśli wyłączymy komputer, PLC po paru minutach przechodzi w stan uśpienia i pobiera wówczas 0,8W.
Wpis jest wstępem do serii mini testów, które przeprowadziłem lub przeprowadzę w najbliższym czasie. Chodzi o rozwiązanie kwestii dostępu urządzeń w domu do internetu i zapewnienia ich łączności pomiędzy sobą. Powodem było moje WiFi, które choć doprowadzone aktualnie do zadowalającej używalności, niekoniecznie było optymalne zarówno jeśli chodzi o stabilność połączenia, jak i oferowane przepływności czy opóźnienia. Na rynku istnieje kilka rozwiązań, które mają za zadanie pomóc w dostarczeniu sieci, niedawny wpis o PLC przypomniał mi, że kiedyś interesowałem się bardziej tematem, a technika poszła naprzód.
Szybkie pytanie na wewnętrznym forum firmowym czy komuś nie zalega parka PLC spotkała się z pozytywnym odzewem (uroki pracy w większej firmie, z otwartymi geekami - ciekaw jestem czego nie dałoby się znaleźć... ;-)) i okazało się, że nie tylko zalega chwilowo, ale są różnego typu, stąd pomysł na porównanie i podzielenie się wnioskami.
Nie ma to być test uniwersalny ani profesjonalny - robię go przede wszystkim dla siebie i w dostępnym mi środowisku (a np. typ ścian czy otoczenie może mieć kolosalne znaczenie dla WiFi, podobnie wygląda kwestia sieci elektrycznej dla PLC), mam jednak nadzieję, że uda się wyciągnąć jakieś wnioski ogólne i może komuś pomoże w wyborze rozwiązania.
O ile nie napisano inaczej, wykorzystywany jest firmware dostarczony z urządzeniami. Systemy nie są specjalnie tuningowane - ot, linuksowy default. Z oczywistych względów trudno mi wypowiadać się na temat stabilności poszczególnych rozwiązań w dłuższym okresie czasu.
Topologia sieci
Topologia sieci jest następująca: modem ISP (kablówka) w przedpokoju, podłączony ethernetem do routera. Router (obecnie TL-841) z wgranym OpenWRT/LEDE dostarcza internet reszcie urządzeń po WiFi. Przedpokój to w miarę centralny punkt w mieszkaniu, odległość od urządzeń końcowych (laptopy, smartfony) ok. 7 metrów, część urządzeń pracuje w 802.11n, część w 802.11g i tak zostanie - modernizacja czy wymiana końcówek są nieopłacalne.
Dla jasności: to działa od lat i w zasadzie wystarcza, jeśli chodzi o przepływność. Wystarczało i na 802.11g, gdy transfery (do mojego laptopa) wynosiły 15-18 Mbps (wg speedtest.net). Po zmianie routera na nowszy jest lepiej - 30 Mbps. Nadal jest to gorzej niż to, co oferuje operator (60 Mbps), ale w zupełności wystarcza do transferów "z zewnątrz". Zobaczymy jednak, czy są jakieś alternatywy i czego się spodziewać.
Ani mieszkanie w kamienicy, ani dość zaszumiony eter na 2,4 GHz, nie pomagają w dobrym działaniu WiFi, więc nieco gorzej wygląda sytuacja, jeśli chodzi o stabilność. Rzadko, bo rzadko, ale zdarzały się problemy (straty do routera, wzrost czasów odpowiedzi). Zwykle, w czasach gdy korzystałem z oryginalnego firmware producenta, wystarczał restart routera lub sprawdzenie jak wygląda sytuacja w eterze przy pomocy WiFi Analyzera i zmiana kanału na wskazany jako najlepszy (czyli najmniej używany).
Swoją drogą zmiana kanału na nieużywany jest najprostszym sposobem na poprawę zasięgu czy jakości WiFi, więc jeśli ktoś szuka odpowiedzi na pytanie jak poprawić sygnał WiFi, to zdecydowanie polecam zacząć od tego.
Pomiary
Wykonywane są cztery testy wewnętrzne, oraz ogólny test przy pomocy speedtest.net (beta, czyli bez Flash). Testy wewnętrzne wykonywane były w dwóch wariantach: krótkim (w założeniu ok. 60s) i długim (ok. 3600s).
iperf3 -u -b 0 -t 60 -c 192.168.10.126
iperf3 -t 60 -c 192.168.10.126
ping -i 0.1 -c 600 192.168.10.126
ping -s 1500 -i 0.1 -c 600 192.168.10.126
iperf3 -u -b 0 -t 3600 -c 192.168.10.126
iperf3 -t 3600 -c 192.168.10.126
ping -i 0.1 -c 36000 192.168.10.126
ping -s 1500 -i 0.1 -c 36000 192.168.10.126
speedtest.net
Jak widać jest to pomiar przepływności przy użyciu pakietów UDP, TCP oraz pomiar opóźnień przy pomocy ping ze standardową oraz maksymalną (MTU 1500) wielkością pakietu. Ostatni test to "realne" połączenie z internetem. Wykorzystywane serwery mojego ISP oraz Orange, który często był wskazywany jako najlepszy.
Za klienta służy mój laptop z Debianem, za sondę posłużyło Banana Pi (jedyny SoC z gigabitowym portem, który miałem pod ręką). W obu systemach wykorzystany iperf3. Pomiar nie był jedyną czynnością wykonywaną przez laptopa, ale - poza testami WiFi - był wykorzystany osobny interfejs, a obciążenie było typowe, bez ekstremów.
Dodatkowo mogą pojawić się uwagi, jeśli coś nieplanowanego podczas testów rzuci mi się w oczy.
Wyniki bazowe
Na wstępie spiąłem oba urządzenie kablem "na krótko" i uruchomiłem testy. Synchronizacja oczywiście 1 Gbps.
Jak widać bez większych niespodzianek - osiągnięte wyniki wynikają raczej z ograniczenia samego Banana Pi. Mimo to widać, że jest szybko, czasy odpowiedzi niskie i jest stabilnie.
[1] W przypadku pomiaru łącz topologia była nieco inna - laptop wpięty po kablu do portu routera (port 100 Mbps). W zasadzie dokładniej byloby wpiąć go bezpośrednio w modem kablowy, ale router jest stałym elementem zestawu w pozostałych topologiach... Dostawca internetu (Inea) deklaruje 60/10 Mbps.
Wczoraj nietypowo, bo ostatniego dnia roku zrobiłem jedną z rzeczy, które chodziły za mną od pewnego czasu, mianowicie wgrałem OpenWrt na domowy router. Ten sam, który kupiłem jakieś półtora roku temu. Późno, ale... jakoś nie miałem weny, a firmware producenta (aktualizowany kilka razy) w zasadzie działał.
Przynajmniej tak mi się wydawało. Jakiś czas temu przestała mi działać strona IKEA. Zarówno na komputerze, jak i telefonie. Oczywiście przyjąłem, że to wina ISP, bo strona zaczynała działać, jeśli korzystałem z netu przez GSM, zarówno na smartfonie, jak i na komputerze podłączonym do niego. A nie działała na żadnym z trzech różnych sprzętów i z tego co pamiętam nawet na ping nie odpowiadała.
Któregoś razu stwierdziłem, że sytuacja jest męcząca, więc sprawdzę o co chodzi dokładnie, czy to problem z routingiem, czy co. Ku mojemu zdziwieniu po odpaleniu sniffera okazało się, że jest komunikacja, nawet dwustronna. Tyle, że mocno szczątkowa. Uniewinniłem więc w myślach ISP i zacząłem męczyć IKEA, że może blokują moje IP z jakiegoś powodu.
Rozmowy były trudne, bo z jednej strony wyraźnie czułem, że się nie rozumiemy (no nie trawię tekstów od osób niezbyt technicznych "to musi być problem z przeglądarką", jak piszę, że na trzech różnych OS sprawdzam i że na innym łączu działa), z drugiej trochę rozumiem, skoro problem nie był po ich stronie. W każdym razie udało mi się uzyskać zapewnienie, że nie blokują.
Olśnienia doznałem jak włączyłem stronę IKEA w sumie przypadkowo i odruchowo na jeszcze innym, stareńkim komputerze w domu i... zadziałała. Zacząłem szukać różnic i znalazłem. Stareńki sprzęt łączył się po 802.11g, wszystkie nowsze po 802.11n. Oczywiście nie powinno mieć to żadnego znaczenia, ale... miało.
Winę za to ponosił prawdopodobnie firmware routera (zresztą jakaś beta - taki był najnowszy). Od tego czasu oficjalnie uznawałem, że muszę zaktualizować do OpenWrt.
Aktualizacja bardzo prosta i przyjemna - wystarczy przeczytać instrukcję dla odpowiedniej wersji hardware (v9) i wgrać odpowiedni firmware. Klikalne GUI, w sumie wszystko działa na pierwszy rzut oka, przynajmniej z podstawowych funkcji. Wydajność OK na pierwszy rzut oka. Jak zwykle polecam i zastanawiam się, czemu tak późno się zdecydowałem.
UPDATE: Ostatecznie, za sprawą komentarzy i wizyty na IRC na kanale traktującym o OpenWrt korzystam z LEDE. Może będzie o tym notka, ale w skrócie: nowszy soft i równie łatwa instalacja.
Serwis webhostingtalk.pl traktujący o polskim hostingu został kupiony przez Nazwa.pl. Więcej można przeczytać na Wykopie i na samym forum. Nie pisałbym o tym, ale mam przeczucie, że na skutek intensywnego zamiatania pod dywan różnymi sposobami link może zniknąć, więc w ramach mirrora będzie wpis.
Forum było jakie było, ranking też. Wiadomo, że przy swobodnej wypowiedzi ludzie zamieszczają różne opinie i że są to tylko opinie pojedynczych osób. Do których jak najbardziej mają prawo. Wiadomo też, że człowiek, żeby coś zrobić, potrzebuje bodźca. Niemniej, część firm posiadała wysokie oceny, a samo forum było neutralne i funkcjonujące na przejrzystych zasadach.
Tymczasem po kupnie, oceny Nazwa.pl zostały zmodyfikowane. Oczywiście na korzyść firmy. Z 49 opinii o Nazwa.pl istniejących we wrześniu 2016 zostało 31. Średnia ocena zmieniła się z 2,27 na 4,07. Co ciekawe, było 18 osób poleca i 31 nie poleca. Teraz jest 26 poleca, 5 nie poleca. Oczywiście nie sposób wykluczyć, że naturalnie pojawiło się w tym czasie 8 pozytywnych opinii, ale biorąc pod uwagę dotychczasowe ilości, jest to bardzo mało prawdopodobne. Bardzo prawdopodobna jest za to manipulacja, mająca na celu wybielenie Nazwa.pl.
Pojawił się też wątek wzrostu liczby domen, który powoduje, że Nazwa.pl wskoczyła na pierwsze miejsce w rankingu, ale to trochę bardziej skomplikowane, więc z braku czasu pomijam.
Wygląda, że szykuje się lekka rewolucja w mobilnej części internetu. Wersja testowa (canary) Chrome w wersji mobilnej wyposażona jest przez producenta w blokowanie inwazyjnych reklam. Zobaczymy jak to w praktyce wyjdzie, ale wygląda, że szykuje się zmiana zasad gry - de facto oznacza to kontrolowanie rynku reklam przez dostawcę przeglądarki, będącego przy okazji jednym z większych (o ile nie największym) graczy na rynku reklamy w sieci. Podobna zmiana jest zapowiedziana dla wersji desktopowej na początek roku.
Firefox Focus już w tej chwili ma podobne rozwiązanie - wbudowana blokada reklam i ochrona prywatności. Przy okazji, przetestowałem Focusa i wygląda on bardzo zachęcająco. W przeciwieństwie do Firefoksa jest lekki (~2 MB do pobrania) i działa żwawo. Czego o Firefoksie (no dobrze, rok temu, nie wiem jak teraz) powiedzieć się nie dało, więc na smartfonie korzystałem z Chrome. W każdym razie Focus domyślnie blokuje reklamy, nie ładuje zbędnych części strony i czyści historię, co czyni tradycyjne ad-trackery bezużytecznymi. Chwilę poklikałem - jest szybko, jest wygodnie, strony wyświetlały się OK. Polecam, jeśli ktoś nie potrzebuje na smartfonie tabów w przeglądarce. Niestety nie widzę wersji dla desktopa ani kodu źródłowego.
Mam mieszane uczucia jeśli chodzi o korzyści dla użytkowników. Z jednej strony strony mają być szansę lżejsze, nie zamulać urządzeń zbędnymi javascriptami czy animacjami i ładować się szybciej, zużywając mniej transferu. Z drugiej strony, szczególnie w przypadku Google, nie mam złudzeń. Natura nie znosi próżni, więc reklamy nadal będą. Ale od Google (lub za ich zgodą). A Google i tak ma śmieci w reklamach AdSense. Podobnie ze śledzeniem - może strony nie będą w stanie tego robić, ale przeglądarka jak najbardziej... No i może historia zatoczy koło - albo płatna przeglądarka, albo wyświetlanie reklam? To już oczywiście było, w czasach płatnej wersji Opery.
W każdym razie właściciele stron stracą (znowu) trochę wolności.
Niedawno na blogu sprawnymarketing.pl pojawił się wpis o tym, jak rzekomo Zenbox stosował black hat SEO. Sprawa okazała się znacznie głębsza, szersza i ciekawa, niż na pierwszy rzut oka wyglądał. W różnych wymiarach, od technicznych, po prawne.
Przede wszystkim, niezaprzeczalnym faktem jest, że niektóre strony (raczej: większość) hostowane na zenbox.pl, pokazywały co innego przy wejściu przez HTTP, a co innego przez HTTPS. Jak pokazują zamieszczone w ww. wpisie zrzuty ekranu, narzędzia do badania SEO zauważały te linki. Raczej słusznie, bo wbrew temu, co twierdzi zenbox.pl, strony te nie zostały zignorowane przez Google, lecz normalnie zaindeksowane, co pokazuje poniższy zrzut ekranu:
Szybko okazało się, że zenbox.pl nie jest jedynym hostingiem, który działa w ten sposób, a winny jest prawdopodobnie panel DirectAdmin, którego domyślna konfiguracja powoduje pokazywanie "zaślepki" przy braku podpiętego certyfikatu SSL. Potem było już tylko weselej, bo w dyskusji na Wykopie niektórzy sugerowali, że w zaślepkach powinien być w linkach atrybut nofollow. Uważam, że akurat brak nofollow świadczy w tym przypadku na korzyść zenbox.pl i braku celowego działania - gdyby ktoś zawracał sobie głowę atrybutami czy anchor text (a są i tacy), to znaczy, że pomyślał o pozycjonowaniu.
Jeszcze bardziej dziwi mnie skupienie się na SEO i ominięcie sedna sprawy: nie chodzi o - celowe lub nie - wprowadzenie w błąd Google. Przede wszystkim mamy do czynienia z podmianą treści na stronie zamieszczonej w określonej domenie. Wątpię, by właściciele domen mieli wiedzę, że taka podmiana miała miejsce. Jeszcze bardziej wątpię w ich zgodę na takie działanie.
HTTPS zamiast HTTP niewiele tu zmienia - oczywiście jest możliwość serwowania różnych treści w zależności od protokołu, podobnie jak strona z przedrostkiem www (de facto subdomena) z technicznego punktu widzenia może kierować zupełnie gdzie indziej, niż domena bez takiego przedrostka, ale przyjęte jest, że kierują w to samo miejsca. W przypadku HTTPS jest to IMO wręcz oczywiste.
Pamiętajmy też, że strony WWW, zwłaszcza popularniejsze blogi, potrafią po prostu sprzedawać miejsce na reklamę na stronie. Wydaje mi się, że w przypadku takich blogów wykazanie szkody w sądzie byłoby trywialne. Dlatego podejście zenbox.pl do sprawy mnie dziwi. Jak widać w komentarzach na blogu, mamy kolejno:
straszenie "na takie działania godzić się nie można i zrobimy wszystko aby takie akcje miały konsekwencje"
negacja, najpierw problemu w ogóle (screenshot w ww. wpisie), potem wpływu "działania nie mają wpływu na pozycję stron klientów ani wpływu na pozycję witryny zenbox.pl"
przyznanie istnienia problemu "wspomnianego problemu nie doświadczyli" i w końcu podjęcie działań (zmiana konfiguracji, mailingi)
Wydaje mi się, że znacznie bardziej na miejscu byłaby analiza sytuacji, podziękowanie za zwrócenie uwagi, naprawienie problemu (poprawa konfiguracji) i przeproszenie klientów.
Cała sprawa ma jeszcze jeden ciekawy aspekt. Wydaje mi się, że największy błąd popełniło... Google, które podmienioną treść na stronie jak widać łyka jak pelikan. Mimo ewidentnych błędów HTTPS (certyfikat nie pasuje do domeny), które m.in. przed taką podmianą miały chronić. W czasach, gdy każda domena może mieć rozpoznawany przez przeglądarki certyfikat SSL za darmo (oczywiście chodzi o projekt Let's Encrypt) strony za niepasującymi, wygasłymi i self signed certyfikatami powinny po prostu być ignorowane.
Prawidłowa konfiguracja to IMHO ta sama treść dostępna po HTTP i HTTPS. Czy to za sprawą odpowiedniego przekierowania (to sensownie uda się tylko z HTTP na HTTPS...), czy też - zwł. na shared hostingu - pod certyfikatem hostingodawcy, jeśli domena nie ma własnego.
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...
Parę dni temu do przeglądarek dostępnych na rynku dołączył nowy gracz - Vivaldi. A w zasadzie nie tyle dołączył, co ukazała się wersja 1.0. Oczywiście zainstalowałem i się pobawiłem. Jest parę ciekawych ficzerów, które przypadły mi do gustu, ale nie wszystko mi się podoba.
Pierwszą rzeczą, którą widzimy po instalacji i uruchomieniu przeglądarki, jest tzw. wizard. Można wybrać schemat kolorów, rozmieszczenie belki z tabami i... obrazek, który będzie służył za tło przy speed dial. Wszystko oczywiście można zmienić później w ustawieniach, ale uważam, że taka szybka i łatwo dostępna personalizacja to miła rzecz. Poza nieszczęsną tapetą dla speed dial - po co tam komu tapeta? Przecież to potrzebne jak tapeta w systemie - widzę ją przez parę sekund po uruchomieniu i tyle.
Kolejną rzeczą, która zwróciła moją uwagę, jest pasek postępu - pokazuje ilość pobranych danych, postęp ładowania w postaci przesuwającego się paska i chyba ilość obrazków na stronie. W każdym razie kiedyś któraś przeglądarka już tak miała i uważam to za lepsze rozwiązanie, niż niewiele mówiące kręcące się kółeczko.
Vivaldi ma chyba pewne ambicje do zastąpienia systemu operacyjnego. Jest i wspomniana tapeta, jest wbudowany w przeglądarkę klient poczty, jest możliwość tworzenia notatek, no i w końcu są panele, czyli tak naprawdę funkcjonalność kafelkowego managera okien. O ile do pierwszych dwóch podchodzę zdecydowanie negatywnie, to do tworzenia notatek mam mieszane uczucia. Za to panele nawet mi się podobają - jest to coś w stylu mini strony WWW, domyślnie w wersji mobilnej, dostępna na każdej zakładce. Po prostu podział powierzchni okna na dwie części. Przy obecnych szerokich monitorach może zdawać egzamin, a w panelach można umieścić np. social media, które i tak nie wymagają wiele miejsca.
OgólnieVivaldi bardzo przypomina mi Operę. Jak się okazało, słusznie, bo projekt tworzą ludzie, którzy kiedyś pisali Operę. Jest parę różnic, przede wszystkim większy nacisk na prezentację. Jest parę innowacji, więc przypuszczam, że - podobnie jak niegdyś Opera - Vivaldi zdobędzie pewne grono gorących zwolenników. Wielkiej popularności nie wróżę, ale zdecydowanie warto spróbować. Ja planuję od czasu do czasu używać, być może Vivaldi zostanie moją przeglądarką do social mediów.
Na koniec słowo o obsługiwanych systemach operacyjnych - Vivaldi dostępna jest dla Maców, Windows (wersje 32 i 64 bit) oraz Linuksa (pakiety deb i rpm w wersjach 32 i 64 bit). Twórcy nie chwalą się adresami repozytoriów, ale są one dostępne i dodawane automatycznie po instalacji (bez ostrzeżenia, nie lubię). Dla porządku, dla gałęzi stabilnej przeglądarki i Debiana wpis dla sources.list to:
deb http://repo.vivaldi.com/stable/deb/ stable main
Dawno nie było notki. W sumie to chyba jeszcze nie było tak długiej przerwy między wpisami. Nie dlatego, że nic się nie dzieje, bo się dzieje aż za dużo, ale po pierwsze jakaś blokada przed jakimkolwiek pisaniem (nie tylko na blogu), po drugie, jakiś taki wypompowany z pracy przychodzę, że mi się nie chce już pisać, nawet jak są ciekawe tematy. No to może na przełamanie...
Ostatnio jeden z czytelników przysłał maila z pytaniem: czy jest możliwość zmodyfikowania TOR-a tak by zawsze przydzielał polski adres IP? Już zacząłem odpisywać, że byłoby to bez sensu, bo przecież wybór exit node tylko z jednego kraju znacznie zmniejsza poziom anonimowości (nie rozwijając: i łatwiej podsłuchać, i łatwiej namierzyć korzystającego), ale... coś mnie tknęło i zacząłem drążyć temat, bo patrząc na to z drugiej strony, do pewnych usług dostęp może być tylko z pewnych lokalizacji geograficznych.
Podrążyłem i - ku memu niewielkiemu zdziwieniu - okazuje się, że można wybrać kraj, czyli np. użyć sieci Tor do obejścia blokady regionalnej. Co lepsze, można wybrać zarówno konkretny exit node, z którego chcemy korzystać (lub ich zbiór), jak i sam kraj (lub zbiór krajów).
Za każdym razem zmiany należy wprowadzić w pliku torrc (pod Debian/Ubuntu: /etc/tor/torrc) i przeładować Tora. Podobno działa, mi na TAILS nie udało się wyedytować konfiga i uruchomić ponownie Tora (ale nie drążyłem specjalnie).
Źródła (i więcej informacji, w tym lista kodów krajów):
Odwieczny problem administratorów sieci to mogę sprawdzić trasę od siebie do danego hosta, ale jak wygląda w drugą stronę? Próbą rozwiązania tego zagadnienia były looking glass, pozwalające na wykonanie od określonego operatora ping czy traceroute. Czasem potrzeba jednak czegoś więcej - sprawdzenia resolvowania DNS, zbadanie stabilności transferu itp. Ogólnie przydałby się shell.
Projekt NLNOG RING jest odpowiedzią na to zapotrzebowanie. Opiera się na prostej zasadzie wzajemności: udostępniamy maszynę wirtualną (administrowaną przez opiekunów projektu) dla projektu, w zamian otrzymujemy dostęp do pozostałych maszyn projektu, w różnych częściach świata i - co ważniejsze - w wielu różnych ASN.
Wymagania co do maszyny są naprawdę niewielkie - 1 GB RAM, 20 GB dysku, 1 core 64bit procesora, adresy IPv4 oraz IPv6. Musi stać w naszym AS i na naszej adresacji. Myślę, że w tej chwili większość operatorów, nawet niewielkich sieci radiowych jest w stanie sprostać. Pozostałe wymagania stawiane organizacji (usługa jest kierowana do firm) to m.in.: bycie operatorem sieciowym, własne ASN, prefiksy IPv4 i IPv6, zgoda organizacji na uczestnictwo w projekcie.
Możliwe jest zarówno połączenie po SSH do wybranej maszyny, jak i wykonywanie, przy pomocy dostępnych narzędzi, operacji na wszystkich maszynach projektu jednocześnie. Generalnie potrafi bardzo pomóc w diagnostyce.
Projekt działa od wielu lat, ale dziś dowiedziałem się, że nawet w środowisku sieciowym niekoniecznie jest znany, więc uważam, że warto przypomnieć o jego istnieniu. Teoretycznie istnieje ryzyko nadużyć, ale użytkownikami są administratorzy sieci, polityka to zero tolerancji dla nadużyć i nie kojarzę jakichkolwiek problemów związanych z udostępnianiem maszyny. Korzystałem, polecam.
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.471s
user 0m0.000s
sys 0m0.772s
RX 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.938s
user 0m0.000s
sys 0m0.904s
RX 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ł.
