Googleblind
Fascynuje mnie pozycja, którą Google wypracowało sobie w ostatnich latach. Firmie tej udało się osiągnąć sytuację, w której umieszczenie znaczku Google na produkcie powoduje wyłączenie zdolności krytycznej jego oceny u znacznej części użytkowników i potencjalnych użytkowników. Sam korzystam z kilku ich produktów, bo dobrze spełniają swoją rolę. Z kilku innych nie korzystam, bo są kiepskie lub nie oferują żadnej wartości dodanej w porównaniu z tymi narzędziami/produktami/usługami, z których korzystam obecnie. Oczywiście pomijając znaczek Google. Dokładnie z tego powodu nie skorzystam (na razie) z Google Public DNS.
Jedną z zalet GDNS ma być szybkość jego działania. Trzeba przyznać, że koncepcje wykorzystane w GDNS są ciekawe, na przykład prefetching. Rzeczywiście, zastosowanie tych pomysłów może przyspieszyć działanie DNS, a co za tym idzie spowodować, że strony będą ładować się szybciej. Zwłaszcza te, które ładują dużo treści z różnych domen, w związku z czym w procesie ich ładowania DNS wykorzystywany jest intensywnie.
Jest jednak druga strona medalu. Gdzie są umieszczone serwery GDNS? Odpowiem – dość daleko (w sensie trasy). Nawet zakładając, że nazwa DNS znajduje się już w cache tych serwerów (bo ktoś kiedyś się o nią odpytał i prefetching działa), pakiet najpierw musi dojść do serwerów GDNS, a później jeszcze z nich wrócić... A wygląda to mniej więcej tak:
; <<>> DiG 9.3.2 <<>> wampir.mroczna-zaloga.org @8.8.8.8 ; (1 server found) ;; global options: printcmd ;; Got answer: ;; –>>HEADER<<– opcode: QUERY, status: NOERROR, id: 1681 ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION: ;wampir.mroczna-zaloga.org. IN A
;; ANSWER SECTION: wampir.mroczna-zaloga.org. 3594 IN A 89.161.205.110
;; Query time: 46 msec ;; SERVER: 8.8.8.8#53(8.8.8.8) ;; WHEN: Sat Dec 05 10:18:12 2009 ;; MSG SIZE rcvd: 59
Szybko? Może i tak, ale gdy zestawi się to z moim “prywatnym” serwerem DNS (zwykły BIND na OpenBSD), wydajność GDNS wcale nie jest zachwycająca:
;; Query time: 15 msec ;; SERVER: 172.16.0.254#53(172.16.0.254) ;; WHEN: Sat Dec 05 10:20:34 2009 ;; MSG SIZE rcvd: 170
Owszem, jest widoczna różnica w przypadku, gdy nazwy nie ma jeszcze w cache. W tym przypadku cache BIND jest jeszcze puste, serwer DNS nie wie jeszcze kogo pytać o daną domenę:
;; Query time: 312 msec ;; SERVER: 172.16.0.254#53(172.16.0.254) ;; WHEN: Sat Dec 05 10:21:21 2009 ;; MSG SIZE rcvd: 154
Zapytanie o nieznaną jeszcze nazwę, dla której nazwy serwerów NS są jednak znane jest już znacznie szybsze, szybsze nawet od GDNS znającego już wcześniej odpowiedź:
;; Query time: 31 msec ;; SERVER: 172.16.0.254#53(172.16.0.254) ;; WHEN: Sat Dec 05 10:26:55 2009 ;; MSG SIZE rcvd: 189
Nawet Google nie pokona wartości, która nazywa się round-trip time. A tu ta wartość pojawia się kilka razy. Nie tylko między klientem i serwerem, ale również między serwerami Google, a serwerami DNS, które obsługują dane domeny. Tak, to drugie wystąpienie RTT może być skutecznie niwelowane przez mechanizm prefetch , ale to pierwsze (klient-serwer GDNS) już nie.
Gdybym mógł postawić sobie GDNS na swoim obszczymurku , może bym z niego korzystał. Może i gdyby dostawcy internetu u siebie uruchomili GDNS, ich klienci odczuliby różnicę. W konfiguracji obecnej, czyli serwery GDNS tam , klienci tu , podejrzewam, że w większości wypadków zysku wydajności nie ma wcale, a może być nawet wprost przeciwnie – zamiast poprawy wydajności, jej spadek. Ale to nie ważne, przecież jest znaczek Google w nazwie...
Oryginał tego wpisu dostępny jest pod adresem Googleblind
Autor: Paweł Goleń