Szybki IPv6
Zadziwiło mnie... porównanie czasów pingów dla IPv4 i IPv6. IPv4 działa po sieci z maskaradą:
% time ping -c 4 google.pl
PING google.pl (66.102.9.104) 56(84) bytes of data.
64 bytes from 66.102.9.104: icmp_seq=1 ttl=241 time=62.2 ms
64 bytes from 66.102.9.104: icmp_seq=2 ttl=241 time=61.4 ms
64 bytes from 66.102.9.104: icmp_seq=3 ttl=241 time=61.3 ms
64 bytes from 66.102.9.104: icmp_seq=4 ttl=241 time=61.3 ms
--- google.pl ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 2999ms
rtt min/avg/max/mdev = 61.381/61.639/62.299/0.456 ms
Jak widać czas rzędu dziesiątków milisekund. Przy IPv6 natomiast (ten sam server, IPv6 zwykłe):
% time ping6 -c 4 google.pl
PING google.pl(3ffe:abcd:1234:9876::480e:dd68) 56 data bytes
64 bytes from 3ffe:abcd:1234:9876::480e:dd68: icmp_seq=1 ttl=254 time=0.302 ms
64 bytes from 3ffe:abcd:1234:9876::480e:dd68: icmp_seq=2 ttl=254 time=0.392 ms
64 bytes from 3ffe:abcd:1234:9876::480e:dd68: icmp_seq=3 ttl=254 time=0.395 ms
64 bytes from 3ffe:abcd:1234:9876::480e:dd68: icmp_seq=4 ttl=254 time=1.03 ms
--- google.pl ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3000ms
Długo zajmuje czas zapytania DNS (totd przekierowuje do binda otwartego na lo, który pyta się serwera neostrady).
Dodanie wpisów typu forwarder przed oznaczającymi binda nie skróciło czasu zapytań - była to przedwczesna optymalizacja.
Komentarze do wpisu
Możesz śledzić odpowiedzi poprzez kanał RSS. Możesz dodać komentarz lub zostawić ślad (trackback) ze swojego bloga.
Uzytkownik
Zapomniałem dodać IPv6 idzie przez 6to4.
14 października 2006, 10:52:44
Uzytkownik
Dziękuje Darkjamesowi za zwrócenie uwagi, że prefix tunelu 6to4 powinien być 2002::
14 października 2006, 11:20:24
Dodaj komentarz